[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

[Martin Kepplinger]

On 06.06.19 08:20, Paul Menzel wrote:
> Dear Martin,
> 
> 
> First, please try to use interleaved style for quoting.
> 
> 
> On 05.06.19 13:47, Martin Kepplinger wrote:
> 
> 
>> Am 05.06.2019 07:58 schrieb Martin Kepplinger:
>>> I can test later but I think I can see what happens. It fixes the issue,
>>> but still prints "ERROR: Keyboard set scancode failed!".
>>>
>>> If we know that it's no error on at least one platform, we shouldn't
>>> print "ERROR" IMO, but as long as the bug gets fixes, I guess I'm fine.
> 
> It’s how it was done before, and I think it is useful to have error
> messages especially in case it aborts. Just to be sure, is the message
> 
>     ERROR: Keyboard set scancode failed!
> 
> also new for you, or did you see it in the past before the change
> resetting the keyboard, but the keyboard kept working. (Maybe with no
> reset it was still working because of the initialization by SeaBIOS or
> GRUB.)

it's new. Before the change that adds the reset, all was fine and no
errors printed.

> 
>> Paul, what do you think about removing the return
>> and error message from the RESET cmd? Other thoughts?
> 
> Your error is not about the failing reset command anymore.
> 
> You should be ablet to work around it by selecting
> LP_PC_KEYBOARD_IGNORE_INIT_FAILURE in the libpayload configuration.


how do I select that?

> 
> Maybe that should be selected by default or we should indeed remove all
> the returns from the error paths in the hope the keyboard will be
> functional despite the non-working commands before.
> 
We must add a fix. If you can select said config by default for
libpayload users, that's fine. Otherwise, remove the return I guess...

thanks,
martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

[Martin Kepplinger]

Paul, what do you think about removing the return
and error message from the RESET cmd? Other thoughts?

thanks
martin


Am 05.06.2019 07:58 schrieb Martin Kepplinger:
I can test later but I think I can see what happens. It fixes the 
issue,

but still prints "ERROR: Keyboard set scancode failed!".

If we know that it's no error on at least one platform, we shouldn't
print "ERROR" IMO, but as long as the bug gets fixes, I guess I'm fine.

thanks
martin


On 05.06.19 07:53, Mike Banon wrote:

Martin, could you please check what happens if you apply this patch
but then remove a return that follows ""ERROR: Keyboard set scancode
failed!" ? Perhaps we'll have to do the same for all these returns :
"Still print this message but don't abort prematurely"

Signed-off-by: Mike Banon 
---
diff --git a/payloads/libpayload/drivers/i8042/keyboard.c
b/payloads/libpayload/drivers/i8042/keyboard.c
index 240385ce6d..c81392ab72 100644
--- a/payloads/libpayload/drivers/i8042/keyboard.c
+++ b/payloads/libpayload/drivers/i8042/keyboard.c
@@ -328,7 +328,6 @@ void keyboard_init(void)
 ret = keyboard_cmd(I8042_KBCMD_SET_SCANCODE);
 if (!ret && !CONFIG(LP_PC_KEYBOARD_IGNORE_INIT_FAILURE)) {
 printf("ERROR: Keyboard set scancode failed!\n");
-return;
 }

 ret = keyboard_cmd(I8042_SCANCODE_SET_1);

On Wed, Jun 5, 2019 at 8:34 AM Martin Kepplinger  
wrote:


Am 04.06.2019 13:59 schrieb Paul Menzel:

Dear coreboot folks,


On 06/04/19 12:15, Paul Menzel wrote:


On 06/04/19 12:01, Paul Menzel wrote:


On 06/04/19 07:10, Martin Kepplinger wrote:


what's wrong? I think commit
7ae606f57f0b3d450ae748141b0e2367041b27d3
Paul?


Did you test if everything works, if you revert the commit?

Did the PS/2 keyboard work before when loading libpayload
based payloads from SeaBIOS or GRUB (chainloader)?


I’ll submit a fix to check true/false.


Furquan created a fix [1] and it was accepted and is now in the
master branch.

Please verify, if it works for you now.


Kind regards,

Paul


[1]: https://review.coreboot.org/c/coreboot/+/33185


Testing that on the X230, I get:

"ERROR: Keyboard set scancode failed!" and keyboard does not work at
all, in said payloads.

Also, reverting https://review.coreboot.org/c/coreboot/+/32951/ (
7ae606f57f0b3d450ae748141b0e2367041b27d3 )
fixes the problem.

Please fix this. I also think we can not return early when "RESET"
fails. Why not just (try to) reset silently, if possible?

thanks,

  martin


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

[Martin Kepplinger]

I can test later but I think I can see what happens. It fixes the issue,
but still prints "ERROR: Keyboard set scancode failed!".

If we know that it's no error on at least one platform, we shouldn't
print "ERROR" IMO, but as long as the bug gets fixes, I guess I'm fine.

thanks
martin


On 05.06.19 07:53, Mike Banon wrote:
> Martin, could you please check what happens if you apply this patch
> but then remove a return that follows ""ERROR: Keyboard set scancode
> failed!" ? Perhaps we'll have to do the same for all these returns :
> "Still print this message but don't abort prematurely"
> 
> Signed-off-by: Mike Banon 
> ---
> diff --git a/payloads/libpayload/drivers/i8042/keyboard.c
> b/payloads/libpayload/drivers/i8042/keyboard.c
> index 240385ce6d..c81392ab72 100644
> --- a/payloads/libpayload/drivers/i8042/keyboard.c
> +++ b/payloads/libpayload/drivers/i8042/keyboard.c
> @@ -328,7 +328,6 @@ void keyboard_init(void)
>  ret = keyboard_cmd(I8042_KBCMD_SET_SCANCODE);
>  if (!ret && !CONFIG(LP_PC_KEYBOARD_IGNORE_INIT_FAILURE)) {
>  printf("ERROR: Keyboard set scancode failed!\n");
> -    return;
>  }
> 
>  ret = keyboard_cmd(I8042_SCANCODE_SET_1);
> 
> On Wed, Jun 5, 2019 at 8:34 AM Martin Kepplinger  wrote:
>>
>> Am 04.06.2019 13:59 schrieb Paul Menzel:
>>> Dear coreboot folks,
>>>
>>>
>>> On 06/04/19 12:15, Paul Menzel wrote:
>>>
>>>> On 06/04/19 12:01, Paul Menzel wrote:
>>>>
>>>>> On 06/04/19 07:10, Martin Kepplinger wrote:
>>>>>
>>>>>> what's wrong? I think commit
>>>>>> 7ae606f57f0b3d450ae748141b0e2367041b27d3
>>>>>> Paul?
>>>>>
>>>>> Did you test if everything works, if you revert the commit?
>>>>>
>>>>> Did the PS/2 keyboard work before when loading libpayload
>>>>> based payloads from SeaBIOS or GRUB (chainloader)?
>>>>
>>>> I’ll submit a fix to check true/false.
>>>
>>> Furquan created a fix [1] and it was accepted and is now in the
>>> master branch.
>>>
>>> Please verify, if it works for you now.
>>>
>>>
>>> Kind regards,
>>>
>>> Paul
>>>
>>>
>>> [1]: https://review.coreboot.org/c/coreboot/+/33185
>>
>> Testing that on the X230, I get:
>>
>> "ERROR: Keyboard set scancode failed!" and keyboard does not work at
>> all, in said payloads.
>>
>> Also, reverting https://review.coreboot.org/c/coreboot/+/32951/ (
>> 7ae606f57f0b3d450ae748141b0e2367041b27d3 )
>> fixes the problem.
>>
>> Please fix this. I also think we can not return early when "RESET"
>> fails. Why not just (try to) reset silently, if possible?
>>
>> thanks,
>>
>>   martin
>>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

[Martin Kepplinger]

Am 04.06.2019 13:59 schrieb Paul Menzel:

Dear coreboot folks,


On 06/04/19 12:15, Paul Menzel wrote:


On 06/04/19 12:01, Paul Menzel wrote:


On 06/04/19 07:10, Martin Kepplinger wrote:

what's wrong? I think commit 
7ae606f57f0b3d450ae748141b0e2367041b27d3

Paul?


Did you test if everything works, if you revert the commit?

Did the PS/2 keyboard work before when loading libpayload
based payloads from SeaBIOS or GRUB (chainloader)?


I’ll submit a fix to check true/false.


Furquan created a fix [1] and it was accepted and is now in the
master branch.

Please verify, if it works for you now.


Kind regards,

Paul


[1]: https://review.coreboot.org/c/coreboot/+/33185


Testing that on the X230, I get:

"ERROR: Keyboard set scancode failed!" and keyboard does not work at 
all, in said payloads.


Also, reverting https://review.coreboot.org/c/coreboot/+/32951/ ( 
7ae606f57f0b3d450ae748141b0e2367041b27d3 )

fixes the problem.

Please fix this. I also think we can not return early when "RESET" 
fails. Why not just (try to) reset silently, if possible?


thanks,

 martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] libpayload/i8042/keyboard: ERROR Keyboard reset failed when selecting Secondary Payload in SeaBIOS

[Martin Kepplinger]

Hi,

Just tested a build using this config: 
https://github.com/merge/skulls/blob/master/x230/nonfree-defconfig-139b3cef03
with a recent coreboot (my master branch HEAD is at 0da3a8a91b 
soc/intel/baytrail: set default VBIOS filename and PCI ID)


When selecting "3" or "4" for the secondary payloads like coreinfo in 
Seabios, I always hit this:
payloads/libpayload/drivers/i8042/keyboard.c:		printf("ERROR: Keyboard 
reset failed ACK: 0x%x\n", ret);


I get "ERROR: Keyboard reset failed ACK: 0x1".

and I basically have to shutdown.

what's wrong? I think commit 7ae606f57f0b3d450ae748141b0e2367041b27d3 
Paul?


thanks,
   martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ramstage/x86emu doesn't build

[Martin Kepplinger]

On 25.04.19 12:23, Patrick Georgi via coreboot wrote:
> There was some recent cleanup on console.h includes that makes printk
> only visible where we thought it was needed.
> A change to add an include for console/console.h to resolve the issue
> here. Cc'ing Elyes since that's his effort.
> 
> As you correctly noticed, x86emu isn't build-tested by default: If you
> want, you could contribute a patch to add your config to configs/, which
> makes it build tested by default to avoid future regressions in the
> x86emu code.

The initial failure is fixed, thanks. Adding a config that uses x86emu
isn't trivial in this case since x86emu is used to run a nonfree vbios
option rom that isn't part of our blobs repo...

thanks

martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] ramstage/x86emu doesn't build

[Martin Kepplinger]

Hi,

Before I dig in without knowing the code: x86emu currently ( 
0987e43aa05bfbafbfdd4952638b79a5084369f8 )

doesn't build:

In file included from src/device/oprom/x86emu/x86emui.h:65,
 from src/device/oprom/x86emu/debug.c:40:
src/device/oprom/x86emu/debug.c: In function 'x86emu_dump_regs':
src/device/oprom/x86emu/debug.h:46:22: error: implicit declaration of 
function 'printk'; did you mean 'printf'? 
[-Werror=implicit-function-declaration]

 #define printf(x...) printk(BIOS_DEBUG, x)
  ^~
src/device/oprom/x86emu/debug.c:366:5: note: in expansion of macro 
'printf'

 printf("\tAX=%04x  ", M.x86.R_AX );
 ^~


I append the config. Also, there's noone in MAINTAINER for it, and 
appearently it's not build-tested :(


thanks

 martin
#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_COREBOOT_BUILD=y
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
# CONFIG_ANY_TOOLCHAIN is not set
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_UTIL_GENPARSER is not set
CONFIG_USE_OPTION_TABLE=y
# CONFIG_STATIC_OPTION_TABLE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
CONFIG_COLLECT_TIMESTAMPS=y
# CONFIG_TIMESTAMPS_ON_CONSOLE is not set
CONFIG_USE_BLOBS=y
# CONFIG_COVERAGE is not set
# CONFIG_UBSAN is not set
# CONFIG_NO_RELOCATABLE_RAMSTAGE is not set
CONFIG_RELOCATABLE_RAMSTAGE=y
CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM=y
# CONFIG_UPDATE_IMAGE is not set
CONFIG_BOOTSPLASH_IMAGE=y
CONFIG_BOOTSPLASH_FILE="bootsplash.jpg"

#
# Mainboard
#

#
# Important: Run 'make distclean' before switching boards
#
# CONFIG_VENDOR_ADI 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_ASROCK is not set
# CONFIG_VENDOR_ASUS is not set
# CONFIG_VENDOR_AVALUE is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_CAVIUM is not set
# CONFIG_VENDOR_COMPULAB is not set
# CONFIG_VENDOR_CUBIETECH is not set
# CONFIG_VENDOR_ELMEX is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_ESD is not set
# CONFIG_VENDOR_FACEBOOK is not set
# CONFIG_VENDOR_FOXCONN 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_IEI is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
CONFIG_VENDOR_LENOVO=y
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_OCP is not set
# CONFIG_VENDOR_OPENCELLULAR is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_PURISM is not set
# CONFIG_VENDOR_RODA is not set
# CONFIG_VENDOR_SAMSUNG is not set
# CONFIG_VENDOR_SAPPHIRE is not set
# CONFIG_VENDOR_SCALEWAY is not set
# CONFIG_VENDOR_SIEMENS is not set
# CONFIG_VENDOR_SIFIVE is not set
# CONFIG_VENDOR_SUPERMICRO is not set
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_TYAN is not set
# CONFIG_VENDOR_VIA is not set
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_DIR="lenovo/x230"
CONFIG_MAINBOARD_PART_NUMBER="ThinkPad X230"
CONFIG_MAX_CPUS=8
CONFIG_CBFS_SIZE=0x40
CONFIG_PAYLOAD_CONFIGFILE=""
CONFIG_MAINBOARD_VENDOR="LENOVO"
CONFIG_VGA_BIOS_ID="8086,0166"
# CONFIG_ONBOARD_VGA_IS_PRIMARY is not set
CONFIG_DIMM_SPD_SIZE=256
CONFIG_VGA_BIOS=y
CONFIG_MAINBOARD_SERIAL_NUMBER="123456789"
CONFIG_VGA_BIOS_FILE="pci8086,0166.rom"
CONFIG_C_ENV_BOOTBLOCK_SIZE=0x1
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="LENOVO"
CONFIG_DRAM_RESET_GATE_GPIO=10
CONFIG_DEVICETREE="devicetree.cb"
CONFIG_INTEL_GMA_VBT_FILE="src/mainboard/$(MAINBOARDDIR)/data.vbt"
CONFIG_PRERAM_CBMEM_CONSOLE_SIZE=0xc00
CONFIG_DCACHE_RAM_BASE=0xfefe
CONFIG_DCACHE_RAM_SIZE=0x2
CONFIG_MAX_REBOOT_CNT=3
CONFIG_USBDEBUG_HCD_INDEX=2
CONFIG_OVERRIDE_DEVICETREE=""
CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
CONFIG_FMDFILE=""
CONFIG_MMCONF_BASE_ADDRESS=0xf000
CONFIG_HAVE_INTEL_FIRMWARE=y
# CONFIG_DRIVERS_UART_8250IO is not set
# CONFIG_VBOOT is not set
CONFIG_TPM_PIRQ=0x0
CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="ThinkPad X230"
# CONFIG_HAVE_IFD_BIN is not set
# CONFIG_BOARD_LENOVO_G505S is not set
# CONFIG_BOARD_LENOVO_L520 is not set
# CONFIG_BOARD_LENOVO_S230U is not set
# CONFIG_BOARD_LENOVO_T400 is not set
# CONFIG_BOARD_LENOVO_T500 is not set
# CONFIG_BOARD_LENOVO_R400 is not set
# CONFIG_BOARD_LENOVO_W500 is not set
# CONFIG_BOARD_LENOVO_T420 is not set
# CONFIG_BOARD_LENOVO_T420S is not set
# CONFIG_BOARD_LENOVO_THINKPAD_T430 is not set
# CONFIG_BOARD_LENOVO_T430S is not set
# CONFIG_BOARD_LENOVO_T431S is not set
# CONFIG_BOARD_LENOVO_T520 is not set
# CONFIG_BOARD_LENOVO_W520 is 

