coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 09 Jan '18

09 Jan '18

Hello Hilbert, I looked into the Coreboot logs (SeaBIOS ones, you have posted recently). My comments with: <<=================================== _______ ress ESC for boot menu. Searching bootorder for: HALT Space available for UMB: c2000-ee800, f6940-f70d0 Returned 192512 bytes of ZoneHigh e820 map has 9 items: <<=========================== Sounds very correct: you have in total 8GB of physical DDR3, aren't you? 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000007efb0000 = 1 RAM 4: 000000007efb0000 - 0000000090000000 = 2 RESERVED 5: 00000000feb00000 - 00000000feb10000 = 2 RESERVED 6: 00000000feb80000 - 00000000fef00000 = 2 RESERVED 7: 00000000ff000000 - 0000000100000000 = 2 RESERVED 8: 0000000100000000 - 0000000280000000 = 1 RAM enter handle_19: NULL Booting from ROM... Booting from c000:0b91 enter handle_18: NULL Booting from ROM... Booting from c100:0b91 enter handle_18: NULL Booting from Floppy... Boot failed: could not read the boot disk enter handle_18: NULL Booting from Hard Disk... Boot failed: could not read the boot disk <<============================== This also sounds correct. enter handle_18: NULL No bootable device. Retrying in 60 seconds. Rebooting. In resume (status=0) In 32bit resume Attempting a hard reboot ACPI hard reset 1:cf9 (6) _______ I have no idea if yuo have there attached HDD/SSD drive? If you do, with GRUB2 + Linux (whatever Linux distro it is), it depends how the drive is configured? Either for UEFI (will NOT work), either for UEFI + MBR or MBR only - should work. You need to investigate what yuor attached drive is: cat, dog, or combination (UEFI, MBR, or MBR + UEFI)? Please, upgrade me with the info I requested (memory and drive)? Thank you, Zoran _______ On Fri, Jan 5, 2018 at 6:17 AM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi David, > > > > After trying to use SeaBIOS as payload, I got more information about reboot > issue as attached file. While U-Boot just reboots directly and Grub hangs, > the SeaBIOS’s dump complains “No bootable device” at the end. Do you think > is it the cause of reboot? Can I say my U-Boot and Grub versions are not > supporting BDX-DE? > > > > -Hilbert > > This e-mail and its attachment may contain information that is confidential > or privileged, and are solely for the use of the individual to whom this > e-mail is addressed. If you are not the intended recipient or have received > it accidentally, please immediately notify the sender by reply e-mail and > destroy all copies of this email and its attachment. Please be advised that > any unauthorized use, disclosure, distribution or copying of this email or > its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Interested in contributing
by Adit Mehta 09 Jan '18

09 Jan '18

Sir, I am Adit Mehta first year student of DA-IICT. I know basics of C and little more comfortable with php. If there is any possible way that I can contribute in Seriallce is a BIOS/Firmware debugging tool project I would be thankful. Thanking you in anticipation, Adit Mehta

1 0

Re: [coreboot] Can coreboot for KabyLake rvp11 work on Intel Sasby Island kit?
by Jay Talbott 08 Jan '18

08 Jan '18

Toan Le, Be careful using the public Kaby Lake FSP from github for SkyLake-U or KabyLake-U processors… my first attempt resulted in two different CRBs (one RVP7 and one RVP15) becoming boat anchors – even restoring the original BIOS made no difference, the boards were completely bricked and had to be sent back to Intel for new functional replacements. Ultimately, after working through the various issues I was having with the FSP via an IPS case for the past 6 weeks (and trying multiple interim FSP releases provided by the engineering team via VIP along the way), I finally got a working solution just this week. I have no idea if/when the latest version of the FSP that I am now using which actually works on the RVP7 and RVP15 will be publicly released. That’s completely up to Intel. Just speaking from personal experience… - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com <http://www.sysproconsulting.com/> From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Toan Le manh Sent: Friday, January 05, 2018 7:16 PM To: Naresh G. Solanki; coreboot Subject: Re: [coreboot] Can coreboot for KabyLake rvp11 work on Intel Sasby Island kit? Hi Naresh, Thanks a lot for your reply. Could you please advise which settings should be modified for sasby island? Thanks. 2018-01-06 2:33 GMT+07:00 Naresh G. Solanki <naresh.solanki.2011(a)gmail.com>: I guess you have coreboot working on rvp11. You may have to modify few settings based on sasby island. On Jan 4, 2018 7:58 AM, "Toan Le manh" <lemanhtoantb(a)gmail.com> wrote: Hi, I had a Intel Sasby Island kit, which has CPU family: SkyLake, model i7-6600U, Memory: LPDDR4. Do you think coreboot for Intel rvp11 (Kabylake U, LPDDR4) can work on that Sasby Island kit? Thanks & BRs, Toan Le -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

