March 2016 - coreboot - mail.coreboot.org

Re: [coreboot] Upstream coreboot on Broadwell/samus
by Patrick Georgi March 23, 2016

March 23, 2016

2016-03-22 9:35 GMT+01:00 Huimin Zhang <thehobn(a)gmail.com>: > I was under the impression that coreboot support for the Broadwell > Chromebooks such as the new Chromebook Pixel was upstreamed but I am having > trouble getting it to work. Everything should be upstreamed, yes. However there isn't any automated testing for upstream on Chromebook devices at this time, so things may break down the road. > unintentional error can be ruled out. Perhaps I am missing some small detail > regarding the build settings specific to Broadwell? It's hard to say what exactly goes wrong with your setup. I can test (since I have a samus with servo header around), but in general, the first requirement to debug coreboot issues is to grab its console somehow. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

VT-d on samus proposal draft
by Huimin Zhang March 23, 2016

March 23, 2016

I have my first draft for my GSoC proposal ready. I am quite anxious for a bit of feedback, as I have yet to receive any so far. The link is below. https://docs.google.com/document/d/1R3FCSGfsmwYGU1WmeiGjafrArWN-H9n7IzBtCtM… Best, Min

1 0

[GSoC] Good RISC-V support — Questions
by Jonathan Neuschäfer March 22, 2016

March 22, 2016

Hello, I'm Jonathan Neuschäfer, a student from Aachen, Germany, and I'm interested in participating in coreboot's GSoC. I have some questions about the "coreboot on the open source Berkeley RISC V processor"[1] project: - The project page says an FPGA board with a RISC-V soft-core can be provided to the student. Does this board (or rather: the programmed HDL code) rely on the Host-Target Interface (HTIF)? In the long run, we should (also) target "untethered"[2] boards, IMHO, simply because they run without the help of another computer. - Does the board (and the HDL code) have a memory-mapped SPI flash? I saw that the untethered lowRISC only has a 64kB boot ROM and an SD card slot[3], which would require some form of early block device support, as outlined in [4] (although a simple SD driver shouldn't be a terrible amount of code). - Does the board have a RAM controller that needs to be trained? - Does the board have removable RAM? How is its presence and size detected? - Does the board have a 32- or 64-bit core? Cheers, Jonathan [1]: https://www.coreboot.org/Project_Ideas#coreboot_on_the_open_source_Berkeley… [2]: http://www.lowrisc.org/docs/untether-v0.2/ [3]: http://www.lowrisc.org/docs/untether-v0.2/bootload/ [4]: https://www.coreboot.org/Project_Ideas#Infrastructure_for_accessing_block_d…

1 0

New on blogs.coreboot.org: coreboot changelog March 2 - March 15
by WordPress March 22, 2016

March 22, 2016

1 0

Upstream coreboot on Broadwell/samus
by Huimin Zhang March 22, 2016

March 22, 2016

Hey all, I was under the impression that coreboot support for the Broadwell Chromebooks such as the new Chromebook Pixel was upstreamed but I am having trouble getting it to work. On startup the lightbar and keyboard backlight activate, but not the screen backlight. After about forty seconds, give or take a second or two, it shuts off. I initially guessed that this was an ME issue since I read that there is a killswitch if ME is missing but apparently that killswitch acts more in the half hour range, and after my second attempt I am sure it is not an ME issue. Regarding the lack of screen backlight, I am inclined to think that it is not a VGA BIOS issue but some error occurring before graphics are ever initialized. I followed the instructions here: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-de… I assume the process is not so different for Broadwell. Of course I remembered to ad-lib the board name and quadruple check that the binaries I extracted from the recovery image were not corrupted. On my first attempt a few months ago I followed the instructions more or less exactly, but on this second attempt I kept the VGA BIOS as 0406 instead of 0a06 and used the new make options for including the descriptor and ME during the build instead of adding it in after the build. I think at this point any chance of an unintentional error can be ruled out. Perhaps I am missing some small detail regarding the build settings specific to Broadwell? Best, Min

1 0

Re: [coreboot] Multiple payloads support?
by Zheng Bao March 21, 2016

March 21, 2016

After a re-test, the coreboot table is back. Maybe my fault, but I don't know what it is. Hope it will not come up again. Zheng From: gaumless(a)gmail.com Date: Mon, 21 Mar 2016 12:24:56 -0600 To: fishbaoz(a)hotmail.com Subject: Re: [coreboot] Multiple payloads support? CC: rminnich(a)gmail.com; nochristrequired(a)gmail.com; stefan.reinauer(a)coreboot.org; coreboot(a)coreboot.org The coreinfo as secondary payload should work under SeaBIOS. if it's having problems, let me know and I'll try to get any issues fixed. I did just test it under qemu, and it booted into coreinfo correctly when it didn't find another payload. Martin On Mon, Mar 21, 2016 at 1:36 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: is CONFIG_COREINFO_SECONDARY_PAYLOAD supposed to work? I tried to add this option in kconfig, but the coreboot table is flushed. I tried to fix it. But it seems to be hard. Anyone got idea? Or I have to work really hard to fix it? :( Zheng Date: Sun, 20 Mar 2016 20:07:34 -0700 From: nochristrequired(a)gmail.com To: rminnich(a)gmail.com Subject: Re: [coreboot] Multiple payloads support? CC: coreboot(a)coreboot.org; stefan.reinauer(a)coreboot.org; fishbaoz(a)hotmail.com I should have been more clear - first build your image using the coreboot build system and specify SeaBIOS as your payload. Then compile coreinfo. Last, include coreinfo in your image using the command I provided in the previous e-mail. Coreinfo will now show up as a boot option under SeaBIOS. This is how I do it - no need to mess with bayou. Works with memtest and other elf binaries as well. Good luck! On Sun, Mar 20, 2016 at 7:59 PM, Nick <nochristrequired(a)gmail.com> wrote: Bayou is not necessary - use SeaBIOS to run coreinfo. ./build/cbfstool ./build/coreboot.rom add-payload -f /gitrepo/coreboot/payloads/coreinfo/build/coreinfo.elf -n img/coreinfo.elf -t payload On Sun, Mar 20, 2016 at 7:02 PM, ron minnich <rminnich(a)gmail.com> wrote: it's a bit of work but I got it to build two years ago. ron On Sun, Mar 20, 2016 at 6:56 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote: But Bayou seems to be dead. It can not be built. The definition like "struct LAR" goes nowhere. Zheng From: rminnich(a)gmail.com Date: Sun, 20 Mar 2016 21:17:24 +0000 To: fishbaoz(a)hotmail.com; coreboot(a)coreboot.org; stefan.reinauer(a)coreboot.org Subject: Re: [coreboot] Multiple payloads support? It was done about 10 years ago and it was called bayou. Take a look in the libpayload side. On Sat, Mar 19, 2016 at 11:30 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote: Hi, all, I am trying to integrate SeaBIOS and another payload(coreinfo, nvramcui) into final image. After a quick code checking, current code in repo does not support multiple payload, does it? I want to let Coreboot load and run nvramcui first. The user can decide to change the CMOS setting or not. If user want to save the setting, the system need to reboot. If user wants to give up the change, the system goes out of the nvramcui and goes into SeaBIOS. Just like other IBV's BIOS. Did anyone do this job before? Any suggestion? Zheng -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Porting coreboot to the Asus P5G41T-M LX motherboard
by Renze Nicolai March 21, 2016

March 21, 2016

Hi Martin, I added back that function and tried changing / adding some other stuff and guess what? Serial console works! Thank you for pointing in the right direction. Now the next problem: this motherboard uses an Intel X4X northbridge with DDR3 RAM. This is the serial console output: ======================================================================= Setting up RAM controller. Dimms per channel: 1 2 CPU cores Capable of DDR2 of 667 MHz or lower fefffac0: 92 10 0b 02 02 11 00 09 03 52 01 08 0c 00 3c 00 .........R....<. fefffad0: 69 78 69 30 69 11 20 89 70 03 3c 3c 00 f0 83 01 ixi0i. .p.<<.... fefffae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fefffaf0: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 01 01 ................ fefffd48: 92 10 0b 02 02 11 00 09 03 52 01 08 0c 00 3c 00 .........R....<. fefffd58: 69 78 69 30 69 11 20 89 70 03 3c 3c 00 f0 83 01 ixi0i. .p.<<.... fefffd68: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fefffd78: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 01 01 ................ 16DS not supported ======================================================================= https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/blob/maste r/serial_log The code for the Intel X4X northbridge has this not-so-nice line in it: "// FIXME Add: raminit_ddr3(&s);" which does not suggest anything good... Should I start a new thread about DDR3 support for the Intel G41 northbridge? Greetings, Renze On Mon, 2016-03-21 at 14:48 -0600, Martin Roth wrote: > Ok, looking at the differences between your code ant the GA-G41M > code, I think you might want to add back in the ich7_enable_lpc() > function (or something equivalent) . My guess is that you're not > sending the necessary IO ports out to LPC. > > Martin > > On Mon, Mar 21, 2016 at 2:25 PM, Renze Nicolai <renze(a)rnplus.nl> > wrote: > > Hi Martin, > > > > Autoport wasn't much use to me since it didn't recognize anything. > > However it left behind all kinds of logs like the full lspci output > > and > > stuff like that -> that's why I shared it. > > > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/blob/m > > aste > > r/superiodump > > > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/blob/m > > aste > > r/superioextradump > > > > This is the output of superiotool using the OEM BIOS. > > > > The SIO is configured for 0x2E. > > > > Greetings, > > Renze > > > > On Mon, 2016-03-21 at 13:47 -0600, Martin Roth wrote: > > > Hi Renze, > > > I haven't used Autoport, so I can't help much with that - > > looking > > > at the output, I'm not sure this chipset is supported. > > > > > > On the console: > > > Have you run superiotool on your platform with the OEM BIOS? Can > > we > > > get the output from that? Is your SIO configured for IO address > > 0x2E > > > or 0x4E? > > > > > > The hang looks unrelated to the console - It looks like you're > > > failing in memory configuration, so I'd keep adding post codes to > > see > > > if you can track down where the actual failure is. This will > > > probably become plain once you get the console working though. > > > > > > Martin > > > > > > > > > On Fri, Mar 18, 2016 at 4:45 PM, Renze Nicolai <renze(a)rnplus.nl> > > > wrote: > > > > Hello everyone, > > > > > > > > I am trying to port coreboot to the Asus P5G41T-M LX > > motherboard > > > > but I > > > > got stuck. > > > > > > > > This motherboard has: > > > > - Northbridge: Intel G41 > > > > - Southbridge: ICH7 > > > > - Super IO: w83627dhg > > > > > > > > I used the Gigabye GA-G41M-ES2L code as base since I think it > > has > > > > the > > > > same north- and southbridge. That motherboard has a different > > Super > > > > IO > > > > chip though. > > > > > > > > I tried to make the devicetree.cb file valid and I replaced the > > > > superio > > > > code in romstage.c with code for the superIO chip on my board. > > I > > > > also > > > > tried to set the correct values in the init code for the > > superio > > > > chip > > > > (irq routing etc). > > > > > > > > In romstage.c I added some post codes. The motherboard gets to > > > > postcode > > > > 0xA6 and then stops. > > > > > > > > Serial output is not working (cable / connection has been > > tested > > > > from > > > > within Linux). Terminal is connected at 115200 baud. No data is > > > > received. > > > > > > > > What I have so far: > > > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx > > > > > > > > Logs / info about the board (generated by autoport): > > > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/tr > > ee/m > > > > aste > > > > r/autoport_logs > > > > > > > > > > > > It would be nice if someone could point me in the right > > direction > > > > as to > > > > what to do next. > > > > > > > > Thank you! > > > > > > > > Greetings, > > > > Renze Nicolai > > > > > > > > -- > > > > coreboot mailing list: coreboot(a)coreboot.org > > > > https://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Porting coreboot to the Asus P5G41T-M LX motherboard
by Renze Nicolai March 21, 2016

March 21, 2016

Hi Martin, Autoport wasn't much use to me since it didn't recognize anything. However it left behind all kinds of logs like the full lspci output and stuff like that -> that's why I shared it. https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/blob/maste r/superiodump https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/blob/maste r/superioextradump This is the output of superiotool using the OEM BIOS. The SIO is configured for 0x2E. Greetings, Renze On Mon, 2016-03-21 at 13:47 -0600, Martin Roth wrote: > Hi Renze, > I haven't used Autoport, so I can't help much with that - looking > at the output, I'm not sure this chipset is supported. > > On the console: > Have you run superiotool on your platform with the OEM BIOS? Can we > get the output from that? Is your SIO configured for IO address 0x2E > or 0x4E? > > The hang looks unrelated to the console - It looks like you're > failing in memory configuration, so I'd keep adding post codes to see > if you can track down where the actual failure is. This will > probably become plain once you get the console working though. > > Martin > > > On Fri, Mar 18, 2016 at 4:45 PM, Renze Nicolai <renze(a)rnplus.nl> > wrote: > > Hello everyone, > > > > I am trying to port coreboot to the Asus P5G41T-M LX motherboard > > but I > > got stuck. > > > > This motherboard has: > > - Northbridge: Intel G41 > > - Southbridge: ICH7 > > - Super IO: w83627dhg > > > > I used the Gigabye GA-G41M-ES2L code as base since I think it has > > the > > same north- and southbridge. That motherboard has a different Super > > IO > > chip though. > > > > I tried to make the devicetree.cb file valid and I replaced the > > superio > > code in romstage.c with code for the superIO chip on my board. I > > also > > tried to set the correct values in the init code for the superio > > chip > > (irq routing etc). > > > > In romstage.c I added some post codes. The motherboard gets to > > postcode > > 0xA6 and then stops. > > > > Serial output is not working (cable / connection has been tested > > from > > within Linux). Terminal is connected at 115200 baud. No data is > > received. > > > > What I have so far: > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx > > > > Logs / info about the board (generated by autoport): > > https://github.com/rnplus/test-coreboot-for-asus-p5g41t-m-lx/tree/m > > aste > > r/autoport_logs > > > > > > It would be nice if someone could point me in the right direction > > as to > > what to do next. > > > > Thank you! > > > > Greetings, > > Renze Nicolai > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Multiple payloads support?
by Zheng Bao March 21, 2016

March 21, 2016

is CONFIG_COREINFO_SECONDARY_PAYLOAD supposed to work? I tried to add this option in kconfig, but the coreboot table is flushed. I tried to fix it. But it seems to be hard. Anyone got idea? Or I have to work really hard to fix it? :( Zheng Date: Sun, 20 Mar 2016 20:07:34 -0700 From: nochristrequired(a)gmail.com To: rminnich(a)gmail.com Subject: Re: [coreboot] Multiple payloads support? CC: coreboot(a)coreboot.org; stefan.reinauer(a)coreboot.org; fishbaoz(a)hotmail.com I should have been more clear - first build your image using the coreboot build system and specify SeaBIOS as your payload. Then compile coreinfo. Last, include coreinfo in your image using the command I provided in the previous e-mail. Coreinfo will now show up as a boot option under SeaBIOS. This is how I do it - no need to mess with bayou. Works with memtest and other elf binaries as well. Good luck! On Sun, Mar 20, 2016 at 7:59 PM, Nick <nochristrequired(a)gmail.com> wrote: Bayou is not necessary - use SeaBIOS to run coreinfo. ./build/cbfstool ./build/coreboot.rom add-payload -f /gitrepo/coreboot/payloads/coreinfo/build/coreinfo.elf -n img/coreinfo.elf -t payload On Sun, Mar 20, 2016 at 7:02 PM, ron minnich <rminnich(a)gmail.com> wrote: it's a bit of work but I got it to build two years ago. ron On Sun, Mar 20, 2016 at 6:56 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote: But Bayou seems to be dead. It can not be built. The definition like "struct LAR" goes nowhere. Zheng From: rminnich(a)gmail.com Date: Sun, 20 Mar 2016 21:17:24 +0000 To: fishbaoz(a)hotmail.com; coreboot(a)coreboot.org; stefan.reinauer(a)coreboot.org Subject: Re: [coreboot] Multiple payloads support? It was done about 10 years ago and it was called bayou. Take a look in the libpayload side. On Sat, Mar 19, 2016 at 11:30 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote: Hi, all, I am trying to integrate SeaBIOS and another payload(coreinfo, nvramcui) into final image. After a quick code checking, current code in repo does not support multiple payload, does it? I want to let Coreboot load and run nvramcui first. The user can decide to change the CMOS setting or not. If user want to save the setting, the system need to reboot. If user wants to give up the change, the system goes out of the nvramcui and goes into SeaBIOS. Just like other IBV's BIOS. Did anyone do this job before? Any suggestion? Zheng -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

2 1

nvramcui: VGA console flashes if no serial console
by Zheng Bao March 21, 2016

March 21, 2016

Hi, all, I am trying to use the nvramcui. If the serial cable is plugged in, both the serial console and VGA console are stable. but if the serial cable is unplugged, the VGA console are flashing. The flashing part is the text inside the frame "Press F1 when done", i.e., the CMOS entries. Zheng

1 1