From stefan.reinauer at coreboot.org  Wed Sep  2 00:26:38 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Wed, 2 Sep 2015 00:26:38 +0000
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
Message-ID: <20150902002637.GA17208@coreboot.org>

* John Lewis <jlewis at johnlewis.ie> [150830 18:43]:
> Hi Guys,
> 
> Coolstar Organisation wants to do his Windows thang with one of the
> Broadwell Chromebooks, so I'm trying to build a working ROM with chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B
> to give him a hand. Luckily USB debug works with this, so here is
> what I'm getting. What could I do next?
 
Do you happen to know if the hang happens at the same spot when using
serial?


> Incidentally, if I flash back my backup, it goes into recovery mode
> now every time I boot (flags are 0x489), I've tried pulling the
> battery to no avail. If anyone has a trick to get around that, I'd
> appreciate it, as the Acer is my main machine.
 
What is the recovery reason? (<TAB> at the recovery screen)


> -?John.
> 
> coreboot-?5cbe3a8-?dirty romstage Sun Aug 23 12:18:55 BST 2015
> starting...
> 
> PM1_STS:   8910
> 
> PM1_EN:    0000
> 
> PM1_CNT:   00000000
> 
> TCO_STS:   0000 0000
> 
> GPE0_STS:  1ef82df0 187d4fdf 0005f240 00000000
> 
> GPE0_EN:   00000000 00000000 00000000 00000000
> 
> GEN_PMCON: 0200 2024 520b
> 
> Previous Sleep State: S5
> 
> CPU: Intel(R) Core(TM) i3-?5005U CPU @ 2.00GHz
> 
> CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d
> 
> CPU: AES supported, TXT NOT supported, VT supported
> 
> MCH: device id 1604 (rev 09) is Broadwell F0
> 
> PCH: device id 9cc5 (rev 03) is Broadwell U Base
> 
> IGD: device id 1616 (rev 09) is Broadwell U GT2
> 
> CPU: frequency set to 2000 MHz
> 
> SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)
> 
> SPD: module type is DDR3
> 
> SPD: module part is HMT425S6AFR6A-?PB
> 
> SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
> 
> SPD: device width 16 bits, bus width 64 bits
> 
> SPD: module size is 2048 MB (per channel)
> 
> Boot Count incremented to 8
> 
> ME: FW Partition Table      : OK
> 
> ME: Bringup Loader Failure  : NO
> 
> ME: Firmware Init Complete  : NO
> 
> ME: Manufacturing Mode      : NO
> 
> ME: Boot Options Present    : NO
> 
> ME: Update In Progress      : NO
> 
> ME: Current Working State   : Normal
> 
> ME: Current Operation State : Bring up
> 
> ME: Current Operation Mode  : Normal
> 
> ME: Error Code              : No Error
> 
> ME: Progress Phase          : BUP Phase
> 
> ME: Power Management Event  : Pseudo-?global reset
> 
> ME: Progress Phase State    : Waiting for DID BIOS message
> 
> ME: HSIO Version            : 8705 (CRC 0xfbc2)
> 
> No FMAP found at ffe10000.
> 
> FMAP: area RW_MRC_CACHE not found
> 
> No MRC cache found.
> 
> Starting Memory Reference Code
> 
> Initializing Policy
> 
> Installing common PPI
> 
> MRC: Starting...
> 
> Initializing Memory
> 
> MRC: Done.
> 
> MRC Version 2.6.0 Build 0
> 
> memcfg DDR3 clock 1600 MHz
> 
> memcfg channel assignment: A: 0, B  1, C  2
> 
> memcfg channel[0] config (00780008):
> 
>    enhanced interleave mode on
> 
>    rank interleave on
> 
>    DIMMA 2048 MB width x16 single rank, selected
> 
>    DIMMB 0 MB width x16 single rank
> 
> memcfg channel[1] config (00780008):
> 
>    enhanced interleave mode on
> 
>    rank interleave on
> 
>    DIMMA 2048 MB width x16 single rank, selected
> 
>    DIMMB 0 MB width x16 single rank
> 
> CBMEM: root @ 7cfff000 254 entries.
> 
> MRC data at ff7d0d9c 6246 bytes
> 
> Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)
> 
> create cbmem for dimm information
> 
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From jlewis at johnlewis.ie  Wed Sep  2 09:02:11 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Wed, 02 Sep 2015 10:02:11 +0100
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <20150902002637.GA17208@coreboot.org>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
 <20150902002637.GA17208@coreboot.org>
Message-ID: <a0631460fde2d30766e737f0247676e7@johnlewis.ie>

>> Coolstar Organisation wants to do his Windows thang with one of the
>> Broadwell Chromebooks, so I'm trying to build a working ROM with 
>> chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B
>> to give him a hand. Luckily USB debug works with this, so here is
>> what I'm getting. What could I do next?
> 
> Do you happen to know if the hang happens at the same spot when using
> serial?

I don't. What do you mean by "using serial"? Serial console? I can tell 
you that if USB debug isn't enabled, it will hang/lock almost 
immediately after pressing the power button, and require a long-press to 
switch off. If using USB debug, it switches itself off and terminates 
the console at the end of the log. The only other thing I notice is that 
on a "normal" boot using the backup, the next bit of log is vboot 
related which I am not using i.e.

Verified boot TPM initialization.
TPM: Init
Found TPM SLB9635 TT 1.2 by Infineon
TPM: Open
TPM: Resume
TPM: command 0x99 returned 0x0
TPM: OK.
Loading image.
Loading ramstage from 7d300000.
Jumping to image.
coreboot-3cbf0db Mon Jan 12 11:23:56 PST 2015 booting...


>> Incidentally, if I flash back my backup, it goes into recovery mode
>> now every time I boot (flags are 0x489), I've tried pulling the
>> battery to no avail. If anyone has a trick to get around that, I'd
>> appreciate it, as the Acer is my main machine.
> 
> What is the recovery reason? (<TAB> at the recovery screen)
> 

I managed to get around that one by flashing a shellball ROM and then 
flashing back the backup internally. Next time I do it I'll press the 
TAB key.

>> 
>> coreboot-?5cbe3a8-?dirty romstage Sun Aug 23 12:18:55 BST 2015
>> starting...
>> PM1_STS:   8910
>> PM1_EN:    0000
>> PM1_CNT:   00000000
>> TCO_STS:   0000 0000
>> GPE0_STS:  1ef82df0 187d4fdf 0005f240 00000000
>> GPE0_EN:   00000000 00000000 00000000 00000000
>> GEN_PMCON: 0200 2024 520b
>> Previous Sleep State: S5
>> CPU: Intel(R) Core(TM) i3-?5005U CPU @ 2.00GHz
>> CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d
>> CPU: AES supported, TXT NOT supported, VT supported
>> MCH: device id 1604 (rev 09) is Broadwell F0
>> PCH: device id 9cc5 (rev 03) is Broadwell U Base
>> IGD: device id 1616 (rev 09) is Broadwell U GT2
>> CPU: frequency set to 2000 MHz
>> SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)
>> SPD: module type is DDR3
>> SPD: module part is HMT425S6AFR6A-?PB
>> SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
>> SPD: device width 16 bits, bus width 64 bits
>> SPD: module size is 2048 MB (per channel)
>> Boot Count incremented to 8
>> ME: FW Partition Table      : OK
>> ME: Bringup Loader Failure  : NO
>> ME: Firmware Init Complete  : NO
>> ME: Manufacturing Mode      : NO
>> ME: Boot Options Present    : NO
>> ME: Update In Progress      : NO
>> ME: Current Working State   : Normal
>> ME: Current Operation State : Bring up
>> ME: Current Operation Mode  : Normal
>> ME: Error Code              : No Error
>> ME: Progress Phase          : BUP Phase
>> ME: Power Management Event  : Pseudo-?global reset
>> ME: Progress Phase State    : Waiting for DID BIOS message
>> ME: HSIO Version            : 8705 (CRC 0xfbc2)
>> No FMAP found at ffe10000.
>> FMAP: area RW_MRC_CACHE not found
>> No MRC cache found.
>> Starting Memory Reference Code
>> Initializing Policy
>> Installing common PPI
>> MRC: Starting...
>> Initializing Memory
>> MRC: Done.
>> MRC Version 2.6.0 Build 0
>> memcfg DDR3 clock 1600 MHz
>> memcfg channel assignment: A: 0, B  1, C  2
>> memcfg channel[0] config (00780008):
>>    enhanced interleave mode on
>>    rank interleave on
>>    DIMMA 2048 MB width x16 single rank, selected
>>    DIMMB 0 MB width x16 single rank
>> memcfg channel[1] config (00780008):
>>    enhanced interleave mode on
>>    rank interleave on
>>    DIMMA 2048 MB width x16 single rank, selected
>>    DIMMB 0 MB width x16 single rank
>> CBMEM: root @ 7cfff000 254 entries.
>> MRC data at ff7d0d9c 6246 bytes
>> Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)
>> create cbmem for dimm information



From jlewis at johnlewis.ie  Wed Sep  2 09:07:01 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Wed, 02 Sep 2015 10:07:01 +0100
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <a0631460fde2d30766e737f0247676e7@johnlewis.ie>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
 <20150902002637.GA17208@coreboot.org>
 <a0631460fde2d30766e737f0247676e7@johnlewis.ie>
Message-ID: <dbe0c72d68e02187f1ef9396dea91137@johnlewis.ie>

>> Coolstar Organisation wants to do his Windows thang with one of the
>> Broadwell Chromebooks, so I'm trying to build a working ROM with
>> chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B
>> to give him a hand. Luckily USB debug works with this, so here is
>> what I'm getting. What could I do next?
> 
> Do you happen to know if the hang happens at the same spot when using
> serial?

I don't. What do you mean by "using serial"? Serial console? I can tell
you that if USB debug isn't enabled, it will hang/lock almost
immediately after pressing the power button, and require a long-press to
switch off. If using USB debug, it switches itself off and terminates
the console at the end of the log. The only other thing I notice is that
on a "normal" boot using the backup, the next bit of log is vboot
related which I am not using i.e.

Verified boot TPM initialization.
TPM: Init
Found TPM SLB9635 TT 1.2 by Infineon
TPM: Open
TPM: Resume
TPM: command 0x99 returned 0x0
TPM: OK.
Loading image.
Loading ramstage from 7d300000.
Jumping to image.
coreboot-3cbf0db Mon Jan 12 11:23:56 PST 2015 booting...


>> Incidentally, if I flash back my backup, it goes into recovery mode
>> now every time I boot (flags are 0x489), I've tried pulling the
>> battery to no avail. If anyone has a trick to get around that, I'd
>> appreciate it, as the Acer is my main machine.
> 
> What is the recovery reason? (<TAB> at the recovery screen)
> 

I managed to get around that one by flashing a shellball ROM and then
flashing back the backup internally. Next time I do it I'll press the
TAB key.

>> 
>> coreboot-?5cbe3a8-?dirty romstage Sun Aug 23 12:18:55 BST 2015
>> starting...
>> PM1_STS:   8910
>> PM1_EN:    0000
>> PM1_CNT:   00000000
>> TCO_STS:   0000 0000
>> GPE0_STS:  1ef82df0 187d4fdf 0005f240 00000000
>> GPE0_EN:   00000000 00000000 00000000 00000000
>> GEN_PMCON: 0200 2024 520b
>> Previous Sleep State: S5
>> CPU: Intel(R) Core(TM) i3-?5005U CPU @ 2.00GHz
>> CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d
>> CPU: AES supported, TXT NOT supported, VT supported
>> MCH: device id 1604 (rev 09) is Broadwell F0
>> PCH: device id 9cc5 (rev 03) is Broadwell U Base
>> IGD: device id 1616 (rev 09) is Broadwell U GT2
>> CPU: frequency set to 2000 MHz
>> SPD: index 1 (GPIO47=0 GPIO9=0 GGPIO13=1)
>> SPD: module type is DDR3
>> SPD: module part is HMT425S6AFR6A-?PB
>> SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
>> SPD: device width 16 bits, bus width 64 bits
>> SPD: module size is 2048 MB (per channel)
>> Boot Count incremented to 8
>> ME: FW Partition Table      : OK
>> ME: Bringup Loader Failure  : NO
>> ME: Firmware Init Complete  : NO
>> ME: Manufacturing Mode      : NO
>> ME: Boot Options Present    : NO
>> ME: Update In Progress      : NO
>> ME: Current Working State   : Normal
>> ME: Current Operation State : Bring up
>> ME: Current Operation Mode  : Normal
>> ME: Error Code              : No Error
>> ME: Progress Phase          : BUP Phase
>> ME: Power Management Event  : Pseudo-?global reset
>> ME: Progress Phase State    : Waiting for DID BIOS message
>> ME: HSIO Version            : 8705 (CRC 0xfbc2)
>> No FMAP found at ffe10000.
>> FMAP: area RW_MRC_CACHE not found
>> No MRC cache found.
>> Starting Memory Reference Code
>> Initializing Policy
>> Installing common PPI
>> MRC: Starting...
>> Initializing Memory
>> MRC: Done.
>> MRC Version 2.6.0 Build 0
>> memcfg DDR3 clock 1600 MHz
>> memcfg channel assignment: A: 0, B  1, C  2
>> memcfg channel[0] config (00780008):
>>    enhanced interleave mode on
>>    rank interleave on
>>    DIMMA 2048 MB width x16 single rank, selected
>>    DIMMB 0 MB width x16 single rank
>> memcfg channel[1] config (00780008):
>>    enhanced interleave mode on
>>    rank interleave on
>>    DIMMA 2048 MB width x16 single rank, selected
>>    DIMMB 0 MB width x16 single rank
>> CBMEM: root @ 7cfff000 254 entries.
>> MRC data at ff7d0d9c 6246 bytes
>> Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)
>> create cbmem for dimm information



From jlewis at johnlewis.ie  Wed Sep  2 09:45:09 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Wed, 02 Sep 2015 10:45:09 +0100
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <20150902002637.GA17208@coreboot.org>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
 <20150902002637.GA17208@coreboot.org>
Message-ID: <c99c19849f70ce1d9c6dba253d639f39@johnlewis.ie>

I think I'm going to come at this from a different angle. I'm trying to 
do a fresh build and here is what I have so far. What's the best way of 
getting around these errors?:

build/lib/cbfs.romstage.o: In function `load_stage_from_cbfs':
/home/dad/coreboot/firmware-yuna-6301.59.B/src/lib/cbfs.c:132: undefined 
reference to `rmodule_stage_load_from_cbfs'
build/soc/intel/broadwell/romstage/romstage.romstage.o: In function 
`romstage_main':
/home/dad/coreboot/firmware-yuna-6301.59.B/src/soc/intel/broadwell/romstage/romstage.c:75: 
undefined reference to `mainboard_pre_console_init'
collect2: error: ld returned 1 exit status
src/arch/x86/Makefile.inc:213: recipe for target 
'build/cbfs/fallback/romstage_null.debug' failed
make: *** [build/cbfs/fallback/romstage_null.debug] Error 1

These are the changes I've made so far:

diff --git a/src/ec/google/chromeec/ec.c b/src/ec/google/chromeec/ec.c
index 0ef12fb..1e058a7 100644
--- a/src/ec/google/chromeec/ec.c
+++ b/src/ec/google/chromeec/ec.c
@@ -161,6 +161,7 @@ void google_chromeec_check_ec_image(int 
expected_type)
         }
  }

+#if CONFIG_CHROMEOS
  /* Check for recovery mode and ensure EC is in RO */
  void google_chromeec_early_init(void)
  {
@@ -169,6 +170,7 @@ void google_chromeec_early_init(void)
                 google_chromeec_check_ec_image(EC_IMAGE_RO);
         }
  }
+#endif

  void google_chromeec_check_pd_image(int expected_type)
  {
@@ -200,6 +202,7 @@ void google_chromeec_check_pd_image(int 
expected_type)
         }
  }

+#if CONFIG_CHROMEOS
  /* Check for recovery mode and ensure PD is in RO */
  void google_chromeec_early_pd_init(void)
  {
@@ -210,6 +213,8 @@ void google_chromeec_early_pd_init(void)
  }
  #endif

