coreboot September 2014

coreboot@coreboot.org

51 participants
90 discussions

Re: [coreboot] X201i RAM upgrade not working
by Vladimir 'φ-coder/phcoder' Serbinenko 21 Sep '14

21 Sep '14

On 21.09.2014 04:12, ron minnich wrote: > Here's the problem. There is caching of the DRAM configuration going > on. So, a restart is not stateless. > > I would be happier if you could guarantee that the mrc cache is > disabled, or never used, each time you change the dram setup (move > DIMMs, whatever). Because from your earlier description it sounds to > me like that is skewing your tests. > > If this makes no sense let me know. > Cache is discarded if SPD is changed. But the easy way to be sure is to delete mrc.cache in cbfs. @Mono: Do you come to Prague? > > ron >

1 0

libpayload and LGPL code
by Paul Menzel 21 Sep '14

21 Sep '14

Dear coreboot folks, Himanshu Chauhan pushed the change set `libpayload: Add Virtio layer and storage device support` for review [1]. It’d be great if somebody with expertise in that area reviewed it. Some of the files are taken from SeaBIOS and are licensed under the GNU LGPLv3. Is that allowed/wanted to be in libpayload? Thanks, Paul [1] http://review.coreboot.org/6934/

2 1

Re: [coreboot] X201i RAM upgrade not working
by Peter Stuge 21 Sep '14

21 Sep '14

ron minnich wrote: > I'm still convinced this is an issue with the code, not the insertion > of the DIMMs. Me too. > Are the DIMMs identical w.r.t. timing? Are you always plugging the > same DIMMs into the same slots, or did you try swapping them around? And are they known to be error free? //Peter

3 2

Re: [coreboot] [RFC] Gerrit: Please enable sticky scores for trivial rebases and no code changes
by Peter Stuge 20 Sep '14

20 Sep '14

David Hendricks wrote: > I also like the idea of keeping scores for trivial rebases and no code > change as well. There's no sense in having to wait for somebody to > re-approve a patch for such things. I disagree. Effectively it is saying that I have reviewed a piece of code which I have, in fact, not reviewed. A rebase with no conflicts isn't automatically correct. //Peter

2 1

Re: [coreboot] X201i RAM upgrade not working
by Mono 20 Sep '14

20 Sep '14

On Fri, Sep 12, 2014 at 03:21:06PM -0700, ron minnich wrote: > I'm still convinced this is an issue with the code, not the insertion > of the DIMMs. um, actually that is what I was trying to say with those test results. > > Are the DIMMs identical w.r.t. timing? Are you always plugging the > same DIMMs into the same slots, or did you try swapping them around? > > ron I have swapped them. The failure and the workaround appear to be not affected by swapping the DIMMs. As for the timings I am not sure at all. Maybe you could comment on this from following informations: >From what is written on the DIMMs they possibly could have the same timing, although the chip names are not identical. DIMM one stickers: ----------------------------------------- RAMAXEL 2GB 2RX8 PC3-8500S-777 HF 100280045 20103563 NK0010090120000032 RMT1970ED48E8F-1066 ----------------------------------------- *11S41R0625ZVJ5DA09XGJ6* SEP/29/2010 FRU 55Y3713 DIMM ----------------------------------------- DIMM one chips: ----------------------------------------- ELPIDA TWN J1108BDBG -DJ-F 1028RR04420 ----------------------------------------- DIMM two stickers: ----------------------------------------- RAMAXEL 2GB 2RX8 PC3-8500S-777 HF 100280045 20102314 NZ0010060530010342 RMT1970ED48E8F-1066 ----------------------------------------- *11S41R0625ZVJ5DA0737DC* FRU: 55Y3713 DIMM ----------------------------------------- DIMM two chips: ----------------------------------------- ELPIDA TWN J1108BDBG -DJ-F 10210R21520 ----------------------------------------- With the DIMMs installed separately MemTest86+ writes for both: RAM: 532 MHz (DDR3-1064) - BCLK: 133 Timings: CAS 7-7-7-20 @ 64-bit Mode Memory SPD Informations Slot 0: 2048 MB DDR3-1066 - Ramaxel RMT1970ED48E8F1066 However, I believe that they are run in Single Channel mode by coreboot. At least that is what it says in the logs. So in conclusion I do not know whether they have identical timings. with best regards, Mono

