-Greetings. I apologize for the incompleteness of what I am about to
-discuss. I was planning on working on it leisurely, but my employment
-circumstances changed and I've been trying to get it completed in a
+Greetings. I apologize for the incompleteness of what I am about to
+discuss. I was planning on working on it leisurely, but my employment
+circumstances changed and I've been trying to get it completed in a
-I've been thinking a lot about LAR lately, and ways to make it more
-extensible and robust. Marc and I have been trading ideas back and
-forth for a number of months, and over time a clear idea of what I
+I've been thinking a lot about LAR lately, and ways to make it more
+extensible and robust. Marc and I have been trading ideas back and
+forth for a number of months, and over time a clear idea of what I
-My goal was to add small things to LAR while retaining the overall
-scheme. Over time, the scheme evolved slightly, but I think you'll find
-that it remains true to the original idea. Below is the beginnings of
-an architecture document - I did it in text form, but if met with
-aclaim, it should be wikified. This presents what I call CBFS - the
-next generation LAR for next generation Coreboot. Its easier to
+My goal was to add small things to LAR while retaining the overall
+scheme. Over time, the scheme evolved slightly, but I think you'll find
+that it remains true to the original idea. Below is the beginnings of
+an architecture document - I did it in text form, but if met with
+aclaim, it should be wikified. This presents what I call CBFS - the
+next generation LAR for next generation Coreboot. Its easier to
-A header has been added somewhere in the bootblock similar to Carl
-Daniel's scheme. In addition to the coreboot information, the header
-reports the size of the ROM, the alignment of the blocks, and the offset
-of the first component in the CBFS. The master header provides all
+A header has been added somewhere in the bootblock similar to Carl
+Daniel's scheme. In addition to the coreboot information, the header
+reports the size of the ROM, the alignment of the blocks, and the offset
+of the first component in the CBFS. The master header provides all
-Each "file" (or component, as I style them) now has a type associated
-with it. The type is used by coreboot to identify the type of file that
-it is loading, and it can also be used by payloads to group items in the
+Each "file" (or component, as I style them) now has a type associated
+with it. The type is used by coreboot to identify the type of file that
+it is loading, and it can also be used by payloads to group items in the
-The header on each "file" (or component, as I like to style them) has
-been simplified - We now only store the length, the type, the checksum,
-and the offset to the data. The name scheme remains the same. The
-addtional information, which is component specific, has been moved to
+The header on each "file" (or component, as I like to style them) has
+been simplified - We now only store the length, the type, the checksum,
+and the offset to the data. The name scheme remains the same. The
+addtional information, which is component specific, has been moved to
alignment from the master header - this is to facilitate partial re-write.
Other then that, the LAR ideas remain pretty much the same.
alignment from the master header - this is to facilitate partial re-write.
Other then that, the LAR ideas remain pretty much the same.
-The plan for moving the metadata to the components is to allow many
-different kinds of components, not all of which are groked by coreboot.
- However, there are three essential component types that are groked by
+The plan for moving the metadata to the components is to allow many
+different kinds of components, not all of which are groked by coreboot.
+ However, there are three essential component types that are groked by
-stage - the stage is being parsed from the original ELF, and stored in
-the ROM as a single blob of binary data. The load address, start
+stage - the stage is being parsed from the original ELF, and stored in
+the ROM as a single blob of binary data. The load address, start
-Following this email are two replies containing the v3 code and a new
-ROM tool to implement this respectively. I told you that I was trying
-to get this out before I disappear, and I'm not kidding - the code is
-compile tested and not run-tested. I hope that somebody will embrace
-this code and take it the rest of the way, otherwise it will die a
+Following this email are two replies containing the v3 code and a new
+ROM tool to implement this respectively. I told you that I was trying
+to get this out before I disappear, and I'm not kidding - the code is
+compile tested and not run-tested. I hope that somebody will embrace
+this code and take it the rest of the way, otherwise it will die a
-I realize that this will start an awesome flamewar, and I'm looking
-forward to it. Thanks for listening to me over the years - and good
-luck with coreboot. When you all make a million dollars, send me a few
+I realize that this will start an awesome flamewar, and I'm looking
+forward to it. Thanks for listening to me over the years - and good
+luck with coreboot. When you all make a million dollars, send me a few
0xFFFFFFFF to locate the beginning of the ROM in memory.
'align' is the number of bytes that each component is aligned to within the
0xFFFFFFFF to locate the beginning of the ROM in memory.
'align' is the number of bytes that each component is aligned to within the
with
regards to the erase block sizes on the ROM - allowing one to replace a
component at runtime without disturbing the others.
with
regards to the erase block sizes on the ROM - allowing one to replace a
component at runtime without disturbing the others.
last
20k of the ROM space, and contains, among other things, the location of the
master header and the entry point for the loader firmware. The bootblock
last
20k of the ROM space, and contains, among other things, the location of the
master header and the entry point for the loader firmware. The bootblock
available
for components in the ROM is (ROM size - 20k - 'offset'). Each CBFS
component is to be aligned according to the 'align' value in the header.
available
for components in the ROM is (ROM size - 20k - 'offset'). Each CBFS
component is to be aligned according to the 'align' value in the header.
Upon recognizing a component, the software then has to search for the
specific name of the component. This is accomplished by comparing the
desired name with the string on the component located at
Upon recognizing a component, the software then has to search for the
specific name of the component. This is accomplished by comparing the
desired name with the string on the component located at
component
has been located, otherwise the software should add 'offset' + 'len' to
the offset and resume the search for the magic value.
component
has been located, otherwise the software should add 'offset' + 'len' to
the offset and resume the search for the magic value.