Hi,
as part of an effort to unify the crt0-y and ldscript-y variables in Kconfig, this patch eliminates the need for special id.inc and id.lds files. These files exist for a number of chipsets because the default location of the .id section collides with romstraps. To fix this, this patch introduces a configuration option ID_SECTION_OFFSET, which is normally set to 0x10 (the default offset) and set to 0x80 (the alternate offset used by those chipsets) in the boards (on newconfig) or southbridges (on kconfig) that require it, which mimics the behaviour of those special files.
It's abuild and kbuildall tested.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
I'm going to ack this but: could we not get rid of the id section and make it a CBFS file instead?
I think the use of sections should be limited to only those cases where hardware leaves us no choice.
Acked-by: Ronald G. Minnich rminnich@gmail.com
Am 27.11.2009 17:40, schrieb ron minnich:
I'm going to ack this but: could we not get rid of the id section and make it a CBFS file instead?
I think the use of sections should be limited to only those cases where hardware leaves us no choice.
I need that special case out of the way. If someone builds a better way (and cbfs is indeed a good idea), I'm all for it. I think that any functional change requires changes in flashrom, so I hesitated to just change behaviour.
Acked-by: Ronald G. Minnichrminnich@gmail.com
Thanks, r4962
Patrick
On 27.11.2009 17:59, Patrick Georgi wrote:
Am 27.11.2009 17:40, schrieb ron minnich:
I'm going to ack this but: could we not get rid of the id section and make it a CBFS file instead?
I think the use of sections should be limited to only those cases where hardware leaves us no choice.
I need that special case out of the way. If someone builds a better way (and cbfs is indeed a good idea), I'm all for it. I think that any functional change requires changes in flashrom, so I hesitated to just change behaviour.
Please no CBFS/LAR parser in flashrom! You could place the ID in its own CBFS member and still have some pointer (in the master header or whatever) point to the ID. The only thing this needs is a final fixup state for cbfstool. With some careful coding, the new scheme will even be compatible with the old one.
However, if parsing CBFS in flashrom becomes necessary, I first want a sure way to identify coreboot images (rather than the current trial-and-error method). Right now the flashrom code has some pending unreviewed changes in that area, so it is unlikely that any CBFS related stuff ends up in flashrom 0.9.2. To be fair to v3 users, we'd have to merge LAR parsing as well if we merge CBFS parsing.
Regards, Carl-Daniel
On 11/27/09 6:42 PM, Carl-Daniel Hailfinger wrote:
To be fair to v3 users, we'd have to merge LAR parsing as well if we merge CBFS parsing.
I don't think there ever was such a group of people. Outside the well-known dozen, at least.
Stefan
On Fri, Nov 27, 2009 at 10:35 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 11/27/09 6:42 PM, Carl-Daniel Hailfinger wrote:
To be fair to v3 users, we'd have to merge LAR parsing as well if we merge CBFS parsing.
I don't think there ever was such a group of people. Outside the well-known dozen, at least.
w.r.t. v3, the only concern should be migrating working v3 boards to the new (not v2) coreboot repo. There is no need to do anything to flashrom for v3.
ron
On 27.11.2009 19:38, ron minnich wrote:
On Fri, Nov 27, 2009 at 10:35 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 11/27/09 6:42 PM, Carl-Daniel Hailfinger wrote:
To be fair to v3 users, we'd have to merge LAR parsing as well if we merge CBFS parsing.
I don't think there ever was such a group of people. Outside the well-known dozen, at least.
w.r.t. v3, the only concern should be migrating working v3 boards to the new (not v2) coreboot repo. There is no need to do anything to flashrom for v3.
And the v3 startup code should be migrated as well. It is so much more readable than the v2 code.
Regards, Carl-Daniel