3 4

Re: [coreboot] 16 GPUs on one board
by Arthur Heymans 08 Jan '18

08 Jan '18

Hi What target are you on? Coreboot tries to locate all PCI BAR's below 4G in the PCI_MMIO region and above the lower DRAM limit (the rest of the DRAM is mapped above 4G). Typically a GPU takes around 256M but I guess that could be more nowadays. If that doesn't fit in the PCI MMIO region, it will have troubles and probably not boot. The real fix would be to have coreboot locate BAR's above 4G too. At least that is what I think is going on here... (sry for top posting it felt like the answer was better in one block) Adam Talbot <ajtalbot1(a)gmail.com> writes: > -Coreboot > I am totally off the deep end and don't know where else to turn for help/advice. I am trying to get 16 GPU's on one motherboard. Whenever I attach more then 3~5 GPU's to a single motherboard, it fails to post. To make matters worse, my post > code reader(s) don't seem to give me any good error codes. Or at least nothing I can go on. > > I am using PLX PEX8614 chips (PCIe 12X switch) to take 4 lanes and pass them to 8 GPU's, 1 lane per GPU. Bandwidth is not an issues as all my code runs native on the GPUs. Depending on the motherboard, I can get up to 5 GPU's to post. After > many hours of debugging, googling, and trouble shooting, I am out of ideas. > > At this point I have no clue. I think there is a hardware, and a BIOS component? Can you help me understand the post process and where the hang up is occurring? Do you think Coreboot will get around this hangup and, if so, can you advise a > motherboard for me to test with? > > Its been a long time sense I last compiled linuxbios. ;-) > > Thanks > -Adam Kind regards -- Arthur Heymans

2 1

coreboot community meeting January 5th, 2017 report
by Arthur Heymans 08 Jan '18

08 Jan '18

Dear coreboot community This is the report of yesterdays community meeting: General coreboot news & Discussion ================================== There is patch [1] up for review that implements LinuxBoot as payload. - Currently with u-root in the initrd, which is an userspace entirely written in go; - Currently only as a payload but in the future it could replace ramstage on some targets; - Currently its still WIP and doesn't work all that well with qemu targets; - It needs some Kconfig options for some simple example configurations; - In the future we also want to integrate the HEADS[2] userspace and possibly also an userspace featuring the petitboot kexec gui[3]; The 4.7 release is imminent and Martin will hopefully be able to finish up the releasenotes this weekend. The 4.6 release announced that after the 4.7 release platforms lacking the early cbmem feature will be removed from the master branch. Those platforms can then live in the 4.7 branch or be reintegrated when early cbmem support is implemented. The details about how and when this will happen have yet to be decided/discussed. Development =========== There was some discussion about how to move forward to use the new ACPI ASL 2.0 syntax, which is considered more readable. There previously was a discussion on this topic on the mailing list [4]. Currently it is possible with iasl to compile and decompile our ASL sources to the new syntax but this would lose all our comments, so ideally a new tool would need to be written to handle that transition. It was also suggested that given the fact that coreboot has reproducibel timeless builds, it would be able to tell if anything changed in the resulting binary, which it shouldn't since the resulting bytecode ought to be the same. In the mean time we still need to have a discussion about what do with for instance new asl source files: do we still want the old syntax or is the new syntax ok for new files? Mixing syntaxes in existing files seemed a bad idea. So what are your ideas and opinions on this? Infrastructure ============== The pre-commit hook doesn't return failures on 'make lint-stable' but this seems to be fixed in [5]. Documentation ============= Currently there is an effort going on to have the documentation accessible in one place on the web. The current idea was to use hugo for static webpage generation for this, see [6]. Some concerns were however raised that this particular theme works rather poorly without javascript, so it might be desirable to find a better lightweight theme. Related to this, is the ongoing effort to convert our current documentation to markdown and move those files to a different directory which starts with lowercase letter for consistency, with a separation of a content and a static folder. The idea to use netlify to push it to the production server was also suggested. (Philipp might be able to say something in more details about this) Flashrom 1.0 was released! This new release has some nice new features that make handling some blobs like the IFD/GBE/ME/... on Intel systems much easier. One can now with the --ifd flag fetch the flash layout from flash and use this to read/write/erase those regions. Also a --noverify-all or -N flag was introduced which skips verifying regions that were not touched at all, which can greatly speed up flashing if one is only writing to a small region on a large flash. Our guides however need to be adapted to use these features. One example where this has already been done is [7] which still has the old instructions for reference. In the future flashrom will support Linux MTD (memory technology device) which can remove the need to boot Linux without strict checking of MMIO memory regions (currently flashrom needs the iomem=relaxed boot parameter to use the internal programmer). I hope you can join us next time! Kind regards Arthur [1] https://review.coreboot.org/#/c/coreboot/+/23071/ [2] https://trmm.net/Heads [3] https://github.com/ArthurHeymans/petitboot_for_coreboot [4] https://mail.coreboot.org/pipermail/coreboot/2016-September/082050.html [5] https://review.coreboot.org/#/c/coreboot/+/23130/ [6] https://www.coreboot.org/Documentation/ [7] https://www.coreboot.org/Board:lenovo/x200#Flashing_your_coreboot_ROM_image

2 1

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 08 Jan '18

08 Jan '18

Hello Hilbert, After work (somewhere around 19:00 PM CET), I'll look into your logs. Please, stay tuned. I am simply sold out, and have no time for anything else... I will have some advises for you, hopefully! Zoran _______ On Mon, Jan 8, 2018 at 11:57 AM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi David, > > > > When I saw following message, I got different result when using different > payload for coreboot: > > ========================================================================== > > Returned from FspNotify(EnumInitPhaseReadyToBoot) > > Jumping to boot code at 000ff06e(7eff6000) > > CPU0: stack: 00129000 - 0012a000, lowest used address 00129b00, stack used: > 1280 bytes > > entry = 0x000ff06e > > lb_start = 0x00100000 > > lb_size = 0x001302f0 > > buffer = 0x7ed60000 > > =========================================================================== > > > > If U-Boot is used as payload, it just rebooted and restarted again. > > If Grub2 is used as payload, it just hung there. > > If SeaBios is used as payload, the result is like following attached file: > > http://mail.coreboot.org/pipermail/coreboot/attachments/20180105/209695a1/a… > > Do you have any idea about this? Is there any action I can do to clarify > what cause reboot? Thanks. > > > > -Hilbert > > > > This e-mail and its attachment may contain information that is confidential > or privileged, and are solely for the use of the individual to whom this > e-mail is addressed. If you are not the intended recipient or have received > it accidentally, please immediately notify the sender by reply e-mail and > destroy all copies of this email and its attachment. Please be advised that > any unauthorized use, disclosure, distribution or copying of this email or > its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 08 Jan '18

08 Jan '18

Hi David, When I saw following message, I got different result when using different payload for coreboot: ========================================================================== Returned from FspNotify(EnumInitPhaseReadyToBoot) Jumping to boot code at 000ff06e(7eff6000) CPU0: stack: 00129000 - 0012a000, lowest used address 00129b00, stack used: 1280 bytes entry = 0x000ff06e lb_start = 0x00100000 lb_size = 0x001302f0 buffer = 0x7ed60000 =========================================================================== If U-Boot is used as payload, it just rebooted and restarted again. If Grub2 is used as payload, it just hung there. If SeaBios is used as payload, the result is like following attached file: http://mail.coreboot.org/pipermail/coreboot/attachments/20180105/209695a1/a… Do you have any idea about this? Is there any action I can do to clarify what cause reboot? Thanks. -Hilbert This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] Can coreboot for KabyLake rvp11 work on Intel Sasby Island kit?
by Toan Le manh 08 Jan '18

08 Jan '18

