[coreboot] Mohon Peak, Memtest86+ does not start

Martin Roth gaumless at gmail.com
Wed Jan 28 04:16:58 CET 2015


Hi Viktor,

   SeaBIOS serial console is currently output only.  Someone would need 
to add a change to read from the serial port and stuff the value into 
the keyboard buffer or something similar for it to be bi-directional.  I 
know that Sage has already done this, but I don't believe that it was 
ever posted to the SeaBIOS mailing list.

For the keyboard, PS/2 keyboards should work, but I don't believe any 
USB keyboards work with memtest86+.  SMM USB implementations MIGHT work, 
but since neither coreboot or SeaBIOS support it, that doesn't help.

Also, you might need to reverse the memory size checks in memtest.  It 
checks for the coreboot memory tables first and uses those if it finds 
them.  This means that any memory reservations that SeaBIOS added are 
not respected.  I had sent a patch to fix this for the 5.0 memtest86+ 
release, but it didn't get included in the final 5.01 release.  You 
should see in memsize.c mem_size() where the order of query_linuxbios() 
and query_pcbios()  can be reversed.

Martin

On 01/27/2015 07:23 AM, Aaron Durbin wrote:
> On Tue, Jan 27, 2015 at 6:59 AM, Kuzmichev Viktor
> <kuzmichevviktorv at gmail.com> wrote:
>> 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.
> I've never actually ran that setup. Hopefully someone on the list can
> help in that area.
>
>> Viktor
>>
>>
>> On 23.01.2015 18:47, Aaron Durbin wrote:
>>> On Fri, Jan 23, 2015 at 1:45 AM, Kuzmichev Viktor
>>> <kuzmichevviktorv at 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_005fALIAS
>>>> 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 at 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 at 0xffe24920 -> 194420 at 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 at 0xffe24920 -> 224972 at 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 at coreboot.org
>>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>




More information about the coreboot mailing list