Hi, all. My question is that:
I need to make use an am3358 rom code's raw mode of memory booting 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 first sector,
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 [TRM SPRUH73K]:
"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.
If I place my binary into LBA #0 (first sector) with the only GP header attached and no CH,
would the Rom code recognize the raw mode and boot my image?
I can't use MBR/FAT mode, because there is GPT and Protective MBR there.
I wanted to learn this, and before bothering you, I checked eMMC content on the Beagle Bone Black board (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 mode 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."
Tell me please, is CH required, in raw mode of memory booting for GP devices and
what its minimal content if it is? Because I cannot let it occupy the entire 512 bytes, only part
of the code block (first 440 bytes) of the Protective MBR may be used.
*** Below is my trying to expalin what I meant saying about unclear offsets and sizes in the TOC and CHSETTINGS description in TRM.
The TRM gives an example of the TOC structure (table 26-20), and CHSETTINGS section (table 26-21).
In the TOC, the Start field indicates value a0h as an offset from the TOC to the (CHSETTINGS) section. Why a0h? it's 160 bytes, whereas TOC from the table is maximum 64 bytes long. Because the last its field is placed at the offset 3ch and has 4 byte. Moreover, the TOC states there should be 8 closing items filled with ffffffffh. Why? Isn't enough one after CHSETTINGS TOC item? Then, TOC size might be as little as 36 bytes!
Next, in the TOC, the Size field (for CHSETTINGS) has a value 50h (80 bytes). But when looking at the next table where CHSETTINGS is described, it requires fields up to the offset e0h (almost all filled with zeroes). it would result in minimum 225 bytes of the CHSETTINGS section! this is definitely not 50h claimed in the TOC. This is a mess. I understand that this all is for smudging CH into the entire sector, but with a Protective MBR it's impossible. The most irritating thing, that this is absolutely not needed, and still it wants to occupy the entire sector! Please, tell me, this CH thing is not needed for raw mode. Because, honestly, rom code checks first 4 bytes of read sector and if they are not 0 or ffffffff, it thinks it's a GP header of a valid image. or at least tell that I can prepare a minimalistic CH not bloated with meaningless tons of closing items and reserved zeroed fields for disabled CHSETTINGS section.