+#endif
+
  u16 google_chromeec_get_board_version(void)
  {
         struct chromeec_command cmd;
diff --git a/src/mainboard/google/auron_yuna/Kconfig 
b/src/mainboard/google/auron_yuna/Kconfig
index 2db9689..1e56e0f 100644
--- a/src/mainboard/google/auron_yuna/Kconfig
+++ b/src/mainboard/google/auron_yuna/Kconfig
@@ -12,8 +12,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
         select HAVE_ACPI_RESUME
         select MMCONF_SUPPORT
         select HAVE_SMI_HANDLER
-       select CHROMEOS
-       select CHROMEOS_VBNV_CMOS
         select EXTERNAL_MRC_BLOB
         select CACHE_ROM
         select MARK_GRAPHICS_MEM_WRCOMB
diff --git a/src/mainboard/google/auron_yuna/romstage.c 
b/src/mainboard/google/auron_yuna/romstage.c
index 705b0af..c1a3916 100644
--- a/src/mainboard/google/auron_yuna/romstage.c
+++ b/src/mainboard/google/auron_yuna/romstage.c
@@ -35,8 +35,10 @@ void mainboard_romstage_entry(struct romstage_params 
*rp)

         post_code(0x32);

+       #if CONFIG_CHROMEOS
         /* Ensure the EC is in the right mode for recovery */
         google_chromeec_early_init();
+       #endif

         /* Initialize GPIOs */
         init_gpios(mainboard_gpio_config);

And this is my current .config (minus things which aren't set):

CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_ALT_CBFS_LOAD_PAYLOAD=y
CONFIG_COMPILER_GCC=y
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
CONFIG_DYNAMIC_CBMEM=y
CONFIG_COLLECT_TIMESTAMPS=y

CONFIG_VENDOR_GOOGLE=y
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_DIR="google/auron_yuna"
CONFIG_MAINBOARD_PART_NUMBER="Auron_Yuna"
CONFIG_IRQ_SLOT_COUNT=18
CONFIG_MAINBOARD_VENDOR="GOOGLE"
CONFIG_MAX_CPUS=8
CONFIG_RAMTOP=0x200000
CONFIG_HEAP_SIZE=0x4000
CONFIG_RAMBASE=0x100000
CONFIG_VGA_BIOS_ID="8086,1616"
CONFIG_STACK_SIZE=0x1000
CONFIG_WARNINGS_ARE_ERRORS=y
CONFIG_VGA_BIOS=y
CONFIG_CONSOLE_POST=y
CONFIG_DCACHE_RAM_BASE=0xff7c0000
CONFIG_DCACHE_RAM_SIZE=0x10000
CONFIG_SERIAL_CPU_INIT=y
CONFIG_ACPI_SSDTX_NUM=0
CONFIG_VGA_BIOS_FILE="pci8086,0406.rom"
CONFIG_MMCONF_BASE_ADDRESS=0xf0000000
CONFIG_XIP_ROM_SIZE=0x10000
CONFIG_VENDOR_SPECIFIC_OPTIONS=y
CONFIG_BOARD_GOOGLE_AURON_YUNA=y
CONFIG_VBOOT_RAMSTAGE_INDEX=0x2
CONFIG_VBOOT_REFCODE_INDEX=0x3
CONFIG_MAINBOARD_FAMILY="Google_Auron"
CONFIG_BOOT_MEDIA_SPI_BUS=0
CONFIG_MMCONF_SUPPORT_DEFAULT=y
CONFIG_LOGICAL_CPUS=y
CONFIG_IOAPIC=y
CONFIG_SMP=y
CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8
CONFIG_MAXIMUM_CONSOLE_LOGLEVEL=8
CONFIG_USBDEBUG=y
CONFIG_CPU_ADDR_BITS=36
CONFIG_BOARD_ROMSIZE_KB_8192=y
CONFIG_COREBOOT_ROMSIZE_KB_8192=y
CONFIG_COREBOOT_ROMSIZE_KB=8192
CONFIG_ROM_SIZE=0x800000
CONFIG_MAINBOARD_SERIAL_NUMBER="123456789"
CONFIG_MAINBOARD_VERSION="1.0"
CONFIG_MAINBOARD_ENCLOSURE_TYPE=0x3
CONFIG_ARCH_X86=y

CONFIG_ARCH_BOOTBLOCK_X86_32=y
CONFIG_ARCH_ROMSTAGE_X86_32=y
CONFIG_ARCH_RAMSTAGE_X86_32=y
CONFIG_MARK_GRAPHICS_MEM_WRCOMB=y
CONFIG_X86_BOOTBLOCK_SIMPLE=y
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
CONFIG_PC80_SYSTEM=y
CONFIG_BOOTBLOCK_NORTHBRIDGE_INIT="soc/intel/broadwell/bootblock/systemagent.c"
CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT="soc/intel/broadwell/bootblock/pch.c"
CONFIG_IOAPIC_INTERRUPTS_ON_FSB=y
CONFIG_HPET_ADDRESS=0xfed00000
CONFIG_ID_SECTION_OFFSET=0x80

CONFIG_ARM_BOOTBLOCK_SIMPLE=y



CONFIG_BOOTBLOCK_CPU_INIT="soc/intel/broadwell/bootblock/cpu.c"
CONFIG_CPU_SPECIFIC_OPTIONS=y
CONFIG_HIGH_SCRATCH_MEMORY_SIZE=0x0
CONFIG_SMM_TSEG_SIZE=0
CONFIG_MICROCODE_INCLUDE_PATH="src/soc/intel/broadwell/microcode"
CONFIG_IED_REGION_SIZE=0x400000
CONFIG_SMM_RESERVED_SIZE=0x100000
CONFIG_MONOTONIC_TIMER_MSR=y
CONFIG_SSE2=y
CONFIG_CACHE_MRC_BIN=y
CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE=y
CONFIG_CPU_INTEL_NUM_FIT_ENTRIES=4
CONFIG_UDELAY_TSC=y
CONFIG_TSC_CONSTANT_RATE=y
CONFIG_TSC_SYNC_MFENCE=y
CONFIG_CACHE_ROM=y
CONFIG_SMM_TSEG=y
CONFIG_SMM_MODULES=y
CONFIG_SMM_MODULE_HEAP_SIZE=0x4000
CONFIG_PARALLEL_MP=y
CONFIG_BACKUP_DEFAULT_SMM_REGION=y
CONFIG_CACHE_AS_RAM=y
CONFIG_AP_SIPI_VECTOR=0xfffff000
CONFIG_CPU_MICROCODE_IN_CBFS=y
CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
CONFIG_CAR_MIGRATION=y

CONFIG_VIDEO_MB=0
CONFIG_CBFS_SIZE=0x100000
CONFIG_CACHE_MRC_SIZE_KB=512
CONFIG_EXTERNAL_MRC_BLOB=y
CONFIG_DCACHE_RAM_MRC_VAR_SIZE=0x30000
CONFIG_HAVE_MRC=y
CONFIG_MRC_FILE="mrc.bin"
CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE=0x2000
CONFIG_PRE_GRAPHICS_DELAY=0

CONFIG_EHCI_BAR=0xd8000000
CONFIG_EHCI_DEBUG_OFFSET=0xa0
CONFIG_USBDEBUG_DEFAULT_PORT=1
CONFIG_SPI_FLASH=y
CONFIG_SERIRQ_CONTINUOUS_MODE=y


CONFIG_EC_GOOGLE_CHROMEEC=y
CONFIG_EC_GOOGLE_CHROMEEC_LPC=y

CONFIG_MRC_BIN_ADDRESS=0xfffa0000
CONFIG_SOC_INTEL_BROADWELL=y
CONFIG_CACHE_MRC_SETTINGS=y
CONFIG_MRC_SETTINGS_CACHE_BASE=0xffb00000
CONFIG_MRC_SETTINGS_CACHE_SIZE=0x10000

CONFIG_ALWAYS_LOAD_OPROM=y
CONFIG_PCI=y
CONFIG_PCIX_PLUGIN_SUPPORT=y
CONFIG_PCIEXP_PLUGIN_SUPPORT=y
CONFIG_AGP_PLUGIN_SUPPORT=y
CONFIG_CARDBUS_PLUGIN_SUPPORT=y
CONFIG_PCIEXP_COMMON_CLOCK=y
CONFIG_PCIEXP_ASPM=y
CONFIG_PCIEXP_CLK_PM=y
CONFIG_PCIEXP_L1_SUB_STATE=y
CONFIG_PCI_BUS_SEGN_BITS=0


CONFIG_SUBSYSTEM_VENDOR_ID=0x0000
CONFIG_SUBSYSTEM_DEVICE_ID=0x0000

CONFIG_ELOG=y
CONFIG_ELOG_FLASH_BASE=0
CONFIG_ELOG_AREA_SIZE=0x1000
CONFIG_ELOG_FULL_THRESHOLD=0xC00
CONFIG_ELOG_SHRINK_SIZE=0x400
CONFIG_ELOG_GSMI=y
CONFIG_ELOG_BOOT_COUNT=y
CONFIG_ELOG_BOOT_COUNT_CMOS_OFFSET=144
CONFIG_DRIVERS_MC146818_RTC=y
CONFIG_DRIVERS_MC146818_CMOS=y
CONFIG_DRIVERS_RTC_HAS_ALTCENTURY=y
CONFIG_SPI_ATOMIC_SEQUENCING=y
CONFIG_SPI_FLASH_MEMORY_MAPPED=y
CONFIG_SPI_FLASH_SMM=y
CONFIG_SPI_FLASH_EON=y
CONFIG_SPI_FLASH_MACRONIX=y
CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_SST=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_WINBOND=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_MMCONF_SUPPORT=y

CONFIG_EARLY_CONSOLE=y
CONFIG_HAVE_USBDEBUG=y
CONFIG_CONSOLE_CBMEM=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x10000
CONFIG_CONSOLE_PRERAM_BUFFER_SIZE=0xc00
CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_8=y
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y
CONFIG_HAVE_UART_IO_MAPPED=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_HAVE_HARD_RESET=y
CONFIG_HAVE_MONOTONIC_TIMER=y
CONFIG_HAVE_OPTION_TABLE=y
CONFIG_HAVE_SMI_HANDLER=y
CONFIG_CACHE_ROM_SIZE=0x100000
CONFIG_RELOCATABLE_MODULES=y
CONFIG_RELOCATABLE_RAMSTAGE=y
CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM=y
CONFIG_HAVE_REFCODE_BLOB=y
CONFIG_REFCODE_BLOB_FILE="refcode.elf"
CONFIG_HAVE_ACPI_TABLES=y
CONFIG_MAX_PIRQ_LINKS=4

CONFIG_GENERATE_ACPI_TABLES=y
CONFIG_GENERATE_SMBIOS_TABLES=y

CONFIG_PAYLOAD_SEABIOS=y
CONFIG_SEABIOS_MASTER=y
CONFIG_PAYLOAD_FILE="$(obj)/seabios/out/bios.bin.elf"
CONFIG_COMPRESSED_PAYLOAD_LZMA=y

CONFIG_REG_SCRIPT=y
CONFIG_CHROMEOS_RAMOOPS_DYNAMIC=y
CONFIG_EC_SOFTWARE_SYNC=y
CONFIG_VIRTUAL_DEV_SWITCH=y
CONFIG_MAX_REBOOT_CNT=3



From jlewis at johnlewis.ie  Wed Sep  2 19:09:22 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Wed, 02 Sep 2015 20:09:22 +0100
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <20150902002637.GA17208@coreboot.org>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
 <20150902002637.GA17208@coreboot.org>
Message-ID: <fbdf004842c4a07d6aef79da2a682d19@johnlewis.ie>

On 2015-09-02 01:26, Stefan Reinauer wrote:
> * John Lewis <jlewis at johnlewis.ie> [150830 18:43]:
>> Hi Guys,
>> 
>> Coolstar Organisation wants to do his Windows thang with one of the
>> Broadwell Chromebooks, so I'm trying to build a working ROM with 
>> chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B
>> to give him a hand. Luckily USB debug works with this, so here is
>> what I'm getting. What could I do next?
> 
> Do you happen to know if the hang happens at the same spot when using
> serial?
> 
> 
>> Incidentally, if I flash back my backup, it goes into recovery mode
>> now every time I boot (flags are 0x489), I've tried pulling the
>> battery to no avail. If anyone has a trick to get around that, I'd
>> appreciate it, as the Acer is my main machine.
> 
> What is the recovery reason? (<TAB> at the recovery screen)
> 

0x54 TPM read error in rewritable firmware

I've done a bit more work and got that coreboot branch building in what 
I think is a relatively sane manner, although it doesn't get us any 
further in the bootstrap process. I'm going to continue with that, as at 
the moment the external refcode binary is being left out. If I get 
stuck, or I make progress, I'll post the diff and log output. Thanks for 
your input so far.


From jlewis at johnlewis.ie  Thu Sep  3 09:52:54 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Thu, 03 Sep 2015 10:52:54 +0100
Subject: [coreboot] Acer Chromebook 15 debug
In-Reply-To: <20150902002637.GA17208@coreboot.org>
References: <6d1622f5cba5d27bdec8edee10d6f8ef@johnlewis.ie>
 <20150902002637.GA17208@coreboot.org>
Message-ID: <6cf1e4a2107863a8d5d998567f0b0443@johnlewis.ie>

I'm still no further along. On the very first boot after flash I get:

coreboot-5cbe3a8-dirty romstage Thu Sep  3 10:28:23 BST 2015 starting...

PM1_STS:   0010
PM1_EN:    0000
PM1_CNT:   00000000
TCO_STS:   0000 0000
GPE0_STS:  1ef86df0 187d4fdf 0005f240 00010000
GPE0_EN:   00000000 00000000 00000000 00000000
GEN_PMCON: 0200 20a0 1a09
Previous Sleep State: S0
CPU: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz
CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1604 (rev 09) is Broadwell F0
PCH: device id 9cc5 (rev 03) is Broadwell U Base
IGD: device id 1616 (rev 09) is Broadwell U GT2
CPU: frequency set to 2000 MHz
POST: 0x32
SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)
SPD: module type is DDR3
SPD: module part is HMT425S6AFR6A-PB
SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
SPD: device width 16 bits, bus width 64 bits
SPD: module size is 2048 MB (per channel)
POST: 0x32
ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : Waiting for DID BIOS message
ME: HSIO Version            : 8705 (CRC 0xfbc2)
No MRC cache found.
Rebooting with EC in RO mode:
POST: 0x00

Reverting to the previous log on subsequent boots. Note I have also 
built the ROM inside the CrOS SDK.

What should I do now?

See attached changes + config.

-John.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-diff
Size: 8667 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150903/1d310600/attachment-0001.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: .config
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150903/1d310600/attachment-0001.ksh>

From duwe at lst.de  Thu Sep  3 10:53:33 2015
From: duwe at lst.de (Torsten Duwe)
Date: Thu, 3 Sep 2015 12:53:33 +0200
Subject: [coreboot] Linux 4.0.x iomem regression
Message-ID: <20150903105333.GA7675@lst.de>

JFYI, I got stuck with kernel 3.19 this spring, and Linux-4.0 didn't work
properly on my coreboot machine. Only now I've had time to look into this.

To make it short: the fault is in the Linux PCI/ACPI code; see mainline
commit 2c62e8492, which fixes this in 4.1-rc3. You may want to skim through
https://lkml.org/lkml/2015/4/3/608 to get an idea of this mess.

" I did it because Windows apparently does that ..."

I'm not sure if and why proprietary BIOSes are unaffected.
Just to let you all know in case you're bisecting across 4.0 linux kernels.

	Torsten



From adurbin at google.com  Thu Sep  3 13:42:58 2015
From: adurbin at google.com (Aaron Durbin)
Date: Thu, 3 Sep 2015 08:42:58 -0500
Subject: [coreboot] Linux 4.0.x iomem regression
In-Reply-To: <20150903105333.GA7675@lst.de>
References: <20150903105333.GA7675@lst.de>
Message-ID: <CAE2855vGDVDry0TPvq0S9-XoDkA=bL7hC-gVk2BWnMRgx=TW5w@mail.gmail.com>

thanks

On Thu, Sep 3, 2015 at 5:53 AM, Torsten Duwe <duwe at lst.de> wrote:
> JFYI, I got stuck with kernel 3.19 this spring, and Linux-4.0 didn't work
> properly on my coreboot machine. Only now I've had time to look into this.
>
> To make it short: the fault is in the Linux PCI/ACPI code; see mainline
> commit 2c62e8492, which fixes this in 4.1-rc3. You may want to skim through
> https://lkml.org/lkml/2015/4/3/608 to get an idea of this mess.
>
> " I did it because Windows apparently does that ..."
>
> I'm not sure if and why proprietary BIOSes are unaffected.
> Just to let you all know in case you're bisecting across 4.0 linux kernels.

Thanks for the heads up. I'm sure this won't be last time either.
We're definitely in the age of tight coupling between kernel and
firmware. ACPI is not the abstraction it was intended to be. Both
sides have to agree on interpretation and tables provided.  For most
people who are used to be able to take an x86 linux live cd and boot
w/ things working, that is not longer the case any more.

-Aaron


From paulepanter at users.sourceforge.net  Thu Sep  3 20:09:57 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Thu, 03 Sep 2015 22:09:57 +0200
Subject: [coreboot] coreboot meeting 2015: SerialICE workshop?
Message-ID: <1441310997.2617.14.camel@users.sourceforge.net>

Dear coreboot folks,


the coreboot meeting 2015 is taking place soon from October 9th to 11th
[1].

Reading so much about SerialICE [2] and never having really used it,
would there be one of the experts be willing to do some kind of
workshop. That?d be really awesome!

I am looking forward to seeing you all.


Thanks,

Paul


[1] http://blogs.coreboot.org/blog/2015/08/04/coreboot-conference-in-europe-october-2015
[2] http://www.serialice.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150903/70b8128b/attachment.asc>

From mytbk920423 at gmail.com  Fri Sep  4 12:12:17 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Fri, 4 Sep 2015 20:12:17 +0800
Subject: [coreboot] build fails when CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT is
	set
Message-ID: <CALWv5jQdAv23EeajEoaAt52pLdcFsYxzmra6yAnhZZ5vdKn32A@mail.gmail.com>

Hi,

I was trying to build coreboot with the latest git code and build failed
when CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT is set. Some of the error message
is:

$ make
    CREATE     build/mainboard/lenovo/x220/cbfs-file.c7KD3B.out (from
src/mainboard/lenovo/x220/cmos.default)
Created CBFS (capacity = 1046552 bytes)
E: Input file size (68464) greater than page size (65536).
    GEN        generated/romstage.ld
    LINK       cbfs/fallback/romstage.debug
    OBJCOPY    cbfs/fallback/romstage.elf
    CBFS       coreboot.pre
    CC         northbridge/intel/sandybridge/gma_sandybridge_lvds.ramstage.o
src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c: In function
'i915lightup_sandy':
src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c:195:21: error:
'struct edid' has no member named 'hborder'
  right_border = edid.hborder;
                     ^

After I searched the git log, I found this commit cause the error:
commit 7dbf9c6747ccdfa8b993d3843a22722742957611
Author: David Hendricks <dhendrix at chromium.org>
Date:   Thu Jul 30 18:49:48 2015 -0700

    edid: Use edid_mode struct to reduce redundancy

    This replaces various timing mode parameters parameters with
    an edid_mode struct within the edid struct.

I hope someone will fix the error soon.

Iru Cai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150904/83eecee4/attachment.html>

From jwerner at chromium.org  Fri Sep  4 19:43:36 2015
From: jwerner at chromium.org (Julius Werner)
Date: Fri, 4 Sep 2015 12:43:36 -0700
Subject: [coreboot] build fails when CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT
 is set
In-Reply-To: <CALWv5jQdAv23EeajEoaAt52pLdcFsYxzmra6yAnhZZ5vdKn32A@mail.gmail.com>
References: <CALWv5jQdAv23EeajEoaAt52pLdcFsYxzmra6yAnhZZ5vdKn32A@mail.gmail.com>
Message-ID: <CAODwPW-8pWD9fYmtohPz5_qQsYwy0+H3u8k10iEFdYDqfUxe1Q@mail.gmail.com>

+Dave for visibility, was a simple oversight in the refactoring

On Fri, Sep 4, 2015 at 5:12 AM, Iru Cai <mytbk920423 at gmail.com> wrote:

> Hi,
>
> I was trying to build coreboot with the latest git code and build failed
> when CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT is set. Some of the error message
> is:
>
> $ make
>     CREATE     build/mainboard/lenovo/x220/cbfs-file.c7KD3B.out (from
> src/mainboard/lenovo/x220/cmos.default)
> Created CBFS (capacity = 1046552 bytes)
> E: Input file size (68464) greater than page size (65536).
>     GEN        generated/romstage.ld
>     LINK       cbfs/fallback/romstage.debug
>     OBJCOPY    cbfs/fallback/romstage.elf
>     CBFS       coreboot.pre
>     CC
> northbridge/intel/sandybridge/gma_sandybridge_lvds.ramstage.o
> src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c: In function
> 'i915lightup_sandy':
> src/northbridge/intel/sandybridge/gma_sandybridge_lvds.c:195:21: error:
> 'struct edid' has no member named 'hborder'
>   right_border = edid.hborder;
>                      ^
>
> After I searched the git log, I found this commit cause the error:
> commit 7dbf9c6747ccdfa8b993d3843a22722742957611
> Author: David Hendricks <dhendrix at chromium.org>
> Date:   Thu Jul 30 18:49:48 2015 -0700
>
>     edid: Use edid_mode struct to reduce redundancy
>
>     This replaces various timing mode parameters parameters with
>     an edid_mode struct within the edid struct.
>
> I hope someone will fix the error soon.
>
> Iru Cai
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150904/394a10a3/attachment.html>

From coreboot-conference at bsi.bund.de  Fri Sep  4 23:55:01 2015
From: coreboot-conference at bsi.bund.de (coreboot conference)
Date: Sat, 5 Sep 2015 01:55:01 +0200
Subject: [coreboot] coreboot conference 2015 invitation
Message-ID: <201509050155.01612.coreboot-conference@bsi.bund.de>

Dear vendors, developers and interested parties,

on behalf of the Federal Office for Information Security (BSI) Germany I would 
like to invite you to the coreboot conference and developer meeting on 
October 9-11 2015 in Bonn, Germany.

This conference and developer meeting is geared towards manufacturers of 
hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
desktops/ appliances) as well as developers of firmware with an interest in 
coreboot and the possibilities it offers.

The Federal Office for Information Security (BSI) in Germany will host the 
conference in Bonn, Germany. As the national cyber security authority, the 
goal of the BSI is to promote IT security in Germany. For this reason, the 
BSI has funded coreboot development in the past for security reasons.

The date of the coreboot conference is Friday October 9 to Sunday October 11, 
2015. This is scheduled directly after Embedded Linux Conference Europe to 
make travel arrangements easier for people attending both events.

If your main interest is forging business relationships and/or strategic 
coordination and you want to skip the technical workshops, Friday (and 
possibly Saturday) will be the outreach day of talks, presentations and 
discussions.
If your main interest is doing development, you can use the separate developer 
room next to the during all three days of the conference.

Call for presentations:
We are looking for interesting talks/presentations about coreboot related 
topics for the first (and possibly second) day of the conference. Please note 
that those presentations are not intended to be advertisements or company 
portfolio presentations.
Expected duration is between 10 and 45 minutes.
Submission: Please send the title, a brief summary, the expected duration and 
name/organization of the speaker to <coreboot-conference at bsi.bund.de> until 
September 21. We will notify you of acceptance until September 28. If you 
want us to make sure the slides work fine with the projector at the venue, 
please submit your final slides in pdf form before Ocober 7.

Call for discussion topics and development suggestions:
We hope to stimulate discussion and foster new ideas as well as explore ways 
to improve code, development and deployment. The format for this will be a 
few minutes (1-5) of presenting your idea/topic followed by discussing it 
with the audience for approximately 5-20 minutes. While there is no formal 
deadline for submission, we'd appreciate a submission to 
<coreboot-conference at bsi.bund.de> before October 2 to be able to list the 
topic on the agenda to allow others to think about the topic in advance.

Call for profiles:
This is the chance to tell others what you're doing, what you can offer and in 
what area you'd like to collaborate. If desired, we can attempt to distribute 
your profile to other conference participants before the conference. Please 
submit such profiles before September 30 to 
<coreboot-conference at bsi.bund.de> .

Call for developers:
If you want to do development all day, every day, just come and do it. We have 
power, networking and some spare hardware (please tell us in advance if you 
need something on site, we might have it in our lab).


Travel information:
If you wonder about how to reach Bonn, there are three options available by 
plane:
The closest is Cologne Airport (CGN), 30 minutes by bus to Bonn main station.
Next is Dusseldorf Airport (DUS), 1 hour by train to Bonn main station.
The airport with most international destinations is Frankfurt Airport (FRA), 1 
hour by train to Bonn main station.
There?s the option to travel by train as well. Bonn is reachable by high-speed 
train (ICE), and other high-speed train stations are reasonably close (30 
minutes).

Conference location:
Wissenschaftszentrum Bonn
Ahrstrasse 45
53175 Bonn
GERMANY

Getting there (German only)
http://www.stifterverband.info/veranstaltungen/wissenschaftszentrum_bonn/anfahrt/index.html
An English version of the directions will be available at 
http://coreboot.org/coreboot_conference_Bonn_2015

Accommodation:
Accommodation is not centrally organized, but if desired we can point you to 
websites listing hotel contact information and/or booking services as well as 
the local tourist information office. We also have a small allotment of rooms 
close to the venue reserved for conference participants, just ask us.

Spare time activities:
If there is enough interest, it might be possible to get a tour of the former 
top secret bunker of the German Federal Government on Saturday evening. More 
info at http://regbu.de/Fremdsprachen/GB1.html
Besides that, Bonn and Cologne have lots of tourist attractions

Food and drinks:
More info will be posted to http://coreboot.org/coreboot_conference_Bonn_2015  
shortly. 

Date and time:
October 9-11 2015
Friday: 9:00-19:00
Saturday: 9:00-16:00
Sunday: 9:00-19:00

To enable us to estimate the number of attendees (for catering etc.), please 
notify us ASAP whether you will attend the conference at 
<coreboot-conference at bsi.bund.de>. Thank you!

All information is also available at 
http://coreboot.org/coreboot_conference_Bonn_2015

Sincerely,
Carl-Daniel Hailfinger
-- 
Hailfinger, Carl-Daniel
_________________________________________
Section C 13 - Operating System and Application Security
Federal Office for Information Security (BSI)

Godesberger Allee 185-189
53175 Bonn, Germany
phone:    +49 (0)228 9582-5939
fax:      +49 (0)228 9582-5400
e-mail:   coreboot-conference at bsi.bund.de
web:    www.bsi.bund.de


From coreboot-conference at bsi.bund.de  Sat Sep  5 01:12:38 2015
From: coreboot-conference at bsi.bund.de (coreboot conference)
Date: Sat, 5 Sep 2015 03:12:38 +0200
Subject: [coreboot] coreboot conference 2015 invitation
In-Reply-To: <201509050155.01612.coreboot-conference@bsi.bund.de>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
Message-ID: <201509050312.38145.coreboot-conference@bsi.bund.de>

Dear vendors, developers, users and interested parties,

my apologies. I accidentally left out users as addressees.

On behalf of the Federal Office for Information Security (BSI) Germany I would 
like to invite you to the coreboot conference and developer meeting on 
October 9-11 2015 in Bonn, Germany.

This conference and developer meeting is geared towards manufacturers of 
hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
desktops/ appliances) as well as developers of firmware with an interest in 
coreboot and the possibilities it offers as well as (potential) coreboot 
users. Both professionals and hobbyists are invited.

Please see the full text of the invitation at 
http://coreboot.org/coreboot_conference_Bonn_2015

Sincerely,
Carl-Daniel Hailfinger
-- 
Hailfinger, Carl-Daniel
_________________________________________
Section C 13 - Operating System and Application Security
Federal Office for Information Security (BSI)

Godesberger Allee 185-189
53175 Bonn, Germany
phone:    +49 (0)228 9582-5939
fax:      +49 (0)228 9582-5400
e-mail:   coreboot-conference at bsi.bund.de
internet: www.bsi.bund.de


From echelon at free.fr  Sat Sep  5 10:49:43 2015
From: echelon at free.fr (echelon at free.fr)
Date: Sat, 5 Sep 2015 12:49:43 +0200 (CEST)
Subject: [coreboot] =?utf-8?q?Re=C2=A0=3A__coreboot_meeting_2015=3A_Serial?=
 =?utf-8?q?ICE_workshop=3F?=
