coreboot January 2014

coreboot@coreboot.org

54 participants
116 discussions

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by Rudolf Marek 30 Jan '14

30 Jan '14

Hi, > _F2A85-M REV 1.02 > _AMD A8-6600K APU (Radeon HD 8570D vga = 1002,990e) > _Corsair Value Select 4 Go DDR3 1333 MHz CL9 (CMV4GX3M1A1333C9) Is it Richland or Trinity? Seems it is Richland. I haven't tried with Richland yet. > I proceeded to build a standard coreboot image using seabios as a > payload (using a local copy of the VGA bios and embedding this into > the coreboot image), leaving all the settings as > default apart from selecting the motherboard, upon writing this to the > flash and rebooting the machine I had no output from the VGA & HDMI adapter and > and my keyboard is frozen. It would be helpful if you could include log from serial console. Maybe you hit some other problem. You can also try to put memory only to blue slots. > Can you send me a link to a known-good image that you use? So that i can > verify my hardware is compatible. > Does he work the revision 1.02 of this motherboard in coreboot? Mine board is also 1.02 version. I think something wrong is with memory setup or cpu setup. Does original BIOS use 1.65V for DDR2 memory? You should select that in configuration too. You can come to IRC #coreboot on freenode.net I'm here until midnight GMT+2 Thanks Rudolf > > > Thank you for your help. >

2 1

Re: [coreboot] AMD Geode LX800 - CS5536 with Coreboot v3?
by Idwer Vollering 30 Jan '14

30 Jan '14

2014-01-30 Darmawan Salihun <darmawan.salihun(a)gmail.com>: > Is this where to clone it from: > http://review.coreboot.org/coreboot.git You can find cloning instructions, and how to contribute/push changes, on this wiki page: http://www.coreboot.org/Git HTH, Idwer

1 0

Re: [coreboot] AMD Geode LX800 - CS5536 with Coreboot v3?
by Kyösti Mälkki 30 Jan '14

30 Jan '14

On 01/30/2014 09:41 AM, Darmawan Salihun wrote: > Hi all, > > Is it still possible to use Coreboot v3 for an AMD Geode LX800-CS5536 board? > Or do I have to resort to other Coreboot version? > You might be very much on your own just with the v3 build environment. I think bachmann/ot200 board is one of the most recent boards with Geode LX + CS5536 and some testing on coreboot v4. > I have all the required datasheet and circuit diagram to do the port. > The board is a custom board, not from any of the usual motherboard > manufacturers. > > Kind Regards, > > Darmawan BTW.. Thanks for your excellent articles at InfoSec on the topic of System Address map initialization on PCI. Kyösti

2 1

AMD Geode LX800 - CS5536 with Coreboot v3?
by Darmawan Salihun 30 Jan '14

30 Jan '14

Hi all, Is it still possible to use Coreboot v3 for an AMD Geode LX800-CS5536 board? Or do I have to resort to other Coreboot version? I have all the required datasheet and circuit diagram to do the port. The board is a custom board, not from any of the usual motherboard manufacturers. Kind Regards, Darmawan -------------------------------------------------------------------- -= Знания людей принадлежат миру =- [-Human knowledge belongs to the world-]

1 0

Re: [coreboot] C720 swapparoo
by Aaron Durbin 29 Jan '14

29 Jan '14

On Wed, Jan 29, 2014 at 4:11 PM, Gregg Levine <gregg.drwho8(a)gmail.com> wrote: > Hello! > Oddly enough Aaron the first one knew who my Google Mail address was, > but did not know what page it was. Whereas your second one worked. > > Now the important one which is, what does this do? And do we need to worry? Do you mean the first link I sent? That was a copy/paste error. I had an internal URL that was actually not related to cbfs at all in my copy buffer. My apologies. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > > On Wed, Jan 29, 2014 at 5:25 PM, Aaron Durbin <adurbin(a)google.com> wrote: >> On Wed, Jan 29, 2014 at 4:16 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>> On 29/01/14 22:03, Aaron Durbin wrote: >>>>> >>>>> >>>>> This is where we reach the crux of the matter - In the stock/shellball >>>>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in >>>>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in >>>>> hexedit it appears to be almost identical to a CBFS that is recognised, >>>>> but >>>>> that's it. I have managed to extract the SVGA binary from the CBFS in the >>>>> RW_LEGACY slot, and I've made an educated guess as to where the >>>>> system-agent >>>>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE >>>>> mrc.bin" or similar with the binary itself following, surrounded by FF's) >>>>> copying and pasting it to a file. I would like to know if I am correct in >>>>> my >>>>> assumptions about extracting that file manually and what size it should >>>>> be, >>>>> in bytes? >>>>> >>>> >>>> That's interesting. It is just a regular 'ol cbfs. The images that >>>> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered. >>>> The next 5 have nothing to do w/ coreboot proper -- all the extra >>>> vboot firmware bits. The last 1MiB is the cbfs. >>>> >>> >>> Okay, well I extracted the attached file using: >>> >>> eval `./fmap_decode bios.bin | grep BOOT_STUB` >>> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size)) >>> iflag=fullblock of=c720-coreboot.bin >>> >>> and: >>> >>> ../coreboot/build/cbfstool c720-coreboot.bin print >>> >>> produces: >>> >>> c720-coreboot.bin: >>> 1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 >>> alignment: 64 bytes >>> >>> Name Offset Type Size >>> >>> zippo. >>> >> >> Try cherry-picking this one: >> https://chrome-internal-review.googlesource.com/153037 >> >> -Aaron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] C720 swapparoo
by Gregg Levine 29 Jan '14