1 0

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 19 Sep '14

19 Sep '14

On 19/09/14 18:07, Aaron Durbin wrote: > On Fri, Sep 19, 2014 at 12:01 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> >> >> On 16/09/14 02:05, Aaron Durbin wrote: >>> >>> On Mon, Sep 15, 2014 at 3:46 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> On 15/09/14 23:17, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Mon, Sep 15, 2014 at 5:13 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>>>> >>>>>> >>>>>> On 15/09/14 23:10, Aaron Durbin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 15, 2014 at 5:00 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 15/09/14 22:50, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Sep 15, 2014 at 4:29 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 15/09/14 22:03, Aaron Durbin wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I've purchased the subject Chromebook with a view to getting some >>>>>>>>>>>> sort >>>>>>>>>>>> of >>>>>>>>>>>> custom ROM going for Baytrail based Chromebooks, and I have my >>>>>>>>>>>> first >>>>>>>>>>>> brick >>>>>>>>>>>> of the day. >>>>>>>>>>>> >>>>>>>>>>>> I'm using ChromeOS coreboot and the firmware-clapper-5218.B >>>>>>>>>>>> branch. >>>>>>>>>>>> As >>>>>>>>>>>> per >>>>>>>>>>>> the advice Aaron gave me regarding the ASUS C200 some time ago, I >>>>>>>>>>>> extracted >>>>>>>>>>>> the reference code binary and changed line 111 in >>>>>>>>>>>> src/arch/x86/Makefile.inc >>>>>>>>>>>> as follows: >>>>>>>>>>>> >>>>>>>>>>>> $(CBFSTOOL) $@.tmp add -f >>>>>>>>>>>> $(CONFIG_REFCODE_BLOB_FILE) >>>>>>>>>>>> -n >>>>>>>>>>>> $(CONFIG_CBFS_PREFIX)/refcode -t raw >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think I might know. You are using upstream, right? This is my >>>>>>>>>>> fault. >>>>>>>>>>> The rmodule format changed. We didn't bump the version, and >>>>>>>>>>> dropped >>>>>>>>>>> the old code. Can you run readelf -e on that blob you extracted? I >>>>>>>>>>> think I allowed ELF packaging for that file. If that doesn't work >>>>>>>>>>> (hexdump -C) would be helpful. >>>>>>>>>>> >>>>>>>>>> No, I'm using ChromiumOS coreboot. With readelf -e I get: >>>>>>>>>> >>>>>>>>>> readelf -e refcode.bin >>>>>>>>>> readelf: Error: Unable to read in 0x7115 bytes of section headers >>>>>>>>>> readelf: Error: Not an ELF file - it has the wrong magic bytes at >>>>>>>>>> the >>>>>>>>>> start >>>>>>>>>> >>>>>>>>>> hexdump -C: >>>>>>>>>> >>>>>>>>>> hexdump -C refcode.bin >>>>>>>>>> 00000000 01 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 >>>>>>>>>> |................| >>>>>>>>>> 00000010 00 00 00 00 ac 10 00 00 b8 4b 00 00 01 00 60 00 >>>>>>>>>> |.........K....`.| >>>>>>>>>> 00000020 00 a0 4b 00 00 00 00 00 00 00 7f 3f ec 22 15 71 >>>>>>>>>> |..K........?.".q| >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> snip >>>>>>>>> >>>>>>>>>> 000010b0 ea 88 85 74 8b 20 1e db 6b 09 b3 c0 40 c3 eb ed |...t. >>>>>>>>>> ..k...@...| >>>>>>>>>> 000010c0 48 a8 8d c4 08 32 85 80 >>>>>>>>>> |H....2..| >>>>>>>>>> 000010c8 >>>>>>>>>> >>>>>>>>>> You may want to snip that. ;) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> OK. A couple of things. Bear with me as I use this thread to think >>>>>>>>> things through. This file is compressed. We extracted it, and added >>>>>>>>> it >>>>>>>>> back using 'raw'. That means cbfs_file->type != CBFS_TYPE_STAGE. So >>>>>>>>> refcode loading would not work. Would it create a brick? I wouldn't >>>>>>>>> think so, but I haven't tried. >>>>>>>>> >>>>>>>>> Offhand, do you have the option rom? Do we see any life out of the >>>>>>>>> display? I'm trying to think of ways to see how far we've gotten >>>>>>>>> without serial console. Is MRC in the same place as the released >>>>>>>>> firmware? Perhaps a cbfstool print might be instructive on your >>>>>>>>> resulting image. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, I extracted all the necessary files from the shellball ROM for >>>>>>>> Clapper. >>>>>>>> No, no life from the display (no backlight even). >>>>>>>> >>>>>>>> coreboot.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset >>>>>>>> 0x400000 >>>>>>>> alignment: 64 bytes, architecture: x86 >>>>>>>> >>>>>>>> Name Offset Type Size >>>>>>>> cmos_layout.bin 0x400000 cmos_layout 1164 >>>>>>>> pci8086,0f31.rom 0x4004c0 optionrom 65536 >>>>>>>> cpu_microcode_blob.bin 0x410500 microcode 103424 >>>>>>>> config 0x429980 raw 4298 >>>>>>>> fallback/refcode 0x42aa80 raw 4296 >>>>>>>> (empty) 0x42bb80 null 17368 >>>>>>>> fallback/romstage 0x42ff80 stage 35171 >>>>>>>> fallback/coreboot_ram 0x438980 stage 71515 >>>>>>>> fallback/payload 0x44a140 payload 34866 >>>>>>>> img/Jeltka 0x4529c0 payload 2970296 >>>>>>>> (empty) 0x727cc0 null 492248 >>>>>>>> mrc.bin 0x79ffc0 (unknown) 70168 >>>>>>>> (empty) 0x7b1240 null 240984 >>>>>>>> spd.bin 0x7ebfc0 (unknown) 1536 >>>>>>>> (empty) 0x7ec600 null 79064 >>>>>>>> >>>>>>>>> >>>>>>>>> After bricking the device can you re-flash the spi part back to a >>>>>>>>> released image? >>>>>>>>> >>>>>>>> I don't see why not, but it's getting late here and people are >>>>>>>> sleeping >>>>>>>> so >>>>>>>> I'll have to do that in the morning. If there's anything else quick >>>>>>>> I'll >>>>>>>> hang around this end for 10 or so minutes to answer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Understood. The only thing I can think of trying really quickly is >>>>>>> making the type of the file to be a stage instead of raw. You'll need >>>>>>> to hexedit the rom to change the type. >>>>>>> >>>>>>> -Aaron >>>>>>> >>>>>> >>>>>> Okay, fire away, I have it open and ready. >>>>> >>>>> >>>>> >>>>> In your rom, find the "LARCHIVE" tombstone with the appropriate name >>>>> afterwards ('fallback/refcode). It should be around offset 0x42aa80. >>>>> For reference: >>>>> >>>>> struct cbfs_file { >>>>>> >>>>>> >>>>>> -------char magic[8]; >>>>>> -------uint32_t len; >>>>>> -------uint32_t type; >>>>>> -------uint32_t checksum; >>>>>> -------uint32_t offset; >>>>> >>>>> >>>>> } __attribute__((packed)); >>>>> >>>>> We want to change the type field. There should be a hex 0x50 >>>>> associated with the fallback/refcode file. Change that number to be >>>>> 0x10. Save and then cbfstool print should list the type as 'stage'. >>>>> >> >> I'm trying to flash the ROM externally now, but it's telling me it can't >> disable block protection. It gets as far as trying to erase 0x600000, then >> goes through all the erase functions, finally crapping out. Do you know how >> I can work-around that? > > The write protect screw is removed, right? After that the flash's > write protect register needs to be updated. Do you know the status > register values? Flashrom should be able to do that. > Yes, it is definitely removed - I didn't put it back in after the initial brick. It says the register value is 0x94 - I did also hook up the Bus Pirate for use with statically linked ChromeOS Flashrom (as the particular version I have doesn't have Dediprog support) - I had an idea running --wp-disable might help, but it didn't recognise the chip and said the register was already 0x94 (paraphrasing). I am currently compiling a newer statically linked version of ChromeOS Flashrom using the SDK, in the hope that might be able to do the job. Am I barking up the wrong tree though, or is there something else I could do? John.

