[LinuxBIOS] [PATCH] v3: support LARchives with header-after-data

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Oct 12 14:54:41 CEST 2007


On 12.10.2007 12:21, Peter Stuge wrote:
> On Fri, Oct 12, 2007 at 11:55:26AM +0200, Stefan Reinauer wrote:
>   
>> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [071012 00:38]:
>>     
>>> > AFAIK not all architectures start executing code at the top of ROM, some
>>> > start at the bottom (low address). 
>>>       
>>
>> Are you working on porting LinuxBIOS to such an architecture currently?
>>     

No, but I'd like to make architectural decisions before they become a
problem in porting when time is short. Rapidly hacked solutions often do
not achieve long-term code understandability.

>> Just add a jump into the "bootblock" member of the lar the first
>> thing before the archive on those architectures that start their
>> execution at the beginning of flash rather than anywhere in the
>> middle.
>>     
>
> Just that it's "unfair" to only be able to identify top bootblocks.
>   

But then we would need special code sequence emission for bottom boot
architectures. That is neither portable nor can it be handled
automatically, i.e. you have to specify the instruction architecture
when creating/modifying a LAR archive.

>> This would be a perfectly valid lar, as lar copes with non-lar-data
>> between the members. It was designed to do that.
>>     
>
> Excellent point.
>   
It is a valid lar, but you have to add special casing all over the lar
utility when reading/modifying such archives or you will lose that
information.

>> Lar could even produce that jump once it supports non-x86
>> architectures. (Obviously lar's bootblock handling can never be
>> 100% generic)
>>     
>
> Maybe it can - if lar is only used to manage locations and sizes
> rather than actual instructions. The rope only has two ends..
>   
I'd like lar to be a pure archive tool, not a code sequence emission
tool as well. That way, you don't have to care about the destination
architecture, only about its top/bottom boot block property.

>> Let's keep things simple so that every idiot can understand it,
>> even 6 months later.
>>     
>
> You made a very good point, I still like the signed idea but it isn't
> at all needed in the short term. When we get popular LAR use on
> bottom bootblock archs we may have even better ideas.
>   

Maybe. I think the code and the comments are both very clear on
methodology and purpose. The log message could be added to the lar
documentation, but otherwise I think the code is explained better than
it was before.
Besides that, the idea has been met with approval on IRC a few weeks ago
(IIRC Jordan Crouse was the one poking me to document the old/new limits
better). Ron wrote in a mail: "OK, I like signed offset, but let's let
stefan weigh in. It's critical that we get this right."

Stefan: Your complaint about my solution being over-engineered has some
truth in it, but the solution carefully avoids big special casing and
code bloat. The only added code for all new functionality is

+		if (walk < (char *)header) {
+			walk = (char *)header;
+			walk += (sizeof(struct lar_header) + strlen(fullname))
+				& 0xfffffff0;
+		}

and all other changes are either better code comments or functionally
equivalent (whitespace / argument reordering) transformations. I doubt
there is a smaller and cleaner solution for bottom boot architectures.

Regards,
Carl-Daniel




More information about the coreboot mailing list