coreboot February 2018

coreboot@coreboot.org

49 participants
79 discussions

Re: [coreboot] [SeaBIOS] Mysterious "is VARVERIFY32INIT but used from" problem while trying to improve SeaBIOS

by Kevin O'Connor

On Sun, Feb 25, 2018 at 03:05:06AM +0300, Mike Banon wrote: > Friends, I need your help. While trying to improve SeaBIOS I got stuck > at this very strange problem - which does not appear when you do a > standalone build of SeaBIOS but it happens when you try building a > coreboot together with SeaBIOS. Steps to reproduce: Please see the developer documentation: https://www.seabios.org/Developer_Documentation In particular, read the "memory model" and "execution and code phase" documents. -Kevin

2 years, 5 months

Re: [coreboot] make gitconfig not working for me with git 1.9.1

by Nico Huber

On 25.02.2018 09:23, Mike Banon wrote: > just upgrade your git? 1.9.1 is a little bit old You probably mean, "just" upgrade every git of every system that is used for coreboot development. Ubuntu 14.04 (which is still maintained btw.) might not be the only active distribution with an old git version. > Although I am unsure if there is anything newer for ubuntu 14.04 > since it is very outdated and everyone switched to 16.04 LTS or later. > Maybe you would have to compile a new git from source if you don't > want / can't reinstall OS Well, we could discuss to add Git to our crossgcc script if you'd like to maintain that. Nico > > On Sat, Feb 24, 2018 at 3:10 AM, <mturney(a)codeaurora.org> wrote: >> >> Errors I receive on command-line strongly point to this commit: >> >> commit fda071ca7a17614a58c0812c28b14a417471b915 >> Author: Alex Thiessen <alex.thiessen.de+coreboot(a)gmail.com> >> Date: Sat Jan 13 17:05:31 2018 +0000 >> >> util/gitconfig: Make gitconfig.sh support gitfile >> >> >> Ubuntu host, 14.04 >> >> >> mturney@mturney-linux:/local/mnt/workspace/mturney/gitrepos/public/coreboot$ >> make gitconfig >> fatal: ambiguous argument 'hooks': unknown revision or path not in the >> working tree. >> Use '--' to separate paths from revisions, like this: >> 'git <command> [<revision>...] -- [<file>...]' >> mkdir: unrecognized option '--git-path >> hooks' >> Try 'mkdir --help' for more information. >> util/gitconfig/gitconfig.sh: line 33: --git-path >> hooks/commit-msg: No such file or directory >> chmod: unrecognized option '--git-path >> hooks/commit-msg' >> Try 'chmod --help' for more information. >> util/gitconfig/gitconfig.sh: line 33: --git-path >> hooks/pre-commit: No such file or directory >> chmod: unrecognized option '--git-path >> hooks/pre-commit' >> Try 'chmod --help' for more information. >> fatal: ambiguous argument 'hooks': unknown revision or path not in the >> working tree. >> Use '--' to separate paths from revisions, like this: >> 'git <command> [<revision>...] -- [<file>...]' >> fatal: ambiguous argument 'hooks': unknown revision or path not in the >> working tree. >> Use '--' to separate paths from revisions, like this: >> 'git <command> [<revision>...] -- [<file>...]' >> fatal: ambiguous argument 'hooks': unknown revision or path not in the >> working tree. >> Use '--' to separate paths from revisions, like this: >> 'git <command> [<revision>...] -- [<file>...]' >> mturney@mturney-linux:/local/mnt/workspace/mturney/gitrepos/public/coreboot$ >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >

2 years, 5 months

Re: [coreboot] Serial input / output with SeaBIOS 1.11.0

by Piotr Kubaj

I didn't get it working with SeaBIOS' SERCON, but I just moved on to SgaBIOS. It turns out it's actually better for me than SERCON, because it provides serial redirection to the point where kernel takes over, while SERCON only provides till bootloader starts. That feature of SgaBIOS makes it possible to use full disk encryption on FreeBSD (without unencrypted /boot), because the password prompt just before bootloader is about to start and currently it's impossible to redirect it to serial (bootloader can be redirected to serial, password prompt can not). With SgaBIOS, I can get a password prompt via serial, with SERCON it's not possible (at least I didn't find a way to do so). -- ________________________________________ / Toilet Toupée, n.: \ | | | Any shag carpet that causes the lid to | | become top-heavy, thus | | | | creating endless annoyance to male | | users. | | | \ -- Rich Hall, "Sniglets" / ---------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