Dear Naresh, Thanks a lot for your advice. I'm finding correct blobs for KBL U. I'll update once I get result. 2018-01-07 22:05 GMT+07:00 Naresh G. Solanki <naresh.solanki.2011(a)gmail.com> : > Hi Toan Le, > > For Sasby Island, which is based on KBL U, you'll need corresponding > blobs(me descriptor & ucode). > Use kblrvp7 as starting point. And based on schematic(of Sasby Island) & > your requirement(interface/device), you may have change settings(like gpio, > devicetree.cb etc). > > Make sure you are using right config & blobs. For this you can get in > touch with Intel FAE. > > Regards, > Naresh G Solanki > > > On Jan 6, 2018 7:45 AM, "Toan Le manh" <lemanhtoantb(a)gmail.com> wrote: > > Hi Naresh, > > Thanks a lot for your reply. > Could you please advise which settings should be modified for sasby island? > > Thanks. > > > 2018-01-06 2:33 GMT+07:00 Naresh G. Solanki <naresh.solanki.2011(a)gmail.com > >: > >> I guess you have coreboot working on rvp11. >> >> You may have to modify few settings based on sasby island. >> >> >> >> On Jan 4, 2018 7:58 AM, "Toan Le manh" <lemanhtoantb(a)gmail.com> wrote: >> >>> Hi, >>> >>> I had a Intel Sasby Island kit, which has CPU family: SkyLake, model >>> i7-6600U, Memory: LPDDR4. >>> Do you think coreboot for Intel rvp11 (Kabylake U, LPDDR4) can work on >>> that Sasby Island kit? >>> >>> Thanks & BRs, >>> Toan Le >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >>> >> > >

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Zeh, Werner 08 Jan '18

08 Jan '18

