No MLO-file on newer BBG's?

[Paul Plankton]

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!

[Robert Nelson]

MLO/u-boot.img are dd'ed into the MBR..

No need for the fat partition anymore either. ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Paul Plankton]

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...

[Robert Nelson]

On Tue, Oct 25, 2016 at 3:04 PM, Paul Plankton <paul.pl...@gmail.com> wrote:
> 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

[Jason Kridner]

On Tue, Oct 25, 2016 at 1:09 PM Robert Nelson <robert...@gmail.com> wrote:

On Tue, Oct 25, 2016 at 3:04 PM, Paul Plankton <paul.pl...@gmail.com> wrote:
> 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. :-)

 

Regards,

--
Robert Nelson
https://rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYivmeN%2BJWOJCQKYj6M1b1JTe96hyBww8_aEn6z_5MmG8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

On Wed, Oct 26, 2016 at 2:57 PM, Jason Kridner <jkri...@beagleboard.org> wrote:

On Tue, Oct 25, 2016 at 1:09 PM Robert Nelson <robert...@gmail.com> wrote:

On Tue, Oct 25, 2016 at 3:04 PM, Paul Plankton <paul.pl...@gmail.com> wrote:
> 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 ? 

[Paul Plankton]

OK just to understand this:

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.

First 512 Bytes are the MBR including the partition table and some other "magic" things. Then the MLO-file is appended (directly at 512 bytes or with an offset of 128k?).

But: who is responsible to jump into the MLO-"file" at it's position in flash? Isn't there a special MBR-code needed that knows where to continue?

[Charles Steinkuehler]

On 11/4/2016 7:50 AM, Paul Plankton wrote:
> OK just to understand this:
>
> 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 *k*bytes (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.
>
> First 512 Bytes are the MBR including the partition table and some other "magic"
> things. Then the MLO-file is appended (directly at 512 bytes or with an offset
> of 128k?).
>
> But: who is responsible to jump into the MLO-"file" at it's position in flash?
> Isn't there a special MBR-code needed that knows where to continue?

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".

--
Charles Steinkuehler
cha...@steinkuehler.net

[val]

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 написав:

[Paul Plankton]

Hi,

I again played yround a bit with this. My first try was an operation

sudo cp /dev/random /dev/mmcblk1

From my understanding this should erase the onboard MMC completely together with all boot data. Nevertheless when I try to boot from a board erased in this way, there is still a u-boot coming up with a bunch of messages. Finally it of course fails because it can not find an operating system - but where does this boot sequence come from? It can't be on the on-board MMC and a SD-card is not inserted!

Thanks!

​

[Robert Nelson]

Or just:

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

[Paul Plankton]

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?

[Jason Kridner]

On Fri, Nov 18, 2016 at 6:22 AM Paul Plankton <paul.pl...@gmail.com> wrote:

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.

 

the board does not boot afterwards, console only prints "CCCC". What else could be missing?

Am Dienstag, 8. November 2016 19:29:15 UTC+1 schrieb RobertCNelson:

On Tue, Nov 8, 2016 at 12:24 PM, Paul Plankton <paul.pl...@gmail.com> wrote:
> Hi,
>
> I again played yround a bit with this. My first try was an operation
>
> sudo cp /dev/random /dev/mmcblk1
>
> From my understanding this should erase the onboard MMC completely together
> with all boot data. Nevertheless when I try to boot from a board erased in
> this way, there is still a u-boot coming up with a bunch of messages.
> Finally it of course fails because it can not find an operating system - but
> where does this boot sequence come from? It can't be on the on-board MMC and
> a SD-card is not inserted!

Or just:

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Regards,

--
Robert Nelson
https://rcn-ee.com/

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5135ad29-c918-4fad-b65f-36ddd545c0a5%40googlegroups.com.

[val]

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 написав: