coreboot July 2013

coreboot@coreboot.org

45 participants
108 discussions

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by Aaron Durbin 31 Jul '13

31 Jul '13

On Wed, Jul 31, 2013 at 1:27 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: > > On 31/07/2013 17:51, Aaron Durbin wrote: > >> On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> >>> On 31/07/2013 17:11, Aaron Durbin wrote: >>> >>>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis(a)johnlewis.ie >>>> [8]> wrote: >>>> >>>>> On 31/07/2013 16:56, Aaron Durbin wrote: >>>>> >>>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <jlewis(a)johnlewis.ie >>>>>> [7][7]> wrote: >>>>>> >>>>>>> On 31/07/2013 16:43, Aaron Durbin wrote: >>>>>>> >>>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis >>>>>>>> <jlewis(a)johnlewis.ie [6][6][6]> wrote: >>>>>>>> >>>>>>>>> On 31/07/2013 16:20, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >>>>>>>>>> <adurbin(a)chromium.org [5][5][5][5]> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>>>>>>>>>> <jlewis(a)johnlewis.ie [4][4][4][4][4]> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 31/07/2013 15:33, Aaron Durbin wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis >>>>>>>>>>>>> <jlewis(a)johnlewis.ie [3][3][3][3][3]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, Just want to confirm where we are in >>>>>>>>>>>>>> terms of things working or not. The new >>>>>>>>>>>>>> system-agent binary works and recognises all 4 GB >>>>>>>>>>>>>> of RAM as long as an additional pei data field is >>>>>>>>>>>>>> added to Stefan's patches in >>>>>>>>>>>>>> http://review.coreboot.org/#/c/3831/ [1] [1] [1] >>>>>>>>>>>>>> [1] [1] [1] as detailed by Kyösti in the >>>>>>>>>>>>>> comments. The patches in >>>>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2] [2] >>>>>>>>>>>>>> [2] [2] [2] don't appear to do anything for >>>>>>>>>>>>>> >>>>>>>>>>>>>> mrc.cache (it's still zero size) and this (or >>>>>>>>>>>>>> perhaps something else) results in a time to >>>>>>>>>>>>>> SeaBIOS prompt of between 5 to 9 seconds. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I >>>>>>>>>>>>> didn't see >>>>>>>>>>>> >>>>>>>>>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >>>>>>>>>>> >>>>>>>>>>> This is your problem. I was hoping for a build.log >>>>>>>>>>> that was completely clean. The build log attached does >>>>>>>>>>> not show mrc.cache being created. Can you try the >>>>>>>>>>> following and rebuilt? dd if=/dev/zero of=mrc.cache >>>>>>>>>>> bs=16K count=1 | tr '00' '377' > mrc.cache >>>>>>>>>> >>>>>>>>>> Apologies. I am doing too many things at once. Remove >>>>>>>>>> the 'of=mrc.cache' parameter to dd. >>>>>>>>> >>>>>>>>> The good news is that cbfstool now reports a non-zero >>>>>>>>> mrc.cache, the bad news is it doesn't make any difference. >>>>>>>>> cbmem -c reports Updating MRC cache data. No FMAP found at >>>>>>>>> ffe70000. FMAP: area RW_MRC_CACHE not found >>>>>>>>> find_current_mrc_cache_local: No valid MRC cache found. SF: >>>>>>>>> Detected W25Q64 with page size 1000, total 800000 Need to >>>>>>>>> erase the MRC cache region of -1 bytes at 0011037f SF: >>>>>>>>> Erase offset/length not multiple of erase size Finally: >>>>>>>>> write MRC cache update to flash at 0011037f ICH SPI: Data >>>>>>>>> transaction error SF: Failed to send write command (1 >>>>>>>>> bytes): -1 SF: Winbond Page Program failed >>>>>>>> >>>>>>>> CONFIG_CHROMEOS=y You have that option enabled. That's why >>>>>>>> you are seeing fmap calls. Therefore, it is not using the >>>>>>>> mrc.cache cbfs file. There's also the fact that certain >>>>>>>> variables are not initialized properly and thinking the >>>>>>>> callee will initialize them. cache_base should be set to NULL >>>>>>>> in update_mrc_cache() before calling get_mrc_cahce_region(). >>>>>>>> You'll see more enlightening messages. That, or ensure >>>>>>>> get_mrc_cache_region NULL's out the parameter>>> don't enable >>>>>> >>>>>> CONFIG_CHROMEOS. > Menuconfig enables it by >>>>>>> >>>>>>> default, and there is no option to > uncheck. If I set it to >>>>>>> 'n' or comment >>>>>> >>>>>> get: > build/generated/crt0.romstage.o: In function `main': > >>>>>> >>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: > >>>>>> undefined reference to `save_chromeos_gpios' > >>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362: > >>>>>> undefined reference to `init_chromeos' > >>>>>> build/northbridge/intel/sandybridge/mrccache.romstage.o: In > >>>>>> function `get_mrc_cache_region': >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71: >>>>>> >>>>>> >>>>>> >>>>>>> undefined reference to `find_fmap_entry' >>>>>>> build/northbridge/intel/sandybridge/raminit.romstage.o: In >>>>>>> function `sdram_initialize': >>>>>> >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240: >>>>>> >>>>>> undefined reference to `recovery_mode_enabled' collect2: error: >>>>>> ld returned 1 exit status make: *** >>>>>> [build/cbfs/fallback/romstage_null.debug] Error 1 Fantastic. In >>>>>> src/mainboard/samsung/lumpy/Kconfig remove 'select CHROMEOS'. >>>>>> You'll need to do a 'make oldconfig' then rebuild. Fwiw, you >>>>>> can't set it to 'n'. It needs to be '# CONFIG_CHROMEOS is not >>>>>> set'. But since you did set it to 'n' the dependency object files >>>>>> weren't included in the link. Anyway, do a clean build after >>>>>> removing 'select CHROMEOS'. hth. -Aaron >>>>> >>>>> Okay. We are getting a bit further along now but: CC >>>>> cbfs/fallback/coreboot_ram.debug build/generated/coreboot_ram.o: In >>>>> function `acpi_create_gnvs': >>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/acpi_tables.c:102: >>>>> undefined reference to `chromeos_init_vboot' collect2: error: ld >>>>> returned 1 exit status make: *** >>>>> [build/cbfs/fallback/coreboot_ram.debug] Error 1 >>>> >>>> Try the following patch: diff --git >>>> a/src/vendorcode/google/chromeos/gnvs.h b/src/vendorcode/google/chrom >>>> index 00fe443..5384423 100644 --- >>>> a/src/vendorcode/google/chromeos/gnvs.h +++ >>>> b/src/vendorcode/google/chromeos/gnvs.h @@ -61,9 +61,13 @@ typedef >>>> struct { // dbe } __attribute__((packed)) chromeos_acpi_t; +#if >>>> CONFIG_CHROMEOS extern chromeos_acpi_t *vboot_data; void >>>> chromeos_init_vboot(chromeos_acpi_t *chromeos); void >>>> chromeos_set_me_hash(u32*, int); void acpi_get_vdat_info(uint64_t >>>> *vdat_addr, uint32_t *vdat_size); +#else +static inline void >>>> chromeos_init_vboot(chromeos_acpi_t *chromeos) {} +#endif #endif Or >>>> wrap the call in lumpy/acpi_tables.c with '#if >>>> CONFIG_CHROMEOS/#endif'. >>> >>> Okay, that worked, but cold reboot takes 5 secs to SeaBIOS, warm >>> reboot is instantaneous. cbmem -c output looks pretty healthy to me. >>> I'll attach it anyway. What do you think? >> >> >> Was the log from a warm or cold reboot? Also, what do you mean by cold >> reboot? >> >> Could you set CONFIG_LAPIC_MONOTONIC_TIMER=y? Also, if you select >> CONFIG_COLLECT_TIMESTAMPS=y as well that will provide times that can >> be read by the cbmem utility (-t option, I think). With that data we >> can do an A/B comparison of boot times for your warm vs cold. >> >> -Aaron > > > Cold, I think. Cold boot - power off and switch on again after a few > seconds. > > If I try to use both those options I get: > > src/lib/timestamp.c:35:31: error: unknown type name ‘tsc_t’ > static uint64_t tsc_to_uint64(tsc_t tstamp) > ^ > src/lib/timestamp.c:41:1: error: expected identifier or ‘(’ before ‘{’ token > { > ^ > src/lib/timestamp.c:59:1: error: expected identifier or ‘(’ before ‘{’ token > { > ^ > src/lib/timestamp.c:76:1: error: expected identifier or ‘(’ before ‘{’ token > { > ^ > make: *** [build/lib/timestamp.romstage.o] Error 1 > Hrmm. I don't understand why that is failing. cpu/x86/tsc.h should be included from timestamp.h. No idea why tsc_t isn't being defined. Well, removing CONFIG_COLLECT_TIMESTAMPS should make your build work. And we can at least see ramstage boot times.

1 0

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by John Lewis 31 Jul '13

31 Jul '13

On 31/07/2013 17:11, Aaron Durbin wrote: > On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis(a)johnlewis.ie> > wrote: > >> On 31/07/2013 16:56, Aaron Durbin wrote: >> >>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <jlewis(a)johnlewis.ie >>> [7]> wrote: >>> >>>> On 31/07/2013 16:43, Aaron Durbin wrote: >>>> >>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis <jlewis(a)johnlewis.ie >>>>> [6][6]> wrote: >>>>> >>>>>> On 31/07/2013 16:20, Aaron Durbin wrote: >>>>>> >>>>>>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >>>>>>> <adurbin(a)chromium.org [5][5][5]> wrote: >>>>>>> >>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>>>>>>> <jlewis(a)johnlewis.ie [4][4][4][4]> wrote: >>>>>>>> >>>>>>>>> On 31/07/2013 15:33, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis >>>>>>>>>> <jlewis(a)johnlewis.ie [3][3][3][3]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, Just want to confirm where we are in terms of >>>>>>>>>>> things working or not. The new system-agent binary >>>>>>>>>>> works and recognises all 4 GB of RAM as long as an >>>>>>>>>>> additional pei data field is added to Stefan's >>>>>>>>>>> patches in http://review.coreboot.org/#/c/3831/ [1] >>>>>>>>>>> [1] [1] [1] [1] as detailed by Kyösti in the >>>>>>>>>>> comments. The patches in >>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2] [2] [2] >>>>>>>>>>> [2] don't appear to do anything for mrc.cache (it's >>>>>>>>>>> still zero size) and this (or perhaps something else) >>>>>>>>>>> results in a time to SeaBIOS prompt of between 5 to 9 >>>>>>>>>>> seconds. >>>>>>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I didn't >>>>>>>>>> see >>>>>>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >>>>>>>> This is your problem. I was hoping for a build.log that >>>>>>>> was completely clean. The build log attached does not show >>>>>>>> mrc.cache being created. Can you try the following and >>>>>>>> rebuilt? dd if=/dev/zero of=mrc.cache bs=16K count=1 | tr >>>>>>>> '00' '377' > mrc.cache >>>>>>> Apologies. I am doing too many things at once. Remove the >>>>>>> 'of=mrc.cache' parameter to dd. >>>>>> The good news is that cbfstool now reports a non-zero >>>>>> mrc.cache, the bad news is it doesn't make any difference. >>>>>> cbmem -c reports Updating MRC cache data. No FMAP found at >>>>>> ffe70000. FMAP: area RW_MRC_CACHE not found >>>>>> find_current_mrc_cache_local: No valid MRC cache found. SF: >>>>>> Detected W25Q64 with page size 1000, total 800000 Need to erase >>>>>> the MRC cache region of -1 bytes at 0011037f SF: Erase >>>>>> offset/length not multiple of erase size Finally: write MRC >>>>>> cache update to flash at 0011037f ICH SPI: Data transaction >>>>>> error SF: Failed to send write command (1 bytes): -1 SF: >>>>>> Winbond Page Program failed >>>>> CONFIG_CHROMEOS=y You have that option enabled. That's why you >>>>> are seeing fmap calls. Therefore, it is not using the mrc.cache >>>>> cbfs file. There's also the fact that certain variables are not >>>>> initialized properly and thinking the callee will initialize >>>>> them. cache_base should be set to NULL in update_mrc_cache() >>>>> before calling get_mrc_cahce_region(). You'll see more >>>>> enlightening messages. That, or ensure get_mrc_cache_region >>>>> NULL's out the parameter. In short, don't enable CONFIG_CHROMEOS. >>>> Menuconfig enables it by default, and there is no option to >>>> uncheck. If I set it to 'n' or comment in .config I get: >>>> build/generated/crt0.romstage.o: In function `main': >>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: >>>> undefined reference to `save_chromeos_gpios' >>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362: >>>> undefined reference to `init_chromeos' >>>> build/northbridge/intel/sandybridge/mrccache.romstage.o: In >>>> function `get_mrc_cache_region': >>>> >>> >>> /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71: >>>> undefined reference to `find_fmap_entry' >>>> build/northbridge/intel/sandybridge/raminit.romstage.o: In >>>> function >>>> `sdram_initialize': >>>> >>> >>> /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240: >>>> undefined reference to `recovery_mode_enabled' collect2: error: ld >>>> returned 1 exit status make: *** >>>> [build/cbfs/fallback/romstage_null.debug] Error 1 >>> Fantastic. In src/mainboard/samsung/lumpy/Kconfig remove 'select >>> CHROMEOS'. You'll need to do a 'make oldconfig' then rebuild. Fwiw, >>> you can't set it to 'n'. It needs to be '# CONFIG_CHROMEOS is not >>> set'. But since you did set it to 'n' the dependency object files >>> weren't included in the link. Anyway, do a clean build after >>> removing >>> 'select CHROMEOS'. hth. -Aaron >> Okay. We are getting a bit further along now but: CC >> cbfs/fallback/coreboot_ram.debug build/generated/coreboot_ram.o: In >> function `acpi_create_gnvs': >> /home/john/coreboot/src/mainboard/samsung/lumpy/acpi_tables.c:102: >> undefined reference to `chromeos_init_vboot' collect2: error: ld >> returned 1 exit status make: *** >> [build/cbfs/fallback/coreboot_ram.debug] Error 1 > > Try the following patch: > > diff --git a/src/vendorcode/google/chromeos/gnvs.h > b/src/vendorcode/google/chrom > index 00fe443..5384423 100644 > --- a/src/vendorcode/google/chromeos/gnvs.h > +++ b/src/vendorcode/google/chromeos/gnvs.h > @@ -61,9 +61,13 @@ typedef struct { > // dbe > } __attribute__((packed)) chromeos_acpi_t; > > +#if CONFIG_CHROMEOS > extern chromeos_acpi_t *vboot_data; > void chromeos_init_vboot(chromeos_acpi_t *chromeos); > void chromeos_set_me_hash(u32*, int); > void acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size); > +#else > +static inline void chromeos_init_vboot(chromeos_acpi_t *chromeos) {} > +#endif > > #endif > > Or wrap the call in lumpy/acpi_tables.c with '#if > CONFIG_CHROMEOS/#endif'. Okay, that worked, but cold reboot takes 5 secs to SeaBIOS, warm reboot is instantaneous. cbmem -c output looks pretty healthy to me. I'll attach it anyway. What do you think?

2 1

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by John Lewis 31 Jul '13

31 Jul '13

On 31/07/2013 16:43, Aaron Durbin wrote: > On Wed, Jul 31, 2013 at 10:34 AM, John Lewis <jlewis(a)johnlewis.ie> > wrote: > >> On 31/07/2013 16:20, Aaron Durbin wrote: >> >>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >>> <adurbin(a)chromium.org >>> [5]> wrote: >>> >>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis <jlewis(a)johnlewis.ie >>>> [4][4]> wrote: >>>> >>>>> On 31/07/2013 15:33, Aaron Durbin wrote: >>>>> >>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis >>>>>> <jlewis(a)johnlewis.ie [3][3]> wrote: >>>>>> >>>>>>> Hi all, Just want to confirm where we are in terms of things >>>>>>> working or not. The new system-agent binary works and >>>>>>> recognises all 4 GB of RAM as long as an additional pei data >>>>>>> field is added to Stefan's patches in >>>>>>> http://review.coreboot.org/#/c/3831/ [1] [1] [1] as detailed >>>>>>> by Kyösti in the comments. The patches in >>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2] [2] don't appear >>>>>>> to do anything for mrc.cache (it's still zero size) and this >>>>>>> (or perhaps something else) results in a time to SeaBIOS >>>>>>> prompt of between 5 to 9 seconds. >>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I didn't see >>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >>>> This is your problem. I was hoping for a build.log that was >>>> completely clean. The build log attached does not show mrc.cache >>>> being created. Can you try the following and rebuilt? dd >>>> if=/dev/zero of=mrc.cache bs=16K count=1 | tr '00' '377' > >>>> mrc.cache >>> Apologies. I am doing too many things at once. Remove the >>> 'of=mrc.cache' parameter to dd. >> The good news is that cbfstool now reports a non-zero mrc.cache, the >> bad news is it doesn't make any difference. cbmem -c reports >> Updating >> MRC cache data. No FMAP found at ffe70000. FMAP: area RW_MRC_CACHE >> not >> found find_current_mrc_cache_local: No valid MRC cache found. SF: >> Detected W25Q64 with page size 1000, total 800000 Need to erase the >> MRC >> cache region of -1 bytes at 0011037f SF: Erase offset/length not >> multiple of erase size Finally: write MRC cache update to flash at >> 0011037f ICH SPI: Data transaction error SF: Failed to send write >> command (1 bytes): -1 SF: Winbond Page Program failed > > CONFIG_CHROMEOS=y > > You have that option enabled. That's why you are seeing fmap calls. > Therefore, it is not using the mrc.cache cbfs file. There's also the > fact that certain variables are not initialized properly and thinking > the callee will initialize them. cache_base should be set to NULL in > update_mrc_cache() before calling get_mrc_cahce_region(). You'll see > more enlightening messages. That, or ensure get_mrc_cache_region > NULL's out the parameter. > > In short, don't enable CONFIG_CHROMEOS. > Menuconfig enables it by default, and there is no option to uncheck. If I set it to 'n' or comment in .config I get: build/generated/crt0.romstage.o: In function `main': /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: undefined reference to `save_chromeos_gpios' /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362: undefined reference to `init_chromeos' build/northbridge/intel/sandybridge/mrccache.romstage.o: In function `get_mrc_cache_region': /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71: undefined reference to `find_fmap_entry' build/northbridge/intel/sandybridge/raminit.romstage.o: In function `sdram_initialize': /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240: undefined reference to `recovery_mode_enabled' collect2: error: ld returned 1 exit status make: *** [build/cbfs/fallback/romstage_null.debug] Error 1 >>>>>> CONFIG_MRC_CACHE_SIZE in your .config. Also, what does >>>>>> 'cbfstool >>>>> Menuconfig doesn't allow you specify it, and there isn't >>>>> currently a default being put in automatically. >>>>> >>>>>> image.rom print' say now? Build logs with V=1 would be helpful >>>>>> to see >>>>> coreboot.rom: 8192 kB, bootblocksize 1552, romsize 8388608, >>>>> offset 0x700000 alignment: 64 bytes Name Offset Type Size >>>>> cmos_layout.bin 0x700000 cmos_layout 1120 pci8086,0106.rom >>>>> 0x7004c0 optionrom 65536 cpu_microcode_blob.bin 0x710500 >>>>> microcode 20544 fallback/romstage 0x7155c0 stage 36438 >>>>> fallback/coreboot_ram 0x71e480 stage 294016 fallback/payload >>>>> 0x766140 payload 87816 (empty) 0x77b880 null 18200 mrc.cache >>>>> 0x77ffc0 (unknown) 0 (empty) 0x780000 null 130968 mrc.bin >>>>> 0x79ffc0 (unknown) 195732 (empty) 0x7cfcc0 null 49880 spd.bin >>>>> 0x7dbfc0 (unknown) 1536 (empty) 0x7dc600 null 144280

2 1

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by John Lewis 31 Jul '13

31 Jul '13

On 31/07/2013 16:20, Aaron Durbin wrote: > On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin <adurbin(a)chromium.org> > wrote: > >> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis <jlewis(a)johnlewis.ie >> [4]> >> wrote: >> >>> On 31/07/2013 15:33, Aaron Durbin wrote: >>> >>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis <jlewis(a)johnlewis.ie >>>> [3]> wrote: >>>> >>>>> Hi all, Just want to confirm where we are in terms of things >>>>> working or not. The new system-agent binary works and recognises >>>>> all 4 GB of RAM as long as an additional pei data field is added >>>>> to Stefan's patches in http://review.coreboot.org/#/c/3831/ [1] >>>>> [1] as detailed by Kyösti in the comments. The patches in >>>>> http://review.coreboot.org/#/c/3830/ [2] [2] don't appear to do >>>>> anything for mrc.cache (it's still zero size) and this (or >>>>> perhaps something else) results in a time to SeaBIOS prompt of >>>>> between 5 to 9 seconds. >>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I didn't see >>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >> This is your problem. I was hoping for a build.log that was >> completely >> clean. The build log attached does not show mrc.cache being created. >> Can you try the following and rebuilt? dd if=/dev/zero of=mrc.cache >> bs=16K count=1 | tr '00' '377' > mrc.cache > > Apologies. I am doing too many things at once. Remove the > 'of=mrc.cache' parameter to dd. The good news is that cbfstool now reports a non-zero mrc.cache, the bad news is it doesn't make any difference. cbmem -c reports Updating MRC cache data. No FMAP found at ffe70000. FMAP: area RW_MRC_CACHE not found find_current_mrc_cache_local: No valid MRC cache found. SF: Detected W25Q64 with page size 1000, total 800000 Need to erase the MRC cache region of -1 bytes at 0011037f SF: Erase offset/length not multiple of erase size Finally: write MRC cache update to flash at 0011037f ICH SPI: Data transaction error SF: Failed to send write command (1 bytes): -1 SF: Winbond Page Program failed > >>>> CONFIG_MRC_CACHE_SIZE in your .config. Also, what does 'cbfstool >>> Menuconfig doesn't allow you specify it, and there isn't currently >>> a >>> default being put in automatically. >>> >>>> image.rom print' say now? Build logs with V=1 would be helpful to >>>> see >>> coreboot.rom: 8192 kB, bootblocksize 1552, romsize 8388608, offset >>> 0x700000 alignment: 64 bytes Name Offset Type Size cmos_layout.bin >>> 0x700000 cmos_layout 1120 pci8086,0106.rom 0x7004c0 optionrom 65536 >>> cpu_microcode_blob.bin 0x710500 microcode 20544 fallback/romstage >>> 0x7155c0 stage 36438 fallback/coreboot_ram 0x71e480 stage 294016 >>> fallback/payload 0x766140 payload 87816 (empty) 0x77b880 null 18200 >>> mrc.cache 0x77ffc0 (unknown) 0 (empty) 0x780000 null 130968 mrc.bin >>> 0x79ffc0 (unknown) 195732 (empty) 0x7cfcc0 null 49880 spd.bin >>> 0x7dbfc0 (unknown) 1536 (empty) 0x7dc600 null 144280

2 1

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by Aaron Durbin 31 Jul '13

31 Jul '13

On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Wed, Jul 31, 2013 at 10:00 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 31/07/2013 15:33, Aaron Durbin wrote: >> >>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>> >>>> Hi all, Just want to confirm where we are in terms of things working or >>>> not. The new system-agent binary works and recognises all 4 GB of RAM >>>> as long as an additional pei data field is added to Stefan's patches in >>>> http://review.coreboot.org/#/c/3831/ [1] as detailed by Kyösti in the >>>> comments. The patches in http://review.coreboot.org/#/c/3830/ [2] don't >>>> >>>> appear to do anything for mrc.cache (it's still zero size) and this (or >>>> perhaps something else) results in a time to SeaBIOS prompt of between >>>> 5 to 9 seconds. >>> >>> >>> Can you show us 'ls -l $(obj)/mrc.cache' ? I didn't see >> >> >> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache > > This is your problem. I was hoping for a build.log that was completely > clean. The build log attached does not show mrc.cache being created. > > Can you try the following and rebuilt? > dd if=/dev/zero of=mrc.cache bs=16K count=1 | tr '\000' '\377' > mrc.cache Apologies. I am doing too many things at once. Remove the 'of=mrc.cache' parameter to dd. > >> >> >>> CONFIG_MRC_CACHE_SIZE in your .config. Also, what does 'cbfstool >> >> >> Menuconfig doesn't allow you specify it, and there isn't currently a default >> being put in automatically. >> >> >>> image.rom print' say now? Build logs with V=1 would be helpful to see >> >> >> coreboot.rom: 8192 kB, bootblocksize 1552, romsize 8388608, offset 0x700000 >> alignment: 64 bytes >> >> >> Name Offset Type Size >> cmos_layout.bin 0x700000 cmos_layout 1120 >> pci8086,0106.rom 0x7004c0 optionrom 65536 >> cpu_microcode_blob.bin 0x710500 microcode 20544 >> fallback/romstage 0x7155c0 stage 36438 >> fallback/coreboot_ram 0x71e480 stage 294016 >> fallback/payload 0x766140 payload 87816 >> (empty) 0x77b880 null 18200 >> >> mrc.cache 0x77ffc0 (unknown) 0 >> (empty) 0x780000 null 130968 >> mrc.bin 0x79ffc0 (unknown) 195732 >> (empty) 0x7cfcc0 null 49880 >> spd.bin 0x7dbfc0 (unknown) 1536 >> (empty) 0x7dc600 null 144280 >> >> >>> what is occurring when mrc.cache is being created. >> >> >> See attached build.log >> >>> >>>> I added a 64 GB SSD this afternoon, which I have working, but something >>>> strange went on with geometry - if I tried to dd the partition itself >>>> back it would crap out at 2 GB (this was after dd'ing the backed up mbr >>>> onto the new drive). If I dd'ed the whole device it worked, but the >>>> partition wouldn't mount, and fdisk would report that the partition was >>>> too large for the device. Luckily, after reboot, it worked anyway. :) >>>> Summary: if we could get rid of the 5 to 9 second delay, and just >>>> confirm the drive detection geometry is A1 I think we are there. John. >>>> -- coreboot mailing list: coreboot(a)coreboot.org [3] >>>> http://www.coreboot.org/mailman/listinfo/coreboot [4]

1 0

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by John Lewis 31 Jul '13

31 Jul '13

On 31/07/2013 15:33, Aaron Durbin wrote: > On Wed, Jul 31, 2013 at 9:24 AM, John Lewis <jlewis(a)johnlewis.ie> > wrote: > >> Hi all, Just want to confirm where we are in terms of things working >> or >> not. The new system-agent binary works and recognises all 4 GB of >> RAM >> as long as an additional pei data field is added to Stefan's patches >> in >> http://review.coreboot.org/#/c/3831/ [1] as detailed by Kyösti in >> the >> comments. The patches in http://review.coreboot.org/#/c/3830/ [2] >> don't >> appear to do anything for mrc.cache (it's still zero size) and this >> (or >> perhaps something else) results in a time to SeaBIOS prompt of >> between >> 5 to 9 seconds. > > Can you show us 'ls -l $(obj)/mrc.cache' ? I didn't see -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache > CONFIG_MRC_CACHE_SIZE in your .config. Also, what does 'cbfstool Menuconfig doesn't allow you specify it, and there isn't currently a default being put in automatically. > image.rom print' say now? Build logs with V=1 would be helpful to see coreboot.rom: 8192 kB, bootblocksize 1552, romsize 8388608, offset 0x700000 alignment: 64 bytes Name Offset Type Size cmos_layout.bin 0x700000 cmos_layout 1120 pci8086,0106.rom 0x7004c0 optionrom 65536 cpu_microcode_blob.bin 0x710500 microcode 20544 fallback/romstage 0x7155c0 stage 36438 fallback/coreboot_ram 0x71e480 stage 294016 fallback/payload 0x766140 payload 87816 (empty) 0x77b880 null 18200 mrc.cache 0x77ffc0 (unknown) 0 (empty) 0x780000 null 130968 mrc.bin 0x79ffc0 (unknown) 195732 (empty) 0x7cfcc0 null 49880 spd.bin 0x7dbfc0 (unknown) 1536 (empty) 0x7dc600 null 144280 > what is occurring when mrc.cache is being created. See attached build.log > >> I added a 64 GB SSD this afternoon, which I have working, but >> something >> strange went on with geometry - if I tried to dd the partition >> itself >> back it would crap out at 2 GB (this was after dd'ing the backed up >> mbr >> onto the new drive). If I dd'ed the whole device it worked, but the >> partition wouldn't mount, and fdisk would report that the partition >> was >> too large for the device. Luckily, after reboot, it worked anyway. >> :) >> Summary: if we could get rid of the 5 to 9 second delay, and just >> confirm the drive detection geometry is A1 I think we are there. >> John. >> -- coreboot mailing list: coreboot(a)coreboot.org [3] >> http://www.coreboot.org/mailman/listinfo/coreboot [4]

2 1

Re: [coreboot] Samsung 550 Chromebook own Coreboot
by John Lewis 31 Jul '13

31 Jul '13

Hi all, Just want to confirm where we are in terms of things working or not. The new system-agent binary works and recognises all 4 GB of RAM as long as an additional pei data field is added to Stefan's patches in http://review.coreboot.org/#/c/3831/ as detailed by Kyösti in the comments. The patches in http://review.coreboot.org/#/c/3830/ don't appear to do anything for mrc.cache (it's still zero size) and this (or perhaps something else) results in a time to SeaBIOS prompt of between 5 to 9 seconds. I added a 64 GB SSD this afternoon, which I have working, but something strange went on with geometry - if I tried to dd the partition itself back it would crap out at 2 GB (this was after dd'ing the backed up mbr onto the new drive). If I dd'ed the whole device it worked, but the partition wouldn't mount, and fdisk would report that the partition was too large for the device. Luckily, after reboot, it worked anyway. :) Summary: if we could get rid of the 5 to 9 second delay, and just confirm the drive detection geometry is A1 I think we are there. John.

2 1

Re: [coreboot] Supported laptops (again), treacherous computing
by Oliver Schinagl 30 Jul '13

30 Jul '13

On 07/30/13 18:43, ron minnich wrote: > On Tue, Jul 30, 2013 at 2:39 AM, Stefan Reinauer > <stefan.reinauer(a)coreboot.org> wrote: > >> No, but it comes with an 8k signed, binary primary bootloade that loads >> coreboot from flash. >> > > in other words, the days when we could have 0 binary blobs are fast ending. Actually, the Allwinner sun[4567]i series come with a LIKLEY GPL violating bootloader in ROM (which loads u-boot atm). While coded in hardware, we could at some point get sources for it. Why likley? We know that the BROM and their own (now GPL released) secondary (boot0) and tertiary (boot1) are build from the same source base. Defines give it away. boot[01] where released under the GPL because they where in violation by copying some trivial functions, from u-boot, but still. Our limited research shows that BROM could very well be infringing as well. The Allwinner SoC could be the first fully free SoC with 0 binary blobs. With lima (Mali GPU) and cederus (cedarX VPU) we could even have fully opensource userspace without any binary blobs! So yes, the days are comming sooner rather then later ;) > > I don't like that either. But I don't create the chips. Technical, this is acceptable by RMS's reasoning. It's firmware that cannot be modified, it's not really software in the chip, but just an IP core I suppose. > > ron >

1 0

Re: [coreboot] Supported laptops (again), treacherous computing
by Denis 'GNUtoo' Carikli 30 Jul '13

30 Jul '13

On Mon, 15 Jul 2013 08:14:22 -0700 ron minnich <rminnich(a)gmail.com> wrote: > I don't see how excluding the new, fixed version from coreboot helps > anything. Further, it means you don't have bug-fixed microcode, which > seems bad. It is at least a licensing problem: That microcode has a proprietary license in its header, with some terms that are incompatible with the GPLv2... And coreboot is released under the GPLv2. Denis.

5 6

Fwd: Re: Samsung 550 Chromebook own Coreboot
by John Lewis 30 Jul '13

30 Jul '13

Forgot to CC list *again*. I've also tried with 3831 on it's own, and that also doesn't work. John. On 30/07/2013 10:48, Kyösti Mälkki wrote: > Well, I could not make the combination of 3830 + 3831 work with > lumpy, > see attached log. Kyösti On Mon, 2013-07-29 at 15:22 -0700, Duncan > Laurie wrote: > >> Just checking to make sure it was still populated... Now we know it >> is >> the internal memory that is the issue. I suspect you may now be >> hitting >> the original issue that Stefan was trying to fix with the >> systemagent >> binary changes ( http://review.coreboot.org/#/c/3568/ [2] [7]) that >> were reverted to get this booting in the first place. Stefan has >> uploaded a patch that applies on top of the earlier reverted patch. >> You >> could try to undo the revert, switch back to the systemagent-r6 >> binary, >> and apply this new patch that was just uploaded: >> http://review.coreboot.org/#/c/3831 [3] [8] >> <http://review.coreboot.org/#/c/3831/1 [4] [9]>/ (and maybe >> http://review.coreboot.org/#/c/3830/ [5] [10] too? Stefan?) Binary >> blobs ruin all the fun. -duncan On Mon, Jul 29, 2013 at 2:50 PM, >> John >> Lewis <jlewis(a)johnlewis.ie [6][11]> wrote: >> >>> So the DIMM slot happens to be empty/seated badly on both our >>> Lumpy's? Don't think so. Mine acted like a brick with the SODIMM >>> removed. John. Duncan Laurie <dlaurie(a)chromium.org [1] [4]> wrote: >>> Lumpy should have 2GB of on-board memory and a DIMM slot that comes >>> with a 2GB DIMM. Coreboot seems to detect the on-board memory and >>> finds the SPD binary for it, any chance the DIMM slot is empty? >>> Memory Straps: - memory capacity 2GB - die revision 1 - vendor >>> Samsung CBFS: Looking for 'spd.bin' starting from 0x700000. CBFS: >>> Found file (offset=0x7dc000, len=1536). I think the console output >>> should show a summary after the MRC binary runs, but the verbose >>> CBFS >>> output is overflowing the buffer: http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/i… >>> [5] -duncan On Mon, Jul 29, 2013 at 8:14 AM, Aaron Durbin >>> <adurbin(a)chromium.org [10][6]>wrote: >>> >>>> Kyösti, I'm not certain it's just the last entry of the e820. mrc >>>> is just seeing 2GiB of ram and setting it up that way. TOUUD >>>> 0x100600000 TOLUD 0x7f200000 TOM 0x80000000 MEBASE 0x7f800000 IGD >>>> decoded, subtracting 32M UMA and 2M GTT TSEG base 0x7c800000 size >>>> 8M Available memory below 4GB: 1992M Available memory above 4GB: >>>> 6M >>>> -Aaron On Mon, Jul 29, 2013 at 10:04 AM, Kyösti Mälkki >>>> <kyosti.malkki(a)gmail.com [7][1]> wrote: >>>> >>>>> On Mon, 2013-07-29 at 15:19 +0100, John Lewis wrote: >>>>> >>>>>> Where do I find/build cbmem binary? Please find attached dmesg. >>>>> Hi I have same issue. Only about 2Gib of 4GiB installed shows. I >>>>> had not noticed this until You pointed this out. Looks like a >>>>> problem with the last entry coreboot creates in e820 memory map. >>>>> This is from your dmesg, I see same with (close to) current >>>>> master. [ 0.000000] BIOS-e820: [mem >>>>> 0x0000000100000000-0x00000001005fffff] >>>> usable >>>> >>>>> The coreboot image my Samsung 550 originally shipped with had >>>>> this: [ 0.000000] BIOS-e820: 0000000100000000 - 000000014fe00000 >>>>> (usable) Kyösti >>>> -- coreboot mailing list: coreboot(a)coreboot.org [8] [2] >>>> http://www.coreboot.org/mailman/listinfo/coreboot [9] [3]

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 July 2013