[coreboot] Re: MEC1619 gpio access question (X230)

[Martin Kepplinger]

Am 14.03.2019 11:46 schrieb Nico Huber:

Hi Martin,

Am 14.03.19 um 10:19 schrieb Martin Kepplinger:

So, I'm looking into h8 EC access.

Where does ec_set_bit(0x3a, 0) for audio-mute or ec_set_bit(0x3a, 6) 
for wwan-enable

come from (let's keep that as an example)?


this uses a software interface that is defined by the program that runs
on the EC, aka the EC firmware. The EC firmware exposes an address 
space

(usually up to 256B) for communication with the host firmware (e.g.
coreboot). Usually, there is *no* relation to hardware registers.



Ok. Patrick, do you have any more details on the interface here, and 
what is

or isn't implemented in coreboot?

thanks

martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] MEC1619 gpio access question (X230)

[Martin Kepplinger]

Hi,

So, I'm looking into h8 EC access.

Where does ec_set_bit(0x3a, 0) for audio-mute or ec_set_bit(0x3a, 6) for 
wwan-enable

come from (let's keep that as an example)?

On the X230, for example wwan-disable should be on GPIO23 (GPIO023 i 
guess).
In the mec1618 (ok different, but hopefully similar enough) datasheet I 
can't really

find the connection to coreboot's implementation here -.-

So there's the AHB Base Address 0xC400h right? Then for example there's 
the
4 bytes "GPIO[000:036] Input Register" at base+0x300. According to this 
"bit indexing example"

table, GPIO023 would be Bit 19 of those 4 bytes...

If so (?), how does that relate to ec_set_bit(0x3a, 6)? It all still 
totally unclear to me, but

I might get it all wrong :)

thanks a lot,

 martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[Martin Kepplinger]

On 24.01.19 01:05, Carl-Daniel Hailfinger wrote:
> Hey everyone,
> 
> just 9 days until FOSDEM in Brussels (2+3 February)!
> There are a couple of talks about coreboot and LinuxBoot and we have a
> coreboot/LinuxBoot/flashrom stand (building AW). Plus, there is a
> hardware enablement devroom.
> 
> - Who's coming?
> - Are you volunteering for a shift at the stand?
> - What demo hardware can you bring? (We have only 1 table, so smaller
> hardware is preferred.)
> - What merchandise/giveaways can you bring?
> - Do we have 1-page flyers about each of coreboot, LinuxBoot and
> flashrom? (PDF is sufficient, I can print in black+white if needed.)
> - Do we have a large coreboot/LinuxBoot/flashrom banner which helps
> others find our stand?
> 

hi,

how're you doing with organisation?

I'm doing a 10min lightning talk about my little x230 coreboot project
tomorrow and obviously have that with me.

There are talks I'll definitely attend, but in case you urgently need
somebody at the stand for a short shift, please just ask.

I only have my X230 and some flashing hardware with me.

thanks

  martin


> Please forward this email to those who you think are coming and might be
> willing to help out. Thank you.
> 
> Regards,
> Carl-Daniel
> 
> 
> On 30.11.2018 09:59, Carl-Daniel Hailfinger wrote:
>> Hi,
>>
>> * FOSDEM 2-3 February 2019
>> * We have a coreboot/LinuxBoot/flashrom stand! Need people for the stand
>> (2 days, 1 table).
>> * We're invited to the Hardware Enablement Devroom! CFP deadline Dec 1
>> 2018: https://lists.fosdem.org/pipermail/fosdem/2018q4/002797.html
>>
>> On 03.11.2018 14:20, Paul Kocialkowski wrote:
>>> Le vendredi 02 novembre 2018 à 22:59 +0100, Carl-Daniel Hailfinger a
>>> écrit :
 In that case, I'd also like to point you to the deadline for submitting
 main track talks which is tomorrow(!).
 https://fosdem.org/2019/news/2018-08-10-call-for-participation/
 Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
 could you submit something or do you have someone in mind who can do that?

 There's also lightning talks, deadline is a bit later.
>>> I just submitted the CFP for the hardware enablement devroom at FOSDEM.
>>> Submissions related to coreboot and associated projects can definitely
>>> be in the scope of the devroom, so feel free to submit talks!
>>>
>>> Our submission deadline is December 1st, so there is still some time
>>> ahead.
>> Great, thank you!
>>
>> Regards,
>> Carl-Daniel
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
> 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] SPI controller and Lock bits

[Martin Kepplinger]

Am 01.10.2018 23:38 schrieb Youness Alaoui:

On Sat, Sep 29, 2018 at 12:21 PM Nico Huber  wrote:


On 9/27/18 10:29 PM, Youness Alaoui wrote:
> Thanks everyone for the responses.
> So far my understanding on the task at hand is :
> - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
> if we lock it on the resume path?)

Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
then only one config, IMO: On the resume path FLOCKDN should always be
set.

> - Remove the chipset_lockdown devicetree config and change the code to
> always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
> right?)

Yes, unless somebody objects. Please make sure to add the right
reviewers to this patch. I expect some resistance.


Ok, this is already done, but I want to finish/test my work before I
send for review and I might not have time until the end of the week.


> - remove the call to fast_spi_pr_dlock() and fix the comment above
> that function to be more accurate

Please also check the tree for code that sets PRRs. IIRC, it is used
somewhere to protect the MRC cache. I would set the discrete lock
directly after writing the region.


Ok, thanks, will do.
Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8
arguments to allow the caller to lock each prr individually instead of
being an all or nothing.


> - Add .config CONFIG options or maybe optional devicetree configs for
> how to setup the registers so coreboot can prepare them (due to the
> resume path) ?

Hmm, I would add Kconfig options for this as well. I you want to match
the configuration of your payload, it definitely doesn't belong into 
the
devicetree. Note that "prepare" also implies to lock them on the 
resume

path.


Yeah, so far, the KConfigs I added are :
FAST_SPI_LOCK_REGISTERS
FAST_SPI_LOCK_REGISTERS_ON_RESUME
FAST_SPI_LOCK_PRR34_REGISTERS
FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME
FAST_SPI_PRR3_REGISTER (hex value)
FAST_SPI_PRR4_REGISTER (hex value)

This way, a user can lock/unlock the register (since it affects more
than just the PRRs) and they can override/set the PRR3 and PRR4 values
and decide whether to lock them or not or only on resume, etc.. I
think those should be enough for most use cases and it's enough for
what I need.


>> AIUI, FLOCKDN always locks the PRRs.
> Actually from what I can see, the FLOCKDN will lock a few registers,
> among which it will lock the "discrete PR locks" register, and it will
> lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
> separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
> set, and in the payload, just set protected range in PRR3 or PRR4,
> then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
> PRR3 and 4 were already locked with the discrete lock register (if I
> remove the call to fast_spi_pr_dlock(), it should be fine for my needs
> though I think, since you said swseq would also fail for protected
> ranges).

Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
at least didn't remember it. In this case it seems best to always set
FLOCKDN in coreboot. The payload can then still protect additional
regions with PRR3/4. On the resume path, coreboot would set both 
FLOCKDN

and PRR34_LOCKDN, right?


On resume, even if coreboot sets them, the PRRs need to be filled,
which is why I also added the hex value of the PRR in the KConfig.
I also want to keep FLOCKDN unlocked, so Heads can set the write
protect bits in the flash then prevent writing to the status register
via hwseq before locking it with FLOCKDN.



>> Also note that swseq is not an option anymore since Skylake (IIRC, the
>> ME protects the flash-cycle go bit in its default configuration). With
>> only hwseq, you can only access the flash chip's first status register
>> which makes many security features unusable. So we have to rely on the
>> protected regions :-/ I hope Intel is going to fix that for future plat-
>> forms (or with an ME update if that could add more hwseq commands).
>
> Well, I saw the opmenu/optypes/etc.. registers still being set in
> skylake (their offsets were not in the datasheet though), so I figured
> swseq is still there, just undocumented. It might work on systems
> where the ME is disabled. I'd have to test. I was thinking of using
> swseq and add the write-register-2 opcode and use it to set SPR1 and
> lock the entire flash until it gets power cycled. I don't know if that
> would work during suspend, but if it does, it might help with the
> resume path at least (but would prevent updating flash after a reboot
> and would force user to shut down and boot). I guess I have some
> trial-error to do.

The tricky part is to get access to the flash chip's second status
register. I couldn't figure any way to do that with SKL (this cost
me some weeks of work once because FSP also locked empty flash pro-
tection).

Only way I see is through swseq, but you say it doesn't work because
of the ME. I'd have to 

Re: [coreboot] SPI controller and Lock bits

[Martin Kepplinger]

Am 02.10.2018 13:51 schrieb Nico Huber:

Am 02.10.18 um 13:01 schrieb Martin Kepplinger:

Am 26.09.2018 01:30 schrieb Youness Alaoui:

Hi,

I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating 
their

flash whenever they want to.



I might be wrong, but since Heads already authenticates to you via 
TOTP,

this wouldn't really add extra security, wouldn't it?


This is the most common misunderstanding about a measured boot. If you
don't have separate hardware that starts the measuring (usually you let
the firmware measure itself), you need a firmware part that starts the
measuring and is read-only for an attacker (referred to as read-only or
static `root of trust`). Otherwise you leave the decision what to mea-
sure to the attacker (and he can choose to measure the original 
software
before his tampering instead of the running program, and TOTP will 
still

work flawlessly).

So it's the other way around: without this, TOTP doesn't provide any
security at all.

Nico


thanks! My high-level understanding was that Heads uses the
TPM as said "root of trust" and the TOTP shared secret will be lost
in any changed firmware.

So a changed firmware would basically need to write PCRs to the TPM
in order for the "PCR matching" to succeed and release the valid TOTP
secret. Be it by measuring and remembering the original firmware or
somehow else.

I don't know why, but I've though that the TPM would prevent a modified
firmware to do this -.-

http://osresearch.net/Keys is quite good, but maybe we'd need a wiki
with real setups compared, or something. I fear that I'm not the only 
one

who's confused with trusted boot stuff.

As a quick fix, couldn't Heads offer to create an image with the IFD 
re-locked,
in order to force (yourself) to hardware-flashing. Has this been 
discussed?


thanks

   martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SPI controller and Lock bits

[Martin Kepplinger]

Am 26.09.2018 01:30 schrieb Youness Alaoui:

Hi,

I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.



I might be wrong, but since Heads already authenticates to you via TOTP,
this wouldn't really add extra security, wouldn't it?

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS upgrade before flashing coreboot

[Martin Kepplinger]

Am 07.06.2018 18:46 schrieb Merlin Büge:

On Thu, 7 Jun 2018 12:05:34 +0200
Akendo  wrote:


Hey everyone,

currently I working on a x220 to flash coreboot onto it. I notice that
my x220 has a current BIOS version from 2011 (1.24 UEFI/BIOS and
1.13  ECP).

Within the change-log[0] variates updates and fixes are stated.
Including changes to the ME engine. Within many documentation part of
coreboot, it's stated, that the ME part can't be written. Here my
question: Should I update the BIOS to the latest release before
flashing coreboot onto it?


A little hint: The BIOS update might also be updating the EC = Embedded
Controller containing various fixes / improvements. E.g. on the X200 it
is recommended to upgrade to the latest stock BIOS before flashing
coreboot, which brings improvements in battery handling IIRC.



Right. Not the ME, but the EC software is why I'd definitely upgrade in 
your

case. Changing that after you've flashed coreboot is quite annoying.

I'm not sure how their support for the X220 (it's been targeting the 
x230) is,

but may be worth having a look:
This project downloads the official iso image, can apply a patch to the
EC firmware to enable using unofficial 3rd-party batteries, and generate 
an

iso or USB image: https://github.com/hamishcoleman/thinkpad-ec

Especially if you plan to apply me_cleaner to your image, all the rest 
doesn't

really matter I guess.

   martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Thinkpad X230: store the proprietary VGA bios in the blobs repo?

[Martin Kepplinger]

Hi,

As documented at 
https://www.coreboot.org/Board:lenovo/x230#Proprietary_components.27_status
and verified by my recent tests, anyone running GRUB on the harddrive or 
Windows,

needs an extracted VGA bios binary on the X230.

This is identical for all X230 models. There have been vga bios binaries
in the blobs repo in the past, so why not put this in?

Is there a place inside blobs, the coreboot build can pick it up from, 
automatically?
I guess a new config option would be needed here, but I'm not entirely 
sure.


Unfortunately I haven't yet found a license applying to it. I'm thankful 
for hints.


thanks,

  martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Thinkpad X230, Coreboot 4.7 + SeaBIOS 1.11.0 flashing, memtest86+ 5.01, fancontrol and WoL

[Martin Kepplinger]

Am 22.04.2018 21:09 schrieb Jan Malakhovski:

Hi.

# Primary TOC

* Thinkpad X230 seems to be a fairly common target for coreboot, but I
  though that another recent success report wouldn't hurt.

* Flashing with "WoL on AC" trick (missing on the wiki).

* Failure report on using Debian's memtest86+ and success report on
  using coreboot's memtest86+.

* The laptop also overheats while running memtest86+ with coreboot (but
  not vendor BIOS) which, I think, is a bug/missing feature in 
coreboot.


* There's also a Wake on LAN issue/question.

# The Success Report

I flashed Thinkpad X230 with Coreboot tagged 4.7
(fd470f7163709c1022ee6185134a2387812774ec) with a config that has the
following diff from the default 4.7 X230 config (made by `cat
configs/builder/config.lenovo_x230 > .config ; make menuconfig` 
followed

by ):

--- config.x230.v4.7.def
+++ config.x230.v4.7.my
@@ -11,7 +11,7 @@
 CONFIG_CBFS_PREFIX="fallback"
 CONFIG_COMPILER_GCC=y
 # CONFIG_COMPILER_LLVM_CLANG is not set
-# CONFIG_ANY_TOOLCHAIN is not set
+CONFIG_ANY_TOOLCHAIN=y
 # CONFIG_CCACHE is not set
 # CONFIG_FMD_GENPARSER is not set
 # CONFIG_UTIL_GENPARSER is not set
@@ -112,6 +112,7 @@
 CONFIG_MAX_CPUS=8
 CONFIG_CACHE_ROM_SIZE_OVERRIDE=0x0
 CONFIG_CBFS_SIZE=0x10
+CONFIG_PAYLOAD_CONFIGFILE=""
 CONFIG_VGA_BIOS_ID="8086,0166"
 CONFIG_ONBOARD_VGA_IS_PRIMARY=y
 CONFIG_DIMM_SPD_SIZE=256
@@ -136,8 +137,8 @@
 CONFIG_FMDFILE=""
 CONFIG_PRERAM_CBMEM_CONSOLE_SIZE=0xc00
 # CONFIG_DRIVERS_UART_8250IO is not set
-CONFIG_IFD_BIN_PATH="site-local/descriptor.bin"
-CONFIG_ME_BIN_PATH="site-local/me.bin"
+CONFIG_IFD_BIN_PATH="site-local/flashregion_0_flashdescriptor.bin"
+CONFIG_ME_BIN_PATH="site-local/flashregion_2_intel_me.bin"
 # CONFIG_BOARD_LENOVO_G505S is not set
 # CONFIG_BOARD_LENOVO_L520 is not set
 # CONFIG_BOARD_LENOVO_R400 is not set
@@ -338,6 +339,7 @@
 #
 CONFIG_EC_ACPI=y
 CONFIG_EC_LENOVO_H8=y
+CONFIG_SEABIOS_PS2_TIMEOUT=3000
 CONFIG_H8_BEEP_ON_DEATH=y
 CONFIG_H8_FLASH_LEDS_ON_DEATH=y
 # CONFIG_H8_SUPPORT_BT_ON_WIFI is not set
@@ -348,9 +350,9 @@
 # Intel Firmware
 #
 # CONFIG_EM100 is not set
-# CONFIG_CHECK_ME is not set
+CONFIG_CHECK_ME=y
 # CONFIG_USE_ME_CLEANER is not set
-CONFIG_GBE_BIN_PATH="site-local/gbe.bin"
+CONFIG_GBE_BIN_PATH="site-local/flashregion_3_gbe.bin"
 # CONFIG_HAVE_EC_BIN is not set
 # CONFIG_MAINBOARD_HAS_CHROMEOS is not set
 # CONFIG_GOOGLE_SMBIOS_MAINBOARD_VERSION is not set
@@ -621,17 +623,31 @@
 #
 # Payload
 #
-CONFIG_PAYLOAD_NONE=y
+# CONFIG_PAYLOAD_NONE is not set
 # CONFIG_PAYLOAD_ELF is not set
 # CONFIG_PAYLOAD_BAYOU is not set
 # CONFIG_PAYLOAD_FILO is not set
 # CONFIG_PAYLOAD_GRUB2 is not set
-# CONFIG_PAYLOAD_SEABIOS is not set
+CONFIG_PAYLOAD_SEABIOS=y
 # CONFIG_PAYLOAD_UBOOT is not set
 # CONFIG_PAYLOAD_LINUX is not set
 # CONFIG_PAYLOAD_TIANOCORE is not set
+CONFIG_PAYLOAD_FILE="payloads/external/SeaBIOS/seabios/out/bios.bin.elf"
+CONFIG_SEABIOS_STABLE=y
+# CONFIG_SEABIOS_MASTER is not set
+# CONFIG_SEABIOS_REVISION is not set
+# CONFIG_SEABIOS_THREAD_OPTIONROMS is not set
+CONFIG_SEABIOS_VGA_COREBOOT=y
+CONFIG_SEABIOS_BOOTORDER_FILE=""
+CONFIG_PAYLOAD_VGABIOS_FILE="payloads/external/SeaBIOS/seabios/out/vgabios.bin"
+CONFIG_SEABIOS_DEBUG_LEVEL=-1
+
+#
+# Using default SeaBIOS log level
+#
 CONFIG_PAYLOAD_OPTIONS=""
 # CONFIG_PXE is not set
+CONFIG_COMPRESSED_PAYLOAD_LZMA=y
 # CONFIG_PAYLOAD_IS_FLAT_BINARY is not set

You should probably ignore CONFIG_ANY_TOOLCHAIN=y since I simply built
gcc 6.3 with coreboot patches via nix package manager and then built
coreboot using that, so I'm using exactly the same compiler, only
packaged via nix (because it was simpler for me this way).

# Flashing with "WoL on AC" trick

A couple of words on reading/flashing X230's SPI

Neither Raspberry Pi 3 B+, nor Beagle Bone Black can supply enough 
power

to feed the MX chips to the board, so the wiki
https://www.coreboot.org/Board:lenovo/x230 both recommends an external
power supply and warns against using it at the same time (as it can
brick the board).

But there's a much simpler and safer method described in
https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whitelist-removal?pid=91134#pid91134
and
https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whitelist-removal?pid=91787#pid91787
that doesn't require an external power supply.

In short: enable Wake On Lan on AC power in Lenovo BIOS, disconnect AC
and battery, insert live Ethernet cable, connect AC, Ethernet port
should go live (LEDs). Connect your external programmer _but leave
VCC/3.3V line disconnected_ (i.e. connect all the data lines and the
ground, but not the VCC). The Ethernet port is on the same power line 
as
MX chips, hence flashing with RPi/BBB with VCC disconnected will work 
as

with older models.


I've flashed 4 or 5 of these, and on 1 or 2 the WoL powering would 
simply not work.

flashrom with spispeed 128 always did. Always set an SPI speed.



The only difference with older models is that you have to cut

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Martin Kepplinger]

Am 21.03.2018 11:13 schrieb Nico Huber:

On 21.03.2018 00:03, taii...@gmx.com wrote:

