coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

Re: [coreboot] coreboot: amd debug
by Timothy Pearson 03 Feb '15

03 Feb '15

On 02/03/2015 01:43 PM, Alexander Couzens wrote: > Hi Timothy, > > thanks for your work on coreboot. I've here some amd boards which I would like to write support for coreboot. > I'm wondering how you debug your amd boards? Do you have jtag support? > > Best, > Alex I did not need to use JTAG when porting as there was already partially-functional K10 support in coreboot. I used the serial console mostly, and as the ROM was socketed it was fastest to simply hot-swap ROMs between a good vendor BIOS and the coreboot development image. What family of processor and northbridge are you looking to support? -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

1 0

Re: [coreboot] Mohon Peak, Memtest86+ does not start
by Kuzmichev Viktor 02 Feb '15

02 Feb '15

Hello, So, I've checked the memtest source files recently. And I guess, I was wrong when I thought that SeaBIOS should control serial IO. There is code in memtest (file named lib.c) that should handle serial input itself. I've added a debug message in the check_input() function and it seems like memtest just does not receive any input. Any suggestions? Viktor On 28.01.2015 06:23, Martin Roth wrote: > Hi Viktor, > I mentioned on the mailing list that Sage has done a read/write > implementation for SeaBIOS. You can find a copy of that SeaBIOS code > in the Gizmo BSP on this page: > http://www.gizmosphere.org/gizmoboard-support/resources/ > > Download the Gizmo BSP, extract it, and go to the > Gizmo_Reference/coreboot/payloads/seabios directory and run make > menuconfig. Enable 'Enable serial console to receive keystrokes'. > > This SeaBIOS tree is pretty out of date, but that's the feature you're > looking for. > > Hope this helps. > Martin > > On 01/27/2015 05:59 AM, Kuzmichev Viktor 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. >> >> 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 >> >> >

1 0

Asus F2A85-M
by Kuba Kukielka 01 Feb '15

01 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I was wanting to get a board that is compatible with coreboot and the Asus F2A85-M was the choice for me as it has DDR-3 RAM. But, after looking on the internet, the only board I could find was the PRO version, which is not supported. The wiki mentioned that it could be easily supported. After looking on the wiki, I found something talking about the CPUs. The only ones mentioned where: AMD Athlon X2 340 AMD Athlon X4 740 AMD Athlon X4 750k Are these the only ones supported? I own a AMD Athlon(tm) II X2 240 Processor so I don't know if it it compatible with this board. (I will need to upgrade it anyway but it would be nice if it was supported) Thanks, -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUzmxtAAoJEI2NIwdfk/klRmUP/0OViwUuYdbZI6iGy8G3GFXh si1hewDg1ZP9VgkdG9jbRbq2ktY82tTNW3B5tqeiz+Bll5Cil4RamgmAX8V2vucx YS1wt0vqAMIORlDUCF32i5AsiG2XyTWRCoaLNBwpV32pkv9JtkaUF2IGuZHME71J TXWbk2h0lVxZ6lQyGIW5hMEmuM2nWKNXrBbVS6hr+32WP0OYiqIlsvUBJt47YmPr KZUNxGcfNwmWVo1hoZBJTB5EbAiQojasCANBGMH6vXkGXNHO2z8YkpH+6Yw0KbnG MS5mfuaMAEPfXx+ZZbQKguY7zjyTw0wI3sec6866tZz0575CwDTQSQKgD6y1nDrm AydD0Jhat7EdeWsowhmha1o2wllDv16DOpepcrC3R4Q3g83lNwzrImGzAIUJaDjC r1Fua8I7QBc6r30sN+hu1XXad6ghfq5c2IknYdOEaA7VQWMUvDI+6vztfl5E58Ii J9NDwfpBPrOFgXCtCqjtMX+uSf5xWNa3Au6gTn54mH25pSho6m4/BZnHSGtO8Rme qSw7KuVSb760gAcZgpEOdOUnlo9HJbd3xmmQl2P3etAvV5alOW4nNuYwKsmPGk5b ZTgPgEFIR7jfE1TiahuCoweW16R3u35hfNkNsD6yWQCPGpv6uuldf0GLOmgIzkH/ SvL+gV9WqhB7bLt0JjCr =mfxO -----END PGP SIGNATURE-----

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2015