In-Reply-To: <1441310997.2617.14.camel@users.sourceforge.net>
Message-ID: <278083595.32849671.1441450183760.JavaMail.root@zimbra6-e1.priv.proxad.net>

+1!
 Florentin

----- Mail d'origine -----
De: Paul Menzel <paulepanter at users.sourceforge.net>
?: coreboot at coreboot.org
Envoy?: Thu, 03 Sep 2015 22:09:57 +0200 (CEST)
Objet: [coreboot] coreboot meeting 2015: SerialICE workshop?

Dear coreboot folks,


the coreboot meeting 2015 is taking place soon from October 9th to 11th
[1].

Reading so much about SerialICE [2] and never having really used it,
would there be one of the experts be willing to do some kind of
workshop. That?d be really awesome!

I am looking forward to seeing you all.


Thanks,

Paul


[1] http://blogs.coreboot.org/blog/2015/08/04/coreboot-conference-in-europe-october-2015
[2] http://www.serialice.com


From lists+coreboot at donderklumpen.de  Mon Sep  7 16:47:08 2015
From: lists+coreboot at donderklumpen.de (Mono)
Date: Mon, 7 Sep 2015 18:47:08 +0200
Subject: [coreboot] Lenovo X60 broken by Change 11388
Message-ID: <20150907164708.GA1301@donderklumpen.de>

Hallo all,

with Change 11388/commit 7dbf9c6 (edid: Use edid_mode struct to reduce redundancy) compiling coreboot for Lenovo X60 fails with this error:

    CC         northbridge/intel/i945/gma.ramstage.o
src/northbridge/intel/i945/gma.c: In function 'intel_gma_init':
src/northbridge/intel/i945/gma.c:111:19: error: 'struct edid' has no member named 'phsync'
  hpolarity = (edid.phsync == '-');
                   ^
src/northbridge/intel/i945/gma.c:112:19: error: 'struct edid' has no member named 'pvsync'
  vpolarity = (edid.pvsync == '-');
                   ^
src/northbridge/intel/i945/gma.c:115:21: error: 'struct edid' has no member named 'hborder'
  right_border = edid.hborder;
                     ^
src/northbridge/intel/i945/gma.c:116:22: error: 'struct edid' has no member named 'vborder'
  bottom_border = edid.vborder;
                      ^
src/northbridge/intel/i945/gma.c:117:15: error: 'struct edid' has no member named 'vbl'
  vblank = edid.vbl;
               ^
src/northbridge/intel/i945/gma.c:118:15: error: 'struct edid' has no member named 'hbl'
  hblank = edid.hbl;
               ^
src/northbridge/intel/i945/gma.c:119:14: error: 'struct edid' has no member named 'vspw'
  vsync = edid.vspw;
              ^
src/northbridge/intel/i945/gma.c:120:14: error: 'struct edid' has no member named 'hspw'
  hsync = edid.hspw;
              ^
src/northbridge/intel/i945/gma.c:121:21: error: 'struct edid' has no member named 'hso'
  hfront_porch = edid.hso;
                     ^
src/northbridge/intel/i945/gma.c:122:21: error: 'struct edid' has no member named 'vso'
  vfront_porch = edid.vso;
                     ^
src/northbridge/intel/i945/gma.c:163:58: error: 'struct edid' has no member named 'pixel_clock'
  target_frequency = conf->gpu_lvds_is_dual_channel ? edid.pixel_clock
                                                          ^
src/northbridge/intel/i945/gma.c:164:14: error: 'struct edid' has no member named 'pixel_clock'
   : (2 * edid.pixel_clock);
              ^
Makefile:236: recipe for target 'build/northbridge/intel/i945/gma.ramstage.o' failed
make: *** [build/northbridge/intel/i945/gma.ramstage.o] Error 1

could you please point me to how to fix this?
thank you!
Mono


From pgeorgi at google.com  Mon Sep  7 18:49:31 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Mon, 7 Sep 2015 20:49:31 +0200
Subject: [coreboot] Lenovo X60 broken by Change 11388
In-Reply-To: <20150907164708.GA1301@donderklumpen.de>
References: <20150907164708.GA1301@donderklumpen.de>
Message-ID: <CAE-gjdW=JvFYzzX8yGEg_VfoHM2=tCp+78Rrzy3Lt=Uw7pqeHA@mail.gmail.com>

2015-09-07 18:47 GMT+02:00 Mono <lists+coreboot at donderklumpen.de>:
> with Change 11388/commit 7dbf9c6 (edid: Use edid_mode struct to reduce redundancy) compiling coreboot for Lenovo X60 fails with this error:

> could you please point me to how to fix this?
See what changed in other files in that commit: some edid.name were
replaced with edid.mode.name.
You'll have to do the same in i945/gma.c


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores


From scan-admin at coverity.com  Tue Sep  8 23:14:59 2015
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Tue, 08 Sep 2015 16:14:59 -0700
Subject: [coreboot] New Defects reported by Coverity Scan for coreboot
Message-ID: <55ef6bf35856d_79e39b931c134bb@scan.mail>


Hi,

Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.

47 new defect(s) introduced to coreboot found with Coverity Scan.
353 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 47 defect(s)


** CID 1323498:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 194 in t114_get_sdram_param()


________________________________________________________________________________________________________
*** CID 1323498:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 194 in t114_get_sdram_param()
188     		u_int32_t *value)
189     {
190     	nvboot_sdram_params *params;
191     	nvboot_config_table *bct = NULL;
192     
193     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323498:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
194     	assert(context != NULL);
195     	assert(bct != NULL);
196     	params = &(bct->sdram_params[index]);
197     
198     	switch (token) {
199     	CASE_GET_SDRAM_PARAM(memory_type);

** CID 1323497:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 1091 in t114_init_bad_block_table()


________________________________________________________________________________________________________
*** CID 1323497:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 1091 in t114_init_bad_block_table()
1085     	u_int32_t bytes_per_entry;
1086     	nvboot_badblock_table *table;
1087     	nvboot_config_table *bct;
1088     
1089     	bct = (nvboot_config_table *)(context->bct);
1090     
>>>     CID 1323497:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1091     	assert(context != NULL);
1092     	assert(bct != NULL);
1093     
1094     	table = &bct->badblock_table;
1095     
1096     	bytes_per_entry = ICEIL(context->partition_size,

** CID 1323496:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 123 in t114_set_dev_param()


________________________________________________________________________________________________________
*** CID 1323496:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 123 in t114_set_dev_param()
117     	parse_token token,
118     	u_int32_t value)
119     {
120     	nvboot_config_table *bct = NULL;
121     
122     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323496:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
123     	assert(context != NULL);
124     	assert(bct != NULL);
125     
126     	bct->num_param_sets = NV_MAX(bct->num_param_sets, index + 1);
127     
128     	switch (token) {

** CID 1323495:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 525 in t114_set_sdram_param()


________________________________________________________________________________________________________
*** CID 1323495:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t114/nvbctlib_t114.c: 525 in t114_set_sdram_param()
519     		u_int32_t value)
520     {
521     	nvboot_sdram_params *params;
522     	nvboot_config_table *bct = NULL;
523     
524     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323495:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
525     	assert(context != NULL);
526     	assert(bct != NULL);
527     	params = &(bct->sdram_params[index]);
528     	/* Update the number of SDRAM parameter sets. */
529     	bct->num_sdram_sets = NV_MAX(bct->num_sdram_sets, index + 1);
530     

** CID 1323494:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 174 in t30_get_dev_param()


________________________________________________________________________________________________________
*** CID 1323494:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 174 in t30_get_dev_param()
168     	parse_token token,
169     	u_int32_t *value)
170     {
171     	nvboot_config_table *bct = NULL;
172     
173     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323494:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
174     	assert(context != NULL);
175     	assert(bct != NULL);
176     
177     	switch (token) {
178     	CASE_GET_DEV_PARAM(nand, clock_divider);
179     	CASE_GET_DEV_PARAM(nand, block_size_log2);

** CID 1323493:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 224 in t30_get_sdram_param()


________________________________________________________________________________________________________
*** CID 1323493:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 224 in t30_get_sdram_param()
218     		u_int32_t *value)
219     {
220     	nvboot_sdram_params *params;
221     	nvboot_config_table *bct = NULL;
222     
223     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323493:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
224     	assert(context != NULL);
225     	assert(bct != NULL);
226     	params = &(bct->sdram_params[index]);
227     
228     	switch (token) {
229     	CASE_GET_SDRAM_PARAM(memory_type);

** CID 1323492:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 879 in t30_init_bad_block_table()


________________________________________________________________________________________________________
*** CID 1323492:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 879 in t30_init_bad_block_table()
873     	u_int32_t bytes_per_entry;
874     	nvboot_badblock_table *table;
875     	nvboot_config_table *bct;
876     
877     	bct = (nvboot_config_table *)(context->bct);
878     
>>>     CID 1323492:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
879     	assert(context != NULL);
880     	assert(bct != NULL);
881     
882     	table = &bct->badblock_table;
883     
884     	bytes_per_entry = ICEIL(context->partition_size,

** CID 1323491:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 123 in t30_set_dev_param()


________________________________________________________________________________________________________
*** CID 1323491:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 123 in t30_set_dev_param()
117     	parse_token token,
118     	u_int32_t value)
119     {
120     	nvboot_config_table *bct = NULL;
121     
122     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323491:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
123     	assert(context != NULL);
124     	assert(bct != NULL);
125     
126     	bct->num_param_sets = NV_MAX(bct->num_param_sets, index + 1);
127     
128     	switch (token) {

** CID 1323490:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 438 in t30_set_sdram_param()


________________________________________________________________________________________________________
*** CID 1323490:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t30/nvbctlib_t30.c: 438 in t30_set_sdram_param()
432     		u_int32_t value)
433     {
434     	nvboot_sdram_params *params;
435     	nvboot_config_table *bct = NULL;
436     
437     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323490:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
438     	assert(context != NULL);
439     	assert(bct != NULL);
440     	params = &(bct->sdram_params[index]);
441     	/* Update the number of SDRAM parameter sets. */
442     	bct->num_sdram_sets = NV_MAX(bct->num_sdram_sets, index + 1);
443     

** CID 1323489:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 163 in t20_get_dev_param()


________________________________________________________________________________________________________
*** CID 1323489:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 163 in t20_get_dev_param()
157     	parse_token token,
158     	u_int32_t *value)
159     {
160     	nvboot_config_table *bct = NULL;
161     
162     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323489:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163     	assert(context != NULL);
164     	assert(bct != NULL);
165     
166     	switch (token) {
167     	CASE_GET_DEV_PARAM(nand, clock_divider);
168     	CASE_GET_DEV_PARAM(nand, nand_timing);

** CID 1323488:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 326 in t20_get_sdram_param()


________________________________________________________________________________________________________
*** CID 1323488:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 326 in t20_get_sdram_param()
320     		u_int32_t *value)
321     {
322     	nvboot_sdram_params *params;
323     	nvboot_config_table *bct = NULL;
324     
325     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323488:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
326     	assert(context != NULL);
327     	assert(bct != NULL);
328     	params = &(bct->sdram_params[index]);
329     
330     	switch (token) {
331     	CASE_GET_SDRAM_PARAM(memory_type);

** CID 1323487:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 672 in t20_init_bad_block_table()


________________________________________________________________________________________________________
*** CID 1323487:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 672 in t20_init_bad_block_table()
666     	u_int32_t bytes_per_entry;
667     	nvboot_badblock_table *table;
668     	nvboot_config_table *bct;
669     
670     	bct = (nvboot_config_table *)(context->bct);
671     
>>>     CID 1323487:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
672     	assert(context != NULL);
673     	assert(bct != NULL);
674     
675     	table = &bct->badblock_table;
676     
677     	bytes_per_entry = ICEIL(context->partition_size,

** CID 1323486:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 123 in t20_set_dev_param()


________________________________________________________________________________________________________
*** CID 1323486:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 123 in t20_set_dev_param()
117     	parse_token token,
118     	u_int32_t value)
119     {
120     	nvboot_config_table *bct = NULL;
121     
122     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323486:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
123     	assert(context != NULL);
124     	assert(bct != NULL);
125     
126     	bct->num_param_sets = NV_MAX(bct->num_param_sets, index + 1);
127     
128     	switch (token) {

** CID 1323485:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 202 in t20_set_sdram_param()


________________________________________________________________________________________________________
*** CID 1323485:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t20/nvbctlib_t20.c: 202 in t20_set_sdram_param()
196     		u_int32_t value)
197     {
198     	nvboot_sdram_params *params;
199     	nvboot_config_table *bct = NULL;
200     
201     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323485:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
202     	assert(context != NULL);
203     	assert(bct != NULL);
204     	params = &(bct->sdram_params[index]);
205     	/* Update the number of SDRAM parameter sets. */
206     	bct->num_sdram_sets = NV_MAX(bct->num_sdram_sets, index + 1);
207     

** CID 1323484:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 164 in t124_get_dev_param()


________________________________________________________________________________________________________
*** CID 1323484:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 164 in t124_get_dev_param()
158     	parse_token token,
159     	u_int32_t *value)
160     {
161     	nvboot_config_table *bct = NULL;
162     
163     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323484:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
164     	assert(context != NULL);
165     	assert(bct != NULL);
166     
167     	switch (token) {
168     	CASE_GET_DEV_PARAM(sdmmc, clock_divider);
169     	CASE_GET_DEV_PARAM(sdmmc, data_width);

** CID 1323483:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 199 in t124_get_sdram_param()


________________________________________________________________________________________________________
*** CID 1323483:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 199 in t124_get_sdram_param()
193     		u_int32_t *value)
194     {
195     	nvboot_sdram_params *params;
196     	nvboot_config_table *bct = NULL;
197     
198     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323483:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
199     	assert(context != NULL);
200     	assert(bct != NULL);
201     	params = &(bct->sdram_params[index]);
202     
203     	switch (token) {
204     	CASE_GET_SDRAM_PARAM(memory_type);

** CID 1323482:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 1104 in t124_init_bad_block_table()


________________________________________________________________________________________________________
*** CID 1323482:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 1104 in t124_init_bad_block_table()
1098     	u_int32_t bytes_per_entry;
1099     	nvboot_badblock_table *table;
1100     	nvboot_config_table *bct;
1101     
1102     	bct = (nvboot_config_table *)(context->bct);
1103     
>>>     CID 1323482:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1104     	assert(context != NULL);
1105     	assert(bct != NULL);
1106     
1107     	table = &bct->badblock_table;
1108     
1109     	bytes_per_entry = ICEIL(context->partition_size,

** CID 1323481:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 128 in t124_set_dev_param()


________________________________________________________________________________________________________
*** CID 1323481:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 128 in t124_set_dev_param()
122     	parse_token token,
123     	u_int32_t value)
124     {
125     	nvboot_config_table *bct = NULL;
126     
127     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323481:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
128     	assert(context != NULL);
129     	assert(bct != NULL);
130     
131     	bct->num_param_sets = NV_MAX(bct->num_param_sets, index + 1);
132     
133     	switch (token) {

** CID 1323480:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 529 in t124_set_sdram_param()


________________________________________________________________________________________________________
*** CID 1323480:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t124/nvbctlib_t124.c: 529 in t124_set_sdram_param()
523     		u_int32_t value)
524     {
525     	nvboot_sdram_params *params;
526     	nvboot_config_table *bct = NULL;
527     
528     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323480:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
529     	assert(context != NULL);
530     	assert(bct != NULL);
531     	params = &(bct->sdram_params[index]);
532     	/* Update the number of SDRAM parameter sets. */
533     	bct->num_sdram_sets = NV_MAX(bct->num_sdram_sets, index + 1);
534     

** CID 1323479:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t210/nvbctlib_t210.c: 164 in t210_get_dev_param()


________________________________________________________________________________________________________
*** CID 1323479:  Null pointer dereferences  (REVERSE_INULL)
/util/nvidia/cbootimage/src/t210/nvbctlib_t210.c: 164 in t210_get_dev_param()
158     	parse_token token,
159     	u_int32_t *value)
160     {
161     	nvboot_config_table *bct = NULL;
162     
163     	bct = (nvboot_config_table *)(context->bct);
>>>     CID 1323479:  Null pointer dereferences  (REVERSE_INULL)
>>>     Null-checking "context" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
164     	assert(context != NULL);
165     	assert(bct != NULL);
166     
167     	switch (token) {
168     	CASE_GET_DEV_PARAM(sdmmc, clock_divider);
169     	CASE_GET_DEV_PARAM(sdmmc, data_width);


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/coreboot?tab=overview

To manage Coverity Scan email notifications for "coreboot at coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&token=49533df725f93b78361afb7b89ccde93



From phcoder at gmail.com  Wed Sep  9 07:29:10 2015
From: phcoder at gmail.com (=?UTF-8?Q?Vladimir_'=cf=86-coder/phcoder'_Serbinenko?=)
Date: Wed, 9 Sep 2015 00:29:10 -0700
Subject: [coreboot] Goodies for Bonn meeting
Message-ID: <55EFDFC6.3080603@gmail.com>

Hello, all. My girlfriend Maria (CC'ed) would like to organize some
goodies for coreboot meeting. Already available are black T-shirts:
2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't
double-check now as I'm travelling.
Expected price is under ?20 for any of items.
Capacity is limited, first come first serve, respond to this e-mail to
order.
What else we can do:
- White t-shirt
- white cups
- colour cups
- Fridge magnets
- case for iPhone (indicate which one), not sure which ones are available
- Beer coaster
- mouse pad
- baseball cap

In addition, if you're ok with waiting about a month + delivery time we
can order:
- Black t-shirt (other than the sizes mentioned above, or once the stock
is out)
- Colour t-shirt over ?20

We're doing it just for fun and to serve the community, the price is
only to cover our costs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150909/e02ef6f5/attachment.asc>

From nico.huber at secunet.com  Wed Sep  9 14:05:36 2015
From: nico.huber at secunet.com (Nico Huber)
Date: Wed, 9 Sep 2015 16:05:36 +0200
Subject: [coreboot] Change in coreboot[master]: coreboot_table: don't
 add CMOS checksum twice.
In-Reply-To: <gerrit.1390787632000.I6d12f35fd8ff12eee9a17365bbfab38845c09574@review.coreboot.org>
References: <gerrit.1390787632000.I6d12f35fd8ff12eee9a17365bbfab38845c09574@review.coreboot.org>
Message-ID: <55F03CB0.2010503@secunet.com>

Am 16.04.2015 15:12, schrieb gerrit code review:
> From Nico Huber <nico.h at gmx.de>:
> 
> Nico Huber has posted comments on this change.
> 
> Change subject: coreboot_table: don't add CMOS checksum twice.
> ......................................................................
> 
> 
> Patch Set 3:
> 
> Ahh, took me a day to find this commit and what is going wrong.
> 
> You were right, that the checksum appeared twice in a row. But that's
> only true, if you don't read the table from the beginning: The
> checksum from the cmos_layout is nested in another tag. That makes a
> difference because libpayload parses the table, looks for the
> checksum, but doesn't understand nested tags.
> 
> I hadn't the time to check whether this problem persists upstream, but
> it looks like it does.
This still persists. To be clear: This change was meant to be cosmetic
but has real impact. Upstream, libpayload is unable to read nvram
variables since this has been merged (January 2014).

The commit still seems to be a good idea. But If nobody plans to adapt
libpayload, shall we revert it?

Nico

-- 
To view, visit http://review.coreboot.org/4829
To unsubscribe, visit http://review.coreboot.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I6d12f35fd8ff12eee9a17365bbfab38845c09574
Gerrit-PatchSet: 3
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Owner: Vladimir Serbinenko <phcoder at gmail.com>
Gerrit-Reviewer: Alexandru Gagniuc <mr.nuke.me at gmail.com>
Gerrit-Reviewer: Nico Huber <nico.h at gmx.de>
Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer at coreboot.org>
Gerrit-Reviewer: Vladimir Serbinenko <phcoder at gmail.com>
Gerrit-Reviewer: build bot (Jenkins)
Gerrit-HasComments: No

-- 
M. Sc. Nico Huber
Senior Berater SINA-Softwareentwicklung
Netzwerk- & Client-Sicherheit / Network & Client Security
Division ?ffentliche Auftraggeber / Public Authorities
secunet Security Networks AG

Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.huber at secunet.com
Mergenthalerallee 77, 65760 Eschborn, Deutschland
www.secunet.com
______________________________________________________________________

Sitz: Kronprinzenstra?e 30, 45128 Essen, Deutschland
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Pleines 
Aufsichtsratsvorsitzender: Dr. Peter Zattler
______________________________________________________________________


From proddik at gmail.com  Sat Sep  5 08:36:21 2015
From: proddik at gmail.com (Adil producer)
Date: Sat, 5 Sep 2015 11:36:21 +0300
Subject: [coreboot] Support intel Bay-trail tablet pc board
Message-ID: <CALUcRvTF=L6pdDWDk_COtTjmZOxSM1Z1RZrpD45q_qO-RF7b8g@mail.gmail.com>

Hi,
My name is Adil. I with my friend developing console for smart home system
based on Intel Z3735g tablet pc motherboard. We planning use coreboot for
booting write it on SPI flash.
Now we have two Chinese tablet pc motherboard we BIOS on Winbond 25Q64FWSIG.
But we don't found in supported hardware list Bay-trail chips. We need help
to prepare firmware for this boot. Can you help us?
If we successful boot on this motherboard - we send you all instructions
and Bay-trail chips can supported coreboot.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150905/377e0949/attachment-0001.html>

From maxime.deroucy at gmail.com  Sun Sep  6 14:10:25 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Sun, 06 Sep 2015 16:10:25 +0200
Subject: [coreboot] STACK_SIZE pcengines apu1
Message-ID: <1441548625.1185.10.camel@gmail.com>

Hello,

I am building a coreboot rom for my pcengines apu1.
A bug is logged during the boot process :
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=pcengines/apu1/4.0-9873-g7b9762f/2015-06-04T15:16:28Z/coreboot_console.txt;hb=HEAD#l1281

In order to solve it I applied this changed :

    diff --git a/src/Kconfig b/src/Kconfig
    index 9c01687..c8b8ad2 100644
    --- a/src/Kconfig
    +++ b/src/Kconfig
    @@ -427,7 +427,7 @@ config HEAP_SIZE
     config STACK_SIZE
            hex
            default 0x0 if (ARCH_RAMSTAGE_ARM || ARCH_RAMSTAGE_MIPS || ARCH_RAMSTAGE_RISCV)
    -       default 0x1000
    +       default 0x2000
     
     config MAX_CPUS
            int

I don't see the bug line anymore, instead I see :

    CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34, stack used: 4812 bytes

I now the patch is not good since it change the default stack size for
all the boards. I didn't found the right place the change the stack
size only for pcengines apu1 board.
But maybe those informations can help developers to improve coreboot.
-- 
Regards
Maxime de Roucy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/71796972/attachment-0001.asc>

From maxime.deroucy at gmail.com  Sun Sep  6 14:20:59 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Sun, 06 Sep 2015 16:20:59 +0200
Subject: [coreboot] coreinfo "General Protection Fault Exception"
Message-ID: <1441549259.1185.16.camel@gmail.com>

Hello,

On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get a
"General Protection Fault Exception".

I attached my .config file of coreinfo (it's the default configuration)
and the console output when coreinfo crash.
-- 
Regards
Maxime de Roucy
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# coreinfo Configuration
#

#
# General settings
#
CONFIG_SHOW_DATE_TIME=y
CONFIG_PAYLOAD_INFO_NAME="coreinfo"
CONFIG_PAYLOAD_INFO_LISTNAME="System Information"
CONFIG_PAYLOAD_INFO_DESC="Display information about the system"
CONFIG_PAYLOAD_INFO_VERSION="0.1"

#
# Modules
#
CONFIG_MODULE_COREBOOT=y
CONFIG_MODULE_MULTIBOOT=y
CONFIG_MODULE_CPUINFO=y
CONFIG_MODULE_PCI=y
CONFIG_MODULE_NVRAM=y
CONFIG_MODULE_BOOTLOG=y
CONFIG_MODULE_RAMDUMP=y
# CONFIG_MODULE_LAR is not set
CONFIG_MODULE_CBFS=y
-------------- next part --------------
General Protection Fault Exception
Error code: 0x20 - descriptor 0x4 in the GDT, internal to the CPU
EIP:    0x000fd272
CS:     0x0010
EFLAGS: 0x00010087
EAX:    0x00000020
ECX:    0x00006fca
EDX:    0x00007e2f
EBX:    0x00009b78
ESP:    0x00006fb4
EBP:    0xffe8e404
ESI:    0x00000000
EDI:    0x00136760
DS:     0x0018
ES:     0x0018
SS:     0x0018
FS:     0x0018
GS:     0x0018
Dumping stack:
0x71a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7180: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7140: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7120: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7100: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x70e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x70c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x70a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7080: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7060: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7020: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x7000: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
0x6fe0: 00000000 00000000 e9810000 0200f000 00000000 00000000 00000000 00000000 
0x6fc0: 00000000 ffe8e3e8 00000000 00000000 00000000 00000000 00000000 00000000 
0x6fa0: 00100000 00000020 000fd272 00000010 00010087 00006fb4 00006fb4 000f5eba 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/c071ed01/attachment-0001.asc>

From wordpress at blogs.coreboot.org  Wed Sep  2 16:36:18 2015
From: wordpress at blogs.coreboot.org (WordPress)
Date: Wed, 2 Sep 2015 16:36:18 +0000
Subject: [coreboot] New on blogs.coreboot.org: 2015-08-28 Librem 13: Weekly
	BIOS Update
Message-ID: <1728404ae3743dc72b45b06459e9c95a@blogs.coreboot.org>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150902/e8c44032/attachment-0001.html>

From jhdoubleoseven at gmail.com  Wed Sep  2 23:51:17 2015
From: jhdoubleoseven at gmail.com (James Heald)
Date: Wed, 2 Sep 2015 16:51:17 -0700
Subject: [coreboot] Is flashrom safe on the x220 with coreboot?
Message-ID: <CAAETRmxKsHxq6TapeR_eC-eLZVZgow0RNZ6RxqwAeOuVA5DnVw@mail.gmail.com>

Hi there!

Just curious, I was able to successfully (albeit maybe not very
intelligently) read the flash chip on my lappy twice, and it read
successfully. However, since the x220 is not "officially" supported by
flashrom I has to use laptop:force_i_want_a_brick.

I'm curious if anyone with the x220 has reflashed coreboot (multiple times
even?) on their x220 and not had any issues. I *thought* I read somewhere
that since the firmware is unlocked it was safe to do, though I could have
been reading something for another laptop.

Thanks!

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150902/b7620ffb/attachment-0001.html>

From maxime.deroucy at gmail.com  Sun Sep  6 14:30:12 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Sun, 06 Sep 2015 16:30:12 +0200
Subject: [coreboot] pcengines apu1 nvram support
Message-ID: <1441549812.1185.22.camel@gmail.com>

Hello,

I made a patch for the pcengines apu1 board to support nvram
(HAVE_OPTION_TABLE).
I made/adapt this patch from the "Sage" source available at
http://www.pcengines.ch/howto.php#CoreBoot
-- 
Regards
Maxime de Roucy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcengines-apu-nvram.patch
Type: text/x-patch
Size: 2777 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/70fd6302/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/70fd6302/attachment-0001.asc>

From maxime.deroucy at gmail.com  Sun Sep  6 16:11:14 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Sun, 06 Sep 2015 18:11:14 +0200
Subject: [coreboot] coreinfo "General Protection Fault Exception"
In-Reply-To: <1441549259.1185.16.camel@gmail.com>
References: <1441549259.1185.16.camel@gmail.com>
Message-ID: <1441555874.1185.30.camel@gmail.com>

Le dimanche 06 septembre 2015 ? 16:20 +0200, Maxime de Roucy a ?crit :
> Hello,
> 
> On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get 
> a "General Protection Fault Exception".

I forget to mention I build coreinfo on a x86_64 Archlinux with :

cd ?/coreboot/payloads/coreinfo
make LIBPAYLOAD_DIR=../libpayload/install CC=?/coreboot/util/crossgcc/xgcc/bin/i386-elf-gcc

-- 
Regards
Maxime de Roucy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/9dada37b/attachment-0001.asc>

From maxime.deroucy at gmail.com  Sun Sep  6 17:12:43 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Sun, 06 Sep 2015 19:12:43 +0200
Subject: [coreboot] pcengines apu1 nvram support
In-Reply-To: <1441549812.1185.22.camel@gmail.com>
References: <1441549812.1185.22.camel@gmail.com>
Message-ID: <1441559563.1185.45.camel@gmail.com>

Le dimanche 06 septembre 2015 ? 16:30 +0200, Maxime de Roucy a ?crit :
> I made a patch for the pcengines apu1 board to support nvram
> (HAVE_OPTION_TABLE).
> I made/adapt this patch from the "Sage" source available at
> http://www.pcengines.ch/howto.php#CoreBoot

I change the patch a little by adding a cmos.default file.
-- 
Regards
Maxime de Roucy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcengines-apu-nvram.patch
Type: text/x-patch
Size: 3355 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/7909291b/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/7909291b/attachment-0001.asc>

From opensource at holgerbrunn.net  Sun Sep  6 16:52:44 2015
From: opensource at holgerbrunn.net (Holger Brunn)
Date: Sun, 06 Sep 2015 18:52:44 +0200
Subject: [coreboot] unbricking an Acer CB5
Message-ID: <1868795.JNtAH7RIoO@rivendell>

Dear readers,

I played with compiling my own coreboot image for my Acer CB5 [1] and failed 
miserably - the bios is messed up and the device won't boot any more. Now I'm 
busy following some guides to undo the damage [2], [3] by flashing the 
original bios again, but given I'm quite clueless about hardware, I'd like to 
ask you for advice about how to proceed:

I ordered a Raspberry PI, some connector cables [4], and then I probably need 
a clip to connect the chip [5].

My question to you is how to locate the chip? The mainboard looks like that: 
http://opensource.holgerbrunn.net/debian-on-acer-cb5/images/DSC01629.JPG and 
the only chip that looks like those in the examples is U37 in the lower right. 
Is there any way to know beforehand if it's the correct one? And then when 
connecting the pins, can I look up somewhere what the correct assignment is or 
is this trial and error? I can't read what is printed on it, but if relevant, 
I'll get a magnifying glass to post the text.

Thank you a lot in advance, and be sure that I won't come back whining if 
anything goes wrong and I fry the chip following your advice - that's entirely 
my fault then.

I'll log the process on the above website if successful so that the next 
person messing this up won't have to bother you.

Regards,
Holger

Links:
[1] https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13
[2] http://www.tnhh.net/2014/08/25/unbricking-chromebook-with-beaglebone.html
[3] https://johnlewis.ie/unbricking-a-samsung-series-5-550-chromebook
[4] https://www.conrad.nl/nl/raspberry-pi-verbindingskabel-rb-cb5-025-bont-banana-pi-pcduino-arduino-raspberry-pi-a-b-b-1290220.html?sc.ref=Homepage
[5] http://www.digikey.nl/product-detail/en/5250/501-1311-ND/745102
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150906/a1a4c3de/attachment-0001.asc>

From kurtqqh at gmail.com  Wed Sep  9 09:42:32 2015
From: kurtqqh at gmail.com (Kurt Qiao)
Date: Wed, 9 Sep 2015 17:42:32 +0800
Subject: [coreboot] [help]build cbfstool fail with cygwin64
Message-ID: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>

does anyone try cygwin64 to build coreboot in windows7 64bit?
i got fail when build cbfstool with cygwin64.
my steps as below:

1. cygwin64 install utility "patch", "flex", 'wget' etc.

2. git pull latest coreboot from github
build crossgcc
./buildgcc -j 4

3. build iasl
download src from link [1]
make
cp acpica-unix-20150818/generate/unix/bin/iasl /usr/local/bin

4. make menuconfig
choose "emulation/qemu-q35" in my case

5.make
then fail as below
----
<stdout>: In function 'yy_init_buffer':
<stdout>:1395:9: error: implicit declaration of function 'fileno'
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
util/cbfstool/Makefile.inc:59: recipe for target
'build/util/cbfstool/fmd_scanner.o' failed
make: *** [build/util/cbfstool/fmd_scanner.o] Error 1
---

i follow link [2] to modify cbfstool makefile, add _D_GNU_SOURCE for
TOOLCPPFLAGS, CPPFLAGS
and fail as below log.
---
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 432 Optimizations
    HOSTCC     cbfstool/fmaptool.o
    HOSTCC     cbfstool/cbfs_sections.o
    HOSTCC     cbfstool/fmap_from_fmd.o
    HOSTCC     cbfstool/fmd.o
    HOSTCC     cbfstool/fmd_parser.o
    HOSTCC     cbfstool/fmd_scanner.o
    HOSTCC     cbfstool/fmap.o
    HOSTCC     cbfstool/kv_pair.o
    HOSTCC     cbfstool/valstr.o
    HOSTCC     cbfstool/fmaptool (link)
build/util/cbfstool/fmd.o:fmd.c:(.text+0xa23): undefined reference to
`yylex_destroy'
build/util/cbfstool/fmd.o:fmd.c:(.text+0xa23): relocation truncated to
fit: R_X86_64_PC32 against undefined symbol `yylex_destroy'
build/util/cbfstool/fmd.o:fmd.c:(.rdata$.refptr.yyin[.refptr.yyin]+0x0):
undefined reference to `yyin'
build/util/cbfstool/fmd_parser.o:fmd_parser.c:(.text+0x386): undefined
reference to `yylex'
build/util/cbfstool/fmd_parser.o:fmd_parser.c:(.text+0x386):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`yylex'
collect2: error: ld returned 1 exit status
util/cbfstool/Makefile.inc:83: recipe for target
'build/util/cbfstool/fmaptool' failed
make: *** [build/util/cbfstool/fmaptool] Error 1
---

[1]:https://acpica.org/sites/acpica/files/acpica-unix-20150818.tar.gz
[2]:http://review.coreboot.org/#/c/10027/1


From jlewis at johnlewis.ie  Thu Sep 10 08:31:23 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Thu, 10 Sep 2015 09:31:23 +0100
Subject: [coreboot] unbricking an Acer CB5
In-Reply-To: <1868795.JNtAH7RIoO@rivendell>
References: <1868795.JNtAH7RIoO@rivendell>
Message-ID: <33f9c6d5c3ff79e83446ac2c4eb23079@johnlewis.ie>

On 2015-09-06 17:52, Holger Brunn wrote:
> Dear readers,
> 
> I played with compiling my own coreboot image for my Acer CB5 [1] and 
> failed
> miserably - the bios is messed up and the device won't boot any more. 
> Now I'm
> busy following some guides to undo the damage [2], [3] by flashing the
> original bios again, but given I'm quite clueless about hardware, I'd 
> like to
> ask you for advice about how to proceed:
> 
> I ordered a Raspberry PI, some connector cables [4], and then I 
> probably need
> a clip to connect the chip [5].
> 
> My question to you is how to locate the chip? The mainboard looks like 
> that:
> http://opensource.holgerbrunn.net/debian-on-acer-cb5/images/DSC01629.JPG 
> and
> the only chip that looks like those in the examples is U37 in the lower 
> right.
> Is there any way to know beforehand if it's the correct one? And then 
> when
> connecting the pins, can I look up somewhere what the correct 
> assignment is or
> is this trial and error? I can't read what is printed on it, but if 
> relevant,
> I'll get a magnifying glass to post the text.

Yes, u37 looks like it. But, bear in mind many Chromebooks have the SPI 
on the other side of the board. If the chip is the wrong size (early 
Chromebooks had a separate EC on a 512k SPI) Flashrom will crap out and 
complain when you try to flash an 8MB binary to it. Pin assignment is 
available in various articles on the web, this is one I found by 
searching - 
https://github.com/bibanon/Coreboot-ThinkPads/wiki/Hardware-Flashing-with-Raspberry-Pi. 
I have used a magnifying app on my smart-phone before, but it's 
unnecessary.

HTH,

John.

> 
> Thank you a lot in advance, and be sure that I won't come back whining 
> if
> anything goes wrong and I fry the chip following your advice - that's 
> entirely
> my fault then.
> 
> I'll log the process on the above website if successful so that the 
> next
> person messing this up won't have to bother you.
> 
> Regards,
> Holger
> 
> Links:
> [1]
> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13
> [2] 
> http://www.tnhh.net/2014/08/25/unbricking-chromebook-with-beaglebone.html
> [3] https://johnlewis.ie/unbricking-a-samsung-series-5-550-chromebook
> [4]
> https://www.conrad.nl/nl/raspberry-pi-verbindingskabel-rb-cb5-025-bont-banana-pi-pcduino-arduino-raspberry-pi-a-b-b-1290220.html?sc.ref=Homepage
> [5] http://www.digikey.nl/product-detail/en/5250/501-1311-ND/745102


From adurbin at google.com  Thu Sep 10 14:02:16 2015
From: adurbin at google.com (Aaron Durbin)
Date: Thu, 10 Sep 2015 09:02:16 -0500
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <1441548625.1185.10.camel@gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
Message-ID: <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>

On Sun, Sep 6, 2015 at 9:10 AM, Maxime de Roucy
<maxime.deroucy at gmail.com> wrote:
> Hello,
>
> I am building a coreboot rom for my pcengines apu1.
> A bug is logged during the boot process :
> http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=pcengines/apu1/4.0-9873-g7b9762f/2015-06-04T15:16:28Z/coreboot_console.txt;hb=HEAD#l1281
>
> In order to solve it I applied this changed :
>
>     diff --git a/src/Kconfig b/src/Kconfig
>     index 9c01687..c8b8ad2 100644
>     --- a/src/Kconfig
>     +++ b/src/Kconfig
>     @@ -427,7 +427,7 @@ config HEAP_SIZE
>      config STACK_SIZE
>             hex
>             default 0x0 if (ARCH_RAMSTAGE_ARM || ARCH_RAMSTAGE_MIPS || ARCH_RAMSTAGE_RISCV)
>     -       default 0x1000
>     +       default 0x2000
>
>      config MAX_CPUS
>             int
>
> I don't see the bug line anymore, instead I see :
>
>     CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34, stack used: 4812 bytes
>
> I now the patch is not good since it change the default stack size for
> all the boards. I didn't found the right place the change the stack
> size only for pcengines apu1 board.
> But maybe those informations can help developers to improve coreboot.

That's quite the stack usage.  It'd be interesting to know what's
using all that stack. Could you apply this patch and run w/ it? It'd
help narrow down at what point in the boot where the stack gets used
up. Also, that you used 4812 bytes just means you overwrote the other
CPU's stack at some point when STACK_SIZE == 4KiB.


diff --git a/src/lib/hardwaremain.c b/src/lib/hardwaremain.c
index b3c0c35..8a241b2 100644
--- a/src/lib/hardwaremain.c
+++ b/src/lib/hardwaremain.c
@@ -378,6 +378,8 @@ static void bs_walk_state_machine(void)
                bs_report_time(state);

                state->complete = 1;
+
+               checkstack(_estack, 0);
        }
 }


> --
> Regards
> Maxime de Roucy
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From marcj303 at gmail.com  Thu Sep 10 15:35:41 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 10 Sep 2015 15:35:41 +0000
Subject: [coreboot] coreinfo "General Protection Fault Exception"
In-Reply-To: <1441549259.1185.16.camel@gmail.com>
References: <1441549259.1185.16.camel@gmail.com>
Message-ID: <CALrs_3jcB0y6KkxWwng7N-NoXZ+kMnmeNqKraYGvMWZ3n+QE0g@mail.gmail.com>

It looks like coreinfo is the only payload, so there is nothing to exit
back to. What were you expecting to happen?

You can try using seabios with multiple payloads or work with bayou as a
multiple payload loader.

Marc

On Thu, Sep 10, 2015 at 12:54 AM Maxime de Roucy <maxime.deroucy at gmail.com>
wrote:

> Hello,
>
> On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get a
> "General Protection Fault Exception".
>
> I attached my .config file of coreinfo (it's the default configuration)
> and the console output when coreinfo crash.
> --
> Regards
> Maxime de Roucy--
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/33ab89a8/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Sep 10 20:14:15 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 10 Sep 2015 22:14:15 +0200
Subject: [coreboot] Hotel rooms: coreboot conference 2015
In-Reply-To: <201509050312.38145.coreboot-conference@bsi.bund.de>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
 <201509050312.38145.coreboot-conference@bsi.bund.de>
Message-ID: <55F1E497.8070701@gmx.net>

The venue still has 7 very affordable single/double rooms available!

Email info at wzbonn.de and tell them you're attending the coreboot
conference. Those rooms are reserved for conference participants.

Regards,
Carl-Daniel


On 05.09.2015 03:12, coreboot conference wrote:
> Dear vendors, developers, users and interested parties,
>
> On behalf of the Federal Office for Information Security (BSI) Germany I would
> like to invite you to the coreboot conference and developer meeting on 
> October 9-11 2015 in Bonn, Germany.
>
> This conference and developer meeting is geared towards manufacturers of 
> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
> desktops/ appliances) as well as developers of firmware with an interest in 
> coreboot and the possibilities it offers as well as (potential) coreboot 
> users. Both professionals and hobbyists are invited.
>
> Please see the full text of the invitation at 
> http://coreboot.org/coreboot_conference_Bonn_2015
>
> Sincerely,
> Carl-Daniel Hailfinger



From maxime.deroucy at gmail.com  Thu Sep 10 21:11:39 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Thu, 10 Sep 2015 23:11:39 +0200
Subject: [coreboot] coreinfo "General Protection Fault Exception"
In-Reply-To: <CALrs_3jcB0y6KkxWwng7N-NoXZ+kMnmeNqKraYGvMWZ3n+QE0g@mail.gmail.com>
References: <1441549259.1185.16.camel@gmail.com>
 <CALrs_3jcB0y6KkxWwng7N-NoXZ+kMnmeNqKraYGvMWZ3n+QE0g@mail.gmail.com>
Message-ID: <1441919499.1012.5.camel@gmail.com>

Le jeudi 10 septembre 2015 ? 15:35 +0000, Marc Jones a ?crit :
> It looks like coreinfo is the only payload, so there is nothing to
> exit back to. What were you expecting to happen? 
> 
> You can try using seabios with multiple payloads or work with bayou
> as a multiple payload loader. 

No, coreinfo isn't the only payload. SeaBIOS is the main payload, I
also have memtest and ipxe (once I also have nvramcui).

I didn't expect coreinfo to launch to the next payload when it stop.
I expect it to reboot the computer as nvramcui do.

max at max-laptop % ./cbfstool coreboot.rom print
coreboot.rom: 2048 kB, bootblocksize 1576, romsize 2097152, offset 0x0
alignment: 64 bytes, architecture: x86

Name                           Offset     Type         Size
?
genroms/ipxe.rom               0x6a880    raw          56832
img/coreinfo                   0x786c0    payload      65500
img/memtest                    0x88700    payload      147240
?

-- 
Regards
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/5e0bf388/attachment.asc>

From maxime.deroucy at gmail.com  Thu Sep 10 21:34:33 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Thu, 10 Sep 2015 23:34:33 +0200
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
Message-ID: <1441920873.1012.9.camel@gmail.com>

Le jeudi 10 septembre 2015 ? 09:02 -0500, Aaron Durbin a ?crit :
> That's quite the stack usage.  It'd be interesting to know what's
> using all that stack. Could you apply this patch and run w/ it? It'd
> help narrow down at what point in the boot where the stack gets used
> up.

You will find the spew log of the modified coreboot you asked.
(it's a reboot, not a boot? I don't know if that's change something).
-- 
Regards
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spew.log
Type: text/x-log
Size: 54567 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/a48d6ff7/attachment-0001.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/a48d6ff7/attachment-0001.asc>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Sep 10 21:31:43 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 10 Sep 2015 23:31:43 +0200
Subject: [coreboot] Hotel rooms: coreboot conference 2015
In-Reply-To: <55F1E497.8070701@gmx.net>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
 <201509050312.38145.coreboot-conference@bsi.bund.de>
 <55F1E497.8070701@gmx.net>
Message-ID: <55F1F6BF.9020309@gmx.net>

My sincere apologies, the email address seems to be out of order.

Please use ////wissenschaftszentrum at wzbonn.de for booking a
bed+breakfast room at the conference venue.

Regards,
Carl-Daniel

On 10.09.2015 22:14, Carl-Daniel Hailfinger wrote:
> The venue still has 7 very affordable single/double rooms available!
>
> Email info at wzbonn.de and tell them you're attending the coreboot
> conference. Those rooms are reserved for conference participants.
>
> Regards,
> Carl-Daniel
>
>
> On 05.09.2015 03:12, coreboot conference wrote:
>> Dear vendors, developers, users and interested parties,
>>
>> On behalf of the Federal Office for Information Security (BSI) Germany I would
>> like to invite you to the coreboot conference and developer meeting on 
>> October 9-11 2015 in Bonn, Germany.
>>
>> This conference and developer meeting is geared towards manufacturers of 
>> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ 
>> desktops/ appliances) as well as developers of firmware with an interest in 
>> coreboot and the possibilities it offers as well as (potential) coreboot 
>> users. Both professionals and hobbyists are invited.
>>
>> Please see the full text of the invitation at 
>> http://coreboot.org/coreboot_conference_Bonn_2015
>>
>> Sincerely,
>> Carl-Daniel Hailfinger
>



From adurbin at google.com  Thu Sep 10 22:15:52 2015
From: adurbin at google.com (Aaron Durbin)
Date: Thu, 10 Sep 2015 17:15:52 -0500
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <1441920873.1012.9.camel@gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
Message-ID: <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>

On Thu, Sep 10, 2015 at 4:34 PM, Maxime de Roucy
<maxime.deroucy at gmail.com> wrote:
> Le jeudi 10 septembre 2015 ? 09:02 -0500, Aaron Durbin a ?crit :
>> That's quite the stack usage.  It'd be interesting to know what's
>> using all that stack. Could you apply this patch and run w/ it? It'd
>> help narrow down at what point in the boot where the stack gets used
>> up.
>
> You will find the spew log of the modified coreboot you asked.
> (it's a reboot, not a boot? I don't know if that's change something).

BS: BS_DEV_INIT times (us): entry 0 run 358353 exit 0
CPU0: stack: 00148000 - 0014a000, lowest used address 00149a2c, stack
used: 1492 bytes
CBMEM:
IMD: root @ dffff000 254 entries.
IMD: root @ dfffec00 62 entries.
Moving GDT to dfffea00...ok
Finalize devices...
Devices finalized
agesawrapper_amdinitlate() returned AGESA_SUCCESS
agesawrapper_amdS3Save() returned AGESA_SUCCESS
SF: Detected MX25L1605D with sector size 0x1000, total 0x200000
SF: Successfully erased 4096 bytes @ 0xffff1000
SF: Detected MX25L1605D with sector size 0x1000, total 0x200000
SF: Successfully erased 4096 bytes @ 0xffff0000
BS: BS_POST_DEVICE times (us): entry 9377 run 3502 exit 113447
CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34, stack
used: 4812 bytes

So I'd get either agesawrapper_amdinitlate() or
agesawrapper_amdS3Save(). In either case it's in AGESA.

> --
> Regards
> Maxime


From jwerner at chromium.org  Thu Sep 10 23:25:54 2015
From: jwerner at chromium.org (Julius Werner)
Date: Thu, 10 Sep 2015 16:25:54 -0700
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
 <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
Message-ID: <CAODwPW-dgCYBLBRAhgRbYBON0-HYU3GKtKKttXs=M4vHz24b4g@mail.gmail.com>

I'd bet it's just a single large allocation somewhere. You can try adding

 CFLAGS_ramstage += -Wstack-usage=1024

somewhere in coreboot/Makefile.inc and then clean+rebuild your code while
passing '-k' to make. You'll get a bunch of compiler warnings, and one of
them is likely to be the culprit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/b3a33803/attachment.html>

From pgeorgi at google.com  Fri Sep 11 15:56:23 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 11 Sep 2015 17:56:23 +0200
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
Message-ID: <CAE-gjdXna0YSLeJk-RBgE9kgJBH7ktsbeqX=AAigDprQB0D2Pg@mail.gmail.com>

2015-09-09 11:42 GMT+02:00 Kurt Qiao <kurtqqh at gmail.com>:
> 5.make
> then fail as below
> ----
> <stdout>: In function 'yy_init_buffer':
> <stdout>:1395:9: error: implicit declaration of function 'fileno'
> [-Werror=implicit-function-declaration]
> ---
>
> i follow link [2] to modify cbfstool makefile, add _D_GNU_SOURCE for
> TOOLCPPFLAGS, CPPFLAGS
That doesn't fix the missing fileno declaration, which is the root cause.
C standard library providers for Windows seem to be undecided what to
do on this function (according to a quick internet search for cygwin
and fileno). Sadly I haven't found a simple solution and don't have a
system around for testing.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores


From ssl at google.com  Thu Sep 10 14:44:22 2015
From: ssl at google.com (Sheng-Liang Song)
Date: Thu, 10 Sep 2015 07:44:22 -0700
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
Message-ID: <CABGK7UOs-ny4u3NqKU+rWUxT04D+ts=4jj8JRrqDRj_H5kkCHg@mail.gmail.com>

It is better to review the pcengines apu1 boot code--pay attention on any
function that uses >= 64B stack storage
(function arguments and local variables).  Try reduce the stack size of
such functions instead of increasing the STACK_SIZE.

On Thu, Sep 10, 2015 at 7:02 AM, Aaron Durbin <adurbin at google.com> wrote:

> On Sun, Sep 6, 2015 at 9:10 AM, Maxime de Roucy
> <maxime.deroucy at gmail.com> wrote:
> > Hello,
> >
> > I am building a coreboot rom for my pcengines apu1.
> > A bug is logged during the boot process :
> >
> http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=pcengines/apu1/4.0-9873-g7b9762f/2015-06-04T15:16:28Z/coreboot_console.txt;hb=HEAD#l1281
> >
> > In order to solve it I applied this changed :
> >
> >     diff --git a/src/Kconfig b/src/Kconfig
> >     index 9c01687..c8b8ad2 100644
> >     --- a/src/Kconfig
> >     +++ b/src/Kconfig
> >     @@ -427,7 +427,7 @@ config HEAP_SIZE
> >      config STACK_SIZE
> >             hex
> >             default 0x0 if (ARCH_RAMSTAGE_ARM || ARCH_RAMSTAGE_MIPS ||
> ARCH_RAMSTAGE_RISCV)
> >     -       default 0x1000
> >     +       default 0x2000
> >
> >      config MAX_CPUS
> >             int
> >
> > I don't see the bug line anymore, instead I see :
> >
> >     CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34,
> stack used: 4812 bytes
> >
> > I now the patch is not good since it change the default stack size for
> > all the boards. I didn't found the right place the change the stack
> > size only for pcengines apu1 board.
> > But maybe those informations can help developers to improve coreboot.
>
> That's quite the stack usage.  It'd be interesting to know what's
> using all that stack. Could you apply this patch and run w/ it? It'd
> help narrow down at what point in the boot where the stack gets used
> up. Also, that you used 4812 bytes just means you overwrote the other
> CPU's stack at some point when STACK_SIZE == 4KiB.
>
>
> diff --git a/src/lib/hardwaremain.c b/src/lib/hardwaremain.c
> index b3c0c35..8a241b2 100644
> --- a/src/lib/hardwaremain.c
> +++ b/src/lib/hardwaremain.c
> @@ -378,6 +378,8 @@ static void bs_walk_state_machine(void)
>                 bs_report_time(state);
>
>                 state->complete = 1;
> +
> +               checkstack(_estack, 0);
>         }
>  }
>
>
> > --
> > Regards
> > Maxime de Roucy
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
Sheng-Liang Song | Software Engineer | ssl at google.com | 650-537-5017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150910/19e8e0b8/attachment.html>

From paulepanter at users.sourceforge.net  Fri Sep 11 20:20:03 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 11 Sep 2015 22:20:03 +0200
Subject: [coreboot] coreinfo "General Protection Fault Exception"
In-Reply-To: <1441549259.1185.16.camel@gmail.com>
References: <1441549259.1185.16.camel@gmail.com>
Message-ID: <1442002803.6609.80.camel@users.sourceforge.net>

Dear Maxime,


Am Sonntag, den 06.09.2015, 16:20 +0200 schrieb Maxime de Roucy:

> On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get a
> "General Protection Fault Exception".
> 
> I attached my .config file of coreinfo (it's the default 
> configuration) and the console output when coreinfo crash.

does that also happen, when using the same payloads files with QEMU?

If yes, maybe it can be better debugged there.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150911/e6ac3f04/attachment-0001.asc>

From paulepanter at users.sourceforge.net  Fri Sep 11 20:22:13 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 11 Sep 2015 22:22:13 +0200
Subject: [coreboot] coreboot conference 2015: Looking for room mate (was:
 Hotel rooms: coreboot conference 2015)
In-Reply-To: <55F1E497.8070701@gmx.net>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
 <201509050312.38145.coreboot-conference@bsi.bund.de>
 <55F1E497.8070701@gmx.net>
Message-ID: <1442002933.6609.82.camel@users.sourceforge.net>

Dear coreboot folks,


Am Donnerstag, den 10.09.2015, 22:14 +0200 schrieb Carl-Daniel Hailfinger:
> The venue still has 7 very affordable single/double rooms available!

Would somebody share a double room to reduce the costs a little? If
yes, please contact me.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150911/58547f0d/attachment.asc>

From paulepanter at users.sourceforge.net  Fri Sep 11 20:36:24 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Fri, 11 Sep 2015 22:36:24 +0200
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAODwPW-dgCYBLBRAhgRbYBON0-HYU3GKtKKttXs=M4vHz24b4g@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
 <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
 <CAODwPW-dgCYBLBRAhgRbYBON0-HYU3GKtKKttXs=M4vHz24b4g@mail.gmail.com>
Message-ID: <1442003784.6609.89.camel@users.sourceforge.net>

Dear coreboot folks,


Am Donnerstag, den 10.09.2015, 16:25 -0700 schrieb Julius Werner:
> I'd bet it's just a single large allocation somewhere. You can try adding
> 
>  CFLAGS_ramstage += -Wstack-usage=1024
> 
> somewhere in coreboot/Makefile.inc and then clean+rebuild your code while
> passing '-k' to make. You'll get a bunch of compiler warnings, and one of
> them is likely to be the culprit.

It looks like that Julius was dead on! Building the similar ASRock
E350M1 with the modification proposed by Julius, building stops with
the error below.

```
$ make
[?]
    CC         northbridge/amd/agesa/oem_s3.ramstage.o
src/northbridge/amd/agesa/oem_s3.c: In function 'OemS3Save':
src/northbridge/amd/agesa/oem_s3.c:118:14: error: stack usage might be 4144 bytes [-Werror=stack-usage=]
 AGESA_STATUS OemS3Save(void *vS3SaveParams)
              ^
```


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150911/dbee4e97/attachment.asc>

From adurbin at google.com  Fri Sep 11 20:49:17 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 11 Sep 2015 15:49:17 -0500
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <1442003784.6609.89.camel@users.sourceforge.net>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
 <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
 <CAODwPW-dgCYBLBRAhgRbYBON0-HYU3GKtKKttXs=M4vHz24b4g@mail.gmail.com>
 <1442003784.6609.89.camel@users.sourceforge.net>
Message-ID: <CAE2855s7j+FOcifbyLi4G9MFMtbx19QhWQmX5YR9C7QsxBci-g@mail.gmail.com>

On Fri, Sep 11, 2015 at 3:36 PM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> Dear coreboot folks,
>
>
> Am Donnerstag, den 10.09.2015, 16:25 -0700 schrieb Julius Werner:
>> I'd bet it's just a single large allocation somewhere. You can try adding
>>
>>  CFLAGS_ramstage += -Wstack-usage=1024
>>
>> somewhere in coreboot/Makefile.inc and then clean+rebuild your code while
>> passing '-k' to make. You'll get a bunch of compiler warnings, and one of
>> them is likely to be the culprit.
>
> It looks like that Julius was dead on! Building the similar ASRock
> E350M1 with the modification proposed by Julius, building stops with
> the error below.
>
> ```
> $ make
> [?]
>     CC         northbridge/amd/agesa/oem_s3.ramstage.o
> src/northbridge/amd/agesa/oem_s3.c: In function 'OemS3Save':
> src/northbridge/amd/agesa/oem_s3.c:118:14: error: stack usage might be 4144 bytes [-Werror=stack-usage=]
>  AGESA_STATUS OemS3Save(void *vS3SaveParams)
>               ^
> ```

Fun. 4KiB buffer on the stack for the win.

$ git grep S3_DATA_MTRR_SIZE -- src/northbridge/amd/agesa/ | grep define
src/northbridge/amd/agesa/oem_s3.c:#define S3_DATA_MTRR_SIZE
        0x1000



>
>
> Thanks,
>
> Paul


From lynxis at fe80.eu  Fri Sep 11 21:21:41 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Fri, 11 Sep 2015 23:21:41 +0200
Subject: [coreboot] Berlin User Group Meeting 21.Sep
Message-ID: <20150911232141.31e1338a@lazus.yip>

Hi folks,

I'm starting a User Group in Berlin. The first meeting will take
place on 21. Sep. in the CCCB.

For more information about the location take a look on
https://berlin.ccc.de/wiki/Club_Discordia

Best,
lynxis

PS: Yes it's Monday evening and it's open for everyone.
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at jabber.ccc.de
mobile: +4915123277221
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150911/b033186d/attachment.sig>

From lynxis at fe80.eu  Fri Sep 11 21:29:41 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Fri, 11 Sep 2015 23:29:41 +0200
Subject: [coreboot] Berlin User Group Meeting 21.Sep
In-Reply-To: <20150911232141.31e1338a@lazus.yip>
References: <20150911232141.31e1338a@lazus.yip>
Message-ID: <20150911232941.7f229e6d@lazus.yip>

Opps, I forgot to mention the time ;)
21.Sep 20:30
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150911/dc03a801/attachment.sig>

From kyosti.malkki at gmail.com  Fri Sep 11 21:54:46 2015
From: kyosti.malkki at gmail.com (=?ISO-8859-1?Q?Ky=F6sti_M=E4lkki?=)
Date: Sat, 12 Sep 2015 00:54:46 +0300
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAE2855s7j+FOcifbyLi4G9MFMtbx19QhWQmX5YR9C7QsxBci-g@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
 <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
 <CAODwPW-dgCYBLBRAhgRbYBON0-HYU3GKtKKttXs=M4vHz24b4g@mail.gmail.com>
 <1442003784.6609.89.camel@users.sourceforge.net>
 <CAE2855s7j+FOcifbyLi4G9MFMtbx19QhWQmX5YR9C7QsxBci-g@mail.gmail.com>
Message-ID: <1442008486.24120.220.camel@obelix>

On pe, 2015-09-11 at 15:49 -0500, Aaron Durbin wrote:
> On Fri, Sep 11, 2015 at 3:36 PM, Paul Menzel
> <paulepanter at users.sourceforge.net> wrote:
> > Dear coreboot folks,
> >
> >
> > Am Donnerstag, den 10.09.2015, 16:25 -0700 schrieb Julius Werner:
> >> I'd bet it's just a single large allocation somewhere. You can try adding
> >>
> >>  CFLAGS_ramstage += -Wstack-usage=1024
> >>
> >> somewhere in coreboot/Makefile.inc and then clean+rebuild your code while
> >> passing '-k' to make. You'll get a bunch of compiler warnings, and one of
> >> them is likely to be the culprit.
> >
> > It looks like that Julius was dead on! Building the similar ASRock
> > E350M1 with the modification proposed by Julius, building stops with
> > the error below.
> >
> > ```
> > $ make
> > [?]
> >     CC         northbridge/amd/agesa/oem_s3.ramstage.o
> > src/northbridge/amd/agesa/oem_s3.c: In function 'OemS3Save':
> > src/northbridge/amd/agesa/oem_s3.c:118:14: error: stack usage might be 4144 bytes [-Werror=stack-usage=]
> >  AGESA_STATUS OemS3Save(void *vS3SaveParams)
> >               ^
> > ```
> 
> Fun. 4KiB buffer on the stack for the win.
> 
> $ git grep S3_DATA_MTRR_SIZE -- src/northbridge/amd/agesa/ | grep define
> src/northbridge/amd/agesa/oem_s3.c:#define S3_DATA_MTRR_SIZE
>         0x1000
> 

Yeah, my bad. I overlooked stack usage while wondering if those MTRRs
really need to be backed up in SPI in the first place.

http://review.coreboot.org/#/c/11633/


Thanks,
Ky?sti



From Zheng.Bao at amd.com  Thu Sep 10 08:34:20 2015
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Thu, 10 Sep 2015 08:34:20 +0000
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
Message-ID: <9190E42A2EF0E146B3940E1FFAD11C3724897521@SCYBEXDAG02.amd.com>

You can remove the -Werror
In util/cbfstool/Makefile.inc
Try again.

Zheng.

> -----Original Message-----
> From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Kurt Qiao
> Sent: Wednesday, September 09, 2015 5:43 PM
> To: coreboot at coreboot.org
> Subject: [coreboot] [help]build cbfstool fail with cygwin64
> 
> does anyone try cygwin64 to build coreboot in windows7 64bit?
> i got fail when build cbfstool with cygwin64.
> my steps as below:
> 
> 1. cygwin64 install utility "patch", "flex", 'wget' etc.
> 
> 2. git pull latest coreboot from github
> build crossgcc
> ./buildgcc -j 4
> 
> 3. build iasl
> download src from link [1]
> make
> cp acpica-unix-20150818/generate/unix/bin/iasl /usr/local/bin
> 
> 4. make menuconfig
> choose "emulation/qemu-q35" in my case
> 
> 5.make
> then fail as below
> ----
> <stdout>: In function 'yy_init_buffer':
> <stdout>:1395:9: error: implicit declaration of function 'fileno'
> [-Werror=implicit-function-declaration]
> cc1: all warnings being treated as errors
> util/cbfstool/Makefile.inc:59: recipe for target
> 'build/util/cbfstool/fmd_scanner.o' failed
> make: *** [build/util/cbfstool/fmd_scanner.o] Error 1
> ---
> 
> i follow link [2] to modify cbfstool makefile, add _D_GNU_SOURCE for
> TOOLCPPFLAGS, CPPFLAGS and fail as below log.
> ---
> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 432 Optimizations
>     HOSTCC     cbfstool/fmaptool.o
>     HOSTCC     cbfstool/cbfs_sections.o
>     HOSTCC     cbfstool/fmap_from_fmd.o
>     HOSTCC     cbfstool/fmd.o
>     HOSTCC     cbfstool/fmd_parser.o
>     HOSTCC     cbfstool/fmd_scanner.o
>     HOSTCC     cbfstool/fmap.o
>     HOSTCC     cbfstool/kv_pair.o
>     HOSTCC     cbfstool/valstr.o
>     HOSTCC     cbfstool/fmaptool (link)
> build/util/cbfstool/fmd.o:fmd.c:(.text+0xa23): undefined reference to
> `yylex_destroy'
> build/util/cbfstool/fmd.o:fmd.c:(.text+0xa23): relocation truncated to
> fit: R_X86_64_PC32 against undefined symbol `yylex_destroy'
> build/util/cbfstool/fmd.o:fmd.c:(.rdata$.refptr.yyin[.refptr.yyin]+0x0):
> undefined reference to `yyin'
> build/util/cbfstool/fmd_parser.o:fmd_parser.c:(.text+0x386): undefined
> reference to `yylex'
> build/util/cbfstool/fmd_parser.o:fmd_parser.c:(.text+0x386):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol `yylex'
> collect2: error: ld returned 1 exit status
> util/cbfstool/Makefile.inc:83: recipe for target
> 'build/util/cbfstool/fmaptool' failed
> make: *** [build/util/cbfstool/fmaptool] Error 1
> ---
> 
> [1]:https://acpica.org/sites/acpica/files/acpica-unix-20150818.tar.gz
> [2]:http://review.coreboot.org/#/c/10027/1
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From stefan.reinauer at coreboot.org  Mon Sep 14 18:07:57 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Mon, 14 Sep 2015 18:07:57 +0000
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
Message-ID: <20150914180756.GA32636@coreboot.org>

* Kurt Qiao <kurtqqh at gmail.com> [150909 09:42]:
> does anyone try cygwin64 to build coreboot in windows7 64bit?
> i got fail when build cbfstool with cygwin64.

Can you try the following two patches to see if they solve your problem

http://review.coreboot.org/11636 Don't use fileno() to get file size
http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW

Also, if that doesn't work try to replace the MINGW check with something
like #if defined (_WIN64) || defined (__CYGWIN64__) instead.

(Make sure to run make clean in the cbfstool directory before trying)

Stefan


From opensource at holgerbrunn.net  Mon Sep 14 22:03:44 2015
From: opensource at holgerbrunn.net (Holger Brunn)
Date: Tue, 15 Sep 2015 00:03:44 +0200
Subject: [coreboot] unbricking an Acer CB5
In-Reply-To: <33f9c6d5c3ff79e83446ac2c4eb23079@johnlewis.ie>
References: <1868795.JNtAH7RIoO@rivendell>
 <33f9c6d5c3ff79e83446ac2c4eb23079@johnlewis.ie>
Message-ID: <3699627.MHbYq6sEAl@rivendell>

John,

> Yes, u37 looks like it.

thank you so much for your helpful advice! I'm up and running again and very 
happy.

For the record: I put what I did for my specific model on 
http://opensource.holgerbrunn.net/debian-on-acer-cb5#unbricking

I seem to have done something stupid when shorting the three pins supposed to 
be connected to 3.3V, this didn't work. But when I disconnected the first pin 
and connected the other to the second 3.3V on the PI, the chip was recognized. 
Is it safe to propose the same to other people or was it beginner's luck I 
didn't damage anything with this wiring?

Regards,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150915/bac7bdf3/attachment.asc>

From jlewis at johnlewis.ie  Mon Sep 14 22:16:11 2015
From: jlewis at johnlewis.ie (John Lewis)
Date: Mon, 14 Sep 2015 23:16:11 +0100
Subject: [coreboot] unbricking an Acer CB5
In-Reply-To: <3699627.MHbYq6sEAl@rivendell>
References: <1868795.JNtAH7RIoO@rivendell>
 <33f9c6d5c3ff79e83446ac2c4eb23079@johnlewis.ie>
 <3699627.MHbYq6sEAl@rivendell>
Message-ID: <b87f4ce7f1227818501f33f25099209a@johnlewis.ie>

>> Yes, u37 looks like it.
> 
> thank you so much for your helpful advice! I'm up and running again and 
> very
> happy.
> 

No problem.

> For the record: I put what I did for my specific model on
> http://opensource.holgerbrunn.net/debian-on-acer-cb5#unbricking
> 
> I seem to have done something stupid when shorting the three pins 
> supposed to
> be connected to 3.3V, this didn't work. But when I disconnected the 
> first pin
> and connected the other to the second 3.3V on the PI, the chip was 
> recognized.
> Is it safe to propose the same to other people or was it beginner's 
> luck I
> didn't damage anything with this wiring?

No, generally you don't need to short the 3 pins. In fact the second 
3.3v you connected may not have been necessary either. I haven't damaged 
any of the Chromebooks I've had doing that, and I must've had about a 
dozen at this stage.

> 
> Regards,
> Holger

Regards,

John.


From mr.nuke.me at gmail.com  Tue Sep 15 01:40:53 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 14 Sep 2015 18:40:53 -0700
Subject: [coreboot] STACK_SIZE pcengines apu1
In-Reply-To: <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
References: <1441548625.1185.10.camel@gmail.com>
 <CAE2855uBjMoLD1UDy=Zp2VonXoCQE1jsXocA1K+JHnq=9WmtFg@mail.gmail.com>
 <1441920873.1012.9.camel@gmail.com>
 <CAE2855vTCPNz4Ds7w07+-VLutvo3uzRv=hmeUor=rQXj8C0WPw@mail.gmail.com>
Message-ID: <55F77725.8040904@gmail.com>

> In either case it's in AGESA.

Of course it's AGESA. Good job on figuring out which part of AGESA (this
 is usually the hard part).

Alex


From maxime.deroucy at gmail.com  Tue Sep 15 22:17:57 2015
From: maxime.deroucy at gmail.com (Maxime de Roucy)
Date: Wed, 16 Sep 2015 00:17:57 +0200
Subject: [coreboot] coreinfo "General Protection Fault Exception"
In-Reply-To: <1442002803.6609.80.camel@users.sourceforge.net>
References: <1441549259.1185.16.camel@gmail.com>
 <1442002803.6609.80.camel@users.sourceforge.net>
Message-ID: <1442355477.1349.14.camel@gmail.com>

Le vendredi 11 septembre 2015 ? 22:20 +0200, Paul Menzel a ?crit :
> does that also happen, when using the same payloads files with QEMU?
> If yes, maybe it can be better debugged there.

I rebuild coreboot with a qemu target and debug enabled.
I also rebuild coreinfo with "-g" added to the CFLAGS.

The probl?me appear 3~4 seconds after coreinfo is launched.
Before I even do anything? (I didn't press ESC).

I rebuild coreinfo and sgabios in a full 32 bits environnement but that
doesn't change anything.

I tried to debug the problem on gdb.
It appear on the second launch of getch but I didn't figured where
exactly.

I upload the rom and elf.debug (and sources) of coreinfo on my server
if someone want to take a look :
http://ftp.craoc.fr/coreboot-debug/

To launch it :
1$ qemu-system-i386 -M q35 -bios coreboot.rom -hda /dev/zero -nographic -s -S

2$ gdb --tui
(gdb) target remote localhost:1234
(gdb) file ../payloads/coreinfo/build/coreinfo.elf.debug
(gdb) b main
(gdb) c
[gdb will stop here but it's wrong, you have to continu]
(gdb) c

in qemu press "ESC" and select "4 payload[coreinfo]".
gdb should stop at the begining of the main function of coreinfo.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150916/00661d4b/attachment.asc>

From no-reply at raptorengineeringinc.com  Wed Sep 16 09:15:27 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Wed, 16 Sep 2015 04:15:27 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
Message-ID: <20150916091526.GA7742@cb-test-ctl>

The ASUS KFSN4-DRE fails verification as of commit a0e77384638878ffb8b6a970f4655eb071e8a7c1

The following tests failed:
VIDEO_FAILURE

Commits since last successful test:
a0e7738 abuild: don't complain about missing junit reports for skipped boards
053322f abuild: log bulding tools
098c4a8 abuild: don't create junit tests with empty testclass field

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering <tpearson at raptorengineeringinc.com> regarding any issues stemming from this notification
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1442394916-0-automaster.log.bz2
Type: application/octet-stream
Size: 51760 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150916/de98d615/attachment-0001.obj>

From tpearson at raptorengineeringinc.com  Wed Sep 16 15:35:09 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Wed, 16 Sep 2015 10:35:09 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
In-Reply-To: <20150916091526.GA7742@cb-test-ctl>
References: <20150916091526.GA7742@cb-test-ctl>
Message-ID: <55F98C2D.1050309@raptorengineeringinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/16/2015 04:15 AM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KFSN4-DRE fails verification as of commit a0e77384638878ffb8b6a970f4655eb071e8a7c1
> 
> The following tests failed:
> VIDEO_FAILURE
> 
> Commits since last successful test:
> a0e7738 abuild: don't complain about missing junit reports for skipped boards
> 053322f abuild: log bulding tools
> 098c4a8 abuild: don't create junit tests with empty testclass field
> 
> See attached log for details
> 
> This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
> Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html
> 
> Raptor Engineering also offers coreboot consulting services!  Please visit https://www.raptorengineeringinc.com for more information
> 
> Please contact Timothy Pearson at Raptor Engineering <tpearson at raptorengineeringinc.com> regarding any issues stemming from this notification
> 

This can likely be ignored.  I am still tweaking timeouts to get
everything testing as quickly as possible without false positives.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJV+YwqAAoJEK+E3vEXDOFbXcEH/RA99iVMe1JgQ1VVA/1Nlh7R
QHJHBh23LOAmjbWe9likqv5dexGEuH/IWI3NjL6T0iht+tFTEwWfoIM+ssQDXZSN
gs2YGPeWhRrRy8AqSnU8rF3Krbeoz+WLLwjWE6sbb/L/7MdzicDoqHK/qVjboca8
z8vZowwHV7fCOPCeQAXy8y/JFHulwUnjOG32kRowzK3+UVN7DpBNvFZ+A36S33Ps
iEl/bAMSsYCjabLaqeqQ+NFLuOF3DNaIoJTa+fhJbtlAaw4mj0Q+rr2MGZespf75
QK41WOiN5Mkb4Lrc7kdp6h0VVSyo+PsWErUrV7rn1zMVYtvhIBtUALNn7pm/pmQ=
=JTW8
-----END PGP SIGNATURE-----


From rminnich at gmail.com  Wed Sep 16 17:15:15 2015
From: rminnich at gmail.com (ron minnich)
Date: Wed, 16 Sep 2015 17:15:15 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <55EFDFC6.3080603@gmail.com>
References: <55EFDFC6.3080603@gmail.com>
Message-ID: <CAP6exYLn300a3h4AWULzE0ejbo2KnXCO3b+-TxVV4+0KAszYCA@mail.gmail.com>

I'd love the
hat
cpu
magnet

thanks

ron

On Wed, Sep 9, 2015 at 12:30 AM Vladimir '?-coder/phcoder' Serbinenko <
phcoder at gmail.com> wrote:

> Hello, all. My girlfriend Maria (CC'ed) would like to organize some
> goodies for coreboot meeting. Already available are black T-shirts:
> 2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't
> double-check now as I'm travelling.
> Expected price is under ?20 for any of items.
> Capacity is limited, first come first serve, respond to this e-mail to
> order.
> What else we can do:
> - White t-shirt
> - white cups
> - colour cups
> - Fridge magnets
> - case for iPhone (indicate which one), not sure which ones are available
> - Beer coaster
> - mouse pad
> - baseball cap
>
> In addition, if you're ok with waiting about a month + delivery time we
> can order:
> - Black t-shirt (other than the sizes mentioned above, or once the stock
> is out)
> - Colour t-shirt over ?20
>
> We're doing it just for fun and to serve the community, the price is
> only to cover our costs.
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150916/ad0b3fcb/attachment.html>

From Zheng.Bao at amd.com  Wed Sep 16 05:53:30 2015
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 16 Sep 2015 05:53:30 +0000
Subject: [coreboot] Kconfig: My clang -print-file-name doesn't output the
	full path
Message-ID: <9190E42A2EF0E146B3940E1FFAD11C3724C24B67@SCYBEXDAG04.amd.com>

The output of uname on my MacOS.
# uname -a 
Darwin Baos-Mac-Pro.local 13.0.0 Darwin Kernel Version 13.0.0: ???????,  9 ?????? 2013 ?. 02:42:04 (MSK); root:xnu-2422.1.72_by_bronya_sinetek_anv_rc7/BUILD/obj/RELEASE_X86_64 x86_64

Gcc version:
# gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

# gcc -print-file-name=libncurses.dylib 
libncurses.dylib
# ls /usr/lib/libncurses.dylib 
/usr/lib/libncurses.dylib

The ld option -lncurses can link the right library.

Is this a bug on my MacOS. If it is, I will stop trying that?

Zheng


From pgeorgi at google.com  Thu Sep 17 08:03:35 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Thu, 17 Sep 2015 10:03:35 +0200
Subject: [coreboot] Kconfig: My clang -print-file-name doesn't output
 the full path
In-Reply-To: <9190E42A2EF0E146B3940E1FFAD11C3724C24B67@SCYBEXDAG04.amd.com>
References: <9190E42A2EF0E146B3940E1FFAD11C3724C24B67@SCYBEXDAG04.amd.com>
Message-ID: <CAE-gjdUhCfJYpDEg-D8iHG6O0xVaUCDJcvE9KMdruW1DmK9Jqw@mail.gmail.com>

2015-09-16 7:53 GMT+02:00 Bao, Zheng <Zheng.Bao at amd.com>:
> Is this a bug on my MacOS. If it is, I will stop trying that?
Our clang support isn't complete yet, and also requires patches to the compiler.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores


From mtsio at cryptolab.net  Tue Sep 22 19:00:14 2015
From: mtsio at cryptolab.net (mtsio)
Date: Tue, 22 Sep 2015 19:00:14 +0000
Subject: [coreboot] dead link in about page
Message-ID: <5601A53E.6080305@cryptolab.net>

Hi,

In this page http://blogs.coreboot.org/about/ the link to 'payload'
doesn't working (http://wiki.coreboot.org/Payloads). I think the correct
one is http://www.coreboot.org/Payloads.


From adurbin at google.com  Tue Sep 22 22:05:01 2015
From: adurbin at google.com (Aaron Durbin)
Date: Tue, 22 Sep 2015 15:05:01 -0700
Subject: [coreboot] mainboard CONFIG_ROM_SIZE and CONFIG_CBFS_SIZE
Message-ID: <CAE2855v_9En3Y1q1SrmOdLcgmqkKpqJ55wQawbAX_T4PE+Nkew@mail.gmail.com>

Hi Folks,

Patrick and I were talking about current mainboard config distribution
within the coreboot tree. Patrick informed me of the -C option for
abuild which generates all the configs (without doing the build) for
all the devices. Good pointer to remember.

We were talking about the CONFIG_ROM_SIZE and CONFIG_CBFS_SIZE
distribution. Please excuse my hacky script, but here's the current
breakdown:

$ for d in coreboot-builds/*; do if [ "$d" ==
"coreboot-builds/sharedutils" ]; then continue; fi; if [ "$d" ==
"coreboot-builds/abuild" ]; then continue; fi; awk '$2 ~
"CONFIG_ROM_SIZE" { romsize=$3 } $2 ~ "CONFIG_CBFS_SIZE" { cbfssize=$3
} END { print romsize,cbfssize} ' $d/config.h;  done | sed -e
's/0x[0]\{1,\}/0x/'  | sort | uniq -c | sort -k 1 -r -n
     78 0x80000 0x80000
     37 0x100000 0x100000
     34 0x400000 0x400000
     31 0x40000 0x40000
     27 0x800000 0x100000
     24 0x200000 0x200000
      8 0x800000 0x800000
      2 0xc00000 0x100000
      2 0x800000 0x200000
      1 0x800000 0x300000
      1 0x400000 0x100000
      1 0x20000 0x20000
      1 0x1000000 0xe00000
      1 0x1000000 0x1000000
      1 0x1000000 0x100000

That's 15 unique tuples with with 6 of those being one-offs.

-Aaron


From kurtqiao at gmail.com  Wed Sep 23 14:16:28 2015
From: kurtqiao at gmail.com (kurt qiao)
Date: Wed, 23 Sep 2015 22:16:28 +0800
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <20150914180756.GA32636@coreboot.org>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
 <20150914180756.GA32636@coreboot.org>
Message-ID: <CAHK7-EmaAyqJ_zKRfBWEgqS11R8Cx1CmoYJF7f4m0NiEY4uNkg@mail.gmail.com>

don't know why my email didn't receive in the list, so i reply again:
i finally built pass with define:

CFLAGS += -std=gnu99  in cbfstool/Makefile
TOOLCFLAGS ?= -std=gnu99  in cbfstool/Makefile.inc

and change cbfstool.c code to :
--  if (tolower(suffix[0])=='k') {
++ if (tolower((int)suffix[0])=='k') {

--  if (tolower(suffix[0])=='m') {
++ if (tolower((int)suffix[0])=='m') {


From dos at snear.de  Thu Sep 24 16:28:34 2015
From: dos at snear.de (Benjamin Bahnsen)
Date: Thu, 24 Sep 2015 18:28:34 +0200
Subject: [coreboot] BIOS for Biostar AM1ML not working
Message-ID: <560424B2.5090900@snear.de>

Yesterday I tried to build my first coreboot BIOS and everything went fine.
I followed the instructions and flashed the mainboard (using flashrom) with
the built rom. Unfortunately, the mainboard is dead now. Fan starts spinning
when I turn the computer on, but screen stays black.

Is there any chance to get a prebuilt rom from somewhere? It won't make 
sense
for me to start over, because I don't know what to do different. I used 
the DOS
version of flashrom, but I don't think that's a problem. I can provide a 
link
to the coreboot bios if someone wants to have a look.

Benjamin


From goljak at gmail.com  Fri Sep 25 14:06:23 2015
From: goljak at gmail.com (Mario Goljak)
Date: Fri, 25 Sep 2015 16:06:23 +0200
Subject: [coreboot] steps before screen mods
Message-ID: <CAJYonf2Y8ZcOYg7ALfmGG6qY66FoOY4N0DGx-o1cP+_wdgSSnA@mail.gmail.com>

Hi guys,

I just came across thinkpad forum thread where people are discuss about
hardware mods for getting FHD screen on lenovo x220/x230 laptops.
http://forum.thinkpads.com/viewtopic.php?f=43&t=106919&start=90

What do you guys think, will this affect coreboot at all? Are there any
necessary steps before playing with the screen?


Best regards,

Mario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150925/567ca168/attachment.html>

From rminnich at gmail.com  Sat Sep 26 20:18:37 2015
From: rminnich at gmail.com (ron minnich)
Date: Sat, 26 Sep 2015 20:18:37 +0000
Subject: [coreboot] Good OCP nodes for development?
Message-ID: <CAP6exYLqpMz1NEp658dauFW4cLjdOYB2bqA45NVz036ir60sqw@mail.gmail.com>

I just joined the open compute project as an individual member. Anybody
have some idea on what type of their nodes and which vendor are good to
look at for coreboot?

I realize OCP is not a coreboot user (I had that discussion with them about
5 years ago and they went with conventional wisdom, sadly, although I
expect one of the CPU providers was unfriendly about coreboot) but I'm
curious as to what it would take to make it work.

thanks

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150926/61c6a0b2/attachment.html>

From tpearson at raptorengineeringinc.com  Sun Sep 27 02:06:59 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Sat, 26 Sep 2015 21:06:59 -0500
Subject: [coreboot] Good OCP nodes for development?
In-Reply-To: <CAP6exYLqpMz1NEp658dauFW4cLjdOYB2bqA45NVz036ir60sqw@mail.gmail.com>
References: <CAP6exYLqpMz1NEp658dauFW4cLjdOYB2bqA45NVz036ir60sqw@mail.gmail.com>
Message-ID: <56074F43.2000202@raptorengineeringinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/26/2015 03:18 PM, ron minnich wrote:
> I just joined the open compute project as an individual member. Anybody
> have some idea on what type of their nodes and which vendor are good to
> look at for coreboot?
> 
> I realize OCP is not a coreboot user (I had that discussion with them
> about 5 years ago and they went with conventional wisdom, sadly,
> although I expect one of the CPU providers was unfriendly about
> coreboot) but I'm curious as to what it would take to make it work.
> 
> thanks
> 
> ron
> 

Anything x86 is going to be somewhat unfriendly due to the heavy push
for Secure Boot and the ensuing TiVo-ization / general platform
lockdown.  Intel uses the Management Engine for this purpose, while AMD
uses the Platform Security Processor.

We have been in talks with IBM regarding OpenPOWER and to be honest
that's probably the direction to be looking at this point.  The entire
chip is open with the exception of the Self Boot Engine, and IBM's
engineers are very open to the idea of custom firmware development.

Just my $0.02. :-)

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWB09AAAoJEK+E3vEXDOFbdUEH/jzmlbD0+Uz60ZKJjGjF3L7X
zWMVFNTTmdjtvjrWWy0LEl5GCp1+oqjp2jKbQ1i20Q3rTG12Ehm70eYX2dghwiRQ
mXyzgdN3fE5QsX9ecDb7rkXsEqG28mKGiu4jbmQr/LtmXLVXiT9rC0djCi0oCvbS
d13JDwhqyRz/zSTgXSL0ji1vimYA1S6BZVOy/JqARD2aBGJjWpB5OUIqeOW3PLrd
AoI0FL8TYsa1RsBTSt0ioAnpodGTYI2Gx1rS9SJqCi7hyorVPoDo3E3/m0p3lz4X
R85wEkQfeE89Qy9kqUBFXerCGKKEPMDV1r37xlvWw262piSxm7OqAgSlnNY7wac=
=JNI2
-----END PGP SIGNATURE-----


From paulepanter at users.sourceforge.net  Sun Sep 27 19:54:23 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Sun, 27 Sep 2015 21:54:23 +0200
Subject: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource
 temporarily unavailable` and code coverage enabled
Message-ID: <1443383663.2876.5.camel@users.sourceforge.net>

Dear coreboot folks,


building a coreboot image for the ASRock E350M1 with the attached
config, having code coverage enabled, I am unable to run the utility
`cbmem`.

```
$ sudo util/cbmem/cbmem -V -l
Looking for coreboot table at 0 1048576 bytes.
Mapping 1MB of physical memory at 0x0 (requested 0x0).
Found!
  coreboot table entry 0x11
    Found forwarding entry.
Unmapping 1MB of virtual memory at 0xb74b6000.
Looking for coreboot table at c7f9f000 1048576 bytes.
Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
  ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Linux complains with the messages below.

```
$ dmesg
[?]
[  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
[  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
[?]
```


Thanks,

Paul


[1] http://review.coreboot.org/11729
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
CONFIG_ANY_TOOLCHAIN=y
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_SCONFIG_GENPARSER is not set
CONFIG_USE_OPTION_TABLE=y
# CONFIG_STATIC_OPTION_TABLE is not set
# CONFIG_UNCOMPRESSED_RAMSTAGE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
# CONFIG_EARLY_CBMEM_INIT is not set
CONFIG_COLLECT_TIMESTAMPS=y
# CONFIG_HAS_PRECBMEM_TIMESTAMP_REGION is not set
# CONFIG_USE_BLOBS is not set
CONFIG_COVERAGE=y
# CONFIG_RELOCATABLE_MODULES is not set
CONFIG_FLASHMAP_OFFSET=0
CONFIG_BOOTBLOCK_SIMPLE=y
# CONFIG_BOOTBLOCK_NORMAL is not set
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
# CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR is not set
# CONFIG_UPDATE_IMAGE is not set
# CONFIG_GENERIC_GPIO_LIB is not set
# CONFIG_BOARD_ID_AUTO is not set
# CONFIG_BOARD_ID_MANUAL is not set
# CONFIG_RAM_CODE_SUPPORT is not set
# CONFIG_ACPI_SATA_GENERATOR is not set

#
# Mainboard
#
# CONFIG_VENDOR_A_TREND is not set
# CONFIG_VENDOR_AAEON is not set
# CONFIG_VENDOR_ABIT is not set
# CONFIG_VENDOR_ADLINK is not set
# CONFIG_VENDOR_ADVANSUS is not set
# CONFIG_VENDOR_AMD is not set
# CONFIG_VENDOR_AOPEN is not set
# CONFIG_VENDOR_APPLE is not set
# CONFIG_VENDOR_ARIMA is not set
# CONFIG_VENDOR_ARTECGROUP is not set
CONFIG_VENDOR_ASROCK=y
# CONFIG_VENDOR_ASUS is not set
# CONFIG_VENDOR_AVALUE is not set
# CONFIG_VENDOR_AZZA is not set
# CONFIG_VENDOR_BACHMANN is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BCOM is not set
# CONFIG_VENDOR_BIFFEROS is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_BROADCOM is not set
# CONFIG_VENDOR_COMPAQ is not set
# CONFIG_VENDOR_CUBIETECH is not set
# CONFIG_VENDOR_DIGITALLOGIC is not set
# CONFIG_VENDOR_DMP is not set
# CONFIG_VENDOR_ECS is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_GETAC is not set
# CONFIG_VENDOR_GIGABYTE is not set
# CONFIG_VENDOR_GIZMOSPHERE is not set
# CONFIG_VENDOR_GOOGLE is not set
# CONFIG_VENDOR_HP is not set
# CONFIG_VENDOR_IBASE is not set
# CONFIG_VENDOR_IBM is not set
# CONFIG_VENDOR_IEI is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_IWAVE is not set
# CONFIG_VENDOR_IWILL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
# CONFIG_VENDOR_LANNER is not set
# CONFIG_VENDOR_LENOVO is not set
# CONFIG_VENDOR_LINUTOP is not set
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_MITAC is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_NEC is not set
# CONFIG_VENDOR_NEWISYS is not set
# CONFIG_VENDOR_NOKIA is not set
# CONFIG_VENDOR_NVIDIA is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_RCA is not set
# CONFIG_VENDOR_RODA is not set
# CONFIG_VENDOR_SAMSUNG is not set
# CONFIG_VENDOR_SIEMENS is not set
# CONFIG_VENDOR_SOYO is not set
# CONFIG_VENDOR_SUNW is not set
# CONFIG_VENDOR_SUPERMICRO is not set
# CONFIG_VENDOR_TECHNEXION is not set
# CONFIG_VENDOR_THOMSON is not set
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_TRAVERSE is not set
# CONFIG_VENDOR_TYAN is not set
# CONFIG_VENDOR_VIA is not set
# CONFIG_VENDOR_WINENT is not set
# CONFIG_VENDOR_WYSE is not set
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_DIR="asrock/e350m1"
CONFIG_MAINBOARD_PART_NUMBER="E350M1"
CONFIG_IRQ_SLOT_COUNT=11
CONFIG_MAINBOARD_VENDOR="ASROCK"
CONFIG_HW_MEM_HOLE_SIZEK=0x200000
CONFIG_MAX_CPUS=2
# CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC is not set
CONFIG_VGA_BIOS_ID="1002,9802"
CONFIG_ONBOARD_VGA_IS_PRIMARY=y
CONFIG_VGA_BIOS=y
# CONFIG_UDELAY_IO is not set
# CONFIG_SB800_AHCI_ROM is not set
CONFIG_MAINBOARD_SERIAL_NUMBER="123456789"
CONFIG_DCACHE_RAM_BASE=0x30000
CONFIG_DCACHE_RAM_SIZE=0x10000
CONFIG_VGA_BIOS_FILE="pci1002,9802.rom.lzma"
CONFIG_MMCONF_BASE_ADDRESS=0xF8000000
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="ASROCK"
# CONFIG_BOARD_ASROCK_939A785GMH is not set
CONFIG_BOARD_ASROCK_E350M1=y
# CONFIG_BOARD_ASROCK_IMB_A180 is not set
CONFIG_ID_SECTION_OFFSET=0x80
CONFIG_RAMTOP=0x400000
CONFIG_CBFS_SIZE=0x400000
CONFIG_CACHE_ROM_SIZE_OVERRIDE=0
CONFIG_UDELAY_LAPIC_FIXED_FSB=200
CONFIG_CPU_ADDR_BITS=36
CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8
# CONFIG_USBDEBUG is not set
CONFIG_MAINBOARD_VERSION="1.0"
# CONFIG_DRIVERS_PS2_KEYBOARD is not set
CONFIG_BOARD_ROMSIZE_KB_4096=y
# CONFIG_COREBOOT_ROMSIZE_KB_64 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_128 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_256 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_512 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set
CONFIG_COREBOOT_ROMSIZE_KB_4096=y
# CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set
# CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set
CONFIG_COREBOOT_ROMSIZE_KB=4096
CONFIG_ROM_SIZE=0x400000
# CONFIG_SYSTEM_TYPE_LAPTOP is not set

#
# Chipset
#

#
# SoC
#
# CONFIG_SOC_BROADCOM_CYGNUS is not set
CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT="southbridge/amd/cimx/sb800/bootblock.c"
CONFIG_EHCI_BAR=0xfef00000
CONFIG_HEAP_SIZE=0xc0000
# CONFIG_SOC_MARVELL_BG4CD is not set
# CONFIG_SOC_NVIDIA_TEGRA124 is not set
# CONFIG_SOC_NVIDIA_TEGRA132 is not set
# CONFIG_SOC_NVIDIA_TEGRA210 is not set
# CONFIG_SOC_QC_IPQ806X is not set
# CONFIG_SOC_ROCKCHIP_RK3288 is not set
# CONFIG_CPU_SAMSUNG_EXYNOS5250 is not set
# CONFIG_CPU_SAMSUNG_EXYNOS5420 is not set
# CONFIG_SOC_UCB_RISCV is not set

#
# CPU
#
# CONFIG_CPU_ALLWINNER_A10 is not set
CONFIG_CBB=0x0
CONFIG_CDB=0x18
CONFIG_XIP_ROM_SIZE=0x100000
CONFIG_NUM_IPI_STARTS=2
CONFIG_CPU_AMD_AGESA=y
CONFIG_S3_DATA_POS=0xFFFF0000
CONFIG_S3_DATA_SIZE=32768
CONFIG_CPU_AMD_AGESA_FAMILY14=y
# CONFIG_CPU_AMD_PI is not set
# CONFIG_CPU_ARMLTD_CORTEX_A9 is not set
# CONFIG_SSE2 is not set
# CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE is not set
# CONFIG_CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED is not set
# CONFIG_CPU_TI_AM335X is not set
# CONFIG_PARALLEL_CPU_INIT is not set
CONFIG_UDELAY_LAPIC=y
CONFIG_LAPIC_MONOTONIC_TIMER=y
# CONFIG_UDELAY_TSC is not set
# CONFIG_UDELAY_TIMER2 is not set
# CONFIG_TSC_CALIBRATE_WITH_IO is not set
CONFIG_TSC_SYNC_LFENCE=y
# CONFIG_TSC_SYNC_MFENCE is not set
CONFIG_LOGICAL_CPUS=y
# CONFIG_SMM_TSEG is not set
CONFIG_X86_AMD_FIXED_MTRRS=y
# CONFIG_PLATFORM_USES_FSP1_0 is not set
# CONFIG_PARALLEL_MP is not set
# CONFIG_BACKUP_DEFAULT_SMM_REGION is not set
# CONFIG_MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING is not set
CONFIG_CACHE_AS_RAM=y
CONFIG_SMP=y
CONFIG_AP_SIPI_VECTOR=0xfffff000
# CONFIG_SUPPORT_CPU_UCODE_IN_CBFS is not set
# CONFIG_CPU_MICROCODE_CBFS_GENERATE is not set
# CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set
CONFIG_CPU_MICROCODE_CBFS_NONE=y

#
# Northbridge
#
CONFIG_NORTHBRIDGE_AMD_AGESA=y
# CONFIG_CONSOLE_VGA_MULTI is not set
# CONFIG_S3_VGA_ROM_RUN is not set
CONFIG_MMCONF_BUS_NUMBER=64
CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY14=y
# CONFIG_AMD_NB_CIMX is not set
# CONFIG_NORTHBRIDGE_AMD_CIMX_RD890 is not set
CONFIG_VIDEO_MB=0
# CONFIG_NORTHBRIDGE_AMD_PI is not set
CONFIG_RAMBASE=0x100000
CONFIG_HPET_ADDRESS=0xfed00000
CONFIG_MAX_PIRQ_LINKS=4

#
# Southbridge
#
CONFIG_AHCI_ROM_ID="1002,4391"
CONFIG_AMD_SB_CIMX=y
CONFIG_SOUTHBRIDGE_AMD_CIMX_SB800=y
# CONFIG_ENABLE_IDE_COMBINED_MODE is not set
CONFIG_IDE_COMBINED_MODE=0x1
# CONFIG_SB800_SATA_IDE is not set
CONFIG_SB800_SATA_AHCI=y
# CONFIG_SB800_SATA_RAID is not set
CONFIG_SB800_SATA_MODE=0x2
CONFIG_SB_SUPERIO_HWM=y
# CONFIG_SB800_IMC_FWM is not set
CONFIG_SB800_NO_FAN_CONTROL=y
# CONFIG_SB800_MANUAL_FAN_CONTROL is not set
# CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900 is not set
# CONFIG_SOUTHBRIDGE_INTEL_COMMON is not set

#
# Super I/O
#
CONFIG_SUPERIO_NUVOTON_COMMON_ROMSTAGE=y
CONFIG_SUPERIO_NUVOTON_NCT5572D=y

#
# Embedded Controllers
#
# CONFIG_MAINBOARD_HAS_CHROMEOS is not set
# CONFIG_UEFI_2_4_BINDING is not set
# CONFIG_ARCH_ARM is not set
# CONFIG_ARCH_BOOTBLOCK_ARM is not set
# CONFIG_ARCH_VERSTAGE_ARM is not set
# CONFIG_ARCH_ROMSTAGE_ARM is not set
# CONFIG_ARCH_RAMSTAGE_ARM is not set
# CONFIG_ARCH_BOOTBLOCK_ARMV4 is not set
# CONFIG_ARCH_VERSTAGE_ARMV4 is not set
# CONFIG_ARCH_ROMSTAGE_ARMV4 is not set
# CONFIG_ARCH_RAMSTAGE_ARMV4 is not set
# CONFIG_ARCH_BOOTBLOCK_ARMV7 is not set
# CONFIG_ARCH_VERSTAGE_ARMV7 is not set
# CONFIG_ARCH_ROMSTAGE_ARMV7 is not set
# CONFIG_ARCH_RAMSTAGE_ARMV7 is not set
# CONFIG_ARCH_BOOTBLOCK_ARMV7_M is not set
# CONFIG_ARCH_VERSTAGE_ARMV7_M is not set
# CONFIG_ARM_BOOTBLOCK_CUSTOM is not set
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_ARM64 is not set
# CONFIG_ARCH_BOOTBLOCK_ARM64 is not set
# CONFIG_ARCH_VERSTAGE_ARM64 is not set
# CONFIG_ARCH_ROMSTAGE_ARM64 is not set
# CONFIG_ARCH_RAMSTAGE_ARM64 is not set
# CONFIG_ARCH_BOOTBLOCK_ARMV8_64 is not set
# CONFIG_ARCH_VERSTAGE_ARMV8_64 is not set
# CONFIG_ARCH_ROMSTAGE_ARMV8_64 is not set
# CONFIG_ARCH_RAMSTAGE_ARMV8_64 is not set
# CONFIG_ARM64_BOOTBLOCK_CUSTOM is not set
# CONFIG_ARM64_A53_ERRATUM_843419 is not set
# CONFIG_ARCH_MIPS is not set
# CONFIG_ARCH_BOOTBLOCK_MIPS is not set
# CONFIG_ARCH_VERSTAGE_MIPS is not set
# CONFIG_ARCH_ROMSTAGE_MIPS is not set
# CONFIG_ARCH_RAMSTAGE_MIPS is not set
# CONFIG_ARCH_RISCV is not set
# CONFIG_ARCH_BOOTBLOCK_RISCV is not set
# CONFIG_ARCH_VERSTAGE_RISCV is not set
# CONFIG_ARCH_ROMSTAGE_RISCV is not set
# CONFIG_ARCH_RAMSTAGE_RISCV is not set
# CONFIG_RISCV_BOOTBLOCK_CUSTOM is not set
CONFIG_ARCH_X86=y
CONFIG_ARCH_BOOTBLOCK_X86_32=y
CONFIG_ARCH_VERSTAGE_X86_32=y
CONFIG_ARCH_ROMSTAGE_X86_32=y
CONFIG_ARCH_RAMSTAGE_X86_32=y
# CONFIG_ARCH_BOOTBLOCK_X86_64 is not set
# CONFIG_ARCH_VERSTAGE_X86_64 is not set
# CONFIG_ARCH_ROMSTAGE_X86_64 is not set
# CONFIG_ARCH_RAMSTAGE_X86_64 is not set
# CONFIG_AP_IN_SIPI_WAIT is not set
# CONFIG_SIPI_VECTOR_IN_ROM is not set
# CONFIG_ROMCC is not set
CONFIG_LATE_CBMEM_INIT=y
CONFIG_PC80_SYSTEM=y
# CONFIG_HAVE_CMOS_DEFAULT is not set
CONFIG_IOAPIC_INTERRUPTS_ON_FSB=y
# CONFIG_IOAPIC_INTERRUPTS_ON_APIC_SERIAL_BUS is not set
# CONFIG_COMPILE_IN_DSDT is not set

#
# Devices
#
# CONFIG_MAINBOARD_HAS_NATIVE_VGA_INIT is not set
CONFIG_NATIVE_VGA_INIT_USE_EDID=y
# CONFIG_MAINBOARD_HAS_NATIVE_VGA_INIT_TEXTMODECFG is not set
# CONFIG_VGA_ROM_RUN is not set
CONFIG_ON_DEVICE_ROM_RUN=y
# CONFIG_MULTIPLE_VGA_ADAPTERS is not set
# CONFIG_SPD_CACHE is not set
CONFIG_PCI=y
# CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT is not set
CONFIG_PCIX_PLUGIN_SUPPORT=y
CONFIG_PCIEXP_PLUGIN_SUPPORT=y
CONFIG_CARDBUS_PLUGIN_SUPPORT=y
# CONFIG_AZALIA_PLUGIN_SUPPORT is not set
CONFIG_PCIEXP_COMMON_CLOCK=y
CONFIG_PCIEXP_ASPM=y
# CONFIG_PCIEXP_CLK_PM is not set
# CONFIG_EARLY_PCI_BRIDGE is not set
# CONFIG_PCIEXP_L1_SUB_STATE is not set
CONFIG_SUBSYSTEM_VENDOR_ID=0x0000
CONFIG_SUBSYSTEM_DEVICE_ID=0x0000
# CONFIG_PXE_ROM is not set
# CONFIG_SOFTWARE_I2C is not set

#
# Generic Drivers
#
# CONFIG_DRIVERS_AS3722_RTC is not set
# CONFIG_GIC is not set
# CONFIG_SMBIOS_PROVIDED_BY_MOBO is not set
# CONFIG_DRIVERS_I2C_RTD2132 is not set
# CONFIG_INTEL_DP is not set
# CONFIG_INTEL_DDI is not set
# CONFIG_INTEL_EDID is not set
# CONFIG_INTEL_INT15 is not set
# CONFIG_INTEL_GMA_ACPI is not set
# CONFIG_DRIVER_INTEL_I210 is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_DRIVERS_LENOVO_WACOM is not set
# CONFIG_DRIVER_MAXIM_MAX77686 is not set
# CONFIG_DRIVER_PARADE_PS8625 is not set
CONFIG_DRIVERS_MC146818=y
# CONFIG_MAINBOARD_HAS_LPC_TPM is not set
# CONFIG_DRIVERS_RICOH_RCE822 is not set
# CONFIG_DRIVERS_SIL_3114 is not set
# CONFIG_SPI_FLASH is not set
# CONFIG_DRIVER_TI_TPS65090 is not set
# CONFIG_DRIVERS_TI_TPS65913 is not set
# CONFIG_DRIVERS_TI_TPS65913_RTC is not set
# CONFIG_DRIVERS_UART is not set
CONFIG_DRIVERS_UART_8250IO=y
# CONFIG_NO_UART_ON_SUPERIO is not set
# CONFIG_DRIVERS_UART_8250MEM is not set
# CONFIG_HAVE_UART_SPECIAL is not set
# CONFIG_DRIVERS_UART_OXPCIE is not set
# CONFIG_DRIVERS_UART_PL011 is not set
CONFIG_HAVE_USBDEBUG=y
CONFIG_HAVE_USBDEBUG_OPTIONS=y
CONFIG_DEVICE_SPECIFIC_OPTIONS=y
# CONFIG_DRIVER_XPOWERS_AXP209 is not set
CONFIG_RTC=y
# CONFIG_TPM is not set
CONFIG_STACK_SIZE=0x1000
# CONFIG_MMCONF_SUPPORT_DEFAULT is not set
CONFIG_MMCONF_SUPPORT=y
# CONFIG_BOOTMODE_STRAPS is not set

#
# Console
#
CONFIG_SQUELCH_EARLY_SMP=y
# CONFIG_CONSOLE_SERIAL is not set
# CONFIG_SPKMODEM is not set
# CONFIG_CONSOLE_NE2K is not set
CONFIG_CONSOLE_CBMEM=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
# CONFIG_CONSOLE_CBMEM_DUMP_TO_UART is not set
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_7 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_5 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_4 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_3 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_2 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_1 is not set
# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_0 is not set
CONFIG_NO_POST=y
# CONFIG_HAVE_ACPI_RESUME is not set
CONFIG_HAVE_HARD_RESET=y
CONFIG_HAVE_MONOTONIC_TIMER=y
# CONFIG_GENERIC_UDELAY is not set
# CONFIG_TIMER_QUEUE is not set
CONFIG_HAVE_OPTION_TABLE=y
# CONFIG_PIRQ_ROUTE is not set
# CONFIG_HAVE_SMI_HANDLER is not set
CONFIG_PCI_IO_CFG_EXT=y
CONFIG_IOAPIC=y
# CONFIG_USE_WATCHDOG_ON_BOOT is not set
CONFIG_VGA=y
CONFIG_GFXUMA=y
CONFIG_HAVE_ACPI_TABLES=y
CONFIG_HAVE_MP_TABLE=y
CONFIG_HAVE_PIRQ_TABLE=y
# CONFIG_COMMON_FADT is not set

#
# System tables
#
CONFIG_GENERATE_MP_TABLE=y
CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_SMBIOS_TABLES=y
CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="E350M1"

#
# Payload
#
# CONFIG_PAYLOAD_NONE is not set
CONFIG_PAYLOAD_ELF=y
# CONFIG_PAYLOAD_FILO is not set
# CONFIG_PAYLOAD_GRUB2 is not set
# CONFIG_PAYLOAD_SEABIOS is not set
# CONFIG_PAYLOAD_LINUX is not set
# CONFIG_PAYLOAD_TIANOCORE is not set
CONFIG_PAYLOAD_FILE="seabios.elf"
CONFIG_COMPRESSED_PAYLOAD_LZMA=y

#
# Debugging
#
# CONFIG_GDB_STUB is not set
# CONFIG_FATAL_ASSERTS is not set
# CONFIG_DEBUG_CBFS is not set
# CONFIG_HAVE_DEBUG_RAM_SETUP is not set
# CONFIG_HAVE_DEBUG_CAR is not set
# CONFIG_DEBUG_PIRQ is not set
# CONFIG_HAVE_DEBUG_SMBUS is not set
# CONFIG_DEBUG_MALLOC is not set
# CONFIG_DEBUG_ACPI is not set
# CONFIG_TRACE is not set
# CONFIG_DEBUG_COVERAGE is not set
# CONFIG_ENABLE_APIC_EXT_ID is not set
CONFIG_WARNINGS_ARE_ERRORS=y
# CONFIG_POWER_BUTTON_DEFAULT_ENABLE is not set
# CONFIG_POWER_BUTTON_DEFAULT_DISABLE is not set
# CONFIG_POWER_BUTTON_FORCE_ENABLE is not set
# CONFIG_POWER_BUTTON_FORCE_DISABLE is not set
# CONFIG_POWER_BUTTON_IS_OPTIONAL is not set
# CONFIG_REG_SCRIPT is not set
CONFIG_MAX_REBOOT_CNT=3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150927/2b512fc6/attachment-0001.asc>

From thierry.laurion at gmail.com  Mon Sep 28 01:12:27 2015
From: thierry.laurion at gmail.com (Thierry Laurion)
Date: Sun, 27 Sep 2015 21:12:27 -0400
Subject: [coreboot] Fwd: coreboot ported to the ASUS KGPE-D16 (Libreboot:
 blobless, fully functional!)
In-Reply-To: <CAAzJznyOAaFtPNDrbUx0xe0=S23VUTs=k+r7rVchtVekQBGWiw@mail.gmail.com>
References: <CAAzJznyOAaFtPNDrbUx0xe0=S23VUTs=k+r7rVchtVekQBGWiw@mail.gmail.com>
Message-ID: <CAAzJznxjkuBwCtXhrS6ea_B7s1hfQm8Wgc69QSd2Moe5NeXkdQ@mail.gmail.com>

Hi tpearson and all,

Checked the kgpe-d16 board status webpage (
https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php)  and didn't
find any place where crowdfunding was happening. Where is it? Why isn't it
more public? Is it being crowdfunded?

I'm really interested in seeing a recent AMD board freed. I know a lot of
people that would chip in/that would like to help and didn't quite got why
there was no crowdfunding going on/why the code wasn't put upstream. I
understand that you currently use this board on your internal cluster (so
it is completely functional as a server), but didn't quite got why you
didn't ask money for different part of the project while doing it?

If it is because you already worked on it and don't want to lose edge, I
would love to know why putting it upstream would make you loose advantage?
When are you planning on upstreaming your work if crowdfunding does not
happen?

Thanks for all your participation on past liberated board :)

I'm still kinda new to libreboot/coreboot (troubleshooting/understanding
coreboot/libreboot for problems found in asus kfsn4-dre regarding sata_nv
and sis_fb) but understand the real need for newer boards to be freed to
accelerate development and inclusion of amd boards to the point where
researchers/developers will have alternative secure platforms to work
from/on.

Cheers,

-- 
Thierry Laurion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150927/90d71d5f/attachment.html>

From adurbin at google.com  Mon Sep 28 14:38:06 2015
From: adurbin at google.com (Aaron Durbin)
Date: Mon, 28 Sep 2015 09:38:06 -0500
Subject: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource
 temporarily unavailable` and code coverage enabled
In-Reply-To: <1443383663.2876.5.camel@users.sourceforge.net>
References: <1443383663.2876.5.camel@users.sourceforge.net>
Message-ID: <CAE2855u-d7RO080KNz7=3b5OfZ=HJpruho6RcMCUn6KEZC5Jrw@mail.gmail.com>

On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> Dear coreboot folks,
>
>
> building a coreboot image for the ASRock E350M1 with the attached
> config, having code coverage enabled, I am unable to run the utility
> `cbmem`.
>
> ```
> $ sudo util/cbmem/cbmem -V -l
> Looking for coreboot table at 0 1048576 bytes.
> Mapping 1MB of physical memory at 0x0 (requested 0x0).
> Found!
>   coreboot table entry 0x11
>     Found forwarding entry.
> Unmapping 1MB of virtual memory at 0xb74b6000.
> Looking for coreboot table at c7f9f000 1048576 bytes.
> Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
>   ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
> Failed to mmap /dev/mem: Resource temporarily unavailable
> ```
>
> Linux complains with the messages below.
>
> ```
> $ dmesg
> [?]
> [  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
> [  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
> [?]
> ```
>

You are going to need to open the /dev/mem file w/ O_SYNC flags
because the kernel is marking that range of memory as uncacheable.
More info can be found here:
https://www.kernel.org/doc/Documentation/x86/pat.txt

# cat /sys/kernel/debug/x86/pat_memtype_list

would be helpful along  with this:

$ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done

>
> Thanks,
>
> Paul
>
>
> [1] http://review.coreboot.org/11729
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From rminnich at gmail.com  Mon Sep 28 16:02:16 2015
From: rminnich at gmail.com (ron minnich)
Date: Mon, 28 Sep 2015 16:02:16 +0000
Subject: [coreboot] Good OCP nodes for development?
In-Reply-To: <56074F43.2000202@raptorengineeringinc.com>
References: <CAP6exYLqpMz1NEp658dauFW4cLjdOYB2bqA45NVz036ir60sqw@mail.gmail.com>
 <56074F43.2000202@raptorengineeringinc.com>
Message-ID: <CAP6exYKQaLKhoT-8vr4SHp6Fw6f408u+-uqQ-KLz+0OWrhMbvA@mail.gmail.com>

What Power board would you recommend for this test?

ron

On Sat, Sep 26, 2015 at 7:07 PM Timothy Pearson <
tpearson at raptorengineeringinc.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/26/2015 03:18 PM, ron minnich wrote:
> > I just joined the open compute project as an individual member. Anybody
> > have some idea on what type of their nodes and which vendor are good to
> > look at for coreboot?
> >
> > I realize OCP is not a coreboot user (I had that discussion with them
> > about 5 years ago and they went with conventional wisdom, sadly,
> > although I expect one of the CPU providers was unfriendly about
> > coreboot) but I'm curious as to what it would take to make it work.
> >
> > thanks
> >
> > ron
> >
>
> Anything x86 is going to be somewhat unfriendly due to the heavy push
> for Secure Boot and the ensuing TiVo-ization / general platform
> lockdown.  Intel uses the Management Engine for this purpose, while AMD
> uses the Platform Security Processor.
>
> We have been in talks with IBM regarding OpenPOWER and to be honest
> that's probably the direction to be looking at this point.  The entire
> chip is open with the exception of the Self Boot Engine, and IBM's
> engineers are very open to the idea of custom firmware development.
>
> Just my $0.02. :-)
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> http://www.raptorengineeringinc.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJWB09AAAoJEK+E3vEXDOFbdUEH/jzmlbD0+Uz60ZKJjGjF3L7X
> zWMVFNTTmdjtvjrWWy0LEl5GCp1+oqjp2jKbQ1i20Q3rTG12Ehm70eYX2dghwiRQ
> mXyzgdN3fE5QsX9ecDb7rkXsEqG28mKGiu4jbmQr/LtmXLVXiT9rC0djCi0oCvbS
> d13JDwhqyRz/zSTgXSL0ji1vimYA1S6BZVOy/JqARD2aBGJjWpB5OUIqeOW3PLrd
> AoI0FL8TYsa1RsBTSt0ioAnpodGTYI2Gx1rS9SJqCi7hyorVPoDo3E3/m0p3lz4X
> R85wEkQfeE89Qy9kqUBFXerCGKKEPMDV1r37xlvWw262piSxm7OqAgSlnNY7wac=
> =JNI2
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150928/5254bd81/attachment.html>

From tpearson at raptorengineeringinc.com  Mon Sep 28 16:10:01 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Mon, 28 Sep 2015 11:10:01 -0500 (CDT)
Subject: [coreboot] Good OCP nodes for development?
Message-ID: <989551180.2607.1443456601099.JavaMail.zimbra@raptorengineeringinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/28/2015 11:02 AM, ron minnich wrote:
> What Power board would you recommend for this test?
> 
> ron

Let me get back to you on this when we are a bit further along.  IBM has
a 2-socket board (similar to Tyan's Habernero, but with the IP owned by
the foundation and therefore with available documentation) that we are
currently exploring.  All of this technology is so new that much of it
is only entering production now or will do so shortly in the future.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWCWU0AAoJEK+E3vEXDOFbShcIAKaeku/mhfsLWtbjeCaKJNVI
ATCE2CVTgnJhwnVOVWSmsGSgGE5oPh5SjQe0Asp40Z5DUsndLRgi47w7MfguqQqp
r/8p3R/A9j2P8MelyCamSEar2vyUQuU0ddGQzZP6jJeK8uh5omvUFsjhZagB6FNA
hhF0QiAbB/7IU2RGHQeUaWJRPMZPblUb9SSUz0KG1uQOoduo3QjtC2Yt4OcLMA2H
CNwtjzEoaV4ZmhtoKtfVRWgRZoqhTQ27S0sEfsgeGnkK/EN5g2jbZ2ZIYpZtO9xw
MB5B6I7p6g56nHI5KFsf2ih8RS8mO3BawAH/fnYirMK6xzRMScf/ygmWoPeUn9I=
=xBEO
-----END PGP SIGNATURE-----


From caoducquan at gmail.com  Mon Sep 28 16:16:21 2015
From: caoducquan at gmail.com (Cao Duc Quan)
Date: Mon, 28 Sep 2015 23:16:21 +0700
Subject: [coreboot]  Output debug log to HSUART1
Message-ID: <CAJPUe9oD0sUNma_PcLc7DUtkxK8PqcBkHsY9NuTiZwymAWL5yw@mail.gmail.com>

Dear all,
I am working on custom board base on BYT-I E3825. The PCBA has two serial
debug port connected to HSUART1 and HSUART2.
I wonder if there is anyone enable the debug log to HSUART1 ?
My configuration for coreboot base on MinnowMax board which uses legacy
console so I do not get any output from coreboot (both romstage and
ramstage).
I think HSUART1 is connected to PCI bus so we should use uart8250mem.c ?
I have tried it but no luck. Any help or guideline is highly appreciated.


Thanks a lot,
-- 
Quan Cao
0976574864
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150928/f0e0df99/attachment.html>

From no-reply at raptorengineeringinc.com  Tue Sep 29 08:30:09 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Tue, 29 Sep 2015 03:30:09 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
Message-ID: <20150929083009.GA12549@cb-test-ctl>

The ASUS KFSN4-DRE fails verification as of commit 321402bfced59bd241711ed8ee4a6d8e46f9f081

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
321402b 3dparty/blobs: Advance to pull in binary microcode
46a7c82 Makefile: Replace the way to test if a string is empty

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering <tpearson at raptorengineeringinc.com> regarding any issues stemming from this notification
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1443515391-0-automaster.log.bz2
Type: application/octet-stream
Size: 26685 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150929/bec84d2a/attachment-0001.obj>

From paulepanter at users.sourceforge.net  Wed Sep 30 07:29:03 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Wed, 30 Sep 2015 09:29:03 +0200
Subject: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource
 temporarily unavailable`
In-Reply-To: <CAE2855u-d7RO080KNz7=3b5OfZ=HJpruho6RcMCUn6KEZC5Jrw@mail.gmail.com>
References: <1443383663.2876.5.camel@users.sourceforge.net>
 <CAE2855u-d7RO080KNz7=3b5OfZ=HJpruho6RcMCUn6KEZC5Jrw@mail.gmail.com>
Message-ID: <1443598143.2687.107.camel@users.sourceforge.net>

Dear Aaron,


thank you for the quick reply.


Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin:
> On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote:

> > building a coreboot image for the ASRock E350M1 with the attached
> > config, having code coverage enabled, I am unable to run the 
> > utility `cbmem`.
> > 
> > ```
> > $ sudo util/cbmem/cbmem -V -l
> > Looking for coreboot table at 0 1048576 bytes.
> > Mapping 1MB of physical memory at 0x0 (requested 0x0).
> > Found!
> >   coreboot table entry 0x11
> >     Found forwarding entry.
> > Unmapping 1MB of virtual memory at 0xb74b6000.
> > Looking for coreboot table at c7f9f000 1048576 bytes.
> > Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
> >   ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
> > Failed to mmap /dev/mem: Resource temporarily unavailable
> > ```
> > 
> > Linux complains with the messages below.
> > 
> > ```
> > $ dmesg
> > [?]
> > [  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
> > [  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
> > [?]
> > ```
> > 
> 
> You are going to need to open the /dev/mem file w/ O_SYNC flags
> because the kernel is marking that range of memory as uncacheable.
> More info can be found here:
> https://www.kernel.org/doc/Documentation/x86/pat.txt

I totally missed, that besides selecting code coverage, the Linux
kernel was updated to version 4.2 in between. Probably they changed
some default.

    $ uname -a
    Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux

> # cat /sys/kernel/debug/x86/pat_memtype_list
> 
> would be helpful

    $ sudo more /sys/kernel/debug/x86/pat_memtype_list 
    PAT memtype list:
uncached-minus @ 0xc7fa7000-0xc7fa8000
write-back @ 0xc7fb8000-0xc7fbb000
write-back @ 0xc7fba000-0xc7fbd000
write-combining @ 0xe0040000-0xe0274000
write-combining @ 0xe0274000-0xe0474000
write-combining @ 0xe0474000-0xe0475000
write-combining @ 0xe0478000-0xe0978000
uncached-minus @ 0xf0004000-0xf0005000
uncached-minus @ 0xf0100000-0xf0140000
uncached-minus @ 0xf0140000-0xf0144000
uncached-minus @ 0xf0144000-0xf0148000
uncached-minus @ 0xf0148000-0xf0149000
uncached-minus @ 0xf0149000-0xf014a000
uncached-minus @ 0xf014a000-0xf014b000
uncached-minus @ 0xf014b000-0xf014c000
uncached-minus @ 0xf014b000-0xf014c000
uncached-minus @ 0xf014b000-0xf014c000
uncached-minus @ 0xf014b000-0xf014c000
uncached-minus @ 0xf8088000-0xf8089000
uncached-minus @ 0xfed00000-0xfed01000
uncached-minus @ 0xfed80000-0xfed81000

> along with this:
> 
> $ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done

    $ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done
    System RAM 0x0 0x9fbff
    reserved 0x9fc00 0x9ffff
    reserved 0xf0000 0xfffff
    System RAM 0x100000 0xc7f9cfff
    reserved 0xc7f9d000 0xdfffffff
    reserved 0xf8000000 0xfbffffff
    System RAM 0x100000000 0x21effffff


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150930/49bba911/attachment.asc>

From adurbin at google.com  Wed Sep 30 13:50:26 2015
From: adurbin at google.com (Aaron Durbin)
Date: Wed, 30 Sep 2015 08:50:26 -0500
Subject: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource
 temporarily unavailable`
In-Reply-To: <1443598143.2687.107.camel@users.sourceforge.net>
References: <1443383663.2876.5.camel@users.sourceforge.net>
 <CAE2855u-d7RO080KNz7=3b5OfZ=HJpruho6RcMCUn6KEZC5Jrw@mail.gmail.com>
 <1443598143.2687.107.camel@users.sourceforge.net>
Message-ID: <CAE2855uj0kvEV3raUCFsizhppU6dsHhXB3K8tO7tfunb0YUTqg@mail.gmail.com>

On Wed, Sep 30, 2015 at 2:29 AM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> Dear Aaron,
>
>
> thank you for the quick reply.
>
>
> Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin:
>> On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote:
>
>> > building a coreboot image for the ASRock E350M1 with the attached
>> > config, having code coverage enabled, I am unable to run the
>> > utility `cbmem`.
>> >
>> > ```
>> > $ sudo util/cbmem/cbmem -V -l
>> > Looking for coreboot table at 0 1048576 bytes.
>> > Mapping 1MB of physical memory at 0x0 (requested 0x0).
>> > Found!
>> >   coreboot table entry 0x11
>> >     Found forwarding entry.
>> > Unmapping 1MB of virtual memory at 0xb74b6000.
>> > Looking for coreboot table at c7f9f000 1048576 bytes.
>> > Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
>> >   ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
>> > Failed to mmap /dev/mem: Resource temporarily unavailable
>> > ```
>> >
>> > Linux complains with the messages below.
>> >
>> > ```
>> > $ dmesg
>> > [?]
>> > [  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
>> > [  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
>> > [?]
>> > ```
>> >
>>
>> You are going to need to open the /dev/mem file w/ O_SYNC flags
>> because the kernel is marking that range of memory as uncacheable.
>> More info can be found here:
>> https://www.kernel.org/doc/Documentation/x86/pat.txt
>
> I totally missed, that besides selecting code coverage, the Linux
> kernel was updated to version 4.2 in between. Probably they changed
> some default.
>
>     $ uname -a
>     Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux
>
>> # cat /sys/kernel/debug/x86/pat_memtype_list
>>
>> would be helpful
>
>     $ sudo more /sys/kernel/debug/x86/pat_memtype_list
>     PAT memtype list:
> uncached-minus @ 0xc7fa7000-0xc7fa8000
> write-back @ 0xc7fb8000-0xc7fbb000
> write-back @ 0xc7fba000-0xc7fbd000

Interesting. The range you requested isn't listed in here. However,
the above 3 are which are smack in the middle of region you are
requesting. I suspect that's where things are falling over. Do you
know what these are? Are they listed in /proc/iomem ? The best
visibility we have currently is the e820 below which just has the
range starting at 0xc7f9d000 through 0xe0000000. There's some weird
fudging the kernel does around the usable memory boundaries so those
may not be we coreboot exported. Presumably you have coreboot logs
from a previous boot not on this kernel? That might provide some
insight as well.

I should also note I didn't go trolling through the kernel to figure
out its logic just yet. Just noting what you're finding.


> write-combining @ 0xe0040000-0xe0274000
> write-combining @ 0xe0274000-0xe0474000
> write-combining @ 0xe0474000-0xe0475000
> write-combining @ 0xe0478000-0xe0978000
> uncached-minus @ 0xf0004000-0xf0005000
> uncached-minus @ 0xf0100000-0xf0140000
> uncached-minus @ 0xf0140000-0xf0144000
> uncached-minus @ 0xf0144000-0xf0148000
> uncached-minus @ 0xf0148000-0xf0149000
> uncached-minus @ 0xf0149000-0xf014a000
> uncached-minus @ 0xf014a000-0xf014b000
> uncached-minus @ 0xf014b000-0xf014c000
> uncached-minus @ 0xf014b000-0xf014c000
> uncached-minus @ 0xf014b000-0xf014c000
> uncached-minus @ 0xf014b000-0xf014c000
> uncached-minus @ 0xf8088000-0xf8089000
> uncached-minus @ 0xfed00000-0xfed01000
> uncached-minus @ 0xfed80000-0xfed81000
>
>> along with this:
>>
>> $ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done
>
>     $ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done
>     System RAM 0x0 0x9fbff
>     reserved 0x9fc00 0x9ffff
>     reserved 0xf0000 0xfffff
>     System RAM 0x100000 0xc7f9cfff
>     reserved 0xc7f9d000 0xdfffffff
>     reserved 0xf8000000 0xfbffffff
>     System RAM 0x100000000 0x21effffff
>
>
> Thanks,
>
> Paul
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From kurtqqh at gmail.com  Tue Sep 15 15:01:13 2015
From: kurtqqh at gmail.com (Kurt Qiao)
Date: Tue, 15 Sep 2015 13:01:13 -0000
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <20150914180756.GA32636@coreboot.org>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
 <20150914180756.GA32636@coreboot.org>
Message-ID: <CAALi9ZNqRmFFRe2LjaG_0ybm6P+_76_BUvWAmacNMdUY8qK8kw@mail.gmail.com>

do a quick update here, thanks for Stefan, the solution seems part of
work for me

1. i changed to cygwin(32bit) due to cygwin64 always got fail, but i
got same fail with cygwin, so below update i based on cygwin.

2. default build will error as below,
HOSTCC     cbfstool/cbfstool.o
/cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function 'main':
/cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: array
subscript has type 'char' [-Werror=char-subscripts]
     if (tolower(suffix[0])=='k') {
     ^
/cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1078:5: error: array
subscript has type 'char' [-Werror=char-subscripts]
     if (tolower(suffix[0])=='m') {
     ^

so i change my cbfstool.c code to :
--  if (tolower(suffix[0])=='k') {
++ if ((int)tolower(suffix[0])=='k') {

--  if (tolower(suffix[0])=='m') {
++ if ((int)tolower(suffix[0])=='m') {


3. patch 11636 works, so build pass util/cbfstool/common.c
but patch 11637 will fail with function '_fileno'
    HOSTCC     cbfstool/fmaptool.o
    HOSTCC     cbfstool/cbfs_sections.o
    HOSTCC     cbfstool/fmap_from_fmd.o
    HOSTCC     cbfstool/fmd.o
    HOSTCC     cbfstool/fmd_parser.o
    HOSTCC     cbfstool/fmd_scanner.o
<stdout>: In function 'yy_init_buffer':
<stdout>:1399:9: error: implicit declaration of function '_fileno'
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
util/cbfstool/Makefile.inc:59: recipe for target
'build/util/cbfstool/fmd_scanner.o' failed
make: *** [build/util/cbfstool/fmd_scanner.o] Error 1


2015-09-15 2:07 GMT+08:00 Stefan Reinauer <stefan.reinauer at coreboot.org>:
> * Kurt Qiao <kurtqqh at gmail.com> [150909 09:42]:
>> does anyone try cygwin64 to build coreboot in windows7 64bit?
>> i got fail when build cbfstool with cygwin64.
>
> Can you try the following two patches to see if they solve your problem
>
> http://review.coreboot.org/11636 Don't use fileno() to get file size
> http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW
>
> Also, if that doesn't work try to replace the MINGW check with something
> like #if defined (_WIN64) || defined (__CYGWIN64__) instead.
>
> (Make sure to run make clean in the cbfstool directory before trying)
>
> Stefan


From kurtqqh at gmail.com  Thu Sep 17 11:34:17 2015
From: kurtqqh at gmail.com (Kurt Qiao)
Date: Thu, 17 Sep 2015 09:34:17 -0000
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAALi9ZMAoffYtgSEzE6teEd33+HxdSjf5mLnwCNzSETmw+fWKw@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
 <20150914180756.GA32636@coreboot.org>
 <CAALi9ZNqRmFFRe2LjaG_0ybm6P+_76_BUvWAmacNMdUY8qK8kw@mail.gmail.com>
 <CAALi9ZMAoffYtgSEzE6teEd33+HxdSjf5mLnwCNzSETmw+fWKw@mail.gmail.com>
Message-ID: <CAALi9ZPjRwWmNUSetKUcmNaRqhb+urcBL-a3yK7AcEdCANKHFw@mail.gmail.com>

hi
i finally built pass with define
CFLAGS += -std=gnu99  in cbfstool/Makefile
TOOLCFLAGS ?= -std=gnu99  in cbfstool/Makefile.inc

change cbfstool.c code to :
--  if (tolower(suffix[0])=='k') {
++ if (tolower((int)suffix[0])=='k') {

--  if (tolower(suffix[0])=='m') {
++ if (tolower((int)suffix[0])=='m') {

is there anyway to dynamic define std to gnu99 when detect build with cygwin?


2015-09-15 21:05 GMT+08:00 Kurt Qiao <kurtqqh at gmail.com>:
> sorry for typo, fix step 1 code:
>
> so i change my cbfstool.c code to :
> --  if (tolower(suffix[0])=='k') {
> ++ if (tolower((int)suffix[0])=='k') {
>
> --  if (tolower(suffix[0])=='m') {
> ++ if (tolower((int)suffix[0])=='m') {
>
> 2015-09-15 21:01 GMT+08:00 Kurt Qiao <kurtqqh at gmail.com>:
>> do a quick update here, thanks for Stefan, the solution seems part of
>> work for me
>>
>> 1. i changed to cygwin(32bit) due to cygwin64 always got fail, but i
>> got same fail with cygwin, so below update i based on cygwin.
>>
>> 2. default build will error as below,
>> HOSTCC     cbfstool/cbfstool.o
>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function 'main':
>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: array
>> subscript has type 'char' [-Werror=char-subscripts]
>>      if (tolower(suffix[0])=='k') {
>>      ^
>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1078:5: error: array
>> subscript has type 'char' [-Werror=char-subscripts]
>>      if (tolower(suffix[0])=='m') {
>>      ^
>>
>> so i change my cbfstool.c code to :
>> --  if (tolower(suffix[0])=='k') {
>> ++ if ((int)tolower(suffix[0])=='k') {
>>
>> --  if (tolower(suffix[0])=='m') {
>> ++ if ((int)tolower(suffix[0])=='m') {
>>
>>
>> 3. patch 11636 works, so build pass util/cbfstool/common.c
>> but patch 11637 will fail with function '_fileno'
>>     HOSTCC     cbfstool/fmaptool.o
>>     HOSTCC     cbfstool/cbfs_sections.o
>>     HOSTCC     cbfstool/fmap_from_fmd.o
>>     HOSTCC     cbfstool/fmd.o
>>     HOSTCC     cbfstool/fmd_parser.o
>>     HOSTCC     cbfstool/fmd_scanner.o
>> <stdout>: In function 'yy_init_buffer':
>> <stdout>:1399:9: error: implicit declaration of function '_fileno'
>> [-Werror=implicit-function-declaration]
>> cc1: all warnings being treated as errors
>> util/cbfstool/Makefile.inc:59: recipe for target
>> 'build/util/cbfstool/fmd_scanner.o' failed
>> make: *** [build/util/cbfstool/fmd_scanner.o] Error 1
>>
>>
>> 2015-09-15 2:07 GMT+08:00 Stefan Reinauer <stefan.reinauer at coreboot.org>:
>>> * Kurt Qiao <kurtqqh at gmail.com> [150909 09:42]:
>>>> does anyone try cygwin64 to build coreboot in windows7 64bit?
>>>> i got fail when build cbfstool with cygwin64.
>>>
>>> Can you try the following two patches to see if they solve your problem
>>>
>>> http://review.coreboot.org/11636 Don't use fileno() to get file size
>>> http://review.coreboot.org/11637 fmd: Use _fileno() on MINGW
>>>
>>> Also, if that doesn't work try to replace the MINGW check with something
>>> like #if defined (_WIN64) || defined (__CYGWIN64__) instead.
>>>
>>> (Make sure to run make clean in the cbfstool directory before trying)
>>>
>>> Stefan


From thierry.laurion at gmail.com  Fri Sep 25 17:27:04 2015
From: thierry.laurion at gmail.com (Thierry Laurion)
Date: Fri, 25 Sep 2015 15:27:04 -0000
Subject: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot:
 blobless, fully functional!)
Message-ID: <CAAzJznyOAaFtPNDrbUx0xe0=S23VUTs=k+r7rVchtVekQBGWiw@mail.gmail.com>

Hi tpearson,

Checked the board status webpage (
https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php)  and didn't
find any place where crowdfunding was happening. Where is it? Why isn't it
more public?

I'm really interested in seeing a recent freed AMD board. I know a lot of
people that would chip in/would like to help and didn't quite got why there
was no crowdfunding going on/why the code wasn't put upstream. I understand
that you currently use this board on your internal cluster (so it is
completely functional as a server), but didn't quite got why you didn't ask
money for different part of the project following the difficulties still
encountered and the time you think it would take for you to fix it
(suspend/resume, etc) if you want to keep it closed until funded.

If it is because you already worked on it and don't want to lose edge, I
would love to read why putting it upstream would make you loose advantage?
When are you planning on upstreaming your work if crowdfunding does not
happen?

Thanks for all your participation on past liberated board :)
I'm new to libreboot/coreboot but understand the real need for such project
to accelerate to the point where researchers only use such board and secure
platforms.

Cheers,
-- 
Thierry Laurion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150925/b6cb3792/attachment.html>