Hi,
after some time I recently bought some BBG’s. Comparing to the older ones I no longer could find a MLO file there. How is the boot-process working now? What is the SoC jumping into when there is no more MLO?
Thanks!
MLO/u-boot.img are dd'ed into the MBR..
No need for the fat partition anymore either. 
Regards,
That’s cool! I use an own, customised MLO file - is there a way to put it into MBR too? It has a size of about 40 kBytes, so more than the 512 bytes of the MBR…
sudo dd if=./MLO of=/dev/mmcblk0 count=1 seek=1 bs=128k
sudo dd if=./u-boot.img of=/dev/mmcblk0 count=2 seek=1 bs=384k
Regards,
That’s cool! I use an own, customised MLO file - is there a way to put it
into MBR too? It has a size of about 40 kBytes, so more than the 512 bytes
of the MBR…sudo dd if=./MLO of=/dev/mmcblk0 count=1 seek=1 bs=128k
sudo dd if=./u-boot.img of=/dev/mmcblk0 count=2 seek=1 bs=384k
To clarify, the 512 bytes is just for the first sector of the MBR that has the partition table in it. We actually skip by that to an offset of 128k. Based on Robert’s instructions, 256 kbytes (384-128) is reserved for the MLO. Of course, MLO needs to fit in the internal RAM of the processor since this is the first place the DDR is configured, so your MLO would never get to be that large.
This version allocates 768 kbytes (2 x 384) for u-boot.img. For some reason, I thought this might have needed to be increased at some point.
Someone will let me know if I’m wrong about any of the above. 
I have not looked at Robert's build instructions lately, and of course
there is no way I could know what goes on at beagleboard.org / circuitco.
But in the past the instructions guided us to make a 1M hole at the start
of the disk( MBR ). Then dd copies the bootloaders to their appropriate
places. So what I always did was extract the whole MBR with dd . ..
dd if=/dev/mmcblk0 of=/path/to/mbr.img count=1 bs=1M
After that when I needed to make a new sdcard, or whatever, I'd extract the
bootloaders using a bs=512k. However it did work a few times, but failed at
least once if I remember right. As I was pulling the first 512k out of the
img file which was probably just the partition table. As at the time I did
not understand the dd seek parameter at all. I still find it confusing, but
now instead of trying to wrangle the bootloaders out of the image file, I
just "blast" the whole 1M MBR when and where I need it.
After that I think Robert was trying to create a 4M hole for the MBR, but
that introduced some sort of bug. Wonder if that's been fixed yet ?
OK just to understand this:
This is not an x86 system that runs code from the MBR to boot-strap
the system. The code that loads and executes MLO is in the on-chip
ROM, details are in chapter 26 "Initialization" of the TRM. Read
through section 26.1.7.5 "MMC / SD Cards".
It looks new BBG uses “raw mode” of rom code’s memory booting. MLO goes at the sector #256 (in fact at #257, CH goes at #256). Configuration Header (CH) directs the rom code to load the “raw” image from the next sector, where GH and your image come. In fact all this thing is abysmally and incorrectly described in TI TRM (for example it says rom code doesn’t support the raw mode for eMMC while it does, and it doesn’t say that in the raw mode, rom code, after identifying CH, expects the raw image at the next sector and not just right after CH bits, and CH and TOC are documented absolutely inconsistently etc.). I’ve figured out how and why this works thanks to people at TI community forum, when had found that my eMMC actually does have MLO despite accordingly to the TRM it shouldn’t. Now they switched to the raw mode. Rom code for the raw mode checks locations (LBA’s) #0, #256, #512 and #768. Looks here it uses the second.
пʼятниця, 4 листопада 2016 р. 14:50:38 UTC+2 користувач Paul Plankton написав:
Hi,
I again played yround a bit with this. My first try was an operation
sudo cp /dev/random /dev/mmcblk1
Thanks!
Or just:
sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10
Regards,
Hm, still not working. I have a MLO-file which works smoothly out of a FatFS partition but when I try to write it to the MMC directly with
sudo dd if=./MLO of=/dev/mmcblk1 count=1 seek=1 bs=128k
and/or
sudo dd if=./MLO of=/dev/mmcblk1 count=1 bs=128k
the board does not boot afterwards, console only prints “CCCC”. What else could be missing?
Hm, still not working. I have a MLO-file which works smoothly out of a FatFS partition but when I try to write it to the MMC directly with
sudo dd if=./MLO of=/dev/mmcblk1 count=1 seek=1 bs=128k
Do you have its target u-boot.img as well? I’m not sure of the behavior without it. The “CCCC” certainly says it the chip is trying other (serial) boot modes. Have you tried adding any debug statements to your MLO? How did you build it? Is the only reason you are confident of its format because you used it in the FAT partition? Are you certain that this is the code that ran when you had it in the FAT partition and that it is formatted with the appropriate headers?
You might share a small hexdump of the head and tail of your MLO.
and/or
sudo dd if=./MLO of=/dev/mmcblk1 count=1 bs=128k
This one would overwrite the partition information. That isn’t good.
In the FAT/MBR mode, rom code searches for MLO file in the root directory, that’s all it needs. In the raw mode, it searches for Configuration Header at the sectors #0, 256, 512, 768 first, to detect the raw mode valid image. Do you put CH at sector 256? Not just your MLO. If you put only MLO file at sector #256, without CH, it won’t work. Look at this project. Read the example for the raw mode case, it has a working CH sample (because as I said, TRM documents this part awfully, it is hard to get from it how CH should look like).
пʼятниця, 18 листопада 2016 р. 13:22:27 UTC+2 користувач Paul Plankton написав: