Re: [beagleboard] GPT format SD card?

[Jason Kridner]

The ROM will work with MLO dumped to sector 0. Don't know about uboot's partition support. 

On Mar 18, 2013 7:57 PM, "Wolfgang Rupprecht" <wolfgang....@gmail.com> wrote:

Does the u-boot and Angstrom environment understand GPT formatted SD cards?   

Sorry, just a personal dislike for MBR's and phony tracks/heads/cylinders that just get in the way of rational blk numbering.

-wolfgang

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Toan Pham]

The ROM will work with MLO dumped to sector 0.

It is not true, MLO can be dumped to other sector #.  I tried that by creating a win fat32, first partition at sector 2048, 62 sector/track layout, and 512 bytes per sector.  I created a native flash builder that does this, any created 50+ images with this CHS layout.

 

[Jason Kridner]

On Wed, Mar 20, 2013 at 5:27 PM, Toan Pham <tpha...@gmail.com> wrote:

The ROM will work with MLO dumped to sector 0.

It is not true, MLO can be dumped to other sector #. 

Just because it can be dumped to another sector # does not mean that it cannot be dumped to 0. Guess that is a language issue.

 

I tried that by creating a win fat32, first partition at sector 2048, 62 sector/track layout, and 512 bytes per sector.  I created a native flash builder that does this, any created 50+ images with this CHS layout.

Is that something you care to share? What is the benefit? This sounds like it heads right into the problem the thread author was trying to avoid.

My process for the BeagleBoard with x-loader (not BeagleBone and not current u-boot SPL) is documented at:

https://groups.google.com/d/topic/x-loader/esbsB6PtN8g/discussion

Pretty much the same thing should work with BeagleBone and u-boot SPL. Other offsets besides 0 are also valid, but the question was about if u-boot could work with GPT. I did a quick google search and the answer to that question is yes:

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.gpt

With the ability to boot from sectors rather than a FAT partition plus u-boot support for GPT, I think the originator of this e-mail thread is in good shape. As to if Angstrom supports it, well, I don't know that the Angstrom u-boot is built with GPT support, but reusing the Angstrom kernel and file system shouldn't be any problem at all.

[Toan Pham]

Just because it can be dumped to another sector # does not mean that it cannot be dumped to 0. Guess that is a language issue.

the first sector of a floppy-like mmc card contains a volume boot sector, similarly, the first sector of a harddrive like mmc card contains a MBR.  I dont think loading x-loader to the first sector would work.

What you are saying is that if i were to do this, MLO would get loaded auto-magically!!

dd if=/myMLO of=/dev/sdc bs=512 count=1   # I would be amazed if it worked. 


In Omap3730 TRM on section "Device Initialization by ROM Code", figure 26-26 SD/MMC Booting.
It does not show that the TI Omap bootloader read the first sector and execute the first stage bootloader from there.  The diagram shows the flow of validation.  If neither MBR or FAT is found on first sector, booting would fail on MMC device completely.  Unless this is documented somewhere, I maybe wrong.

 

I tried that by creating a win fat32, first partition at sector 2048, 62 sector/track layout, and 512 bytes per sector.  I created a native flash builder that does this, any created 50+ images with this CHS layout.

Is that something you care to share? What is the benefit? This sounds like it heads right into the problem the thread author was trying to avoid.

This is to proof that the real x-loader (MLO) content lives in cluster# > 2, on a fat32 filesystem.  I am sorry if you do not understand my  point.