29 Jan '14

Hello! Oddly enough Aaron the first one knew who my Google Mail address was, but did not know what page it was. Whereas your second one worked. Now the important one which is, what does this do? And do we need to worry? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Wed, Jan 29, 2014 at 5:25 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, Jan 29, 2014 at 4:16 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 29/01/14 22:03, Aaron Durbin wrote: >>>> >>>> >>>> This is where we reach the crux of the matter - In the stock/shellball >>>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in >>>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in >>>> hexedit it appears to be almost identical to a CBFS that is recognised, >>>> but >>>> that's it. I have managed to extract the SVGA binary from the CBFS in the >>>> RW_LEGACY slot, and I've made an educated guess as to where the >>>> system-agent >>>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE >>>> mrc.bin" or similar with the binary itself following, surrounded by FF's) >>>> copying and pasting it to a file. I would like to know if I am correct in >>>> my >>>> assumptions about extracting that file manually and what size it should >>>> be, >>>> in bytes? >>>> >>> >>> That's interesting. It is just a regular 'ol cbfs. The images that >>> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered. >>> The next 5 have nothing to do w/ coreboot proper -- all the extra >>> vboot firmware bits. The last 1MiB is the cbfs. >>> >> >> Okay, well I extracted the attached file using: >> >> eval `./fmap_decode bios.bin | grep BOOT_STUB` >> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size)) >> iflag=fullblock of=c720-coreboot.bin >> >> and: >> >> ../coreboot/build/cbfstool c720-coreboot.bin print >> >> produces: >> >> c720-coreboot.bin: >> 1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 >> alignment: 64 bytes >> >> Name Offset Type Size >> >> zippo. >> > > Try cherry-picking this one: > https://chrome-internal-review.googlesource.com/153037 > > -Aaron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] C720 swapparoo
by John Lewis 29 Jan '14

29 Jan '14

On 29/01/14 22:03, Aaron Durbin wrote: > > The issue w.r.t. cbfstool complaining is that in the header of the > cbfs there is a field which states 8MiB rom. So you need to make an > 8MiB file with that upper 1MiB cbfs at the top. It should then read > properly. > > In other words: rom size != cbfs size. > I now know what you meant by the above - the CBFS header contains a value which defines the size of the file it comes as part of. The file size was wrong versus this value, so cbfstool couldn't read it properly. I guess, therefore, that in the older generation of Chromebooks the header value was just 1 MB, hence why it had to be extracted with fmap_decode and dd. The new rom "format" negates the need to do that, which is nice. :) Thanks again, -John

1 0

Re: [coreboot] C720 swapparoo
by John Lewis 29 Jan '14

29 Jan '14

On 29/01/14 22:49, Aaron Durbin wrote: >> >> Okay. I ran: >> >> git fetch http://review.coreboot.org/coreboot refs/changes/71/4771/1 && git >> checkout FETCH_HEAD >> >> then ran make, which updated the binary, but still no change in reading the >> file. >> >> I also compiled and ran the cbfstool in ./util in case that was somehow >> different, but same result. > > I did this w/ the ChromeOS coreboot: > > $ dd if=/dev/zero of=spi.bin bs=1M count=7 > $ cat spi.bin c720-coreboot.bin > c720-coreboot-8MiB.bin > $ cbfstool c720-coreboot-8MiB.bin print > c720-coreboot-8MiB.bin: 8192 kB, bootblocksize 3144, romsize 8388608, > offset 0x700000 > alignment: 64 bytes, architecture: x86 > > Name Offset Type Size > cmos_layout.bin 0x700000 cmos_layout 1164 > pci8086,0406.rom 0x7004c0 optionrom 65536 > cpu_microcode_blob.bin 0x710500 microcode 41024 > config 0x71a5c0 raw 5541 > fallback/vboot 0x71bbc0 stage 15081 > (empty) 0x71f700 null 2136 > fallback/romstage 0x71ff80 stage 42497 > fallback/coreboot_ram 0x72a600 stage 91421 > fallback/payload 0x740b80 payload 54921 > u-boot.dtb 0x74e280 (unknown) 7923 > (empty) 0x7501c0 null 327128 > mrc.bin 0x79ffc0 (unknown) 190180 > (empty) 0x7ce700 null 120984 > spd.bin 0x7ebfc0 (unknown) 1792 > (empty) 0x7ec700 null 76888 > > The file you use with cbfstool needs to match the header rom size. In > this case it is 8MiB. > > Hope that helps. > > -Aaron > Yep, that's it. Thanks very much. I don't pretend to understand how the CBFS portion relates to the rest of the ROM, I just know the ROM format here is a little different to the older generation Chromebooks. FTR, the mrc.bin I extracted manually was the right size! ;) -John

