Questions about CBFS

[Hamo]

Dear list,
Hi all. Here I come again. ^_^ This time, There are 2 questions about CBFS.
1. When we create the rom file, we covert all address and size from
LSB to MSB using htonl, and when we use them in the rom, we covert
them to LSB. Why we do this? Is it necessary or historical or
something else? Since ARM don't have an instruction like BSWAP in X86
(or I don't know it), it is not easy to covert a register from LSB to
MSB or vice versa.
2. What's the purpose of tryharder in src/arch/x86/lib/walkcbfs.S? In
my opinion, After we found a 'LARCHIVE', we can just compare the name
with the target name. If they are the same, OK, we got it and we can
jump to it, If not, we should jump to searchfile to find the next CBFS
component.

Thanks,
Hamo

[Georgi, Patrick]

Am Donnerstag, den 16.06.2011, 21:50 +0800 schrieb Hamo:
> When we create the rom file, we covert all address and size from
>
> LSB to MSB using htonl, and when we use them in the rom, we covert
> them to LSB. Why we do this? Is it necessary or historical or
> something else? Since ARM don't have an instruction like BSWAP in X86
> (or I don't know it), it is not easy to covert a register from LSB to
> MSB or vice versa.

We thought it's a good idea to mandate _some_ default, otherwise we'd
risk having incompatible image formats created by the same tool.

Question is if we should define native endianess per platform and let
cbfstool take care of things (instead of coreboot at runtime), adding a
flag to the CBFS header (which would have to be properly specified so
things are clear)
> What's the purpose of tryharder in src/arch/x86/lib/walkcbfs.S? In
>
> my opinion, After we found a 'LARCHIVE', we can just compare the name
> with the target name. If they are the same, OK, we got it and we can
> jump to it, If not, we should jump to searchfile to find the next CBFS
> component.

It's probably somewhat misnamed:
searchfile takes the alignment property of an image and searches the
image for LARCHIVE headers in "align"-increments.
tryharder skips a file (of a known size) so the cbfs walker doesn't have
to search inside files (we know that new files won't start there).

Essentially the algorithm is like this:
1. determine ALIGN
2. set cursor to the beginning of the image
3. search for 'LARCHIVE' header in ALIGN-steps (address mod ALIGN == 0)
   (searchfile)
4. if a file is found, check filename
5. if filename matches, return success
7. otherwise skip file (tryharder)
8. if cursor left image area, return failure
9. go to 3.

where 3. expands to:
3a. look for 'LARCHIVE'
3b. if found, go to 4.
3c. otherwise do cursor += ALIGN;
3d. if cursor left image area, return failure
3e. go to 3a.

Regards,
Patrick

[Hamo]

On Fri, Jun 17, 2011 at 2:29 PM, Georgi, Patrick
 wrote:
> Am Donnerstag, den 16.06.2011, 21:50 +0800 schrieb Hamo:
> We thought it's a good idea to mandate _some_ default, otherwise we'd
> risk having incompatible image formats created by the same tool.

You mean that we use MSB as default now?
> Question is if we should define native endianess per platform and let
> cbfstool take care of things (instead of coreboot at runtime), adding a
> flag to the CBFS header (which would have to be properly specified so
> things are clear)

A new question:
Why we use a binary file to create the rom but using an ELF to add a
stage to this rom?

Thanks,
Hamo

[Patrick Georgi]

Am 17.06.2011 16:36, schrieb Hamo:
> You mean that we use MSB as default now?

I think there's an exception for one field (entry point?), but other
than that, yes.
> A new question:
> Why we use a binary file to create the rom but using an ELF to add a
> stage to this rom?

Mostly historical reasons, that is, no real reason, I guess.

Patrick

[Hamo]

Hi Patrick,
This time I come to romstage. As I know, After walkcbfs in bootblock,
we return the entry from struct cbfs_stage. This entry is copied from
the ELF header's entry point of romstage.elf. This is generated by the
compile process of romstage. But the really address we place the
romstage in the rom is found by cbfstool, and we run the romstage just
in the rom, not copying it to the ram. So I need to make the entry
point to the address we place the romstage in rom. Am I wrong?
If so, what's the really process that bootblock passes control to
romstage. If not, How could I predict the really address that we place
romstage in rom just before we compile the romstage( Since we need the
entry address as ldscript to compile it).

Thanks very much for your continuously help!
Hamo

[Patrick Georgi]

Am 20.06.2011 um 04:17 schrieb Hamo :
> If not, How could I predict the really address that we place
> romstage in rom just before we compile the romstage( Since we need the
> entry address as ldscript to compile it).

I'm on vacation, so only a quick hint: look at the makefile where it  
generates location.ld.
We link things twice, first to know its size and determine a good  
location, then to tell the code about that location.

Patrick