Skip to first unread message
val
Aug 16, 2016, 5:22:30 PM8/16/16
to BeagleBoard
Hi, all. My question is that:
I need to make use a Rom code's raw mode of reading its payloads from both SD cards and eMMC.
My question is whether the CH (Configuration Header) needed in this case?
TI's TRM on Sitara am335x states CH must be located at the sector #0,
and says it might be void (only containing a _disabled_ CHSETTINGS item),
but it is very unclear with respect of its size and offsets. and also it's not clear whether it's needed at all.
Quote:
"The raw mode is detected by reading sectors #0, #256, #512, #768.
The content of these sectors is then verified for presence of a TOC structure as described in Section 26.1.9."
But section 26.1.9 even doesn't mention CH, just a GP header.
And the TRM on Sitara 572x states CH is optional for GP devices.
I mean, if I place my binary into LBA #0 (first sector) with the only GP header attached and no CH,
would the Rom code load it?
I can't use MBR/FAT mode, because there is GPT and PMBR there.
I wanted to learn this, and before bothering you, I checked eMMC content on BBB,
since TI's TRM states for embedded memories ROM code doesn't use MBR/FAT mode.
So on eMMC there should be a valid example of CH with TOC in the first sector. But on BBB, somehow,
and it is clearly seen, the FAT/MBR is used and there is no any TOC at all (first bytes
of the first sector are filled with zeros up to the Partition records). TRM states if the first
4 bytes are 0x00 or 0xFF this device is considererd as not containig the image to load:
Quote
"The detection of whether an image is present or not on a selected device depends on the first few bytes.
On a GP Device type a booting image is considered to be present when the first four bytes of the sector is
not equal to 0000 0000h or FFFF FFFFh."
Maybe there are some knowledgeable people here,
tell me please, is CH needed (for the Romcode) in the raw mode for GP memory booting and
what its minimal content is? Because I cannot let it occupy the entire 512 byte, only part
of the code block (first 440 bytes) of the Protective MBR may be used.
I need to make use a Rom code's raw mode of reading its payloads from both SD cards and eMMC.
My question is whether the CH (Configuration Header) needed in this case?
TI's TRM on Sitara am335x states CH must be located at the sector #0,
and says it might be void (only containing a _disabled_ CHSETTINGS item),
but it is very unclear with respect of its size and offsets. and also it's not clear whether it's needed at all.
Quote:
"The raw mode is detected by reading sectors #0, #256, #512, #768.
The content of these sectors is then verified for presence of a TOC structure as described in Section 26.1.9."
But section 26.1.9 even doesn't mention CH, just a GP header.
And the TRM on Sitara 572x states CH is optional for GP devices.
I mean, if I place my binary into LBA #0 (first sector) with the only GP header attached and no CH,
would the Rom code load it?
I can't use MBR/FAT mode, because there is GPT and PMBR there.
I wanted to learn this, and before bothering you, I checked eMMC content on BBB,
since TI's TRM states for embedded memories ROM code doesn't use MBR/FAT mode.
So on eMMC there should be a valid example of CH with TOC in the first sector. But on BBB, somehow,
and it is clearly seen, the FAT/MBR is used and there is no any TOC at all (first bytes
of the first sector are filled with zeros up to the Partition records). TRM states if the first
4 bytes are 0x00 or 0xFF this device is considererd as not containig the image to load:
Quote
"The detection of whether an image is present or not on a selected device depends on the first few bytes.
On a GP Device type a booting image is considered to be present when the first four bytes of the sector is
not equal to 0000 0000h or FFFF FFFFh."
Maybe there are some knowledgeable people here,
tell me please, is CH needed (for the Romcode) in the raw mode for GP memory booting and
what its minimal content is? Because I cannot let it occupy the entire 512 byte, only part
of the code block (first 440 bytes) of the Protective MBR may be used.
John Syne
Aug 17, 2016, 6:49:56 PM8/17/16
to beagl...@googlegroups.com
I recommend you ask your question on Texas Instruments E2E website
I’m not sure anyone here would have this level of detailed knowledge.
Regards,
John
--
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/0908e47d-6d81-46a0-baf9-260e7e9794a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
val
Aug 22, 2016, 8:11:55 PM8/22/16
to BeagleBoard
четвер, 18 серпня 2016 р. 01:49:56 UTC+3 користувач john3909 написав:
I recommend you ask your question on Texas Instruments E2E websiteI’m not sure anyone here would have this level of detailed knowledge.Regards,John
Thank you for the recommendation. I did so, and got the answers.
For those who might be interested, the short answer is the rom code does need CH, put at the one of sectors - #0, #256, #512 or #768. CH is about 288 bytes in size (there is a very good project at github, clearly illustarting this and more), so it fits into an MBR's BootCode block, but this will not help you with putting your image right after it into remaining bytes of the BootCode, because the rom code expects the image to be placed sector aligned, thus - at the beginning of the next sector.
So if you cannot place it there, because there is some other thing already occupying it, as the GPT header in my case, and you still want to use the raw mode of booting, your only choice is to skip 256 sectors and lay your bundle - TOC, CHSETTINGS at the beginning of Lba #256 and GP+your image at Lba #257. Rom code checks all 4 locations, so finding the CH at Lba #256 it will load it. Hopefully.
John Syne
Aug 23, 2016, 12:42:14 AM8/23/16
to beagl...@googlegroups.com
Thank you for sharing.
Regards,
John
--
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/4bbe0885-d868-4628-a0f3-7f0dcf266f3d%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages