coreboot March 2016

coreboot@coreboot.org

43 participants
117 discussions

Re: [coreboot] Multiple payloads support?
by ron minnich 21 Mar '16

21 Mar '16

Neat! On Sun, Mar 20, 2016, 8:07 PM Nick <nochristrequired(a)gmail.com> wrote: > 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 >>> >> >> >

1 0

Re: [coreboot] Multiple payloads support?
by Nick 21 Mar '16

21 Mar '16

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 >> > >

1 0

Re: [coreboot] Multiple payloads support?
by Nick 21 Mar '16

21 Mar '16

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 >

1 0

Re: [coreboot] Multiple payloads support?
by Zheng Bao 21 Mar '16

21 Mar '16

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

2 1

Multiple payloads support?
by Zheng Bao 20 Mar '16

20 Mar '16

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

2 1

Re: [coreboot] Good source for SOIC clips
by Felix Held 19 Mar '16

19 Mar '16

> There are a number of chinese websites offering cheap SOIC clips, the > most widely known is probably Alibaba/Aliexpress: > http://www.aliexpress.com/wholesale?catId=0&initiative_id=&SearchText=SOIC+… > > These are certainly much cheaper than the expensive ones available in > the "west" - though I don't know if the quality is adequate. > Should you order some it would probably be interesting to give > feedback on that. With those cheap SOIC clips with wires you might need to replace or at least make the wires shorter to be able to read and write the flash chips reliably. I use some of the cheap SOIC8 clips and they work quite well with better and shorter wires. Regards Felix

1 0

Good source for SOIC clips
by Elena ``of Valhalla'' 19 Mar '16

19 Mar '16

Hello at FOSDEM this year I stopped at the Coreboot stand and I mentioned that I was having problems finding a 16 pin SOIC clip to flash coreboot on my thinkpad x200. The person at the stand said that somebody in the project knows a chinese website which sells those clips at a significantly lower price than the usual ones, and that this information could be shared someway on the website / mailing list. Does anybody know which website is that? Thanks in advance -- Elena ``of Valhalla''

3 2

Re: [coreboot] [GSoC 2016] ROM-O-Matic project
by Denis 'GNUtoo' Carikli 19 Mar '16

19 Mar '16

On Thu, 17 Mar 2016 15:56:13 -0600 Martin Roth <gaumless(a)gmail.com> wrote: > As the project proposal says, first we want to just build roms that > are already present in the board status database. We have a config > already present for these, so we don't need to ask any configuration > options at all, just give them a list of boards that they can build a > rom for. We also don't need to give users every option available in > Kconfig. Maybe we give them an edit window that they can paste a > config into or edit an existing config. I would see ROM-O-Matic for coreboot working this way: The users would have a list of boards, and could then select the given known-good configuration that they want. The configuration would list the hardware variations used in the test, such as RAM, CPU when relevant[3]. - It would also warn the user when additional binaries have to be added to cbfs[1]. The user would then need to keep that in mind when consulting the installation documentation. - It would warn against or filter out configurations with unknown payloads, or payloads with unknown revisions. - It would warn against or filter out boards and configurations not in board-status. Then an image would be produced, but also its hash and signature. The website would also use https (everywhere). Along with the image (and its hash and signature), some information would appear: - A big warning if some are lacking in cbfs[2]. - If the files matches, but the hash differ from the one in board-status[4], then a big warning will appear too. - A link to the relevant documentation explaining how to install/flash this image for the given board. I'm undecided on the idea of permitting users to do dangerous things, such as editing the configuration, building for master revisions of payloads, building for untested boards: - One one hand, it would permit users to test that configuration, and then to upload the result on board-status more easily. - On the other hand, we might rather want the given configuration to be uploaded on board-status first. This would be to reduce bricking probabilities. - Another option would be to have both. In that case, we might want to very strongly warn the user if they want to have their own configuration built. References: ----------- [1]Part the necessary binaries can be deduced from coreboot's .config. [2]That can be deduced from board-status: it has the list of CBFS files. [3]This would have to be deduced from the logs. It's not trivial, so maybe there is some better way. Doing it at board-status log submission time is probably a better idea. Its scripts would have to be modified for that. [4]board-status scripts will need to be modified to add such feature. Coreboot build scripts will also need to be modified to make sure that builds are reproducible. In coreboot, util/genbuild_h/genbuild_h.sh still leaks some non-reproducible information. Fixing it would also be needed to give users proper feedback. Denis.

1 0

Re: [coreboot] [Xen-users] Enabling AMD-Vi IOMMU panics Xen
by 小太 19 Mar '16

19 Mar '16

On Sat, Mar 19, 2016 at 7:14 PM, Zir Blazer <zir_blazer(a)hotmail.com> wrote: > Fix: Added xen-users as CC. > > ________________________________ > > From: nospam(a)kota.moe > > To: xen-users(a)lists.xen.org > > Date: Sat, 19 Mar 2016 07:30:40 +0000 > > Subject: [Xen-users] Enabling AMD-Vi IOMMU panics Xen > > > > Note that the board "by default" doesn't support IOMMU, but since it > > runs coreboot, I compiled in some code that initialises the IOMMU (so > > if this bug seems to be caused by the BIOS, hopefully it can be fixed > > fairly quickly). > > > > Using that command line, the IOMMU does not get enabled due to some > > problems with the IVRS table (which seems to be generated by AMD's > > closed-source AGESA), which you can see in "apic_verbosity=debug.log" > > (attached). > > My answer will not really be very useful, but at least it may save you > some time... > > If there are issues with the ACPI IVRS Table, the issues are Firmware > side. I suppose that you could try contacting Coreboot developers and > asking them if they can give you a hand fixing it for a AMD Jaguar platform. > Curiously, cpuid reports the CPU as family 22 (16h) and model 48 (30h), making it a Puma (Mullins) chip. > > I don't specifically recall if Xen could, but the Linux Kernel itself > could workaround a broken ACPI IVRS Table since you had a Boot Loader > parameter that you could set to override the broken values of it with your > own provided values, check here: > > https://bbs.archlinux.org/viewtopic.php?id=163102 > > Basically, for the Linux Kernel, you could use something like iommu=1 > ivrs_ioapic[6]=00:14.0 as boot parameter or so and get a working IOMMU with > a broken BIOS ACPI IVRS Table. However, this only works if you were going > to use the IOMMU for QEMU-KVM-VFIO Passthrough, not Xen, but I think it > could also do something similar to that. The problem is that I don't know > what the Xen parameters are (If they exist), or how you are supposed to get > the correct values to get it working. > If it is not possible to do something like that in Xen, your only choice > is fix it Firmware-side. > To partially answer your question, Xen indeed has the ivrs_ioapic and ivrs_hpet params too: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/drivers/passthrough/a… That said, I have no idea how to find the device IDs for the IOAPICs. According to https://github.com/torvalds/linux/commit/c2ff5cf5294bcbd7fa50f7d860e90a66db… (and http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=06bbcaf48d09c18a41c4828… for Xen), the southboard IOAPIC is always at 00:14.0 (I'm also curious of where this information was sourced from - it doesn't seem to be in either the IOMMU spec or BKDG), though I don't know whether it's IOAPIC #4 or #5. According to http://ubuntuforums.org/showthread.php?t=2254677, their (presumably northbridge) IOAPIC was at 00:00.1, though they don't mention how they determined that either. 00:00.1 doesn't show up under a lspci either, so I'm unsure if I have that on my board, though AMD's IOMMU spec ( http://support.amd.com/TechDocs/48882_IOMMU.pdf page 260) claims they aren't normally enumerable. The lspci output on the board is as follows: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1566] 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device [1022:1567] 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:156b] 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1 [1022:1439] 00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1 [1022:1439] 00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 16h Processor Functions 5:1 [1022:1439] 00:08.0 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Device [1022:1537] 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7814] (rev 11) 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [IDE mode] [1022:7800] (rev 40) 00:13.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller [1022:7808] (rev 39) 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] (rev 42) Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:780b] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:780e] (rev 11) 00:14.7 SD Host controller [0805]: Advanced Micro Devices, Inc. [AMD] FCH SD Flash Controller [1022:7813] (rev 01) 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1580] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1581] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1582] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1583] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1584] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1585] 01:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:157b] (rev 03) 02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:157b] (rev 03) 03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:157b] (rev 03) If 00:14.0 is indeed one of the IOAPIC devices, I'm also curious on how it relates to SMBus. I'm CC'ing coreboot and also Joerg Roedel, the author of the linux commit, to see if they can help out. If we work out a process to properly identify the IOAPIC number to device ID mappings, I'll try to properly document it somewhere and make patches for Xen/coreboot/linux to use it.

1 0

Porting coreboot to the Asus P5G41T-M LX motherboard
by Renze Nicolai 18 Mar '16

18 Mar '16

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/maste 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

1 0

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2016