On 03/20/2018 06:14 PM, Nico Huber wrote:


These patches need to be added stat

You obviously have no idea what you are talking about.

What makes you say that?


You. You seem to rate the convenience to have a binary in the blobs
repository higher than possible redistribution issues.

Though, we might have a simple misunderstanding here. I now realized
that you were trying to cherry-pick that commit into a different re-
pository. This thread is about a change to the blobs repository which
is independent of the coreboot source repository and has different
rules.

Anyway, I wasn't telling not to fix it, I was just offended by the way
you want to fix it and your arrogance. You can mitigate Spectre in many
ways. These microcode updates are just part of one way. And putting
them into coreboot is just one way to apply them. And having them in
the blobs repository is just for convenience. Yet, you claimed the lat-
ter must happen.

AFAIK, nobody who has the right to submit to the blobs repository has 
commented yet on
newer microcode updates or was asked personally if this is 
acceptable.
You might have noticed that microcode updates are not public domain 
but

licensed.
Almost every linux distro redistributes them without issue and intel 
is

suppository a coreboot contributor (to which I have been reminded of
multiple times)


The files are explicitly distributed by Intel for Linux distributors, 
we
are not a Linux distributor. And, FWIW, Intel hasn't ever contributed 
to

our blobs repository.


I don't see as to how that is something that can't be worked around by
asking people to download it themselves from a browser or making a 
shell
script that imports intel's EULA and asks the user to agree to it 
before

downloading it when they compile coreboot.


You are already free to add any microcode update to coreboot you want.
And we kind of ask people by prompting during coreboot configuration.
Not every license is an EULA btw.



Other microcode updates are included coreboot so are a variety of ME
images and other binary blobs from intel so I fail to see the
distinction here.


Yep, but they were submitted a long time ago. And that stopped at some
point. I don't know yet if due to licensing issues or just because it's
more convenient for Google to maintain their own, hidden blobs repo.


FWIW, my understanding is that Intel *calls* this microcode release 
"Linux".
Nothing in the license text refers to Linux or Linux distributors. In 
principal

it is distributable. The relevant OEM part of the license basically says

* only use with Intel CPUs, only under this license
* don't reverse engineer
* only distribute in conjunction with a "written license aggreement" 
like a

"break-the-seal license" to "safeguard Intel's ownership rights".

That last part may indeed be tricky. Other than that, it may be good to
include the license text in the blobs repo directly.

IANAL, but coreboot might not be compliant indeed now. I can imagine
*some* way of achieving compliance like a prominent statement with
"press any key" during the build process though.

Coreboot should (only) care about *it's* users and pass on this license 
to them

(distributors or whoever, who then can deal with it too).

In short: We can greatly improve the situation quite easily, and 
probably

should do so. Thanks for bringing this up.




- the stakes are too high for this to take months.

You still didn't get what Spectre is about, did you?

I do.

It's just one of many side-channel attacks that are possible when you
run untrusted code on your machine.
The whole point of a VM is that you are able to run untrusted code 
with

some decent level of isolation and spectre ruins this.


So does Rowhammer, any caching related side-channel attacks, hyper-
threading related side-channel attacks, I don't know maybe more. These
attacks exist and are possible, some may be more complicated than
Spectre but most of all: They are not as popular as Spectre.


What other exploits exist which can easily read data from a VM's host?


Sorry, easily? Even a Spectre attack isn't that easy. It depends a lot
on the code around your VM (no matter the microcode updates in ques-
tion). You can make it secure against Spectre even without these micro-
code updates.


If you were a sysadmin for a large company would you tell them to not
bother applying the spectre mitigations? should their users use 
umatrix
instead and that anyone who accidentally enables a site with 
encryption

key/password stealing malicious javascript gets fired? Enabling
javascript on a per site basis is like playing minesweeper - 
eventually

you will step on a mine no matter how careful you are.


Good analogy, you are right. No matter how careful you are, you may get
powned at some point. But what you suggest doesn't seem much better,
trigger all mines you can spot all day with a gas mask on that only
protects you 

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Martin Kepplinger]

Am 20.03.2018 00:15 schrieb taii...@gmx.com:
So you are saying that sandy and ivybridge have spectre microcode 
updates?


I hate how unclear intel is about this.

How do I patch my coreboot?


Like I said, the update is here for anybody to cherry-pick and test:
https://review.coreboot.org/#/c/blobs/+/23315/

I expect this change to be merged sometime "soon", when reviewed.

Yes, they even updated sandybridge and ivybridge. (For those, you
only need the first of those 4 patches)

Intel doesn't seem to care about informing users directly, at least this 
time around.

They've worked with and for their "industry partners" and have left
packaging updates to BIOS vendors. In the end we have a full release
from Intel again though, so we're happy at last :)

 martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Martin Kepplinger]

Am 14.03.2018 22:46 schrieb David Hobach:

On 01/11/2018 03:55 AM, taii...@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode 
updates released for older intel CPU's (ex: sandy/ivybridge) and 
failing that, what can be done in regards to securing them from 
meltdown/spectre.


Looks like they're available now. Has anyone tested them yet?

https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File


I have. I have the relevant patchset up for review: 
https://review.coreboot.org/#/c/blobs/+/23315/
and currently always apply it on top of my coreboot build (for the 
Thinkpad X230 in
my case; has then revision "1f" and verified functionality using 
https://github.com/speed47/spectre-meltdown-checker

or similar tools)

martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] only 8GB RAM on ThinkPad X230 after commit 7539b8c3

[Martin Kepplinger]

Am 18.03.2018 23:42 schrieb Marek Behun:

Hello,

with the commit 7539b8c3 "nb/intel/sandybridge: Use common mrc cache
functions" I only have accessible 8 GB of ram on ThinkPad X230,
although I have two 8 GB modules. On the previous commit whole 16 GB is
visible.

Marek


I'm running cb9f55ec38 on my X230 and cannot reproduce that. I have my 
16 GB.


(Just to be exact, I applied 
https://review.coreboot.org/#/c/blobs/+/23315/ on top,

but that won't change anything here)

   martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] blobs: is there a reason for intel microcode version 20150121?

[Martin Kepplinger]

Am 21.11.2017 12:42 schrieb Zoran Stojsavljevic:

I know very little about it really. It may well be potentially bad

to simply use the latest version,

but in case it's really only because nobody did it, I might prepare

a patch to use

downloadmirror.intel.com/27337/eng/microcode-20171117.tgz [1]

instead (someday, after

I testing it on my device).


To understand what is really going on, I did the following
investigation on my only coreboot clone version,
I have on my current SSD the following: WIN10, using VMware®
Workstation 12 Player, version  12.5.8 build-7098237
with Fedora 26 VM, where the coreboot is located.

CLI transcript follows:

_[user@localhost coreboot]$ pwd_
_/home/user/projects/coreboot/coreboot_
_[user@localhost coreboot]$ git describe_
_4.5-1006-gef7e98a2ac_
_[user@localhost coreboot]$ grep -r 20150121 *_
_3rdparty/blobs/cpu/intel/microcode/update-microcodes.sh:MICROCODE_VERSION=20150121_
_[user@localhost coreboot]$ cd 3rdparty/blobs/cpu/intel/microcode_
_[user@localhost microcode]$ ls -al_
_total 24_
_drwxrwxr-x.  2 user user 12288 Nov 21 12:27 ._
_drwxrwxr-x. 24 user user  4096 Feb 18  2017 .._
_-rwxrwxr-x.  1 user user  1782 Feb 18  2017 microcode2bin.sh_
_-rwxrwxr-x.  1 user user  2989 Nov 21 12:27 update-microcodes.sh_
_[user@localhost microcode]$ tail -10 update-microcodes.sh _
_}_

