Currently the msdosfs partition on RPI-B SD card images is 17MB, and is 74% full. It's enough to boot, but a bit too small when you want to experiment with different firmware ('bootloader') releases, and there's no easy way around it, apart from recompiling the image myself. Raspbian uses 41MB partition on their release images: => 63 9666497 md0 MBR (4.6G) 63 8129 - free - (4.0M) 8192 85611 1 !12 (42M) 93803 4501 - free - (2.2M) 98304 9568256 2 linux-data (4.6G) I propose to increase our size to the same value. (FIWIW, theirs is 51% full, they use 21MB of it).
Sounds reasonable to me
A commit references this bug: Author: gjb Date: Wed Apr 18 14:34:34 UTC 2018 New revision: 332674 URL: https://svnweb.freebsd.org/changeset/base/332674 Log: Increase the msdosfs partition size on arm SoC images where the current size may not be sufficiently large for development and/or testing. PR: 227548 Submitted by: trasz MFC after: 3 days Sponsored by: The FreeBSD Foundation Changes: head/release/arm/BEAGLEBONE.conf head/release/arm/GUMSTIX.conf head/release/arm/PANDABOARD.conf head/release/arm/RPI-B.conf
I agree we need to increase our DOS sizes for the whole family of these images, I do not agree to blindly copy the Linux used values however. I note in looking at the Linux values posted below that they seem to be using a 63 sector track size, but fail to align anything to this. This may cause some bioses issue with CHS translations at boot time. I propose that we use the values that imp (Warner Losh) suggested some place else in adjusting our alignment of all memstick and VM images. This would make the memstick images more use full in VM situations, and probably fix some performance related issues with bad alignment choices even for SD or USB sticks. Adjust the linux one to this: => 63 9666497 md0 MBR (4.6G) 63 8129 - free - (4.0M) 8192 85611 1 !12 (42M) Size 85611 is not a round MB size, make it (42*2048==86016), this size and the following free space make no since to me at all. 93803 4501 - free - (2.2M) 98304 9568256 2 linux-data (4.6G) This is already on a MB boundary, so I am unsure why the free space hole that above is even there, why did they do that?
A commit references this bug: Author: gjb Date: Mon Apr 23 13:47:30 UTC 2018 New revision: 332888 URL: https://svnweb.freebsd.org/changeset/base/332888 Log: MFC r332674: Increase the msdosfs partition size on arm SoC images where the current size may not be sufficiently large for development and/or testing. PR: 227548 Sponsored by: The FreeBSD Foundation Changes: _U stable/10/ stable/10/release/arm/BEAGLEBONE.conf stable/10/release/arm/GUMSTIX.conf stable/10/release/arm/PANDABOARD.conf stable/10/release/arm/RPI-B.conf _U stable/11/ stable/11/release/arm/BEAGLEBONE.conf stable/11/release/arm/GUMSTIX.conf stable/11/release/arm/PANDABOARD.conf stable/11/release/arm/RPI-B.conf
Merged to stable/11 and stable/10. I'll close this, unless rgrimes re-opens it in followup to comment 3.
(In reply to Glen Barber from comment #5) Given the way FreeBSD builds I believe the right stuff is just going to happen, and if it does not it is a tool issue, not a build system issue. As far as I am concerned this stays closed.