1 0

Re: [coreboot] C720 swapparoo
by John Lewis 29 Jan '14

29 Jan '14

On 29/01/14 22:27, Aaron Durbin wrote: > On Wed, Jan 29, 2014 at 4:25 PM, Aaron Durbin <adurbin(a)google.com> wrote: >> On Wed, Jan 29, 2014 at 4:16 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>> On 29/01/14 22:03, Aaron Durbin wrote: >>>>> >>>>> >>>>> This is where we reach the crux of the matter - In the stock/shellball >>>>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in >>>>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in >>>>> hexedit it appears to be almost identical to a CBFS that is recognised, >>>>> but >>>>> that's it. I have managed to extract the SVGA binary from the CBFS in the >>>>> RW_LEGACY slot, and I've made an educated guess as to where the >>>>> system-agent >>>>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE >>>>> mrc.bin" or similar with the binary itself following, surrounded by FF's) >>>>> copying and pasting it to a file. I would like to know if I am correct in >>>>> my >>>>> assumptions about extracting that file manually and what size it should >>>>> be, >>>>> in bytes? >>>>> >>>> >>>> That's interesting. It is just a regular 'ol cbfs. The images that >>>> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered. >>>> The next 5 have nothing to do w/ coreboot proper -- all the extra >>>> vboot firmware bits. The last 1MiB is the cbfs. >>>> >>> >>> Okay, well I extracted the attached file using: >>> >>> eval `./fmap_decode bios.bin | grep BOOT_STUB` >>> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size)) >>> iflag=fullblock of=c720-coreboot.bin >>> >>> and: >>> >>> ../coreboot/build/cbfstool c720-coreboot.bin print >>> >>> produces: >>> >>> c720-coreboot.bin: >>> 1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 >>> alignment: 64 bytes >>> >>> Name Offset Type Size >>> >>> zippo. >>> >> >> Try cherry-picking this one: >> https://chrome-internal-review.googlesource.com/153037 > > Ugh. If only my copy/past worked. Try this one instead: > http://review.coreboot.org/#/c/4771/ > Okay. I ran: git fetch http://review.coreboot.org/coreboot refs/changes/71/4771/1 && git checkout FETCH_HEAD then ran make, which updated the binary, but still no change in reading the file. I also compiled and ran the cbfstool in ./util in case that was somehow different, but same result. -John

2 1

Re: [coreboot] C720 swapparoo
by John Lewis 29 Jan '14

29 Jan '14

On 29/01/14 22:25, Aaron Durbin wrote: > On Wed, Jan 29, 2014 at 4:16 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 29/01/14 22:03, Aaron Durbin wrote: >>>> >>>> >>>> This is where we reach the crux of the matter - In the stock/shellball >>>> firmware, extracting BOOT_STUB doesn't yield a file which cbfstool in >>>> upstream coreboot or CrOS coreboot can decipher. Looking at the file in >>>> hexedit it appears to be almost identical to a CBFS that is recognised, >>>> but >>>> that's it. I have managed to extract the SVGA binary from the CBFS in the >>>> RW_LEGACY slot, and I've made an educated guess as to where the >>>> system-agent >>>> begins and ends in the unrecognised CBFS (section beginning "LARCHIVE >>>> mrc.bin" or similar with the binary itself following, surrounded by FF's) >>>> copying and pasting it to a file. I would like to know if I am correct in >>>> my >>>> assumptions about extracting that file manually and what size it should >>>> be, >>>> in bytes? >>>> >>> >>> That's interesting. It is just a regular 'ol cbfs. The images that >>> shipped with your device is an 8MiB SPI. First 2MiB Duncan covered. >>> The next 5 have nothing to do w/ coreboot proper -- all the extra >>> vboot firmware bits. The last 1MiB is the cbfs. >>> >> >> Okay, well I extracted the attached file using: >> >> eval `./fmap_decode bios.bin | grep BOOT_STUB` >> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size)) >> iflag=fullblock of=c720-coreboot.bin >> >> and: >> >> ../coreboot/build/cbfstool c720-coreboot.bin print >> >> produces: >> >> c720-coreboot.bin: >> 1024 kB, bootblocksize 3144, romsize 8388608, offset 0x700000 >> alignment: 64 bytes >> >> Name Offset Type Size >> >> zippo. >> > > Try cherry-picking this one: > https://chrome-internal-review.googlesource.com/153037 > > -Aaron > It seems I don't have permission to see that, as a non-Googler. -John

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2014