Hi Ian. > Ian Lewis wrote: > I do have one question: You clearly have no issue for your compliance. But, do you tell your OEM customers that they need to provide the GPL license to their customers as part of their product packaging, We do have a sticker on each component which tells that this component contains open source software and how to find the details on the component. Further we have a chapter in the end-user manual which describes all the details about open source software and the licenses. This manual will be handed over to the end-customer by the OEM. > Peter Stuge wrote: > Please consider the risk associated with offloading distribution of source code to a third party, be it upstream or anyone else. Of course we keep the exact copy of the source code for every single release version internally. So we have any time the ability to provide the code by ourselves. And our customers are aware of this. The upstream repo is just the first place to get the code from. Werner > Peter Stuge wrote: > > Consider Section 3 a) "on a medium customarily used for software interchange" - a Control Panel snap-in arguably isn't such a > medium. > > What specific interface to use for delivery of source code probably depends on how your product works, and what you want to enable > your customers to offer. > Peter Stuge wrote: > > Unlike David I'm not so sure about this. Requiring a special software to access the source code IMO does not satisfy "medium > customarily used for software interchange" - while a virtual CD-ROM would, if your product connects via USB in normal operation. > > The Control Panel idea may be a good way to help your customers with being compliant, but I don't think it's very good for your own > compliance, if that makes sense? > Peter Stuge wrote: > >Lewis, Ian (Microstar Laboratories) wrote: > >> Still, the more I look at this, the more it sounds like we would meet > >> our obligations if we provide an About tab in our control panel > >> application... > > > Mh - again, I don't think that's cool. > > Would you consider this true - for our compliance - if we put a piece of paper in the box that told you where to find the source code > from your measurement device? If this point about the medium on which the user obtains the source code is critical, then this option is > probably not a good solution for us. But, I am still curious whether you would consider us compliant if we had a piece of paper in the > box that told the user that the source code for the Coreboot/SeaBIOS (if we use SeaBIOS) firmware in their measurement instrument is > available by opening our Control Panel application, going to the About tab, and clicking the Get Firmware Source button (say). > > I will note that it is impossible to use our device in any way unless our driver and server are installed, the basic version of which is > available to anyone for download from our web site. And, the installation of these components always installs the Control Panel > application. So, even if an OEM were to pre-configure a system with our hardware, the Control Panel application would always be > available to all potential users of our device. > > Peter Stuge wrote: > > Sorry, I wasn't clear enough. I meant to refer to flash memory which is *somehow* accessible via USB - but not neccessarily in the > form of a "removable drive". A much better "look" would be a virtual CD-ROM, which are per definition read-only. > > I fully understood what you said in your original message. My point remains: if we provide a virtual CD-ROM - which I still consider a > "removable drive" even if it is read only - then plugging in our device, which has nothing to do with a drive of any kind, you suddenly > have a new drive letter taken under Windows for no obvious reason (for most users). Taking up a drive letter can really mess things up > for a user if they assume that letter is free for use, for example to attach to a network share when they log into a network. > > Of course, you do gain the nice feature that Windows will pop up a box on first use telling you the new drive showed up. And, that > would give you something that lets a user know something is going on that might need their attention. And, as you say, a CD-ROM is > clearly a " medium customarily used for software interchange". > > Peter Stuge wrote: > > This is actually quite common with USB cellphone network modems and with some other USB-connected devices as well. > > Yes. We know how to do this, though I am not overly enthusiastic about implementing it. I do not know much about USB cellphone > modems, but it seems like the drive might make some sense to the user in this case. It certainly does when you plug in a cell phone > since the cell phone has storage you want to be able to access. With our device, it would just be a spurious drive in most real > installations. Of course, a user could disable the drive. But, because of the way Windows manages USB devices, it would most likely > keep popping back up from time to time when you plugged it into a different slot. > > Peter Stuge wrote: > > I would recommend to avoid SeaBIOS if you can. Not because it's bad, but because you may not require it, and it would avoid > dealing with GPLv3 compliance, which is a lot more involved. > > We will almost certainly try to do this, though for initial development - all in house, so no GPL issues, we are going to work with > SeaBIOS because we already have loader code that knows how to talk with a legacy BIOS. Once we have that fully functional, we can > look at direct loading from Coreboot. Currently we boot our systems either directly from the first instruction the processor executes, > when using our own processor designs, or from a legacy BIOS or UEFI for processor modules. I suspect it will be pretty easy for us to > add one more boot mechanism to load directly as a payload of Coreboot. We make very little demand on the initial boot load > environment. > > Peter Stuge wrote: > > You really should learn how to build the boot image yourself, because it is quite risky to rely on third parties. > > Yes. I think this is completely correct. I do not think we would be in a good position at all if we claimed we had the correct source for a > binary we did not build ourselves. This would be especially true if we have to comply with GPLv3 where we probably have to provide > the instructions on how to go about replacing the firmware. > > Peter Stuge wrote: > > Ian Lewis wrote: > >> we will definitely release our changes back to the relevant project to accept or reject. > > You don't strictly have to just to be compliant, but it is certainly in the spirit of the license, and it does *simplify* compliance, because > you do not have to maintain private patches. > > Understood. But, since we plan to distribute a product, we have to make any changes public. So, we might as well make them > available to the original project. And, we usually do that even when we make changes to an open source project only for internal use, if > the changes seem to have any general value. > > Peter Stuge wrote: > > Keep in mind that compliance is required when copying and distributing the Program in object code or executable form, meaning > that marketing material such as webpages don't come with requirements. > > Right. I understood this. I did not mean to imply that Siemens had done anything wrong. I just meant that I could not tell how they > handled GPL compliance. So, I could not use their practices to learn anything about what we should do. > > Peter Stuge wrote: > >>> If it is already there people will stop asking your customers for > >>> the source code! > > No - please avoid that reasoning. > Peter Stuge wrote: > > Upstream *can never* ensure your compliance! > > Understood. The license itself seems very clear on this point. > > > I very much appreciate the effort you - and everyone else on this group - have taken to help me understand our obligations under GPL > and how to use your product in that context. > > Ian > > -- > coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

EARLY_CBMEM_INIT for Geode LX platforms
by Michal Zygowski 08 Jan '18

08 Jan '18

Hello Everyone, As a result of incoming 4.7 release many boards are going to be deprecated. We would like to support alix platforms which are based on Geode LX and yet not EARLY_CBMEM_INIT enabled. We have all hardware at hand and would gladly bring these platforms up to current standards. We saw that Kyösti Mälkki did a lot of good work for other AMD platforms and even offered to help with implementing EARLY_CBMEM_INIT on Geode. Unfortunately the thread died: https://www.mail-archive.com/coreboot@coreboot.org/msg50205.html Could You give us any tips where and how to start? AFAIK it is about calculating the top of RAM and recovering the cbmem on S3 resume (am I wrong?). I have already tried to implement it, but when trying to get timestamps with cbmem, it complains that it could not find timestamp table (did not even get error with cpufreq missing as this module occurs to be a problem on Geode). Has anybody maybe done some work yet? Best Regards, --- Michał Żygowski https://3mdeb.com | @3mdeb_com

3 2

← Newer
1
...
8
9
10
11
12
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2018