2 years, 5 months

Re: [coreboot] [SeaBIOS] Mysterious "is VARVERIFY32INIT but used from" problem while trying to improve SeaBIOS

by Mike Banon

"varverify32init.patch" in the attachments. To apply a patch please copy it to the coreboot directory, "cd" to coreboot, and - if seabios is already cloned (e.g. after building a coreboot once, followed by a "make clean" of course) run " patch -l -p1 < varverify32init.patch " Sorry, my previous message had a typo, the final results for testfunc() : (1) = OK, inside " cbfs_copyfile " (2) = OK, inside " coreboot_cbfs_init " (3) = ERR, inside " cbfs_run_payload " P.S. I'm using the default "menuconfig" settings, "emulation/qemu-i440fx" target Best regards, Mike On Sun, Feb 25, 2018 at 11:55 AM, Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > Dear Mike, > > > Am 25.02.2018 um 01:05 schrieb Mike Banon: >> >> Friends, I need your help. While trying to improve SeaBIOS I got stuck >> at this very strange problem - which does not appear when you do a >> standalone build of SeaBIOS but it happens when you try building a >> coreboot together with SeaBIOS. Steps to reproduce: > > > Please attach your patch, so that it can easily applied and the build > problem reproduced. > > […] > > > Kind regards, > > Paul

2 years, 5 months

Re: [coreboot] OpenBMC & KGPE-D16

by Piotr Kubaj

Strange, I didn't apply any patches. I run D16 with stock coreboot 4.7 and OpenBMC. Could it be because I have different memory modules (4xKVR16R11D4/16)? On 18-02-24 12:00:01, coreboot-request(a)coreboot.org wrote: >Send coreboot mailing list submissions to > coreboot(a)coreboot.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://mail.coreboot.org/mailman/listinfo/coreboot >or, via email, send a message with subject or body 'help' to > coreboot-request(a)coreboot.org > >You can reach the person managing the list at > coreboot-owner(a)coreboot.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of coreboot digest..." > > >Today's Topics: > > 1. Re: OpenBMC & KGPE-D16 (Elisenda Cuadros) > 2. Re: OpenBMC & KGPE-D16 (Timothy Pearson) > 3. Re: OpenBMC & KGPE-D16 (Elisenda Cuadros) > 4. Re: OpenBMC & KGPE-D16 (Timothy Pearson) > 5. Re: OpenBMC & KGPE-D16 (Elisenda Cuadros) > 6. make gitconfig not working for me with git 1.9.1 > (mturney(a)codeaurora.org) > 7. Re: OpenBMC & KGPE-D16 (Elisenda Cuadros) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 23 Feb 2018 23:38:42 +0100 >From: Elisenda Cuadros <lists(a)e4L.es> >To: Timothy Pearson <tpearson(a)raptorengineering.com>, Coreboot > <coreboot(a)coreboot.org> >Subject: Re: [coreboot] OpenBMC & KGPE-D16 >Message-ID: <024a1ee2-7edc-be52-f87d-3bfbf95aa90f(a)e4L.es> >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >Hello, > >Thank you for your reply. > >I reflashed (same build) the BMC module with a hotplug. Now it works >like a charm, it got an ip, I can log through ssh, reboot, etc.. > >But now I have a new problem. If I try to boot from a halted system, >with BMC module attached, the system fires up but Coreboot hangs: > >Unable to detect valid memory on any nodes.? Halting! >mct_d: fatalexit > >If I remove the BMC module the system boots fine. > >I have 4 Micron MT18JSF25672PDZ-1G4F1DD modules, located in CPU1 orange >slots. > >I attach both console logs. > >Regards, > >- Eli > > > >On 22/02/18 22:36, Timothy Pearson wrote: >> Actually, for OpenBMC work, hotplugging is often the only way to go. >> Just be very careful to align the pins correctly the first time; you >> don't have a second chance if you misalign the pins and fry the module... >> >> On 02/22/2018 03:22 PM, Taiidan(a)gmx.com wrote: >>> On 02/17/2018 09:46 AM, Elisenda Cuadros wrote: >>> >>>> Hi, >>>> >>>> Now I trying to use your OpenBMC port. >>>> >>>> I followed the instructions and everything was fine (compiling, >>>> reading and flashing). I waited several minutes after flashing, but >>>> the module didn 't blinked like in the vendor rom, nor did it receive >>>> an ip. >>>> >>>> I halted the system because I thought maybe it needs a cold start. >>>> >>>> After this, the system doesn't boot with the module plugged in. The >>>> fans begin to spin for approximately 1/4 second, but nothing else. >>>> >>>> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed (~1000rpm) >>>> >>>> In the case I have to reflash the module, is it possible to hotplug it? >>> Hotplugging is dangerous and not supported, don't do it. >>>> Thank you very much for your support. >>> You can use a test clip to externally flash it via a flashing device >>> (not sure which can do 16 pins though, I would inquire on the flashrom >>> mailinglist) >>> >>> Are you using the latest coreboot? AFAIK coreboot was patched to support >>> OpenBMC, so you need a new version with the patches. >

