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
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
>
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 |
|| ||
"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
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.
>
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$
> 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
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
>
>
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
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.
