and first question is, why is there no need to create and format a
VFAT partition? from memory, i would always create a small, initial
VFAT partition and put MLO and uboot there, and format the rest of the
SD card as ext? for the rootfs.
but the instructions on that page don't create an initial VFAT
partition, they just raw copy MLO and u-boot.img to exact addresses on
the freshly-zeroed SD card. i had no idea you could do this. or am i
misreading something?
(side note: since those instructions are copying to a device file,
i'm guessing the dd "conv=notrunc" option is unnecessary.)
finally, on my fedora rawhide system, attempting to run sfdisk as
given there tells me:
1) --in-order is not even a valid option
2) both --Linux and --unit are deprecated options
anyway, if anyone wants to clarify any of the above, that would be
great, thanks. like i said, it's been a while since i've done this, i
really should do it more often.
and first question is, why is there no need to create and format a
VFAT partition? from memory, i would always create a small, initial
VFAT partition and put MLO and uboot there, and format the rest of the
SD card as ext? for the rootfs.
but the instructions on that page don't create an initial VFAT
partition, they just raw copy MLO and u-boot.img to exact addresses on
the freshly-zeroed SD card. i had no idea you could do this. or am i
misreading something?
It's a feature of the omap4+ bootrom. (omap35/36xx can't do it). We
had users deleting MLO/u-boot.img in that fat partition so we started
looking for a way to better protect that.
Ps.. the bootloader does a lot more internally now too, so we can have
simplified /boot/uEnv.txt script...
>
> been a while since i had to format an SD card from scratch for my
> BBB and, reading RCN's instructions over at eewiki.net, i have a
> couple questions.
>
> reading here:
>
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSD/SDcard
>
> and first question is, why is there no need to create and format a
> VFAT partition? from memory, i would always create a small, initial
> VFAT partition and put MLO and uboot there, and format the rest of the
> SD card as ext? for the rootfs.
>
> but the instructions on that page don't create an initial VFAT
> partition, they just raw copy MLO and u-boot.img to exact addresses on
> the freshly-zeroed SD card. i had no idea you could do this. or am i
> misreading something?
It's a feature of the omap4+ bootrom. (omap35/36xx can't do it). We
had users deleting MLO/u-boot.img in that fat partition so we started
looking for a way to better protect that.
Ps.. the bootloader does a lot more internally now too, so we can have
simplified /boot/uEnv.txt script...
which rev of the BBB does that relate to? i'm still using rev B.
> finally, on my fedora rawhide system, attempting to run sfdisk as
> given there tells me:
>
> 1) --in-order is not even a valid option
> 2) both --Linux and --unit are deprecated options
Yuck! I knew this was coming, was hoping they "wouldn't" break
everyone's script.. Looks like they did, sometimes i wonder if they
enjoy doing that...
making your life difficult ... it's what i live for.
sorry, i phrased that question badly. obviously, i can always
upgrade u-boot on my rev B, but i assume there was a point in the
recent past where the onboard bootrom could handle the dd'ed
MLO/u-boot.img, and that's *not* something i could update.
given that my BBBs were purchased a while back, i suspect i don't
have that feature in the bootrom. eh, time to pick up some rev Cs.
sorry, i phrased that question badly. obviously, i can always
upgrade u-boot on my rev B, but i assume there was a point in the
recent past where the onboard bootrom could handle the dd'ed
MLO/u-boot.img, and that's *not* something i could update.
given that my BBBs were purchased a while back, i suspect i don't
have that feature in the bootrom. eh, time to pick up some rev Cs.
All "am335x" have that feature in the bootrom.. It was added back when
the omap4 came out (I've heard even the dm81xx had it, but i never had
one of those boards..)
So yes, even the BBB "B"'s and the BBW's with there ES1.x silicon
fully support it...
as you say, the only real benefit to moving the MLO and u-boot.img
outside of a partition is to keep people from accidentally wiping them
out, is that it? other than that, there's no effective difference,
correct?
If I understand correctly
Boot rom dont care about the FAT table . its only read first several blocks
generally , MLO should be on the 2nd block ,1st block is MBR ,
But if there is a FAT file system . 2nd block should be fat table ,
3nd block should be MLO
whats my failed boot experience is when you format a sd card ,then copy a dummy file first ,then copy MLO to fat partiton
this will cause boot failed
and if you try another way , fdisk from 10M an create only one ext4 partiton
dd if=MLO of=/dev/sdb bs=512 seek=2
this still boot mlo ,but no u-boot.bin , this only because u-boot source code
Actually , if you check QNX ipl source code , they dont need any FAT
And if you really want a customed u-boot ,
You can get it minimized lower than 64K and boot kernel directly
If I understand correctly
Boot rom dont care about the FAT table . its only read first several blocks
generally , MLO should be on the 2nd block ,1st block is MBR ,
But if there is a FAT file system . 2nd block should be fat table ,
3nd block should be MLO
whats my failed boot experience is when you format a sd card ,then copy a dummy file first ,then copy MLO to fat partiton
this will cause boot failed
and if you try another way , fdisk from 10M an create only one ext4 partiton
dd if=MLO of=/dev/sdb bs=512 seek=2
this still boot mlo ,but no u-boot.bin , this only because u-boot source code
Actually , if you check QNX ipl source code , they dont need any FAT
And if you really want a customed u-boot ,
You can get it minimized lower than 64K and boot kernel directly
Mainline u-boot also doesn’t require ‘fat’, on omap4+ you can also use ext, as long as mlo is copied first. For omap3 there isn’t enough SRAM so it can be either fat or ext…