2 1

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 19 Sep '14

19 Sep '14

On 16/09/14 02:05, Aaron Durbin wrote: > On Mon, Sep 15, 2014 at 3:46 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 15/09/14 23:17, Aaron Durbin wrote: >>> >>> On Mon, Sep 15, 2014 at 5:13 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> On 15/09/14 23:10, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Mon, Sep 15, 2014 at 5:00 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 15/09/14 22:50, Aaron Durbin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 15, 2014 at 4:29 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 15/09/14 22:03, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I've purchased the subject Chromebook with a view to getting some >>>>>>>>>> sort >>>>>>>>>> of >>>>>>>>>> custom ROM going for Baytrail based Chromebooks, and I have my >>>>>>>>>> first >>>>>>>>>> brick >>>>>>>>>> of the day. >>>>>>>>>> >>>>>>>>>> I'm using ChromeOS coreboot and the firmware-clapper-5218.B branch. >>>>>>>>>> As >>>>>>>>>> per >>>>>>>>>> the advice Aaron gave me regarding the ASUS C200 some time ago, I >>>>>>>>>> extracted >>>>>>>>>> the reference code binary and changed line 111 in >>>>>>>>>> src/arch/x86/Makefile.inc >>>>>>>>>> as follows: >>>>>>>>>> >>>>>>>>>> $(CBFSTOOL) $@.tmp add -f $(CONFIG_REFCODE_BLOB_FILE) >>>>>>>>>> -n >>>>>>>>>> $(CONFIG_CBFS_PREFIX)/refcode -t raw >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think I might know. You are using upstream, right? This is my >>>>>>>>> fault. >>>>>>>>> The rmodule format changed. We didn't bump the version, and dropped >>>>>>>>> the old code. Can you run readelf -e on that blob you extracted? I >>>>>>>>> think I allowed ELF packaging for that file. If that doesn't work >>>>>>>>> (hexdump -C) would be helpful. >>>>>>>>> >>>>>>>> No, I'm using ChromiumOS coreboot. With readelf -e I get: >>>>>>>> >>>>>>>> readelf -e refcode.bin >>>>>>>> readelf: Error: Unable to read in 0x7115 bytes of section headers >>>>>>>> readelf: Error: Not an ELF file - it has the wrong magic bytes at the >>>>>>>> start >>>>>>>> >>>>>>>> hexdump -C: >>>>>>>> >>>>>>>> hexdump -C refcode.bin >>>>>>>> 00000000 01 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 >>>>>>>> |................| >>>>>>>> 00000010 00 00 00 00 ac 10 00 00 b8 4b 00 00 01 00 60 00 >>>>>>>> |.........K....`.| >>>>>>>> 00000020 00 a0 4b 00 00 00 00 00 00 00 7f 3f ec 22 15 71 >>>>>>>> |..K........?.".q| >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> snip >>>>>>> >>>>>>>> 000010b0 ea 88 85 74 8b 20 1e db 6b 09 b3 c0 40 c3 eb ed |...t. >>>>>>>> ..k...@...| >>>>>>>> 000010c0 48 a8 8d c4 08 32 85 80 >>>>>>>> |H....2..| >>>>>>>> 000010c8 >>>>>>>> >>>>>>>> You may want to snip that. ;) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> OK. A couple of things. Bear with me as I use this thread to think >>>>>>> things through. This file is compressed. We extracted it, and added it >>>>>>> back using 'raw'. That means cbfs_file->type != CBFS_TYPE_STAGE. So >>>>>>> refcode loading would not work. Would it create a brick? I wouldn't >>>>>>> think so, but I haven't tried. >>>>>>> >>>>>>> Offhand, do you have the option rom? Do we see any life out of the >>>>>>> display? I'm trying to think of ways to see how far we've gotten >>>>>>> without serial console. Is MRC in the same place as the released >>>>>>> firmware? Perhaps a cbfstool print might be instructive on your >>>>>>> resulting image. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Yes, I extracted all the necessary files from the shellball ROM for >>>>>> Clapper. >>>>>> No, no life from the display (no backlight even). >>>>>> >>>>>> coreboot.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset >>>>>> 0x400000 >>>>>> alignment: 64 bytes, architecture: x86 >>>>>> >>>>>> Name Offset Type Size >>>>>> cmos_layout.bin 0x400000 cmos_layout 1164 >>>>>> pci8086,0f31.rom 0x4004c0 optionrom 65536 >>>>>> cpu_microcode_blob.bin 0x410500 microcode 103424 >>>>>> config 0x429980 raw 4298 >>>>>> fallback/refcode 0x42aa80 raw 4296 >>>>>> (empty) 0x42bb80 null 17368 >>>>>> fallback/romstage 0x42ff80 stage 35171 >>>>>> fallback/coreboot_ram 0x438980 stage 71515 >>>>>> fallback/payload 0x44a140 payload 34866 >>>>>> img/Jeltka 0x4529c0 payload 2970296 >>>>>> (empty) 0x727cc0 null 492248 >>>>>> mrc.bin 0x79ffc0 (unknown) 70168 >>>>>> (empty) 0x7b1240 null 240984 >>>>>> spd.bin 0x7ebfc0 (unknown) 1536 >>>>>> (empty) 0x7ec600 null 79064 >>>>>> >>>>>>> >>>>>>> After bricking the device can you re-flash the spi part back to a >>>>>>> released image? >>>>>>> >>>>>> I don't see why not, but it's getting late here and people are sleeping >>>>>> so >>>>>> I'll have to do that in the morning. If there's anything else quick >>>>>> I'll >>>>>> hang around this end for 10 or so minutes to answer. >>>>> >>>>> >>>>> >>>>> Understood. The only thing I can think of trying really quickly is >>>>> making the type of the file to be a stage instead of raw. You'll need >>>>> to hexedit the rom to change the type. >>>>> >>>>> -Aaron >>>>> >>>> >>>> Okay, fire away, I have it open and ready. >>> >>> >>> In your rom, find the "LARCHIVE" tombstone with the appropriate name >>> afterwards ('fallback/refcode). It should be around offset 0x42aa80. >>> For reference: >>> >>> struct cbfs_file { >>>> >>>> -------char magic[8]; >>>> -------uint32_t len; >>>> -------uint32_t type; >>>> -------uint32_t checksum; >>>> -------uint32_t offset; >>> >>> } __attribute__((packed)); >>> >>> We want to change the type field. There should be a hex 0x50 >>> associated with the fallback/refcode file. Change that number to be >>> 0x10. Save and then cbfstool print should list the type as 'stage'. >>> I'm trying to flash the ROM externally now, but it's telling me it can't disable block protection. It gets as far as trying to erase 0x600000, then goes through all the erase functions, finally crapping out. Do you know how I can work-around that? John.

2 1

Baytrail SD card interface
by Wen Wang 18 Sep '14

18 Sep '14

Hello all, Does the current baytrail fsp coreboot code support SD/uSD card interface? Is anybody able to get it to work on Bayley Bay CRB? It does not seem to work on our CRB. We checked the SD3_PWREN signal, it always remains high and therefore the SD card doesn't get any power. Thanks, Wen

4 7

Re: [coreboot] MinnowMax: Tentative patch for S3 suspend/resume support
by Mohan 18 Sep '14

18 Sep '14

>> Also need to add a "Signed-off-by:" to my patch. > Yes, and gerrit will force you to do that when you do the git push. > Stop in #coreboot if you have questions or problems on your first > commit. Once it is in gerrit. > > Regards, > Marc > > > Thanks for the information. I have managed to created a review for this on Gerrit. Regards, Mohan

1 0

Re: [coreboot] 回复： Could not find a bounce buffer tested in minnowmax
by Mohan 18 Sep '14

18 Sep '14

On 09/18/14 14:01, DM365 wrote: > Thanks for your help. > Where can I change the IFD (Intel FlashDesciptor) ? > ‍ > > I took 4M from original BIOS image and attached the 4M coreboot.rom to the end of the file. eg. $ dd if=original_minnowmax_BIOS.bin of=BIOS.bin bs=1M count=4 $ dd if=coreboot.rom >> BIOS.bin - Mohan

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2014