SIze of Pi4 /boot

The Raspbian updates complain that my /boot partition
is too small, Pi4 support dropped.
How large must /boot be for Pi4?
--

-TV
Reply to
Tauno Voipio
Loading thread data ...
It "should" be set to a reasonable (correct) size when you copy the image to the SD card (etcher, dd or similar). However, I have found the same sort of error as you. I generally format a new card with FAT partition of 1G, ext4 for the rest and then rsync the "old" card partitions to the "new" one. Yes, I know 1G FAT is overkill, but big SD cards are cheap these days. Check the values in /boot/cmdline.txt and /etc/fstab after rsync.
--

Chris Elvidge, England
Reply to
Chris Elvidge
Raspbian installer allocates 256Mb.
Reply to
Dave
__________________________________ On an expanded 32-bit Raspbian I see /boot: 253 MB size, 53 MB used, 200 MB avail, 21% used
pi@RasPi-22:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 29G 5.7G 23G 21% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 9.6M 1.9G 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 53M 200M 21% /boot tmpfs 386M 0 386M 0% /run/user/109 tmpfs 386M 0 386M 0% /run/user/1000
__________________________________ On an expanded 64-bit Raspbian I see /boot: 253 MB size, 54MB used, 199 MB avail, 22% used
pi@RasPi-23:~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 29G 3.2G 25G 12% / devtmpfs 1.8G 0 1.8G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 2.3M 1.9G 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 54M 199M 22% /boot tmpfs 380M 0 380M 0% /run/user/1000
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
Thanks to all for the responses.
I solved the complaint by moving the root partition upward by 86 megabytes, enough to get space for a 128 Mib /boot.
The size of Pi4 /boot is around 53 megabytes, so 64 megabytes should already do it.
----
Another oddity: The /boot partition is in FAT32, but the Windowses do not like FAT32 smaller than 500 Mib, so the partition has to be deleted and re-created in the desired size, of course saving and restoring the contents separately.
Maybe Pi is happy to boot from a FAT16, as well. I have not tried it yet.
--

-TV
Reply to
Tauno Voipio
More space may be required during updates, so don't make it just big enough. 128MB is OK currently, but 256MB gives enough room for future expansion, such as if the number of kernels supplied increases.
Who cares what Windows thinks! :)
If you have a large enough card and aren't worried about a few meg, you could use a 512MB partition. I have for the Pi which I dual boot between 32 and 64 bit OS's.
I'd don't believe the GPU has code to boot from anything other than FAT32, but I haven't tried it either.
---druck
Reply to
druck
Re: Re: SIze of Pi4 /boot By: Tauno Voipio to druck on Sun Jun 07 2020 13:33:04
TV> I'd rather see an ext2 partition accepted for the boot, but TV> FAT seems to be cast on silicon in the GPU.
are you (and others) saying that the rPi does not have a CPU (Central Processing Unit)? that everything it does is done by the GPU (Graphical Processing Unit aka Video Card/Chip)? are terminologies being mised up here?
)\/(ark
Reply to
mark lewis
FATxx are Windows specifications. The tools available on Linux and OS X do respect the Windows desires, so there's a problem. Another thing that does not conform to Windows usage is the use of lower case letters in the partition label. If the Windows partition type must be used, it should be used correctly.
I'd rather see an ext2 partition accepted for the boot, but FAT seems to be cast on silicon in the GPU.
--

-TV
Reply to
Tauno Voipio
Doesn't that depend on the cluster size? For normal 512 byte clusters, the minimum fat32 partition size is 32 MB.
Reply to
A. Dumas
(I guess 512 byte isn't "normal" really, but the old standard and now minimum for fat32.) So 256 MB for 4 KB clusters, etc. So doesn't Windows adjust the cluster size depending on what size volume you request?
Reply to
A. Dumas
It has both, but the gpu controls the boot up process & activates the cpu after reading the firmware from disk. The gpu is sort of its bios.
Reply to
A. Dumas
On Sun, 07 Jun 2020 09:52:03 +1300, snipped-for-privacy@f1.n70.z4350.fidonet.org (mark lewis) declaimed the following:
The SoC used in the R-Pi uses the GPU to perform initial boot operations. It uses a Broadcom provided binary. The GPU loads that binary, and when running, the binary proceeds to load Linux into the RAM allocated to the ARM CPU, followed by releasing the ARM CPU to run with the loaded Linux image.
That Broadcom binary expects to find a device tree blob, and a core OS image, in the first partition -- which it appears to also expect will be a FAT file system.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber
On Sun, 7 Jun 2020 11:57:31 -0000 (UTC), A. Dumas declaimed the following:
Not that I can see... Granted, I'm not trying to repartition a flash memory, but the format operation on a 32GB "thumb drive" reports:
FAT32 (can be changed to NTFS or exFAT) 16kB allocation unit (can be changed to 8, 16, 32, 64kB)
Okay -- digging up the Disk Management control as a test. A 256MB partition defaults to FAT(16) with 4kB allocation size.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber
Previous Pis are happy to boot from FAT16, and I would expect the Pi 4 to be similar.
Fun fact: the ROM in a Pi 1 doesn't use FAT long filenames, so in 8.3 land your file has to be called LOADER.BIN - if it's called loader.bin it can't find it. The long filenames make that problem go away for 99% of us (the file is called LOADER.BIN as an 8.3 filename and whatever case we choose as the long name), but if your filesystem puts lower case in the short names, even if the file is uppercase in the long name, it doesn't work.
Theo
Reply to
Theo
The trouble is Microsoft keeps changing the rules after everyone else followed the specs.
I remember having problems with FAT16 disks, where Windows wouldn't see the files a non Windows machine wrote, and the non Windows machine wouldn't see the files that Windows had written. Both sets of files were there though.
The reason being is that FAT16 was originally specified with a fixed size root directory following on from the FAT, but at some point Microsoft started using FAT32's variable sized root directory on FAT16. Therefor non Windows machines used the old fixed sized directory as the format specified, but Windows used a different root directory - which is right and which is wrong?
So at some point Windows will break FAT32 so Pi's can't boot, so you are safer using a Linux tool which will produce partitions which follow the spec at the time the Pi was created, and ignoring any spurious warnings from Windows.
---druck
Reply to
druck
In article (Dans l'article) , druck
In the 1980s IBM did just the same.
Barely a part of the Token Ring was standardized and the equipment was "improved" to (again) become incompatible with that available from the "partners".
--
Jean-Pierre Kuypers
Reply to
Jean-Pierre Kuypers
There never were official published specs, it's all reverse engineering.
--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot
[]
[]
The trouble is that things on Linux keep changing in ways which are not backwards compatible, and the versions of software within distros are not kept up-to-date. Out of date examples - ntp, gpsd. Incompatible examples - gpsd, Raspberry Pi serial ports.
Backwards compatibility is something which Microsoft appears to care somewhat more about - not that I'm saying they are perfect, far from it.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.