2 years, 5 months

make gitconfig not working for me with git 1.9.1

by mturney＠codeaurora.org

Errors I receive on command-line strongly point to this commit: commit fda071ca7a17614a58c0812c28b14a417471b915 Author: Alex Thiessen <alex.thiessen.de+coreboot(a)gmail.com> Date: Sat Jan 13 17:05:31 2018 +0000 util/gitconfig: Make gitconfig.sh support gitfile Ubuntu host, 14.04 mturney@mturney-linux:/local/mnt/workspace/mturney/gitrepos/public/coreboot$ make gitconfig fatal: ambiguous argument 'hooks': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' mkdir: unrecognized option '--git-path hooks' Try 'mkdir --help' for more information. util/gitconfig/gitconfig.sh: line 33: --git-path hooks/commit-msg: No such file or directory chmod: unrecognized option '--git-path hooks/commit-msg' Try 'chmod --help' for more information. util/gitconfig/gitconfig.sh: line 33: --git-path hooks/pre-commit: No such file or directory chmod: unrecognized option '--git-path hooks/pre-commit' Try 'chmod --help' for more information. fatal: ambiguous argument 'hooks': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' fatal: ambiguous argument 'hooks': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' fatal: ambiguous argument 'hooks': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' mturney@mturney-linux:/local/mnt/workspace/mturney/gitrepos/public/coreboot$

2 years, 5 months

Re: [coreboot] OpenBMC & KGPE-D16

by Mike Banon

> Any particular reason those patches were not upstreamed? Because a person who submitted these patches did not fix some problems, if you scroll down to comments at https://review.coreboot.org/#/c/coreboot/+/19820/ Paul Menzel May 23, 2017 Patch Set 1: (2 comments) src/mainboard/asus/kgpe-d16/romstage.c Line 96: Add macro or set `dev = PCI_DEV(0, 0x14, 4)`? Line 118: Line length? Arthur Heymans May 23, 2017 Patch Set 1: (5 comments) Change looks good, just pci_def.h macros that could be used a bit more. src/mainboard/asus/kgpe-d16/romstage.c Line 93: Use macros? Line 101: #define TEMP_PCI_BUS 0x1 Line 101: PCI_SECUNDARY_BUS Line 102: PCI_SUBORDINATE_BUS Line 103: PCI_BASE_ADDRESS_4 On Sun, Feb 25, 2018 at 6:01 AM, Thierry Laurion <thierry.laurion(a)gmail.com> wrote: > Any particular reason those patches were not upstreamed? > > > Le ven. 23 févr. 2018 21:40, Thierry Laurion <thierry.laurion(a)gmail.com> a > écrit : >> >> Timothys patches were mot included un coreboot >> https://review.coreboot.org/#/c/coreboot/+/19822/ >> >> Le ven. 23 févr. 2018 17:40, Elisenda Cuadros <lists(a)e4l.es> a écrit : >>> >>> Hello, >>> >>> Thank you for your reply. >>> >>> I reflashed (same build) the BMC module with a hotplug. Now it works >>> like a charm, it got an ip, I can log through ssh, reboot, etc.. >>> >>> But now I have a new problem. If I try to boot from a halted system, >>> with BMC module attached, the system fires up but Coreboot hangs: >>> >>> Unable to detect valid memory on any nodes. Halting! >>> mct_d: fatalexit >>> >>> If I remove the BMC module the system boots fine. >>> >>> I have 4 Micron MT18JSF25672PDZ-1G4F1DD modules, located in CPU1 orange >>> slots. >>> >>> I attach both console logs. >>> >>> Regards, >>> >>> - Eli >>> >>> >>> >>> On 22/02/18 22:36, Timothy Pearson wrote: >>> > Actually, for OpenBMC work, hotplugging is often the only way to go. >>> > Just be very careful to align the pins correctly the first time; you >>> > don't have a second chance if you misalign the pins and fry the >>> > module... >>> > >>> > On 02/22/2018 03:22 PM, Taiidan(a)gmx.com wrote: >>> >> On 02/17/2018 09:46 AM, Elisenda Cuadros wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> Now I trying to use your OpenBMC port. >>> >>> >>> >>> I followed the instructions and everything was fine (compiling, >>> >>> reading and flashing). I waited several minutes after flashing, but >>> >>> the module didn 't blinked like in the vendor rom, nor did it receive >>> >>> an ip. >>> >>> >>> >>> I halted the system because I thought maybe it needs a cold start. >>> >>> >>> >>> After this, the system doesn't boot with the module plugged in. The >>> >>> fans begin to spin for approximately 1/4 second, but nothing else. >>> >>> >>> >>> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed >>> >>> (~1000rpm) >>> >>> >>> >>> In the case I have to reflash the module, is it possible to hotplug >>> >>> it? >>> >> Hotplugging is dangerous and not supported, don't do it. >>> >>> Thank you very much for your support. >>> >> You can use a test clip to externally flash it via a flashing device >>> >> (not sure which can do 16 pins though, I would inquire on the flashrom >>> >> mailinglist) >>> >> >>> >> Are you using the latest coreboot? AFAIK coreboot was patched to >>> >> support >>> >> OpenBMC, so you need a new version with the patches. >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

