2015-02-26 21:56 GMT+01:00 Aaron Durbin <adurbin(a)chromium.org>:
> I reproduced the error. I was trying to figure out how to debug it. I
> entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and
> typed make. Everything worked... I'm trying again. I'm not really sure
> why one way would fail and the other not.
Interesting.
Paul, could you try executing buildgcc manually (not through a make rule)?
If that works, there's some make environment stuff that survives and
breaks things.
Patrick
--
Google Germany GmbH
ABC-Str. 19
20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Dear coreboot folks,
Am Sonntag, den 08.09.2013, 15:27 +0100 schrieb Mark Mc:
> Unfortunately it wont compile the rom without crossgcc compiling for both
> platforms, my crossgcc-build.log ends with and appears to have no other
> failures than:
>
> cc1: fatal error: .vis: No such file or directory
> compilation terminated.
> make[5]: *** [libunwind.o] Error 1
> make[4]: *** [multi-do] Error 1
> make[3]: *** [all-multi] Error 2
> make[2]: *** [all-target-libgcc] Error 2
> /usr/bin/install: cannot stat ‘libgcc.a’: No such file or directory
> make[3]: *** [install-leaf] Error 1
> make[2]: *** [install-target-libgcc] Error 2
trying to build the recommended toolchain for Google Rush, I am hitting
the same problem in latest master at commit 6529c33a (build: mipsel
cross compiler support).
`make crossgcc-aarch64` succeeds, but `make crossgcc-arm` fails.
$ make crossgcc-arm
Warning: no suitable GCC for arm.
Warning: no suitable GCC for arm64.
Warning: no suitable GCC for riscv.
Warning: no suitable GCC for mipsel.
fatal: Repository '/home/paul/src/nvidia-cbootimage.git' existiert nicht.
Klonen von '/home/paul/src/nvidia-cbootimage.git' in Submodul-Pfad 'util/nvidia/cbootimage' fehlgeschlagen
Welcome to the coreboot cross toolchain builder v1.26 (February 23th, 2015)
Target arch is now armv7-a-eabi
Will skip GDB ... ok
Downloading tar balls ...
* gmp-5.1.2.tar.bz2 (downloading)
* mpfr-3.1.2.tar.bz2 (downloading)
* mpc-1.0.3.tar.gz (downloading)
* libelf-0.8.13.tar.gz (downloading)
* gcc-4.8.3.tar.bz2 (downloading)
* binutils-2.23.2.tar.bz2 (downloading)
* acpica-unix-20140114.tar.gz (downloading)
Downloaded tar balls ... ok
Unpacking and patching ...
* gmp-5.1.2.tar.bz2
* mpfr-3.1.2.tar.bz2
* mpc-1.0.3.tar.gz
* libelf-0.8.13.tar.gz
* gcc-4.8.3.tar.bz2
* binutils-2.23.2.tar.bz2
o binutils-2.23.2_armv7a.patch
o binutils-2.23.2_no-bfd-doc.patch
* acpica-unix-20140114.tar.gz
Unpacked and patched ... ok
Building GMP 5.1.2 ... ok
Building MPFR 3.1.2 ... ok
Building MPC 1.0.3 ... ok
Building libelf 0.8.13 ... ok
Building binutils 2.23.2 ... ok
Building GCC 4.8.3 ... failed
Makefile:21: recipe for target 'build-armv7a-without-gdb' failed
make[1]: *** [build-armv7a-without-gdb] Error 1
Makefile.inc:455: recipe for target 'crossgcc-arm' failed
make: *** [crossgcc-arm] Error 2
Please find the log attached. I am using Debian Sid/unstable.
$ more util/crossgcc/build-armv7-a-eabi-gcc/crossgcc-build.log
configure.ac:34: error: Please use exactly Autoconf 2.64 instead of 2.69.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:34: the top level
[…]
config.status: executing default commands
Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc
with_multisubdir=fpu
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes]
__gnu_h2f_internal(unsigned short a, int ieee)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes]
__gnu_f2h_ieee(unsigned int a)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes]
__gnu_h2f_ieee(unsigned short a)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes]
__gnu_f2h_alternative(unsigned int x)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes]
__gnu_h2f_alternative(unsigned short a)
^
In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0:
../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry':
../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual]
ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content;
^
cc1: fatal error: .vis: No such file or directory
compilation terminated.
../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed
make[5]: *** [libunwind.o] Error 1
Makefile:1104: recipe for target 'multi-do' failed
make[4]: *** [multi-do] Error 1
Makefile:113: recipe for target 'all-multi' failed
make[3]: *** [all-multi] Error 2
Makefile:9962: recipe for target 'all-target-libgcc' failed
make[2]: *** [all-target-libgcc] Error 2
/usr/bin/install: der Aufruf von stat für „libgcc.a“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Makefile:1066: recipe for target 'install-leaf' failed
make[3]: *** [install-leaf] Error 1
Makefile:10024: recipe for target 'install-target-libgcc' failed
make[config.status: executing default commands
Adding multilib support to Makefile in ../../../../gcc-4.8.3/libgcc
with_multisubdir=fpu
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S: Assembler messages:
../../../../gcc-4.8.3/libgcc/config/arm/lib1funcs.S:351: use of r15 in bx in ARM mode is not really useful
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:97:1: warning: no previous prototype for '__gnu_h2f_internal' [-Wmissing-prototypes]
__gnu_h2f_internal(unsigned short a, int ieee)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:122:1: warning: no previous prototype for '__gnu_f2h_ieee' [-Wmissing-prototypes]
__gnu_f2h_ieee(unsigned int a)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:128:1: warning: no previous prototype for '__gnu_h2f_ieee' [-Wmissing-prototypes]
__gnu_h2f_ieee(unsigned short a)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:134:1: warning: no previous prototype for '__gnu_f2h_alternative' [-Wmissing-prototypes]
__gnu_f2h_alternative(unsigned int x)
^
../../../../gcc-4.8.3/libgcc/config/arm/fp16.c:140:1: warning: no previous prototype for '__gnu_h2f_alternative' [-Wmissing-prototypes]
__gnu_h2f_alternative(unsigned short a)
^
In file included from ../../../../gcc-4.8.3/libgcc/config/arm/unwind-arm.c:143:0:
../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc: In function 'get_eit_entry':
../../../../gcc-4.8.3/libgcc/unwind-arm-common.inc:245:29: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual]
ucbp->pr_cache.ehtp = (_Unwind_EHT_Header *)&eitp->content;
^
cc1: fatal error: .vis: No such file or directory
compilation terminated.
../../../../gcc-4.8.3/libgcc/static-object.mk:28: recipe for target 'libunwind.o' failed
make[5]: *** [libunwind.o] Error 1
Makefile:1104: recipe for target 'multi-do' failed
make[4]: *** [multi-do] Error 1
Makefile:113: recipe for target 'all-multi' failed
make[3]: *** [all-multi] Error 2
Makefile:9962: recipe for target 'all-target-libgcc' failed
make[2]: *** [all-target-libgcc] Error 2
/usr/bin/install: der Aufruf von stat für „libgcc.a“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Makefile:1066: recipe for target 'install-leaf' failed
make[3]: *** [install-leaf] Error 1
Makefile:10024: recipe for target 'install-target-libgcc' failed
make[2]: *** [install-target-libgcc] Error 22]: *** [install-target-libgcc] Error 2
[…]
Thanks,
Paul
On Thu, Feb 26, 2015 at 8:10 AM, Patrick Georgi via coreboot
<coreboot(a)coreboot.org> wrote:
> 2015-02-26 16:23 GMT+01:00 Emilian Bold <emilian.bold(a)gmail.com>:
>> It seems that Coreboot doesn't have reproducible builds yet.
> You're right, it doesn't. One of the major items is probably to
> replace the current build time stamps with something more reasonable.
> For example, the current commit's time stamp (unless the tree is
> dirty, in which reproducability is impossible).
>
There are two facets to this issue:
- when an image needs to built from source, we want the binary to be
the same. In case the tree is dirty we might include a hash of the
tree diffs against the top SHA1, just a thought.
- build always recompiles some files and relinks the image, even if
there is not source code changes. Is this really necessary, shouldn't
make just do nothing in case the source did not change?
--vb
>> I think Coreboot should adopt this concept.
> Patches accepted.
>
>>
>> It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've
>> noticed is that even if I extract the CONFIG_ values the build still needs
>> some manual tweaking.
>>
>> Ideally we should record the tools used (crossgcc version, etc), the
> We do.
>
>> coreboot git revision id,
> We do.
>
>> the CONFIG_ values and the build info for the
> We optionally do.
>
>> payloads (for the auto-downloaded SeaBIOS I think just the git revision id
>> would be enough).
> Payloads are more intricate. I'd stick with the coreboot parts, that
> is, a coreboot build without adding a payload is bit-identical. Then
> do the same for the payload (we can add meta-data to cbfs files or
> store payload information in a separate cbfs file).
>
>> Is there anyone willing to help me with this (or already working on this)?
> Like Peter I'm happy to review changesets on gerrit.
>
>
> Patrick
> --
> Google Germany GmbH
> ABC-Str. 19
> 20354 Hamburg
>
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
2015-02-26 16:23 GMT+01:00 Emilian Bold <emilian.bold(a)gmail.com>:
> It seems that Coreboot doesn't have reproducible builds yet.
You're right, it doesn't. One of the major items is probably to
replace the current build time stamps with something more reasonable.
For example, the current commit's time stamp (unless the tree is
dirty, in which reproducability is impossible).
> I think Coreboot should adopt this concept.
Patches accepted.
>
> It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've
> noticed is that even if I extract the CONFIG_ values the build still needs
> some manual tweaking.
>
> Ideally we should record the tools used (crossgcc version, etc), the
We do.
> coreboot git revision id,
We do.
> the CONFIG_ values and the build info for the
We optionally do.
> payloads (for the auto-downloaded SeaBIOS I think just the git revision id
> would be enough).
Payloads are more intricate. I'd stick with the coreboot parts, that
is, a coreboot build without adding a payload is bit-identical. Then
do the same for the payload (we can add meta-data to cbfs files or
store payload information in a separate cbfs file).
> Is there anyone willing to help me with this (or already working on this)?
Like Peter I'm happy to review changesets on gerrit.
Patrick
--
Google Germany GmbH
ABC-Str. 19
20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Emilian Bold wrote:
> It seems that Coreboot doesn't have reproducible builds yet.
That is correct.
> Ideally
Yep.
> Is there anyone willing to help me with this (or already working on this)?
Yes, I am willing to help you review your patches when they are in
Gerrit.
//Peter
Hello,
I was trying to duplicate a coreboot build back in November and I noticed I
couldn't get my ROM file to be identical to the one I found online.
It seems that Coreboot doesn't have reproducible builds yet.
Debian has been looking into this for a while
https://wiki.debian.org/ReproducibleBuilds and I think Coreboot should
adopt this concept.
It seems like we are halfway there with INCLUDE_CONFIG_FILE but what I've
noticed is that even if I extract the CONFIG_ values the build still needs
some manual tweaking.
Ideally we should record the tools used (crossgcc version, etc), the
coreboot git revision id, the CONFIG_ values and the build info for the
payloads (for the auto-downloaded SeaBIOS I think just the git revision id
would be enough). If the timestamps and such are cleaned we should get a
reproducible ROM.
Is there anyone willing to help me with this (or already working on this)?
--emi
ron minnich wrote:
> > > logo with half of the rotation attached (15° instead of 30° backwards).
> >
> > I really like this one. Nice!
>
> Very nice. I like the one on the left best.
Same here.
//Peter
Yes Patrick, you get me right.
Why should we spread the work that can be commonly done by the I2C
controller driver
over several slave drivers.
I was concerned of several issues on the I2C bus due to the following
policy:
I2C is a slow, low bandwidth bus, let us do the single transfers byte
wise in the background task.
This has two disadvantages:
1. If you have a serious bug and you have to look at the physical bus
level to get a clue what is going on there,
you have to capture a lot of time with an oscilloscope and your single
transfers will be interrupted by huge gaps
(because the transfers are spitted and other things happens in between).
This makes it really hard to analyze.
2. There is a bigger chance to mess up the slave. If that is happen, you
can get a hanging I2C bus. And in the worst case
you will have to power-cycle your slave (and in the most cases your
board as well) to get the slave in the working condition again.
In my point of view, it is much better to keep transfers on I2C bus as
close as possible together to avoid errors.
Werner
Am 20.02.2015 um 17:30 schrieb Patrick Georgi via coreboot:
> 2015-02-19 21:12 GMT+01:00 Peter Stuge <peter(a)stuge.se>:
>>> I think the question is really what we would gain from this.
>> I think it's less about performance and more about an accurate and
>> clean model being available to mainboard code when needed.
> From discussing things with Werner, one of his concerns (as I
> understood them) was higher stability in light of picky I2C devices:
> When you schedule the entire communication in one pass, the
> (sufficiently capable) controller makes sure that things happen in the
> right order and at the right time. If some of that is arbitrated by
> CPU code, there's more room for error.
>
> Even for the I2C controllers that essentially bitbang things with no
> help by the controller chip, that should help avoid mistakes, since
> all the nasty warts of I2C (of which were seem to be many) are managed
> in the bus driver, not in every single slave driver.
>
>
> Patrick
Julius Werner wrote:
> > We maybe can expand it to have informations like time-out or
> > retry count for a given segment.
>
> One word of caution I'd like to add here is that making this API more
> complex/powerful requires significant effort, now and in the future.
Not if the architecture is any good.
> We already have 4 I2C driver implementations in coreboot, and 4 more
> are going to be upstreamed soon from the Chromium tree. As we scale up
> to we'll probably add at least one new driver per SoC vendor, maybe
> even per SoC. Adding complex functionality like retries to the API
> will require us to account for it over an over again in every single
> implementation.
No - that doesn't make any sense. Probably there will be a fair bit
of code that can be shared among controllers. There aren't that many
ways to implement I²C.
> I think the question is really what we would gain from this.
I think it's less about performance and more about an accurate and
clean model being available to mainboard code when needed.
//Peter
Thank you very much, this helped a lot! Now memtest is loading and it
successfully performs RAM tests.
But there is another issue. Somehow, input via serial console does not
work. And it seems like the problem is not in memtest, rather it's in
SeaBIOS or coreboot. There is no any prompt for input in coreboot. But
there is in SeaBIOS, and I was not able to enter boot menu since it did
not respond to F12. Although, SeaBIOS responds to the keyboard that is
directly connected to the board while memtest does not seem to respond
at all (at least, I tried to hit Esc which should reboot the board).
I've tried to search for this but so far found nothing.
Will appreciate any help.
Viktor
On 23.01.2015 18:47, Aaron Durbin wrote:
> On Fri, Jan 23, 2015 at 1:45 AM, Kuzmichev Viktor
> <kuzmichevviktorv(a)gmail.com> wrote:
>> Hello Stefan,
>>
>> Thank you for the tip, I'm currently looking into that. But I'm still not
>> sure how to specify the load address. My guess is that I should edit the
>> linking script properly to do it. By default it looks as follows
>> (memtest.lds):
>>
>> OUTPUT_FORMAT("elf32-i386");
>> OUTPUT_ARCH(i386);
>>
>> ENTRY(_start);
>> SECTIONS {
>> . = 0x10000;
>> _start = . ;
>> .data : {
>> *(.data)
>> }
>> }
>>
>> And here is the output of 'readelf -a memtest' command:
>>
>> ELF Header:
>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>> Class: ELF32
>> Data: 2's complement, little endian
>> Version: 1 (current)
>> OS/ABI: UNIX - System V
>> ABI Version: 0
>> Type: EXEC (Executable file)
>> Machine: Intel 80386
>> Version: 0x1
>> Entry point address: 0x10000
>> Start of program headers: 52 (bytes into file)
>> Start of section headers: 239496 (bytes into file)
>> Flags: 0x0
>> Size of this header: 52 (bytes)
>> Size of program headers: 32 (bytes)
>> Number of program headers: 1
>> Size of section headers: 40 (bytes)
>> Number of section headers: 3
>> Section header string table index: 2
>>
>> Section Headers:
>> [Nr] Name Type Addr Off Size ES Flg Lk
>> Inf Al
>> [ 0] NULL 00000000 000000 000000 00 0
>> 0 0
>> [ 1] .data PROGBITS 00010000 010000 02a774 00 WA 0 0
>> 1
>> [ 2] .shstrtab STRTAB 00000000 03a774 000011 00 0
>> 0 1
>> Key to Flags:
>> W (write), A (alloc), X (execute), M (merge), S (strings)
>> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>> O (extra OS processing required) o (OS specific), p (processor specific)
>>
>> There are no section groups in this file.
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> LOAD 0x000000 0x00000000 0x00000000 0x3a774 0x3a774 RW 0x200000
>>
>> Section to Segment mapping:
>> Segment Sections...
>> 00 .data
>>
>> There is no dynamic section in this file.
>>
>> There are no relocations in this file.
>>
>> The decoding of unwind sections for machine type Intel 80386 is not
>> currently supported.
>>
>> No version information found in this file.
>>
>> So, the entry point is at the offset of 0x10000. But I think I should
>> somehow change the 'VirtAddr'. I've tried to edit the script in different
>> ways, for example, I've tried to add MEMORY command and then allocate
>> certain sections to the regions as explained here:
>> https://sourceware.org/binutils/docs/ld/REGION_005fALIAS.html#REGION_005fAL…
>> but haven't come to any success yet.
>>
>> Are there any advices you could give me? Am I even looking in the right
>> direction?
> Ya. You are on the right path. I just confirmed your findings locally.
> What you'd like to see is VirtAddr/PhysAddr = 0x10000 as well as
> offset to be 0x10000 because that would match with .data section. Also
> notice that MemSiz is 0x10000 greater than the Size of the .data
> section. So when this payload is loading all memory from 0x00000 to
> 0x10000 is filled with zeros before the start of the program at
> 0x10000.
>
> I poked around in trying to relink in different ways but it kept
> loading at 0. You could hexedit the memtest elf file. Apparently there
> is an 'ht editor' program. However, I couldn't for the life of me
> figure it out, but I was able to make it coredump trying to figure out
> how to navigate it. :/
>
> But I just found this page:
> http://dwarfdump.blogspot.com/2009/08/executable-file-editor-elf-editor.html
>
> $ hte memtest
>
> <hit space>
>
> Goto 'elf/program headers'. Hit <enter>
>
> Expand 'entry 0' with <enter>
> Goto 'offset'
> Hit <F4>.
> Make 'offset', 'virtual address', 'physical address' all to 00010000
> Make 'in file size' and 'in memory size' 00027008.
>
> Hit <F2> to save.
> Hit <F10> to quit.
>
> Those values were based on the memtest I compiled:
> $ readelf -e memtest
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x10000
> Start of program headers: 52 (bytes into file)
> Start of section headers: 225308 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 1
> Size of section headers: 40 (bytes)
> Number of section headers: 3
> Section header string table index: 2
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> [ 0] NULL 00000000 000000 000000 00 0 0 0
> [ 1] .data PROGBITS 00010000 010000 027008 00 WA 0 0 1
> [ 2] .shstrtab STRTAB 00000000 037008 000011 00 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000000 0x00000000 0x00000000 0x37008 0x37008 RW 0x200000
>
> Section to Segment mapping:
> Segment Sections...
> 00 .data
>
>
> After the instructions above I get the following:
>
> $ readelf -e memtest
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x10000
> Start of program headers: 52 (bytes into file)
> Start of section headers: 225308 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 1
> Size of section headers: 40 (bytes)
> Number of section headers: 3
> Section header string table index: 2
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> [ 0] NULL 00000000 000000 000000 00 0 0 0
> [ 1] .data PROGBITS 00010000 010000 027008 00 WA 0 0 1
> [ 2] .shstrtab STRTAB 00000000 037008 000011 00 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x010000 0x00010000 0x00010000 0x27008 0x27008 RW 0x200000
>
> Section to Segment mapping:
> Segment Sections...
> 00 .data
>
>
> Notice now that we're only loading the .data section at 0x10000. I
> hope that helps.
>
>> Thanks in advance,
>> Viktor
>>
>>
>> On 20.01.2015 22:33, Stefan Reinauer wrote:
>>> * Kuzmichev Viktor <kuzmichevviktorv(a)gmail.com> [150120 14:31]:
>>>> Hello,
>>>>
>>>> I'm trying to load Memtest86+ on the Mohon Peak reference board from
>>>> CBFS and it fails.
>>>> My primary payload is SeaBIOS. Memtest is added using cbfstool, so
>>>> the layout of my ROM file is as follows:
>>>>
>>>> $ ./build/cbfstool build/coreboot.rom print
>>>> coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset
>>>> 0x600000
>>>> alignment: 64 bytes, architecture: x86
>>>>
>>>> Name Offset Type Size
>>>> cmos_layout.bin 0x600000 cmos_layout 1352
>>>> fallback/romstage 0x600580 stage 26616
>>>> fallback/ramstage 0x606dc0 stage 60446
>>>> fallback/payload 0x615a40 payload 55799
>>>> config 0x623480 raw 4323
>>>> revision 0x6245c0 raw 714
>>>> img/Memtest86+ 0x6248c0 payload 225028
>>>> (empty) 0x65b800 null 1001368
>>>> mrc.cache 0x74ffc0 (unknown) 65536
>>>> cpu_microcode_blob.bin 0x760000 microcode 83968
>>>> (empty) 0x774840 null 46936
>>>> fsp.bin 0x77ffc0 (unknown) 372736
>>>> (empty) 0x7db000 null 150424
>>>>
>>>> I've tried versions 4.20 and 5.01. Memtest86+ v4.20 just hangs, here
>>>> is output of SeaBIOS trying to load it:
>>>> Trying CBFS
>>>> Booting from CBFS...
>>>> Run img/Memtest86+
>>>> Segment 41544144 194420@0xffe24920 -> 194420@0x00000000
>>>> No compression
>>>>
>>>> And then nothing. Memtest86+ v5.01 goes a bit further, SeaBIOS finds
>>>> its entry point:
>>>> Trying CBFS
>>>> Booting from CBFS...
>>>> Run img/Memtest86+
>>>> Segment 41544144 224972@0xffe24920 -> 224972@0x00000000
>>>> No compression
>>>> Calling addr 0x00010000
>>> It looks like in both cases memtest86+ is loaded at address 0x00000000
>>> which will overwrite a bunch of memory, including the coreboot tables.
>>> Looks like the memtest86+ elf binary needs to specify a load address.
>>>
>>> Stefan
>>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
