[coreboot] Mohon Peak, Memtest86+ does not start
Aaron Durbin
adurbin at chromium.org
Tue Jan 27 15:23:52 CET 2015
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