coreboot October 2011

coreboot@coreboot.org

46 participants
501 discussions

Re: [coreboot] [msrtool] Bug report
by Nils 25 Oct '11

25 Oct '11

Hi Peter, I wanted to read registers 0x80002010 (BIST_MSR) , 0xA0002000 (GLD_MSR_CAP) , 0xC0002010 (MSR_DIAG_VP) and lots of others. >Hm.. Did you try other addresses >= 0x80000000? And are you sure that >0x80000000 is a valid MSR address on GX2? The only mention of the >value when searching quickly through the databook is the parameter >for the CPUID instruction.. Yes i tested several addresses. I now used the Debian program MSR-TOOLS (RDMSR) and that works fine. So i'm pretty sure it is a bug. I did cc coreboot but i got a message that the moderator had to approve it .... Maybe because i have a new mail address. Thanks, Nils.

1 0

New patch to review for coreboot: d5e94e6 X60/T60: remove superflous h8_set_audio_mute()
by Sven Schnelle 25 Oct '11

25 Oct '11

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/335 -gerrit commit d5e94e6830f868d7437f0749be65f0d25869d61f Author: Sven Schnelle <svens(a)stackframe.org> Date: Tue Oct 25 15:31:26 2011 +0200 X60/T60: remove superflous h8_set_audio_mute() muting is handled by h8 code, no need to do it here. Change-Id: I3f152e99f30701cd032b03105cbe3ae778865305 Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/mainboard/lenovo/t60/mainboard.c | 3 --- src/mainboard/lenovo/x60/mainboard.c | 3 --- 2 files changed, 0 insertions(+), 6 deletions(-) diff --git a/src/mainboard/lenovo/t60/mainboard.c b/src/mainboard/lenovo/t60/mainboard.c index 8456992..d4f260d 100644 --- a/src/mainboard/lenovo/t60/mainboard.c +++ b/src/mainboard/lenovo/t60/mainboard.c @@ -42,9 +42,6 @@ static void mainboard_enable(device_t dev) device_t dev0, idedev; u8 defaults_loaded = 0; - /* enable Audio */ - h8_set_audio_mute(0); - /* If we're resuming from suspend, blink suspend LED */ dev0 = dev_find_slot(0, PCI_DEVFN(0,0)); if (dev0 && pci_read_config32(dev0, SKPAD) == SKPAD_ACPI_S3_MAGIC) diff --git a/src/mainboard/lenovo/x60/mainboard.c b/src/mainboard/lenovo/x60/mainboard.c index bf3d8d3..e59b2e4 100644 --- a/src/mainboard/lenovo/x60/mainboard.c +++ b/src/mainboard/lenovo/x60/mainboard.c @@ -42,9 +42,6 @@ static void mainboard_enable(device_t dev) device_t dev0, idedev; u8 defaults_loaded = 0; - /* enable Audio */ - h8_set_audio_mute(0); - ec_clr_bit(0x03, 2); if (inb(0x164c) & 0x08) {

1 0

New patch to review for coreboot: 0139e6e Lenovo H8: Fix h8_set_audio_mute()
by Sven Schnelle 25 Oct '11

25 Oct '11

Sven Schnelle (svens(a)stackframe.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/334 -gerrit commit 0139e6e1c0527c0be622e92f596a3b159ecde2e2 Author: Sven Schnelle <svens(a)stackframe.org> Date: Tue Oct 25 15:29:47 2011 +0200 Lenovo H8: Fix h8_set_audio_mute() Logic is inverted (if argument is true, one would expect that mute is enabled) and the wrong bit was used (1 instead 0) Change-Id: I71133ba639f1fb0d3c3582f16211dd266a11cc64 Signed-off-by: Sven Schnelle <svens(a)stackframe.org> --- src/ec/lenovo/h8/h8.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/ec/lenovo/h8/h8.c b/src/ec/lenovo/h8/h8.c index 560c39c..f81a39c 100644 --- a/src/ec/lenovo/h8/h8.c +++ b/src/ec/lenovo/h8/h8.c @@ -63,12 +63,12 @@ static void h8_log_ec_version(void) fwvh >> 4, fwvh & 0x0f, fwvl >> 4, 0x41 + (fwvl & 0xf)); } -void h8_set_audio_mute(int on) +void h8_set_audio_mute(int mute) { - if (on) - ec_clr_bit(0x3a, 0); + if (mute) + ec_set_bit(0x3a, 0); else - ec_set_bit(0x3a, 1); + ec_clr_bit(0x3a, 0); } void h8_enable_event(int event)

1 0

[msrtool] Bug report
by Nils 25 Oct '11

25 Oct '11

Hi all, I found a bug in msrtool. On AMD Geode GX2 the reading of MSR registers above 0x7FFFFFFF gives an error. For MSR register 0x80000000 the error is: linux_rdmsr: read(0x80000000): Invalid argument I spend about 8 hours to look at the code but it needs a more expirienced programmer. The bug tracking system does not seem to know msrtool. Thanks, Nils.

2 1

[RFC]What to do with TINY_BOOTBLOCK?
by Patrick Georgi 25 Oct '11

25 Oct '11

Hi all, as you may be aware, coreboot has two different ROM layouts so far. The older one is derived from what we did before CBFS, and has all code that does RAM init (our "romstage") in the bootblock (up to 64k at the top end of the image). This worked for a long time, but required some hackery for supporting dual-image scenarios (like fallback/normal, where we normal passed control to fallback by jumping to start-8 bytes), and it also broke when AMD's RAM setup became so complicated that it doesn't fit in 64k anymore. Those 64k are mandated by ROM mappings of various chipsets which, by default, only provide access to the upper 64k. The newer one, created after the CBFS switch and exploiting its features, has a tiny bootblock (hence the name), often less than 1k, which implements some policy: By default, it simply looks up "fallback/romstage" in CBFS and executes it. Our other policy does the old fallback/normal routine (using a counter in nvram), but executing files in CBFS as well, instead of jumping into the void and hoping that there's code there. The problem with the new approach is that it requires full ROM mapping rather early. Boards whose romstage fit in the 64k were free to defer setting up mapping to whereever it is convenient inside the romstage, so it's not all that easy to identify without means to test it. Unfortunately, this is a runtime problem, not a build problem, so it's hard to test all our 160 boards. For this reason, we kept both mechanisms in the tree, under the monikers BIG_BOOTBLOCK and TINY_BOOTBLOCK. Some chipsets that are in common use were converted rather early, so by now, 100 boards use tiny bootblock, while 60 use the old method. Since then - not much happened. Kyösti Mälkki recently brought this issue up again (thanks!), and proposes to invert the flags, making tiny bootblock the default, so "big" bootblock has to be requested explicitely and also adding some "maybe" flag for boards that might just work. This is quite a large change, but I fear it'll bring relatively little progress - people will just copy the TINY_NO_BOOTBLOCK (or what it's called in the latest patch iteration) flag and move on. Therefore, I propose (http://review.coreboot.org/#change,320) to get rid of the "big bootblock" variant altogether. This might break some boards (silently: they still build, but they fail on boot), but at least it forces action to fix them. Advantages: - one flag less to care about - more uniform feature set (big bootblock didn't support any fallback mechanism) - more opportunities to clean out and simplify the build system and code - there are some crude workarounds to make both mechanisms work Disadvantages: - Boards might be broken for a long time until someone tries them again. The visible result is that the boot fails early (ie. no error signalling at all, the system simply hangs, nothing visible). It's possible to determine all boards that _might_ be affected (those that use a big bootblock now), so I could add that list to the commit message, hopefully helping whoever stumbles over this issue. Comments? Patrick

4 5

Re: [coreboot] [RFC] Tracking run tested coreboot revisions for boards
by Peter Stuge 25 Oct '11

25 Oct '11

Thomas Gstädtner wrote: > As a "end-user" I'd really prefer a possibility to participate in this > issue; You would send a patch. > I think it is not possible for the few active devs to maintain > every mainboard all the time and make sure to note it in git. This was never the idea. It is obvious that it will fail. > don't think the coreboot git repo itself is the best place to keep > this information, nor is it the best tool for the job. Hm. > I think WINEs appdb (http://appdb.winehq.org) is a good example on how > it could be done. They have a overview site per application (for > coreboot this would be per board) The big difference is that coreboot will never really work on any mainboard which does not also have explicit support in the repo. So the repo seems like a natural place to track testing. > Another possibility might be using gerrit for such contributions. Yes of course. Test results would also go through gerrit. //Peter

2 1

Re: [coreboot] [RFC]What to do with TINY_BOOTBLOCK?
by Kyösti Mälkki 25 Oct '11

25 Oct '11

On Mon, 2011-10-24 at 10:22 -0600, Marc Jones wrote: > On Mon, Oct 24, 2011 at 4:15 AM, Patrick Georgi <patrick(a)georgi-clan.de> wrote: > > Hi all, > > > > as you may be aware, coreboot has two different ROM layouts so far. > > > > The older one is derived from what we did before CBFS, and has all code that > > does RAM init (our "romstage") in the bootblock (up to 64k at the top end of > > the image). This worked for a long time, but required some hackery for > > supporting dual-image scenarios (like fallback/normal, where we normal > > passed control to fallback by jumping to start-8 bytes), and it also broke > > when AMD's RAM setup became so complicated that it doesn't fit in 64k > > anymore. > > Those 64k are mandated by ROM mappings of various chipsets which, by > > default, only provide access to the upper 64k. > > > > The newer one, created after the CBFS switch and exploiting its features, > > has a tiny bootblock (hence the name), often less than 1k, which implements > > some policy: By default, it simply looks up "fallback/romstage" in CBFS and > > executes it. Our other policy does the old fallback/normal routine (using a > > counter in nvram), but executing files in CBFS as well, instead of jumping > > into the void and hoping that there's code there. > > > > The problem with the new approach is that it requires full ROM mapping > > rather early. Boards whose romstage fit in the 64k were free to defer > > setting up mapping to whereever it is convenient inside the romstage, so > > it's not all that easy to identify without means to test it. Unfortunately, > > this is a runtime problem, not a build problem, so it's hard to test all our > > 160 boards. For this reason, we kept both mechanisms in the tree, under the > > monikers BIG_BOOTBLOCK and TINY_BOOTBLOCK. > > > > Some chipsets that are in common use were converted rather early, so by now, > > 100 boards use tiny bootblock, while 60 use the old method. > > Since then - not much happened. > > > > Kyösti Mälkki recently brought this issue up again (thanks!), and proposes > > to invert the flags, making tiny bootblock the default, so "big" bootblock > > has to be requested explicitely and also adding some "maybe" flag for boards > > that might just work. This is quite a large change, but I fear it'll bring > > relatively little progress - people will just copy the TINY_NO_BOOTBLOCK (or > > what it's called in the latest patch iteration) flag and move on. > > > > Therefore, I propose (http://review.coreboot.org/#change,320) to get rid of > > the "big bootblock" variant altogether. This might break some boards > > (silently: they still build, but they fail on boot), but at least it forces > > action to fix them. > > > > Advantages: > > - one flag less to care about > > - more uniform feature set (big bootblock didn't support any fallback > > mechanism) > > - more opportunities to clean out and simplify the build system and code - > > there are some crude workarounds to make both mechanisms work > > > > Disadvantages: > > - Boards might be broken for a long time until someone tries them again. The > > visible result is that the boot fails early (ie. no error signalling at all, > > the system simply hangs, nothing visible). > > > > It's possible to determine all boards that _might_ be affected (those that > > use a big bootblock now), so I could add that list to the commit message, > > hopefully helping whoever stumbles over this issue. > > > > Comments? > > > > Hi Patrick, > > I think that this makes sense. It seems like the change would improve > the build and standardize early coreboot. I think that we can support > developers in the porting for those platforms when they come up. The > ROM decode is a typically a southbridge setting, so do you know what > southbridges would be untested? > > Marc > > Hello Marc I am glad this topic brings up discussion. List of mainboards that currently do not select TINY_BOOTBLOCK and do not select ROMCC in Kconfig: aaeon/pfm-540i_revb amd/db800 amd/norwich amd/rumba artecgroup/dbe61 asus/a8v-e_deluxe asus/a8v-e_se asus/mew-am asus/mew-vm bcom/winnetp680 digitallogic/msm800sev ecs/p6iwp-fe hp/e_vectra_p2706t iei/pcisa-lx-800-r10 intel/eagleheights intel/mtarvon jetway/j7f24 lenovo/x60 lippert/frontrunner lippert/hurricane-lx lippert/literunner-lx lippert/roadrunner-lx lippert/spacerunner-lx mitac/6513wu msi/ms6178 nec/powermate2000 pcengines/alix1c pcengines/alix2d roda/rk886ex traverse/geos tyan/s2735 via/epia-cn via/epia-m700 via/pc2500e winent/pl6064 wyse/s50 List of southbridges on those mainboards, as taken from the mainboard/Kconfig files. SOUTHBRIDGE_AMD_CS5535 SOUTHBRIDGE_AMD_CS5536 SOUTHBRIDGE_INTEL_I3100 SOUTHBRIDGE_INTEL_I82801AX SOUTHBRIDGE_INTEL_I82801EX SOUTHBRIDGE_INTEL_I82801GX SOUTHBRIDGE_INTEL_I82870 SOUTHBRIDGE_RICOH_RL5C476 SOUTHBRIDGE_TI_PCI7420 SOUTHBRIDGE_VIA_K8T890 SOUTHBRIDGE_VIA_VT8237R It appears all but the two below already have an implementation with tiny bootblock on some other mainboard: SOUTHBRIDGE_AMD_CS5535 SOUTHBRIDGE_AMD_CS5536 It may be that the only reason BIG_BOOTBLOCK gets dragged along, is that there has been no clear migration path away from it. I think there now exists a better choice, pushing the choice in menuconfig. http://review.coreboot.org/333 As a side note. I did not realise it was possible to have TINY_BOOTBLOCK without Cache-As-Ram. There was no such implementation (besides QEMU). I thought that tiny bootblock would also move memory controller initialisation away from romstage (so it could be compiled with gcc) and then utilise cache for its stack. KM

3 2

Re: [coreboot] [RFC]What to do with TINY_BOOTBLOCK?
by Patrick Georgi 24 Oct '11

24 Oct '11

Am Montag, 24. Oktober 2011 21:53:24 schrieb Marc Jones: > On Mon, Oct 24, 2011 at 12:37 PM, Kyösti Mälkki<kyosti.malkki(a)gmail.com> wrote: >> On Mon, 2011-10-24 at 10:22 -0600, Marc Jones wrote: >>> On Mon, Oct 24, 2011 at 4:15 AM, Patrick Georgi<patrick(a)georgi-clan.de> wrote: >>>> Hi all, >>>> >>>> as you may be aware, coreboot has two different ROM layouts so far. >>>> >>>> The older one is derived from what we did before CBFS, and has all code that >>>> does RAM init (our "romstage") in the bootblock (up to 64k at the top end of >>>> the image). This worked for a long time, but required some hackery for >>>> supporting dual-image scenarios (like fallback/normal, where we normal >>>> passed control to fallback by jumping to start-8 bytes), and it also broke >>>> when AMD's RAM setup became so complicated that it doesn't fit in 64k >>>> anymore. >>>> Those 64k are mandated by ROM mappings of various chipsets which, by >>>> default, only provide access to the upper 64k. >>>> >>>> The newer one, created after the CBFS switch and exploiting its features, >>>> has a tiny bootblock (hence the name), often less than 1k, which implements >>>> some policy: By default, it simply looks up "fallback/romstage" in CBFS and >>>> executes it. Our other policy does the old fallback/normal routine (using a >>>> counter in nvram), but executing files in CBFS as well, instead of jumping >>>> into the void and hoping that there's code there. >>>> >>>> The problem with the new approach is that it requires full ROM mapping >>>> rather early. Boards whose romstage fit in the 64k were free to defer >>>> setting up mapping to whereever it is convenient inside the romstage, so >>>> it's not all that easy to identify without means to test it. Unfortunately, >>>> this is a runtime problem, not a build problem, so it's hard to test all our >>>> 160 boards. For this reason, we kept both mechanisms in the tree, under the >>>> monikers BIG_BOOTBLOCK and TINY_BOOTBLOCK. >>>> >>>> Some chipsets that are in common use were converted rather early, so by now, >>>> 100 boards use tiny bootblock, while 60 use the old method. >>>> Since then - not much happened. >>>> >>>> Kyösti Mälkki recently brought this issue up again (thanks!), and proposes >>>> to invert the flags, making tiny bootblock the default, so "big" bootblock >>>> has to be requested explicitely and also adding some "maybe" flag for boards >>>> that might just work. This is quite a large change, but I fear it'll bring >>>> relatively little progress - people will just copy the TINY_NO_BOOTBLOCK (or >>>> what it's called in the latest patch iteration) flag and move on. >>>> >>>> Therefore, I propose (http://review.coreboot.org/#change,320) to get rid of >>>> the "big bootblock" variant altogether. This might break some boards >>>> (silently: they still build, but they fail on boot), but at least it forces >>>> action to fix them. >>>> >>>> Advantages: >>>> - one flag less to care about >>>> - more uniform feature set (big bootblock didn't support any fallback >>>> mechanism) >>>> - more opportunities to clean out and simplify the build system and code - >>>> there are some crude workarounds to make both mechanisms work >>>> >>>> Disadvantages: >>>> - Boards might be broken for a long time until someone tries them again. The >>>> visible result is that the boot fails early (ie. no error signalling at all, >>>> the system simply hangs, nothing visible). >>>> >>>> It's possible to determine all boards that _might_ be affected (those that >>>> use a big bootblock now), so I could add that list to the commit message, >>>> hopefully helping whoever stumbles over this issue. >>>> >>>> Comments? >>>> >>> >>> Hi Patrick, >>> >>> I think that this makes sense. It seems like the change would improve >>> the build and standardize early coreboot. I think that we can support >>> developers in the porting for those platforms when they come up. The >>> ROM decode is a typically a southbridge setting, so do you know what >>> southbridges would be untested? >>> >>> Marc >>> >>> >> >> Hello Marc >> >> I am glad this topic brings up discussion. >> >> List of mainboards that currently do not select TINY_BOOTBLOCK >> and do not select ROMCC in Kconfig: >> >> aaeon/pfm-540i_revb >> amd/db800 >> amd/norwich >> amd/rumba >> artecgroup/dbe61 >> asus/a8v-e_deluxe >> asus/a8v-e_se >> asus/mew-am >> asus/mew-vm >> bcom/winnetp680 >> digitallogic/msm800sev >> ecs/p6iwp-fe >> hp/e_vectra_p2706t >> iei/pcisa-lx-800-r10 >> intel/eagleheights >> intel/mtarvon >> jetway/j7f24 >> lenovo/x60 >> lippert/frontrunner >> lippert/hurricane-lx >> lippert/literunner-lx >> lippert/roadrunner-lx >> lippert/spacerunner-lx >> mitac/6513wu >> msi/ms6178 >> nec/powermate2000 >> pcengines/alix1c >> pcengines/alix2d >> roda/rk886ex >> traverse/geos >> tyan/s2735 >> via/epia-cn >> via/epia-m700 >> via/pc2500e >> winent/pl6064 >> wyse/s50 >> >> List of southbridges on those mainboards, as taken from the >> mainboard/Kconfig files. >> >> SOUTHBRIDGE_AMD_CS5535 >> SOUTHBRIDGE_AMD_CS5536 >> SOUTHBRIDGE_INTEL_I3100 >> SOUTHBRIDGE_INTEL_I82801AX >> SOUTHBRIDGE_INTEL_I82801EX >> SOUTHBRIDGE_INTEL_I82801GX >> SOUTHBRIDGE_INTEL_I82870 >> SOUTHBRIDGE_RICOH_RL5C476 >> SOUTHBRIDGE_TI_PCI7420 >> SOUTHBRIDGE_VIA_K8T890 >> SOUTHBRIDGE_VIA_VT8237R >> >> It appears all but the two below already have an implementation with >> tiny bootblock on some other mainboard: >> >> SOUTHBRIDGE_AMD_CS5535 >> SOUTHBRIDGE_AMD_CS5536 >> >> It may be that the only reason BIG_BOOTBLOCK gets dragged along, is that >> there has been no clear migration path away from it. I think there now >> exists a better choice, pushing the choice in menuconfig. >> >> http://review.coreboot.org/333 >> >> >> As a side note. I did not realise it was possible to have TINY_BOOTBLOCK >> without Cache-As-Ram. There was no such implementation (besides QEMU). >> I thought that tiny bootblock would also move memory controller >> initialisation away from romstage (so it could be compiled with gcc) and >> then utilise cache for its stack. > > i think that the change for 5535/5536 should be fine. There is a SB > rom decode register that has to be written, but that should be it. Sounds simple. A side note: In my drop-tinybootblock patch, I changed the MTRR behaviour of romcc boards to not require the XIP_ROM_BASE, but to calculate it from current EIP and XIP_ROM_SIZE instead. This should be safe, unless XIP_ROM_SIZE doesn't cover the entire code section, which would be a problem with the AUTO_XIP_ROM_BASE trick, too. I'll split this in a separate patch again (tomorrow), but other than that: Shall we go that route with the various CAR setups, too? It eliminates the link-twice trick we use, and should have no negative impact. Essentially, the AUTO_XIP_ROM_BASE code is replaced by dummyname: movl dummyname, %eax; andl CONFIG_XIP_ROM_SIZE, %eax; orl MTRR_something, %eax; // as usual It's all based on that MTRR configuration is defined to match: addr & mtrr_size = mttr_base & mtrr_size (as taken from the intel manual) That is, MTRRs always cover a power-of-two sized area (size = x) with alignment x. Patrick

1 0

Patch merged into coreboot/master: 478a377 Various fixes to cbfstool.
by gerrit＠coreboot.org 24 Oct '11

24 Oct '11

the following patch was just integrated into master: commit 478a377df0f0ba6f891d87b0746c3da9febdcd40 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Fri Oct 21 14:24:57 2011 -0700 Various fixes to cbfstool. - add ntohll and htonll (as coreboot parses 64bit fields now) - use the same byte swapping code across platforms - detect endianess early - fix lots of warnings - Don't override CFLAGS in Makefile Change-Id: Iaea02ff7a31ab6a95fd47858d0efd9af764a3e5f Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Build-Tested: build bot (Jenkins) at Mon Oct 24 20:14:39 2011, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Mon Oct 24 20:29:29 2011, giving +2 See http://review.coreboot.org/313 for details. -gerrit

1 0

Patch set updated for coreboot: 478a377 Various fixes to cbfstool.
by Stefan Reinauer 24 Oct '11

24 Oct '11

Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/313 -gerrit commit 478a377df0f0ba6f891d87b0746c3da9febdcd40 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Fri Oct 21 14:24:57 2011 -0700 Various fixes to cbfstool. - add ntohll and htonll (as coreboot parses 64bit fields now) - use the same byte swapping code across platforms - detect endianess early - fix lots of warnings - Don't override CFLAGS in Makefile Change-Id: Iaea02ff7a31ab6a95fd47858d0efd9af764a3e5f Signed-off-by: Stefan Reinauer <reinauer(a)google.com> --- util/cbfstool/Makefile | 13 ++++------- util/cbfstool/cbfs-mkpayload.c | 10 ++++---- util/cbfstool/cbfs-mkstage.c | 18 ++++++---------- util/cbfstool/cbfs.h | 24 ++++++++++---------- util/cbfstool/cbfstool.c | 25 ++++++++++++++++++---- util/cbfstool/common.c | 18 ++++++++-------- util/cbfstool/common.h | 16 +++++++------- util/cbfstool/swab.h | 44 ++++++++++++++++++++++++++++++++++++++++ 8 files changed, 110 insertions(+), 58 deletions(-) diff --git a/util/cbfstool/Makefile b/util/cbfstool/Makefile index 843e677..0b61342 100644 --- a/util/cbfstool/Makefile +++ b/util/cbfstool/Makefile @@ -1,9 +1,10 @@ obj ?= $(shell pwd) -HOSTCXX ?= g++ -HOSTCC ?= gcc -CFLAGS ?= -g - +HOSTCXX ?= g++ +HOSTCC ?= gcc +CFLAGS ?= -g -Wall +CXXFLAGS ?=-DCOMPACT $(CFLAGS) +LDFLAGS ?= -g BINARY:=$(obj)/cbfstool @@ -44,9 +45,5 @@ clean: tags: ctags *.[ch] -CXXFLAGS=-DCOMPACT -g -CFLAGS=-g -LDFLAGS=-g - $(obj)/cbfstool:$(COMMON) $(HOSTCXX) $(LDFLAGS) -o $@ $^ diff --git a/util/cbfstool/cbfs-mkpayload.c b/util/cbfstool/cbfs-mkpayload.c index baa92ff..ff6479d 100644 --- a/util/cbfstool/cbfs-mkpayload.c +++ b/util/cbfstool/cbfs-mkpayload.c @@ -152,9 +152,9 @@ int parse_elf_to_payload(unsigned char *input, unsigned char **output, if (phdr[i].p_filesz == 0) { segs[segments].type = PAYLOAD_SEGMENT_BSS; segs[segments].load_addr = - (unsigned long long)htonl(phdr[i].p_paddr); + (uint64_t)htonll(phdr[i].p_paddr); segs[segments].mem_len = - (unsigned int)htonl(phdr[i].p_memsz); + (uint32_t)htonl(phdr[i].p_memsz); segs[segments].offset = htonl(doffset); segments++; @@ -162,8 +162,8 @@ int parse_elf_to_payload(unsigned char *input, unsigned char **output, } segs[segments].type = PAYLOAD_SEGMENT_DATA; - segs[segments].load_addr = (unsigned int)htonl(phdr[i].p_paddr); - segs[segments].mem_len = (unsigned int)htonl(phdr[i].p_memsz); + segs[segments].load_addr = (uint64_t)htonll(phdr[i].p_paddr); + segs[segments].mem_len = (uint32_t)htonl(phdr[i].p_memsz); segs[segments].compression = htonl(algo); segs[segments].offset = htonl(doffset); @@ -190,7 +190,7 @@ int parse_elf_to_payload(unsigned char *input, unsigned char **output, } segs[segments].type = PAYLOAD_SEGMENT_ENTRY; - segs[segments++].load_addr = (unsigned long long)htonl(ehdr->e_entry); + segs[segments++].load_addr = (uint64_t)htonll(ehdr->e_entry); *output = sptr; diff --git a/util/cbfstool/cbfs-mkstage.c b/util/cbfstool/cbfs-mkstage.c index 2f81da0..c9163ef 100644 --- a/util/cbfstool/cbfs-mkstage.c +++ b/util/cbfstool/cbfs-mkstage.c @@ -36,10 +36,12 @@ unsigned int idemp(unsigned int x) return x; } -unsigned int swap32(unsigned int x) +/* This is a wrapper around the swab32() macro to make it + * usable for the current implementation of parse_elf_to_stage() + */ +static unsigned int swap32(unsigned int x) { - return ((x >> 24) | ((x >> 8) & 0xff00) | ((x << 8) & 0xff0000) | - (x << 24)); + return swab32(x); } unsigned int (*elf32_to_native) (unsigned int) = idemp; @@ -59,7 +61,6 @@ int parse_elf_to_stage(unsigned char *input, unsigned char **output, unsigned int data_start, data_end, mem_end; int elf_bigendian = 0; - int host_bigendian = 0; comp_func_ptr compress = compression_function(algo); if (!compress) @@ -73,11 +74,6 @@ int parse_elf_to_stage(unsigned char *input, unsigned char **output, if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) { elf_bigendian = 1; } - char test[4] = "1234"; - uint32_t inttest = *(uint32_t *) test; - if (inttest == 0x31323334) { - host_bigendian = 1; - } if (elf_bigendian != host_bigendian) { elf32_to_native = swap32; } @@ -171,10 +167,10 @@ int parse_elf_to_stage(unsigned char *input, unsigned char **output, stage = (struct cbfs_stage *)out; - stage->load = data_start; + stage->load = data_start; /* FIXME: htonll */ stage->memlen = mem_end - data_start; stage->compression = algo; - stage->entry = ehdr->e_entry; + stage->entry = ehdr->e_entry; /* FIXME: htonll */ compress(buffer, data_end - data_start, (char *)(out + sizeof(struct cbfs_stage)), (int *)&stage->len); diff --git a/util/cbfstool/cbfs.h b/util/cbfstool/cbfs.h index 5c93838..cdd0030 100644 --- a/util/cbfstool/cbfs.h +++ b/util/cbfstool/cbfs.h @@ -29,7 +29,7 @@ struct cbfs_header { } __attribute__ ((packed)); struct cbfs_file { - char magic[8]; + uint8_t magic[8]; uint32_t len; uint32_t type; uint32_t checksum; @@ -37,11 +37,11 @@ struct cbfs_file { } __attribute__ ((packed)); struct cbfs_stage { - unsigned int compression; - unsigned long long entry; - unsigned long long load; - unsigned int len; - unsigned int memlen; + uint32_t compression; + uint64_t entry; + uint64_t load; + uint32_t len; + uint32_t memlen; } __attribute__ ((packed)); #define PAYLOAD_SEGMENT_CODE 0x45444F43 @@ -51,12 +51,12 @@ struct cbfs_stage { #define PAYLOAD_SEGMENT_ENTRY 0x52544E45 struct cbfs_payload_segment { - unsigned int type; - unsigned int compression; - unsigned int offset; - unsigned long long load_addr; - unsigned int len; - unsigned int mem_len; + uint32_t type; + uint32_t compression; + uint32_t offset; + uint64_t load_addr; + uint32_t len; + uint32_t mem_len; } __attribute__ ((packed)); struct cbfs_payload { diff --git a/util/cbfstool/cbfstool.c b/util/cbfstool/cbfstool.c index f017b2e..b8abb51 100644 --- a/util/cbfstool/cbfstool.c +++ b/util/cbfstool/cbfstool.c @@ -19,7 +19,9 @@ */ #include <stdio.h> +#include <stdlib.h> #include <string.h> +#include <ctype.h> #include "common.h" #include "cbfs.h" @@ -196,7 +198,6 @@ static int cbfs_add_stage(int argc, char **argv) static int cbfs_create(int argc, char **argv) { char *romname = argv[1]; - char *cmd = argv[2]; if (argc < 5) { printf("not enough arguments to 'create'.\n"); return 1; @@ -239,7 +240,6 @@ static int cbfs_locate(int argc, char **argv) static int cbfs_print(int argc, char **argv) { char *romname = argv[1]; - char *cmd = argv[2]; void *rom = loadrom(romname); if (rom == NULL) { @@ -254,7 +254,6 @@ static int cbfs_print(int argc, char **argv) static int cbfs_extract(int argc, char **argv) { char *romname = argv[1]; - char *cmd = argv[2]; void *rom = loadrom(romname); if (rom == NULL) { @@ -271,7 +270,7 @@ static int cbfs_extract(int argc, char **argv) return extract_file_from_cbfs(romname, argv[3], argv[4]); } -struct command commands[] = { +static const struct command commands[] = { {CMD_ADD, "add", cbfs_add}, {CMD_ADD_PAYLOAD, "add-payload", cbfs_add_payload}, {CMD_ADD_STAGE, "add-stage", cbfs_add_stage}, @@ -281,7 +280,7 @@ struct command commands[] = { {CMD_EXTRACT, "extract", cbfs_extract}, }; -void usage(void) +static void usage(void) { printf ("cbfstool: Management utility for CBFS formatted ROM images\n\n" @@ -302,6 +301,20 @@ void usage(void) print_supported_filetypes(); } +/* Small, OS/libc independent runtime check + * for endianess + */ +int host_bigendian = 0; + +static void which_endian(void) +{ + char test[4] = "1234"; + uint32_t inttest = *(uint32_t *) test; + if (inttest == 0x31323334) { + host_bigendian = 1; + } +} + int main(int argc, char **argv) { int i; @@ -311,6 +324,8 @@ int main(int argc, char **argv) return 1; } + which_endian(); + char *cmd = argv[2]; for (i = 0; i < ARRAY_SIZE(commands); i++) { diff --git a/util/cbfstool/common.c b/util/cbfstool/common.c index cbf0757..df74421 100644 --- a/util/cbfstool/common.c +++ b/util/cbfstool/common.c @@ -26,7 +26,7 @@ #include "cbfs.h" #include "elf.h" -#define dprintf +#define dprintf(x...) uint32_t getfilesize(const char *filename) { @@ -118,7 +118,7 @@ int cbfs_file_header(uint32_t physaddr) struct cbfs_file *cbfs_create_empty_file(uint32_t physaddr, uint32_t size) { struct cbfs_file *nextfile = (struct cbfs_file *)phys_to_virt(physaddr); - strncpy(nextfile->magic, "LARCHIVE", 8); + strncpy((char *)(nextfile->magic), "LARCHIVE", 8); nextfile->len = htonl(size); nextfile->type = htonl(0xffffffff); nextfile->checksum = 0; // FIXME? @@ -231,6 +231,7 @@ int extract_file_from_cbfs(const char *filename, const char *payloadname, const uint32_t length = ntohl(thisfile->len); // Locate the file name char *fname = (char *)(phys_to_virt(current) + sizeof(struct cbfs_file)); + // It's not the file we are looking for.. if (strcmp(fname, payloadname) != 0) { @@ -267,7 +268,8 @@ int extract_file_from_cbfs(const char *filename, const char *payloadname, const // We'll only dump one file. return 0; } - + printf("File %s not found.\n", payloadname); + return 1; } @@ -332,8 +334,7 @@ int add_file_to_cbfs(void *content, uint32_t contentsize, uint32_t location) thisfile->len = htonl(location - current - ntohl(thisfile->offset)); - struct cbfs_file *nextfile = - cbfs_create_empty_file(location, + cbfs_create_empty_file(location, length - (location - current)); @@ -376,7 +377,7 @@ void *create_cbfs_file(const char *filename, void *data, uint32_t * datasize, } memset(newdata, 0xff, *datasize + headersize); struct cbfs_file *nextfile = (struct cbfs_file *)newdata; - strncpy(nextfile->magic, "LARCHIVE", 8); + strncpy((char *)(nextfile->magic), "LARCHIVE", 8); nextfile->len = htonl(*datasize); nextfile->type = htonl(type); nextfile->checksum = 0; // FIXME? @@ -421,8 +422,7 @@ int create_cbfs_image(const char *romfile, uint32_t _romsize, recalculate_rom_geometry(romarea); - struct cbfs_file *one_empty_file = - cbfs_create_empty_file((0 - romsize) & 0xffffffff, + cbfs_create_empty_file((0 - romsize) & 0xffffffff, romsize - bootblocksize - sizeof(struct cbfs_header) - sizeof(struct cbfs_file) - 16); @@ -439,7 +439,7 @@ static int in_segment(int addr, int size, int gran) uint32_t cbfs_find_location(const char *romfile, uint32_t filesize, const char *filename, uint32_t alignment) { - void *rom = loadrom(romfile); + loadrom(romfile); int filename_size = strlen(filename); int headersize = diff --git a/util/cbfstool/common.h b/util/cbfstool/common.h index 8f397d8..7034e0c 100644 --- a/util/cbfstool/common.h +++ b/util/cbfstool/common.h @@ -17,23 +17,23 @@ */ #include <stdint.h> -#ifndef WIN32 -#include <arpa/inet.h> -#else -#define ntohl(x) (((x)>>24) | ((x)<<24) | (((x)>>8)&0xff00) | (((x)<<8)&0xff0000)) -#define htonl ntohl -#endif +#include "swab.h" +#define ntohl(x) (host_bigendian?(x):swab32(x)) +#define htonl(x) (host_bigendian?(x):swab32(x)) +#define ntohll(x) (host_bigendian?(x):swab64(x)) +#define htonll(x) (host_bigendian?(x):swab64(x)) extern void *offset; extern struct cbfs_header *master_header; extern uint32_t phys_start, phys_end, align, romsize; +extern int host_bigendian; -static void *phys_to_virt(uint32_t addr) +static inline void *phys_to_virt(uint32_t addr) { return offset + addr; } -static uint32_t virt_to_phys(void *addr) +static inline uint32_t virt_to_phys(void *addr) { return (unsigned long)(addr - offset) & 0xffffffff; } diff --git a/util/cbfstool/swab.h b/util/cbfstool/swab.h new file mode 100644 index 0000000..c5e4370 --- /dev/null +++ b/util/cbfstool/swab.h @@ -0,0 +1,44 @@ +#ifndef _SWAB_H +#define _SWAB_H + +/* + * linux/byteorder/swab.h + * Byte-swapping, independently from CPU endianness + * swabXX[ps]?(foo) + * + * Francois-Rene Rideau <fare(a)tunes.org> 19971205 + * separated swab functions from cpu_to_XX, + * to clean up support for bizarre-endian architectures. + * + * See asm-i386/byteorder.h and suches for examples of how to provide + * architecture-dependent optimized versions + * + */ + +/* casts are necessary for constants, because we never know how for sure + * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way. + */ +#define swab16(x) \ + ((unsigned short)( \ + (((unsigned short)(x) & (unsigned short)0x00ffU) << 8) | \ + (((unsigned short)(x) & (unsigned short)0xff00U) >> 8) )) + +#define swab32(x) \ + ((unsigned int)( \ + (((unsigned int)(x) & (unsigned int)0x000000ffUL) << 24) | \ + (((unsigned int)(x) & (unsigned int)0x0000ff00UL) << 8) | \ + (((unsigned int)(x) & (unsigned int)0x00ff0000UL) >> 8) | \ + (((unsigned int)(x) & (unsigned int)0xff000000UL) >> 24) )) + +#define swab64(x) \ + ((uint64_t)( \ + (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) | \ + (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) | \ + (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) | \ + (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) << 8) | \ + (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >> 8) | \ + (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) | \ + (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) | \ + (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56) )) + +#endif /* _SWAB_H */

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
51
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2011