2 years, 5 months

Re: [coreboot] OpenBMC & KGPE-D16

by Thierry Laurion

Any particular reason those patches were not upstreamed? Le ven. 23 févr. 2018 21:40, Thierry Laurion <thierry.laurion(a)gmail.com> a écrit : > Timothys patches were mot included un coreboot > https://review.coreboot.org/#/c/coreboot/+/19822/ > > Le ven. 23 févr. 2018 17:40, Elisenda Cuadros <lists(a)e4l.es> a écrit : > >> Hello, >> >> Thank you for your reply. >> >> I reflashed (same build) the BMC module with a hotplug. Now it works >> like a charm, it got an ip, I can log through ssh, reboot, etc.. >> >> But now I have a new problem. If I try to boot from a halted system, >> with BMC module attached, the system fires up but Coreboot hangs: >> >> Unable to detect valid memory on any nodes. Halting! >> mct_d: fatalexit >> >> If I remove the BMC module the system boots fine. >> >> I have 4 Micron MT18JSF25672PDZ-1G4F1DD modules, located in CPU1 orange >> slots. >> >> I attach both console logs. >> >> Regards, >> >> - Eli >> >> >> >> On 22/02/18 22:36, Timothy Pearson wrote: >> > Actually, for OpenBMC work, hotplugging is often the only way to go. >> > Just be very careful to align the pins correctly the first time; you >> > don't have a second chance if you misalign the pins and fry the >> module... >> > >> > On 02/22/2018 03:22 PM, Taiidan(a)gmx.com wrote: >> >> On 02/17/2018 09:46 AM, Elisenda Cuadros wrote: >> >> >> >>> Hi, >> >>> >> >>> Now I trying to use your OpenBMC port. >> >>> >> >>> I followed the instructions and everything was fine (compiling, >> >>> reading and flashing). I waited several minutes after flashing, but >> >>> the module didn 't blinked like in the vendor rom, nor did it receive >> >>> an ip. >> >>> >> >>> I halted the system because I thought maybe it needs a cold start. >> >>> >> >>> After this, the system doesn't boot with the module plugged in. The >> >>> fans begin to spin for approximately 1/4 second, but nothing else. >> >>> >> >>> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed >> (~1000rpm) >> >>> >> >>> In the case I have to reflash the module, is it possible to hotplug >> it? >> >> Hotplugging is dangerous and not supported, don't do it. >> >>> Thank you very much for your support. >> >> You can use a test clip to externally flash it via a flashing device >> >> (not sure which can do 16 pins though, I would inquire on the flashrom >> >> mailinglist) >> >> >> >> Are you using the latest coreboot? AFAIK coreboot was patched to >> support >> >> OpenBMC, so you need a new version with the patches. >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > >

2 years, 5 months

Mysterious "is VARVERIFY32INIT but used from" problem while trying to improve SeaBIOS

by Mike Banon

Friends, I need your help. While trying to improve SeaBIOS I got stuck at this very strange problem - which does not appear when you do a standalone build of SeaBIOS but it happens when you try building a coreboot together with SeaBIOS. Steps to reproduce: add this innocent looking function to the beginning of ./coreboot/payloads/external/SeaBIOS/seabios/src/fw/coreboot.c : int // doesn't matter if static or not testfunc(void) { int *c = malloc_tmp(sizeof(int)); // doesn't matter if _tmp or _tmphigh // free(c); // <--- commented out because doesn't affect the results return 0; } and try calling it from "cbfs_copyfile" function of the same file: static int cbfs_copyfile(struct romfile_s *file, void *dst, u32 maxlen) { ... void *temp = malloc_tmphigh(size); ... int ret = ulzma(dst, maxlen, temp, size); testfunc(); // <--- added ... } Then I get this problem while building a coreboot with together SeaBIOS : ... Compiling whole program out/code32seg.o Compiling whole program out/ccode16.o Compiling to assembler out/src/asm-offsets.s Generating offset file out/asm-offsets.h Compiling (16bit) out/romlayout.o Building ld scripts ERROR: .data.varinit.. is VARVERIFY32INIT but used from ['.text.runtime..', '.text.do_boot', '.text.malloc_tmp'] Makefile:162: recipe for target 'out/romlayout16.lds' failed make[2]: *** [out/romlayout16.lds] Error 1 Makefile:80: recipe for target 'build' failed make[1]: *** [build] Error 2 payloads/external/Makefile.inc:73: recipe for target 'payloads/external/SeaBIOS/seabios/out/bios.bin.elf' failed make: *** [payloads/external/SeaBIOS/seabios/out/bios.bin.elf] Error 2 However, if I try adding this function to the end of "coreboot_cbfs_init" function I don't get such an error: void coreboot_cbfs_init(void) { ... process_links_file(); testfunc(); // <--- works OK there } What is a difference between "cbfs_copyfile" and "coreboot_cbfs_init" that affects this behaviour? And why it is OK to call "malloc_" from inside the "cbfs_copyfile" function --- void *temp = malloc_tmphigh(size); --- but we couldn't call there our testfunc() which calls "malloc_" without running into this problem? Best regards, Mike Banon

2 years, 5 months

Re: [coreboot] OpenBMC & KGPE-D16

by Elisenda Cuadros

Hello, Thank you for your reply. I reflashed (same build) the BMC module with a hotplug. Now it works like a charm, it got an ip, I can log through ssh, reboot, etc.. But now I have a new problem. If I try to boot from a halted system, with BMC module attached, the system fires up but Coreboot hangs: Unable to detect valid memory on any nodes. Halting! mct_d: fatalexit If I remove the BMC module the system boots fine. I have 4 Micron MT18JSF25672PDZ-1G4F1DD modules, located in CPU1 orange slots. I attach both console logs. Regards, - Eli On 22/02/18 22:36, Timothy Pearson wrote: > Actually, for OpenBMC work, hotplugging is often the only way to go. > Just be very careful to align the pins correctly the first time; you > don't have a second chance if you misalign the pins and fry the module... > > On 02/22/2018 03:22 PM, Taiidan(a)gmx.com wrote: >> On 02/17/2018 09:46 AM, Elisenda Cuadros wrote: >> >>> Hi, >>> >>> Now I trying to use your OpenBMC port. >>> >>> I followed the instructions and everything was fine (compiling, >>> reading and flashing). I waited several minutes after flashing, but >>> the module didn 't blinked like in the vendor rom, nor did it receive >>> an ip. >>> >>> I halted the system because I thought maybe it needs a cold start. >>> >>> After this, the system doesn't boot with the module plugged in. The >>> fans begin to spin for approximately 1/4 second, but nothing else. >>> >>> My two fans (1 cpu & 1 chassis) have 3 pins and are low speed (~1000rpm) >>> >>> In the case I have to reflash the module, is it possible to hotplug it? >> Hotplugging is dangerous and not supported, don't do it. >>> Thank you very much for your support. >> You can use a test clip to externally flash it via a flashing device >> (not sure which can do 16 pins though, I would inquire on the flashrom >> mailinglist) >> >> Are you using the latest coreboot? AFAIK coreboot was patched to support >> OpenBMC, so you need a new version with the patches.

2 years, 5 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2018