_get_microcode_
_separate_microcode_
_move_microcode_
_DUMP_CPUIDS <<=== I ADDED THIS LINE OF CODE
TO SEE WHICH CPUIDSS MCUS ARE ADDED HERe: _

_rm -f $MICROCODE_ARCHIVE_
_rm -f $MICROCODE_FILE_

_[user@localhost microcode]$ _

Now, you can substitute 20150121.tgz with 20171117 [1].tgz in bash
shell script update-microcodes.sh and see what will happen?!



That's not enough. The integers in the url of
https://review.coreboot.org/cgit/blobs.git/tree/cpu/intel/microcode/update-microcodes.sh#n24
change aswell, not just MICROCODE_VERSION.

So if you're suggesting that a download fails, that's not the issue.

But maybe I got you wrong. Anyways, I haven't tried to change and run 
it. I might. so...


thanks

 martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] blobs: is there a reason for intel microcode version 20150121?

[Martin Kepplinger]

Since there are many releases of Intel's cpu microcode since 2015-01, I 
was wondering if

there's a reason why coreboot, if at all, uses this one.

I know very little about it really. It may well be potentially bad to 
simply use the latest version,
but in case it's really only because nobody did it, I might prepare a 
patch to use
downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead 
(someday, after

I testing it on my device).

thanks
 martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

On 2017-09-23 17:52, Peter Stuge wrote:
> Martin Kepplinger wrote:
>> It's lying here as a brick.
> 
> Where is "here" ? What city?
> 

Linz, Austria

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot on X230 and Dualboot / How to make it work

[Martin Kepplinger]

Am 26.09.2017 02:20 schrieb One7two99 via coreboot:

Hello,

I tried to flash the 8 MB Chip on my X230, but it didn't worked out.


Me: what do I need to do to flash the 2nd (8MB) chip.

If the 1st chip contains the last 4MB of the file, I assume the
correct command could be:

dd of=chip8mb.rom bs=1M if=build/coreboot.rom count=8

Is this correct? If this is right I'll add this to the wiki as soon
as I have write permissions.


I've dd'ed the first 8MB of the coreboot.rom file with the above
command and flashed it on the 8MB chip, but when booting my machine
only illuminated the on-off-button for a second before it dies.

When reflashing the 8MB chip with the stock image which I grabbed
before will bring my laptop back to life. As such it seems that there
must be another was two flash both chips and to strip the coreboot.rom
image.

Any ideas what went wrong?

As all howto's I've found so far, which cover the flashing of only the
upper 4 MB Chip, the question is also, if someone has already flashed
both chips and what (s)he did to make it work.



what would you want to do? Analyse the image. If your BIOS fits in 4MB,
you really only need to flash the last 4MB, and using a hardware 
flasher,

you cut it out and flash it to the one 4MB chip. done.

The first 8MB contain the ME. So if you want to, read it, run me_cleaner
on it or whatever and flash it back. You will never need it for updating
coreboot as long as the BIOS is less than 4MB, which it easily is, say,
when you have only seaBIOS as your payload.

The wiki also contains an image file which is useful when you want to 
try
to flash from a running system in software, using flashrom. I don't 
recommend
doing that though. I can't say why, but my X230 died after flashing a 
few times
from a running Debian with flashrom. I couldn't bring it back to life 
using the

saved vendor bios image.

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

Am 20.09.2017 19:32 schrieb Alexander Couzens:

Hi Martin,

I would like to take a look on your brick. Do you come to the meeting?



No I don't come to meeting. It's disassembled right now. I plan to 
assemble it and
run the official Lenovo Live CD. If that doesn't help, I'd send it to 
you, but it really
can take a while, maybe weeks. If you're still interested, I'll remember 
to notify you.


thanks though,

  martin

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

Am 19.09.2017 22:41 schrieb taii...@gmx.com:

On 09/19/2017 01:20 PM, Martin Kepplinger wrote:

What I want to add is:

* This was a git checkout in June this year.

* I flashed a coreboot image (I can't remember what config) fine, and
used the laptop while everything (shutdown, suspend, reboot) worked.
Maybe the config is irrelevant, whatever.

* the machine didn't die "right after" or "during" flashrom-flashing. 
It

ran fine for a while. I can't remember if it suspended to and resumed
from RAM too, or even shutdown or reboot worked. IIRC after shutting
down it died. I guess the first shutdown after flashing, but I'm 
really

not sure at all.

* I had upgraded the EC and BIOS to the latest Lenovo version before
starting with coreboot.

To be clear did you use a clip flash or did you flash a running 
machine?


I always do a clip flash on my first flash of every board, I can't
understand why someone wouldn't given you need to for a me_clean and
it is dangerous to do a flash without rescue equipment - although your
issue is much different and way scarier D: D: D:


The first (few) coreboot flash was a clip flash. I flashed from a 
running system

too, using flashrom, before the laptop died.



Have you tried updating the EC externally or swapping the chip/FRU
board that contains it? I can't believe it is truly dead and I imagine
it is EC related.


Nope. I didn't solder anything nor bought any replacement. Now when I 
think
about it, what I didn't try is to run the Lenovo BIOS upgrade from their 
live CD...


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

On 2017-09-19 19:10, Martin Kepplinger wrote:
> On 2017-09-18 04:02, Alexander Couzens wrote:
>> Hi,
>>
>> the x230 is quite good working,
>> ... but recently some boards died (I know from 2 boards over the last
>> years). I'm still not sure why they died, but rumors that the EC
>> firmware ran into a bug when doing In-Circuit flashing.
>>
>> I've an x230 myself and never managed to trigger that bug. I would
>> recommend you to update the EC to the newest firmware. The EC firmware
>> is updated together with the bios, so updating the vendor bios/uefi is
>> enough.
>>
>> We can also desolder your spi chip, programm it and put it back. But
>> that's also a way I wouldn't recommend doing to often.
>>
>> Best,
>> lynxis
>>
>>
>>
> 
> Oh, finally I hear about this. I triggered this bug. The machine totally
> died. Nothing, at least nothing like flashing the original bios or
> flashing whatever, could bring it back. It's lying here as a brick. I
> *did* flash using flashrom online while running Debian.
> 
> I plan to get another X230 one day soon, but will only flash offline,
> using my pomona clip :(
> 
> Would be good to have the wiki updated and possibly a bug filed I guess...

What I want to add is:

* This was a git checkout in June this year.

* I flashed a coreboot image (I can't remember what config) fine, and
used the laptop while everything (shutdown, suspend, reboot) worked.
Maybe the config is irrelevant, whatever.

* the machine didn't die "right after" or "during" flashrom-flashing. It
ran fine for a while. I can't remember if it suspended to and resumed
from RAM too, or even shutdown or reboot worked. IIRC after shutting
down it died. I guess the first shutdown after flashing, but I'm really
not sure at all.

* I had upgraded the EC and BIOS to the latest Lenovo version before
starting with coreboot.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

On 2017-09-18 05:47, Persmule wrote:
> 在 2017年09月18日 10:45, diffusae via coreboot 写道:
>> On 18.09.2017 04:35, Alexander Couzens wrote:
>>> On Mon, 18 Sep 2017 02:17:56 +
>>> Persmule  wrote:
>>>
 Why solder is needed? X230 is in-system
  programmable with even a ch341a. 
>>> Some boards come with a WSON8 spi flash. Or is there another way to
>>> do in-system-programmable without an SPI clip?
>> I guess, that you always need a SOIC-8 clip for the first time.
>> Unless you have a modified vendor UEFI.
>>
>>
>> .
>>
> No. Using a pomona 5250 clip to program a wson-8 chip on board is
> possible, according to
> https://www.coreboot.org/Board:lenovo/t430s#Preparation .
> 
> 

Isn't a pomona 5250 clip a "SOIC-8 clip" Alexander was mentioning? :)
Anyways, I flashed an X230 using a pomona clip without any problem.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Berlin Meeting 21. Sep Thursday @afra_berlin

[Martin Kepplinger]

On 2017-09-18 04:02, Alexander Couzens wrote:
> Hi,
> 
> the x230 is quite good working,
> ... but recently some boards died (I know from 2 boards over the last
> years). I'm still not sure why they died, but rumors that the EC
> firmware ran into a bug when doing In-Circuit flashing.
> 
> I've an x230 myself and never managed to trigger that bug. I would
> recommend you to update the EC to the newest firmware. The EC firmware
> is updated together with the bios, so updating the vendor bios/uefi is
> enough.
> 
> We can also desolder your spi chip, programm it and put it back. But
> that's also a way I wouldn't recommend doing to often.
> 
> Best,
> lynxis
> 
> 
> 

Oh, finally I hear about this. I triggered this bug. The machine totally
died. Nothing, at least nothing like flashing the original bios or
flashing whatever, could bring it back. It's lying here as a brick. I
*did* flash using flashrom online while running Debian.

I plan to get another X230 one day soon, but will only flash offline,
using my pomona clip :(

Would be good to have the wiki updated and possibly a bug filed I guess...

thanks

 martin


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230

[Martin Kepplinger]

Am 04.07.2017 18:20 schrieb Marcel Maci:

Thx - so, if I understand correctly you mean that I can handle the to
chips separately? Which means:
- first step: read the 8MB chip, apply me_cleaner, unlock it and write
  it back
- second step: build coreboot (optionally with video bios extracted
  from original bios) and flash it to the 4MB chip
If this is true, it would mean that I could now flash back just the 8MB
of the stock firmware (applying me_cleaner and unlocking it before
flashing) and it should work fine with the upper 4MB (that contain
coreboot). I haven't tried that but I'm a little bit sceptical that it
will work...


Sure you can handle the chips completely seperately. That's how did it
when initially doing external SPI flashing.


Just in order to be clear about what I did (and what worked perfectly
on the another Thinkpad x230 to which I installed the same
coreboot/seabios/me_cleaner-configuration):
- I extracted both 8MB + 4MB stock firmware and concatenated them to
  one 12MB image
- I applied me_cleaner, unlocked it, extracted gbe.bin, me.bin,
  descriptor.bin and vbios.bin
- I built a 12MB coreboot-image adding those binary blobs
- I separated the image into lower 8MB and upper 4MB and flashed them
  back separately.
As I've said it worked perfectly for the other x230 I have and I don't
understand what's different with this one.



I guess that should be the same. Your problem may be unrelated to 
flashing,

as suggested by others here.



 Am Tue, 04 Jul 2017 14:05:07 +0200
schrieb Martin Kepplinger <mart...@posteo.de>:


Am 03.07.2017 17:23 schrieb Marcel Maci:
> Hi, I've flashed coreboot with seaBIOS and me_cleaner to my Thinkpad
> x230 and everything works fine except the network. Neither wifi nor
> ethernet works. Could this be a problem with the gbe.bin I've used
> (I extracted it with ifdtool -x from the factory bios and the first
> time I did this on another Thinkpad x230 it worked perfectly)?

You don't need to extract gbe.bin, descriptor.bin or me.bin for the
X230. I
planned to update the wiki a little because I also found it to be not
clear
enough:

So you are talking about external SPI flashing. There are 2 flash
chips and
the gbe part is in the "second", 8MB one, together with the me and
descriptor
parts. You really "need" to access this chip only once. What you want
to do is
read it (obviously), run me_cleaner on it (you can use the whole
image. me_cleaner
will recognise it and write a new one for you), and run ifdtool -u on
it in order
to unlock internal writing from now on. That's it, so write that
back. Until
me_cleaner or the libreboot people find a way to *really* remove the
ME, I guess you don't have to touch that 8MB chip anymore.

For the bios (coreboot with payload), you only need to access the
"first", 4MB
chip, and you don't need any extracted binary blob when building
coreboot for
this; they're part of the other one. (except for the video BIOS, if
you want to).
When flashing (writing) *externally*, of course you have to cut out
the 4MB
from the 12MB that the coreboot build creates for you, like seen in
the wiki.

When flashing *internally*, you can use the 12MB image as is, and use
flashrom's
--layout feature, again using only the 4MB for flashing coreboot,
leaving all
the rest untouched. So again, you don't need any extracted binary
when building
coreboot.

hope that helps. Although I use an Atheros wifi chip on PCIe, it
works just fine.

  martin



--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230

[Martin Kepplinger]

Am 03.07.2017 17:23 schrieb Marcel Maci:

Hi, I've flashed coreboot with seaBIOS and me_cleaner to my Thinkpad
x230 and everything works fine except the network. Neither wifi nor
ethernet works. Could this be a problem with the gbe.bin I've used
(I extracted it with ifdtool -x from the factory bios and the first
time I did this on another Thinkpad x230 it worked perfectly)?


You don't need to extract gbe.bin, descriptor.bin or me.bin for the 
X230. I
planned to update the wiki a little because I also found it to be not 
clear

enough:

So you are talking about external SPI flashing. There are 2 flash chips 
and
the gbe part is in the "second", 8MB one, together with the me and 
descriptor
parts. You really "need" to access this chip only once. What you want to 
do is
read it (obviously), run me_cleaner on it (you can use the whole image. 
me_cleaner
will recognise it and write a new one for you), and run ifdtool -u on it 
in order
to unlock internal writing from now on. That's it, so write that back. 
Until

me_cleaner or the libreboot people find a way to *really* remove the ME,
I guess you don't have to touch that 8MB chip anymore.

For the bios (coreboot with payload), you only need to access the 
"first", 4MB
chip, and you don't need any extracted binary blob when building 
coreboot for
this; they're part of the other one. (except for the video BIOS, if you 
want to).
When flashing (writing) *externally*, of course you have to cut out the 
4MB
from the 12MB that the coreboot build creates for you, like seen in the 
wiki.


When flashing *internally*, you can use the 12MB image as is, and use 
flashrom's
--layout feature, again using only the 4MB for flashing coreboot, 
leaving all
the rest untouched. So again, you don't need any extracted binary when 
building

coreboot.

hope that helps. Although I use an Atheros wifi chip on PCIe, it works 
just fine.


 martin


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot