On Tue, Jan 27, 2015 at 6:59 AM, Kuzmichev Viktor <kuzmichevvikt...@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 >> <kuzmichevvikt...@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 <kuzmichevvikt...@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@coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot > > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot