From isaac.christensen at se-eng.com Fri Aug 1 20:50:06 2014 From: isaac.christensen at se-eng.com (Isaac) Date: Fri, 01 Aug 2014 12:50:06 -0600 Subject: [coreboot] Chromium Upstreaming / Introduction Message-ID: <53DBE15E.6060401@se-eng.com> > Do you plan to upstream all Chromebook coreboot and libpayload > branches from Chromium git, or just the individual patches Sage finds > useful and necessary for the boards You currently work on? The goal of this effort is to minimize the differences between the Chromium chromeos-2013.04 branch and the coreboot master branch. As part of this any outstanding patches or differences between the branches will be addressed. > Do we expect the original authors to review the rebased, possibly > modified work, or is the plan these patches just get rubberstamped as +2 > by a 3rd party once they build cleanly? Original authors are automatically added as reviewers if they have coreboot.org gerrit accounts. I try to get approval from the original authors, but they are not always available for comment. If they are not available and the patch is non-trivial, we look for someone else familiar with the area or the original author of the section for review. We would like to avoid too many rubber stamp reviews. > Did you develop some nice method to keep track of which branches from > Chromium we can consider as completely upstreamed? This hasn't been a problem yet since we are only focusing on the chromeos-2013.04 branch at this time. If you know of a good solution for this I would appreciate any information. > Do you have the facilities to do regular board-status script runs for > recent Chromebooks? Not at this time but we're coordinating with Google on this. Isaac From paulepanter at users.sourceforge.net Sat Aug 2 15:07:24 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Sat, 02 Aug 2014 15:07:24 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <53D7D218.5020609@se-eng.com> References: <53D7D218.5020609@se-eng.com> Message-ID: <1406984844.4459.56.camel@mattotaupa> Dear Isaac, Am Dienstag, den 29.07.2014, 10:55 -0600 schrieb Isaac: > I am currently working on helping the Chromium team get their coreboot > patches upstreamed so I thought I should introduce myself to the community. > My name is Isaac Christensen and I've been working for Sage Electronic > Engineering since October. welcome to coreboot and thank you very much for getting in contact with the coreboot community! > These will be my first pushes up to coreboot.org so if you have any > comments on process or workflow feel free to let me know as I'm still > learning. As already commented on your change sets, I?d prefer if you could avoid squashing commits. Ky?sti made very good points, so I won?t repeat them. Also it?d be great to at least address such review comments and not ignore them and push the patches. I am looking forward to the time when the future Chromium OS branches can be rebased on the coreboot upstream master branches. ;-) Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From peter at stuge.se Mon Aug 4 22:53:12 2014 From: peter at stuge.se (Peter Stuge) Date: Mon, 4 Aug 2014 22:53:12 +0200 Subject: [coreboot] Minimum Steps Neccessary to Boot an Intel Architecture Platform in 2010 Message-ID: <20140804205312.28580.qmail@stuge.se> http://www.intel.com/content/www/us/en/intelligent-systems/intel-boot-loader-development-kit/minimal-intel-architecture-boot-loader-paper.html http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/minimal-intel-architecture-boot-loader-paper.pdf It does not go into any detail, but it gives a good high-level overview. //Peter From stefan.reinauer at coreboot.org Tue Aug 5 20:36:46 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Tue, 5 Aug 2014 20:36:46 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <1406984844.4459.56.camel@mattotaupa> References: <53D7D218.5020609@se-eng.com> <1406984844.4459.56.camel@mattotaupa> Message-ID: <20140805183645.GA30967@coreboot.org> * Paul Menzel [140802 15:07]: > As already commented on your change sets, I?d prefer if you could avoid > squashing commits. Ky?sti made very good points, so I won?t repeat them. One of the reasons Isaac has been squashing patches was that some in the community have been complaining about a vast amount of unsquashed patches last time, e.g.: https://www.mail-archive.com/coreboot at coreboot.org/msg40272.html http://www.coreboot.org/pipermail/coreboot/2013-January/073543.html As always, we have taken the community input under consideration, and tried acting upon it in the best possible way. Are you suggesting that the needs have changed here? Stefan From stefan.reinauer at coreboot.org Tue Aug 5 20:59:11 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Tue, 5 Aug 2014 20:59:11 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <53DA9249.5040405@gmail.com> References: <53D7D218.5020609@se-eng.com> <53DA9249.5040405@gmail.com> Message-ID: <20140805185911.GB30967@coreboot.org> * Ky?sti M?lkki [140731 21:00]: > Do you plan to upstream all Chromebook coreboot and libpayload > branches from Chromium git, or just the individual patches Sage > finds useful and necessary for the boards You currently work on? No, the plan for now is to only upstream the Chromium HEAD, since all Chrome OS product branches are derived from that. In theory all changes made to product branches should all go into Chromium HEAD as well. While this is not always true, the product branches are now all open on chromium.org. > Do we expect the original authors to review the rebased, possibly > modified work, or is the plan these patches just get rubberstamped > as +2 by a 3rd party once they build cleanly? Of course we value the feedback of the original authors. > I see some of you first patches had a couple commits from Chromium > tree squashed into one. Why was the approach changed from how eg. > Aaron and Stefan handled the process? It was changed due to community feedback. > This has the unpleasant effect that commit ownership (and eg. git > blame) will no longer reflect the actual author of change and also git > log --oneline no longer serves as a datapoint in attempt to compare > which changes from Chromium branches have been upstreamed or not. The idea is that we will switch to a new upstream coreboot version ASAP and get into a continuous upstreaming process where we don't accumulate such a large number of patches anymore but upstream at least every few weeks so we can stay closer to upstream coreboot in the future. > Did you develop some nice method to keep track of which branches > from Chromium we can consider as completely upstreamed? The method will be product firmware branches ==> Chrome OS HEAD ==> coreboot upstream > Do you have the facilities to do regular board-status script runs > for recent Chromebooks? Not at this time, but we are constantly working on improving our testing infrastructure to allow more flexible and broader testing. I hope at some point we can add that. However, if you rely on stability, you definitely want to run coreboot off the product firmware branches. Stefan From patrick at georgi-clan.de Tue Aug 5 21:32:17 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 05 Aug 2014 21:32:17 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <20140805183645.GA30967@coreboot.org> References: <53D7D218.5020609@se-eng.com> <1406984844.4459.56.camel@mattotaupa> <20140805183645.GA30967@coreboot.org> Message-ID: <53E13141.4060209@georgi-clan.de> Am 05.08.2014 um 20:36 schrieb Stefan Reinauer: > Are you suggesting that the needs have changed here? My only concern here would be to keep rebase/merge et al more functional, but it's probably already too late for that in the current state. I suppose, once the trees are somewhat synchronized, one could build a merge commit between both histories to create a new baseline - and redo that every now and then. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gregg.drwho8 at gmail.com Tue Aug 5 21:35:59 2014 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 5 Aug 2014 15:35:59 -0400 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <20140805185911.GB30967@coreboot.org> References: <53D7D218.5020609@se-eng.com> <53DA9249.5040405@gmail.com> <20140805185911.GB30967@coreboot.org> Message-ID: Hello! Stefan, by what you posted there, (and correct me if I'm wrong) if I were to put together a system who would be running ChromeOS and of course using coreboot to bring it up, the OS would be constructed from the head of the entire Chromium set? Just checking. As of this moment I do not have these plans, but its always an interest to do so. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Aug 5, 2014 at 2:59 PM, Stefan Reinauer wrote: > * Ky?sti M?lkki [140731 21:00]: >> Do you plan to upstream all Chromebook coreboot and libpayload >> branches from Chromium git, or just the individual patches Sage >> finds useful and necessary for the boards You currently work on? > > No, the plan for now is to only upstream the Chromium HEAD, since all > Chrome OS product branches are derived from that. In theory all changes > made to product branches should all go into Chromium HEAD as well. > While this is not always true, the product branches are now all open on > chromium.org. > >> Do we expect the original authors to review the rebased, possibly >> modified work, or is the plan these patches just get rubberstamped >> as +2 by a 3rd party once they build cleanly? > > Of course we value the feedback of the original authors. > >> I see some of you first patches had a couple commits from Chromium >> tree squashed into one. Why was the approach changed from how eg. >> Aaron and Stefan handled the process? > > It was changed due to community feedback. > >> This has the unpleasant effect that commit ownership (and eg. git >> blame) will no longer reflect the actual author of change and also git >> log --oneline no longer serves as a datapoint in attempt to compare >> which changes from Chromium branches have been upstreamed or not. > > The idea is that we will switch to a new upstream coreboot version ASAP > and get into a continuous upstreaming process where we don't accumulate > such a large number of patches anymore but upstream at least every few > weeks so we can stay closer to upstream coreboot in the future. > >> Did you develop some nice method to keep track of which branches >> from Chromium we can consider as completely upstreamed? > > The method will be > > product firmware branches ==> Chrome OS HEAD ==> coreboot upstream > >> Do you have the facilities to do regular board-status script runs >> for recent Chromebooks? > > Not at this time, but we are constantly working on improving our testing > infrastructure to allow more flexible and broader testing. I hope at > some point we can add that. However, if you rely on stability, you > definitely want to run coreboot off the product firmware branches. > > Stefan > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From paulepanter at users.sourceforge.net Tue Aug 5 22:59:22 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 05 Aug 2014 22:59:22 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <20140805183645.GA30967@coreboot.org> References: <53D7D218.5020609@se-eng.com> <1406984844.4459.56.camel@mattotaupa> <20140805183645.GA30967@coreboot.org> Message-ID: <1407272362.3332.35.camel@mattotaupa> Dear Stefan, Am Dienstag, den 05.08.2014, 20:36 +0200 schrieb Stefan Reinauer: > * Paul Menzel [140802 15:07]: > > As already commented on your change sets, I?d prefer if you could avoid > > squashing commits. Ky?sti made very good points, so I won?t repeat them. > > One of the reasons Isaac has been squashing patches was that some in the > community have been complaining about a vast amount of unsquashed > patches last time, e.g.: > > https://www.mail-archive.com/coreboot at coreboot.org/msg40272.html very interesting read. ;-) First of, I am sorry, that it looks like one time I write this and the other time that. But it is more my fault for not being clear. So let me clarify. By fix-ups I meant typos or wrong PCI IDs. Looking at the squashed commits in [1], from my point of view, these are no fix-ups and should not have been squashed. > http://www.coreboot.org/pipermail/coreboot/2013-January/073543.html Well, that message actually asks for more communication with the community, so is unrelated. > As always, we have taken the community input under consideration, and > tried acting upon it in the best possible way. Yes, thanks again for your answer. > Are you suggesting that the needs have changed here? The basic need has not changed and it looks like it was a misunderstanding in the past. Thanks, Paul [1] http://review.coreboot.org/6425 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From stefan.reinauer at coreboot.org Tue Aug 5 23:41:11 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Tue, 5 Aug 2014 23:41:11 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <53E13141.4060209@georgi-clan.de> References: <53D7D218.5020609@se-eng.com> <1406984844.4459.56.camel@mattotaupa> <20140805183645.GA30967@coreboot.org> <53E13141.4060209@georgi-clan.de> Message-ID: <20140805214111.GC30967@coreboot.org> * Patrick Georgi [140805 21:32]: > > > Am 05.08.2014 um 20:36 schrieb Stefan Reinauer: > > Are you suggesting that the needs have changed here? > > My only concern here would be to keep rebase/merge et al more > functional, but it's probably already too late for that in the current > state. Unfortunately, without significant amounts of testing, there is no guarantee that any given configuration in the Chromium HEAD or coreboot upstream HEAD will actually work on a given hardware. for every single build. If you want something that is tested for a given product, you will have to use a product firmware branch. If you want to make changes to a given configuration, you will have to have equipment and knowledge in place to test and fix up your configuration yourself. That's certainly not something you'd get for free in any open source project, and particularly not in a hardware related project. > I suppose, once the trees are somewhat synchronized, one could build a > merge commit between both histories to create a new baseline - and > redo that every now and then. The idea is indeed that the pain will go away if synchronization happens more regularly in both directions. Stefan From pierwien at wp.pl Fri Aug 1 10:58:20 2014 From: pierwien at wp.pl (Krzysztof Pierwieniecki) Date: Fri, 01 Aug 2014 10:58:20 +0200 Subject: [coreboot] events from GPIO in ACPI Message-ID: <53db56ac42a086.99312796@wp.pl> An HTML attachment was scrubbed... URL: From peter at stuge.se Wed Aug 6 00:08:59 2014 From: peter at stuge.se (Peter Stuge) Date: Wed, 6 Aug 2014 00:08:59 +0200 Subject: [coreboot] iy my pc supported for coreboot? In-Reply-To: References: Message-ID: <20140805220859.8683.qmail@stuge.se> Simon Andr? wrote: > I want use coreboot but i dont know if my system is supportet: > I have an Acer Predator G3620 It isn't. > I hope someone can help me As always with open source you have to help yourself. //Peter From wen.wang at adiengineering.com Wed Aug 6 21:44:51 2014 From: wen.wang at adiengineering.com (Wen Wang) Date: Wed, 6 Aug 2014 15:44:51 -0400 Subject: [coreboot] Baytrail SD card interface Message-ID: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> Hello all, Does the current baytrail fsp coreboot code support SD/uSD card interface? Is anybody able to get it to work on Bayley Bay CRB? It does not seem to work on our CRB. We checked the SD3_PWREN signal, it always remains high and therefore the SD card doesn't get any power. Thanks, Wen From stefan.reinauer at coreboot.org Wed Aug 6 22:38:33 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 6 Aug 2014 22:38:33 +0200 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: References: <53D7D218.5020609@se-eng.com> <53DA9249.5040405@gmail.com> <20140805185911.GB30967@coreboot.org> Message-ID: <20140806203833.GA27238@coreboot.org> * Gregg Levine [140805 21:35]: > Hello! > Stefan, by what you posted there, (and correct me if I'm wrong) if I > were to put together a system who would be running ChromeOS and of > course using coreboot to bring it up, the OS would be constructed from > the head of the entire Chromium set? That is correct. We start out with chromium.org's HEAD and then move into a branch once development has stabilized. Stefan From wen.wang at adiengineering.com Thu Aug 7 16:16:40 2014 From: wen.wang at adiengineering.com (Wen Wang) Date: Thu, 7 Aug 2014 10:16:40 -0400 Subject: [coreboot] Baytrail SD card interface In-Reply-To: References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> Message-ID: <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> Julien, Thanks much for the information! We must have missed something. For SD card, we have SD enabled in fsp, and the GPIO mux configured in coreboot. Is there anything else we need to do? Did you have to do anything in seabios? Thanks, Wen -----Original Message----- From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] Sent: Thursday, August 7, 2014 3:34 AM To: Wen Wang; coreboot at coreboot.org Subject: Re: [coreboot] Baytrail SD card interface Wen, SD Card , SD Card Boot work. We have designed several Boards with SD Card Boot. Although I would recommend USB3 Boot as it's a magnitude faster. Regards Julien Snell Cocom www.cc-e.co.uk ???? ?????? Cocom design and manufacture internet connected devices (IoT) Introducing two new brands Mi-ProtoPCB, UK made lightning fast assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. -----Original Message----- From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen Wang Sent: 06 August 2014 20:45 To: coreboot at coreboot.org Subject: [coreboot] Baytrail SD card interface Hello all, Does the current baytrail fsp coreboot code support SD/uSD card interface? Is anybody able to get it to work on Bayley Bay CRB? It does not seem to work on our CRB. We checked the SD3_PWREN signal, it always remains high and therefore the SD card doesn't get any power. Thanks, Wen -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot From martin.roth at se-eng.com Thu Aug 7 17:08:06 2014 From: martin.roth at se-eng.com (Martin Roth) Date: Thu, 07 Aug 2014 09:08:06 -0600 Subject: [coreboot] Baytrail SD card interface In-Reply-To: <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> Message-ID: <53E39656.2010800@se-eng.com> Wen, I'll push a patch for the muxing - I'd been meaning to do this and just got behind. I don't believe that SeaBIOS yet supports boot from SD (without a USB translator). Sage pushed a preliminary patch supporting SD boot on specific platforms to the SeaBIOS mailing list a while back, but I don't believe that worked on Bay Trail, and I don't believe that any additional work has been done on the patches since then. The thread starts here: http://www.coreboot.org/pipermail/seabios/2014-June/008105.html Here's a link to the patch: http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351/attachment-0001.gz Hi Julien, Were those boards using Bay Trail and booting coreboot / SeaBIOS? I'm assuming you just meant that SD boot works in general. Martin On 08/07/2014 08:16 AM, Wen Wang wrote: > Julien, > > Thanks much for the information! We must have missed something. For SD > card, we have SD enabled in fsp, and the GPIO mux configured in coreboot. Is > there anything else we need to do? Did you have to do anything in seabios? > > Thanks, > > Wen > > > > -----Original Message----- > From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] > Sent: Thursday, August 7, 2014 3:34 AM > To: Wen Wang; coreboot at coreboot.org > Subject: Re: [coreboot] Baytrail SD card interface > > Wen, > > SD Card , SD Card Boot work. We have designed several Boards with SD Card > Boot. > Although I would recommend USB3 Boot as it's a magnitude faster. > > Regards > Julien Snell > Cocom > www.cc-e.co.uk > > Cocom design and manufacture internet connected devices (IoT) Introducing > two new brands Mi-ProtoPCB, UK made lightning fast assembled PCB proto-types > and Mi-Embedded, your very own customised embedded board. > > -----Original Message----- > From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen Wang > Sent: 06 August 2014 20:45 > To: coreboot at coreboot.org > Subject: [coreboot] Baytrail SD card interface > > Hello all, > > Does the current baytrail fsp coreboot code support SD/uSD card interface? > Is anybody able to get it to work on Bayley Bay CRB? It does not seem to > work on our CRB. We checked the SD3_PWREN signal, it always remains high and > therefore the SD card doesn't get any power. > > Thanks, > > Wen > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > > > From wen.wang at adiengineering.com Thu Aug 7 19:43:34 2014 From: wen.wang at adiengineering.com (Wen Wang) Date: Thu, 7 Aug 2014 13:43:34 -0400 Subject: [coreboot] Baytrail SD card interface In-Reply-To: <53E39656.2010800@se-eng.com> References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> <53E39656.2010800@se-eng.com> Message-ID: <002601cfb267$1cbdcc50$563964f0$@adiengineering.com> Thanks Martin! We probably missed something in the muxing setting. Looking forward to your patch. By the way, I also have started looking into the eMMC4.5. I do have it enabled in fsp and device tree, but it does not seem to work. lspci does not list eMMC device either. Is it currently supported in coreboot? - should I start a new thread on this topic? Thanks, Wen -----Original Message----- From: Martin Roth [mailto:martin.roth at se-eng.com] Sent: Thursday, August 7, 2014 11:08 AM To: Wen Wang; 'Julien Snell'; coreboot at coreboot.org Subject: Re: [coreboot] Baytrail SD card interface Wen, I'll push a patch for the muxing - I'd been meaning to do this and just got behind. I don't believe that SeaBIOS yet supports boot from SD (without a USB translator). Sage pushed a preliminary patch supporting SD boot on specific platforms to the SeaBIOS mailing list a while back, but I don't believe that worked on Bay Trail, and I don't believe that any additional work has been done on the patches since then. The thread starts here: http://www.coreboot.org/pipermail/seabios/2014-June/008105.html Here's a link to the patch: http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351/attac hment-0001.gz Hi Julien, Were those boards using Bay Trail and booting coreboot / SeaBIOS? I'm assuming you just meant that SD boot works in general. Martin On 08/07/2014 08:16 AM, Wen Wang wrote: > Julien, > > Thanks much for the information! We must have missed something. For > SD card, we have SD enabled in fsp, and the GPIO mux configured in > coreboot. Is there anything else we need to do? Did you have to do anything in seabios? > > Thanks, > > Wen > > > > -----Original Message----- > From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] > Sent: Thursday, August 7, 2014 3:34 AM > To: Wen Wang; coreboot at coreboot.org > Subject: Re: [coreboot] Baytrail SD card interface > > Wen, > > SD Card , SD Card Boot work. We have designed several Boards with SD > Card Boot. > Although I would recommend USB3 Boot as it's a magnitude faster. > > Regards > Julien Snell > Cocom > www.cc-e.co.uk > > Cocom design and manufacture internet connected devices (IoT) > Introducing two new brands Mi-ProtoPCB, UK made lightning fast > assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. > > -----Original Message----- > From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen > Wang > Sent: 06 August 2014 20:45 > To: coreboot at coreboot.org > Subject: [coreboot] Baytrail SD card interface > > Hello all, > > Does the current baytrail fsp coreboot code support SD/uSD card interface? > Is anybody able to get it to work on Bayley Bay CRB? It does not seem > to work on our CRB. We checked the SD3_PWREN signal, it always remains > high and therefore the SD card doesn't get any power. > > Thanks, > > Wen > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > > > From marcj303 at gmail.com Thu Aug 7 21:09:15 2014 From: marcj303 at gmail.com (Marc Jones) Date: Thu, 7 Aug 2014 13:09:15 -0600 Subject: [coreboot] Baytrail SD card interface In-Reply-To: <002601cfb267$1cbdcc50$563964f0$@adiengineering.com> References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> <53E39656.2010800@se-eng.com> <002601cfb267$1cbdcc50$563964f0$@adiengineering.com> Message-ID: Wen, The emmc device can be set to PCI mode or ACPI mode. If you can't find it in lspci, it is probably in ACPI mode. I'm not certain what mode the FSP sets up the device as. Marc On Thu, Aug 7, 2014 at 11:43 AM, Wen Wang wrote: > Thanks Martin! We probably missed something in the muxing setting. Looking > forward to your patch. > > By the way, I also have started looking into the eMMC4.5. I do have it > enabled in fsp and device tree, but it does not seem to work. lspci does not > list eMMC device either. Is it currently supported in coreboot? - should I > start a new thread on this topic? > > Thanks, > > Wen > > -----Original Message----- > From: Martin Roth [mailto:martin.roth at se-eng.com] > Sent: Thursday, August 7, 2014 11:08 AM > To: Wen Wang; 'Julien Snell'; coreboot at coreboot.org > Subject: Re: [coreboot] Baytrail SD card interface > > Wen, > I'll push a patch for the muxing - I'd been meaning to do this and just > got behind. > > I don't believe that SeaBIOS yet supports boot from SD (without a USB > translator). Sage pushed a preliminary patch supporting SD boot on specific > platforms to the SeaBIOS mailing list a while back, but I don't believe that > worked on Bay Trail, and I don't believe that any additional work has been > done on the patches since then. > > The thread starts here: > http://www.coreboot.org/pipermail/seabios/2014-June/008105.html > > Here's a link to the patch: > http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351/attac > hment-0001.gz > > Hi Julien, > Were those boards using Bay Trail and booting coreboot / SeaBIOS? > I'm assuming you just meant that SD boot works in general. > > Martin > > > On 08/07/2014 08:16 AM, Wen Wang wrote: >> Julien, >> >> Thanks much for the information! We must have missed something. For >> SD card, we have SD enabled in fsp, and the GPIO mux configured in >> coreboot. Is there anything else we need to do? Did you have to do > anything in seabios? >> >> Thanks, >> >> Wen >> >> >> >> -----Original Message----- >> From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] >> Sent: Thursday, August 7, 2014 3:34 AM >> To: Wen Wang; coreboot at coreboot.org >> Subject: Re: [coreboot] Baytrail SD card interface >> >> Wen, >> >> SD Card , SD Card Boot work. We have designed several Boards with SD >> Card Boot. >> Although I would recommend USB3 Boot as it's a magnitude faster. >> >> Regards >> Julien Snell >> Cocom >> www.cc-e.co.uk >> >> Cocom design and manufacture internet connected devices (IoT) >> Introducing two new brands Mi-ProtoPCB, UK made lightning fast >> assembled PCB proto-types and Mi-Embedded, your very own customised > embedded board. >> >> -----Original Message----- >> From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen >> Wang >> Sent: 06 August 2014 20:45 >> To: coreboot at coreboot.org >> Subject: [coreboot] Baytrail SD card interface >> >> Hello all, >> >> Does the current baytrail fsp coreboot code support SD/uSD card interface? >> Is anybody able to get it to work on Bayley Bay CRB? It does not seem >> to work on our CRB. We checked the SD3_PWREN signal, it always remains >> high and therefore the SD card doesn't get any power. >> >> Thanks, >> >> Wen >> >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> >> >> >> > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com From phcoder at gmail.com Thu Aug 7 21:46:47 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Thu, 07 Aug 2014 21:46:47 +0200 Subject: [coreboot] iy my pc supported for coreboot? In-Reply-To: <20140805220859.8683.qmail@stuge.se> References: <20140805220859.8683.qmail@stuge.se> Message-ID: <53E3D7A7.3080305@gmail.com> On 06.08.2014 00:08, Peter Stuge wrote: > Simon Andr? wrote: >> I want use coreboot but i dont know if my system is supportet: >> I have an Acer Predator G3620 > > It isn't. > > >> I hope someone can help me > > As always with open source you have to help yourself. > Or hire someone to do it. > > //Peter > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From alim.akhtar at gmail.com Thu Aug 7 23:40:19 2014 From: alim.akhtar at gmail.com (Alim Akhtar) Date: Fri, 8 Aug 2014 03:10:19 +0530 Subject: [coreboot] Chromium Upstreaming / Introduction In-Reply-To: <20140806203833.GA27238@coreboot.org> References: <53D7D218.5020609@se-eng.com> <53DA9249.5040405@gmail.com> <20140805185911.GB30967@coreboot.org> <20140806203833.GA27238@coreboot.org> Message-ID: Hi Stefan, Good to know that Chromium HEAD is going upstream. Specially the starting branch chromeos-2013.04, which is really far ahead of what upstream has. Major one is ARMv8 support which is currently missing in upstream version. On Thu, Aug 7, 2014 at 2:08 AM, Stefan Reinauer wrote: > * Gregg Levine [140805 21:35]: >> Hello! >> Stefan, by what you posted there, (and correct me if I'm wrong) if I >> were to put together a system who would be running ChromeOS and of >> course using coreboot to bring it up, the OS would be constructed from >> the head of the entire Chromium set? > > That is correct. We start out with chromium.org's HEAD and then move > into a branch once development has stabilized. > > Stefan > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- Regards, Alim From alexhenrie24 at gmail.com Fri Aug 8 07:21:09 2014 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Thu, 7 Aug 2014 23:21:09 -0600 Subject: [coreboot] Intel HM76 support Message-ID: Hi, What is needed to support the Intel HM76 chipset? It looks like Intel has provided some example code already: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23615 I'm willing to donate hardware if it will help. I'm also not opposed to hunting for documentation or writing some C code. -Alex From dhendrix at google.com Sat Aug 9 02:18:37 2014 From: dhendrix at google.com (David Hendricks) Date: Fri, 8 Aug 2014 17:18:37 -0700 Subject: [coreboot] Intel HM76 support In-Reply-To: References: Message-ID: On Thu, Aug 7, 2014 at 10:21 PM, Alex Henrie wrote: > Hi, > > What is needed to support the Intel HM76 chipset? It looks like Intel > has provided some example code already: > https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23615 The good news is that HM76 (or at least very similar chipsets) are already supported in coreboot :-) The bad news is that there are many other factors to consider which are specific to the platform you intend to target. Look around the codebase and try to find something that most matches the criteria you are targeting. The Kconfig files under src/mainboard/* list the components of each mainboard pretty well. Porting to a totally new mainboard can take a few days or maybe weeks if you have all the CPU/chipset documentation, mainboard schematics, and requisite vendor-provided binaries (especially for Intel platforms). If you have none of the documentation or binaries then it can take several months assuming you're skilled and knowledgeable of x86 platforms, years if not. Start with the Lenovo x230 (Ivy Bridge) since phcoder (a highly skilled and knowledgeable dude) wrote native RAM init code on his own , an impressive feat that probably took him a few months. If you have a business relationship with Intel you can ask them for a binary to do the same thing for whatever northbridge you are targeting. HTH. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Aug 9 05:24:11 2014 From: rminnich at gmail.com (ron minnich) Date: Fri, 8 Aug 2014 20:24:11 -0700 Subject: [coreboot] good news on video init Message-ID: Some of furquan's very fine work from -- yegads! -- a year ago is just now coming upstream. Take a look. ron From john at jjdev.com Sun Aug 10 21:06:44 2014 From: john at jjdev.com (John de la Garza) Date: Sun, 10 Aug 2014 15:06:44 -0400 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit Message-ID: <20140810190643.GA16519@vega.jjdev.com> I understand that the calling functions in 32 bit C uses the stack and this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use registers to pass arguments to functions? If this is the case why not run in 64 bit mode? Also, even if cache as RAM is used and a stack is available, why not just build a 64 bit binary? What are the advantages to using a 32 bit binary? From patrick at georgi-clan.de Sun Aug 10 21:18:26 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Sun, 10 Aug 2014 21:18:26 +0200 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <20140810190643.GA16519@vega.jjdev.com> References: <20140810190643.GA16519@vega.jjdev.com> Message-ID: <53E7C582.2020700@georgi-clan.de> Am 10.08.2014 um 21:06 schrieb John de la Garza: > Doesn't 64 bit C use registers to pass arguments to functions? If > this is the case why not run in 64 bit mode? Even in 64bit mode you have to store state somewhere (that is, on the stack) before you have free registers to call new functions. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From pietrushnic at gmail.com Sun Aug 10 21:57:48 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Sun, 10 Aug 2014 21:57:48 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU Message-ID: <20140810195745.GB19278@echad> Hi all, I tried to boot coreboot using latest qemu and figured out that it fails with: qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000 R00=00000002 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=0007fed0 R14=6001032f R15=04000000 PSR=600000d3 -ZC- A svc32 (...) I was able to narrow down qemu commit that breaks coreboot booting. Bisection points to 75c9a1a 'target-arm: Implement vCPU reset via KVM_ARM_VCPU_INIT for 32-bit CPUs': http://git.qemu.org/?p=qemu.git;a=commit;h=75c9a1a0473cc5ca9756d11b236c715c7bc0ba67 It was changed by someone from Linaro, can we assume that this change is ok and problem is on coreboot side ? If the problem is on coreboot side than have you got any ideas how to fix it (or where to dig) ? Best Regards, Piotr Kr?l From phcoder at gmail.com Sun Aug 10 22:02:07 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Sun, 10 Aug 2014 22:02:07 +0200 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <20140810190643.GA16519@vega.jjdev.com> References: <20140810190643.GA16519@vega.jjdev.com> Message-ID: <53E7CFBF.9040608@gmail.com> On 10.08.2014 21:06, John de la Garza wrote: > I understand that the calling functions in 32 bit C uses the stack and > this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use > registers to pass arguments to functions? If this is the case why not > run in 64 bit mode? > > Also, even if cache as RAM is used and a stack is available, why not just > build a 64 bit binary? What are the advantages to using a 32 bit binary? > > long mode (64-bit) needs paging table in RAM. So no 64-bit for preram binary. For rest it's theoretically possible but it's too much hassle for no benefit. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Sun Aug 10 23:35:46 2014 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Aug 2014 14:35:46 -0700 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140810195745.GB19278@echad> References: <20140810195745.GB19278@echad> Message-ID: You can't assume much of anything. That commit seems not that harmful. What would help is if you tell us more about when the problem happens. There's just not enough info in your note, but I'd love to try to help. Thanks! ron On Sun, Aug 10, 2014 at 12:57 PM, Piotr Kr?l wrote: > Hi all, > I tried to boot coreboot using latest qemu and figured out that it fails > with: > > qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000 > > R00=00000002 R01=00000000 R02=00000000 R03=00000000 > R04=00000000 R05=00000000 R06=00000000 R07=00000000 > R08=00000000 R09=00000000 R10=00000000 R11=00000000 > R12=00000000 R13=0007fed0 R14=6001032f R15=04000000 > PSR=600000d3 -ZC- A svc32 > (...) > > I was able to narrow down qemu commit that breaks coreboot booting. > > Bisection points to 75c9a1a 'target-arm: Implement vCPU reset via > KVM_ARM_VCPU_INIT for 32-bit CPUs': > > http://git.qemu.org/?p=qemu.git;a=commit;h=75c9a1a0473cc5ca9756d11b236c715c7bc0ba67 > > It was changed by someone from Linaro, can we assume that this change is > ok and problem is on coreboot side ? > > If the problem is on coreboot side than have you got any ideas how to > fix it (or where to dig) ? > > Best Regards, > Piotr Kr?l > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From rminnich at gmail.com Sun Aug 10 23:37:03 2014 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Aug 2014 14:37:03 -0700 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <53E7CFBF.9040608@gmail.com> References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> Message-ID: One of the reasons I"m working to implement paging for 32-bit mode is for our eventual change to 64-bit mode for coreboot. It's gone on the back burner for a bit as I'm doing a few other coreboot things first. I'd love to have the help, if you have time. ron On Sun, Aug 10, 2014 at 1:02 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: > On 10.08.2014 21:06, John de la Garza wrote: >> I understand that the calling functions in 32 bit C uses the stack and >> this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use >> registers to pass arguments to functions? If this is the case why not >> run in 64 bit mode? >> >> Also, even if cache as RAM is used and a stack is available, why not just >> build a 64 bit binary? What are the advantages to using a 32 bit binary? >> >> > long mode (64-bit) needs paging table in RAM. So no 64-bit for preram > binary. For rest it's theoretically possible but it's too much hassle > for no benefit. > > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From info at gluglug.org.uk Sun Aug 10 23:48:18 2014 From: info at gluglug.org.uk (The Gluglug) Date: Sun, 10 Aug 2014 22:48:18 +0100 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> Message-ID: <53E7E8A2.2080503@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What about 32-bit-only machines, or people that want to use a 32-bit OS? On 10/08/14 22:37, ron minnich wrote: > One of the reasons I"m working to implement paging for 32-bit mode > is for our eventual change to 64-bit mode for coreboot. It's gone > on the back burner for a bit as I'm doing a few other coreboot > things first. > > I'd love to have the help, if you have time. > > ron > > On Sun, Aug 10, 2014 at 1:02 PM, Vladimir '?-coder/phcoder' > Serbinenko wrote: >> On 10.08.2014 21:06, John de la Garza wrote: >>> I understand that the calling functions in 32 bit C uses the >>> stack and this is why coreboot needs to use cache as RAM. >>> Doesn't 64 bit C use registers to pass arguments to functions? >>> If this is the case why not run in 64 bit mode? >>> >>> Also, even if cache as RAM is used and a stack is available, >>> why not just build a 64 bit binary? What are the advantages >>> to using a 32 bit binary? >>> >>> >> long mode (64-bit) needs paging table in RAM. So no 64-bit for >> preram binary. For rest it's theoretically possible but it's too >> much hassle for no benefit. >> >> >> >> >> -- coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT5+iiAAoJEP9Ft0z50c+U2CsH/i5aWRH4VB4Kwa9k9P4Dl1sf NhnHlg+YBmr82oRKpCR2Dtq78J0JQKOZbc5rfy0IaROxdX6Fkr4CcTxmyqWOLEhW 8RFx03NLqjOgfyVZx8JBz21RfFOJt3YVdbGtMfrRlacucUrL09JD680iwB65Zeqy zooNe2RddsXUvTHflR13MJQoxTUCESlL7XSkNAnzjSBNkwcHisgI8oOlZBvxbzD0 WLul+mvCD15IvyeJuBOSIld1UWdRWMGqK0nUqGdaPMKqeRdwvLYPzpmEbd81YXAr 3cUXnC2sWW9h7xGv1N+IKvMjrjXwaD0czPCmZ/7wAvVlhEAzM3rOabmuvukgOuk= =l8NY -----END PGP SIGNATURE----- From rminnich at gmail.com Mon Aug 11 00:07:20 2014 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Aug 2014 15:07:20 -0700 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <53E7E8A2.2080503@gluglug.org.uk> References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> <53E7E8A2.2080503@gluglug.org.uk> Message-ID: On Sun, Aug 10, 2014 at 2:48 PM, The Gluglug wrote: > What about 32-bit-only machines, or people that want to use a 32-bit OS? > well, we won't compile 64-bit firmware for 32-bit machines, if that helps. See: ARM v8 vs. v7. And a 32-bit OS can run on a machine with 64-bit firmware; see: EFI. ron From pietrushnic at gmail.com Mon Aug 11 00:10:20 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Mon, 11 Aug 2014 00:10:20 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810195745.GB19278@echad> Message-ID: <20140810221017.GA26493@echad> On Sun, Aug 10, 2014 at 02:35:46PM -0700, ron minnich wrote: > You can't assume much of anything. That commit seems not that harmful. > What would help is if you tell us more about when the problem happens. > There's just not enough info in your note, but I'd love to try to > help. I will try to do my best. Problem occurs at very early phase. There is no coreboot gdb support so I used qemu '-s -S'. Whole qemu command: qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom -s -S Exactly at address 0x6001024f qemu tries to execute: 0x60010249: adds r3, #1 0x6001024b: cmp r3, #7 0x6001024d: bne.n 0x6001019c => 0x6001024f: ldmia.w sp!, {r2, r3, r4, r5, r6, r7, r9, r10, r11, pc} 0x60010253: movs r3, #0 0x60010255: mcr 15, 0, r3, cr8, cr7, {0} 0x60010259: mcr 15, 0, r3, cr8, cr6, {0} 0x6001025d: mcr 15, 0, r3, cr8, cr5, {0} I can't find this instruction in coreboot code. Registers before executing ldmia: R0: 0x00000002 R1: 0x00000000 R2: 0xFFFFFFFE R3: 0x00000007 R4: 0x00000000 R5: 0x00000000 R6: 0x09000003 R7: 0x00000004 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FEA8 LR: 0x6001032F PC: 0x6001024E And after: R0: 0x00000002 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FED0 LR: 0x6001032F PC: 0x00000000 PC goes to 0 and we jumping to code where is 'andeq r0, r0, r0'. Qemu execute the same instruction till PC reach 0x4000000, then ends execution with: > > qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000 Hope this is enough information. Thanks, Piotr From peter at stuge.se Mon Aug 11 00:15:32 2014 From: peter at stuge.se (Peter Stuge) Date: Mon, 11 Aug 2014 00:15:32 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140810221017.GA26493@echad> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> Message-ID: <20140810221532.18133.qmail@stuge.se> Piotr Kr?l wrote: > Problem occurs at very early phase. Hm. > There is no coreboot gdb support There is some gdb support in coreboot, but maybe not for ARM? > so I used qemu '-s -S'. Whole qemu command: > > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom Is -kernel really correct for coreboot.rom ? //Peter From scott at notabs.org Mon Aug 11 00:20:51 2014 From: scott at notabs.org (Scott Duplichan) Date: Sun, 10 Aug 2014 17:20:51 -0500 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <53E7CFBF.9040608@gmail.com> References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> Message-ID: <001001cfb4e9$59a8d450$0cfa7cf0$@notabs.org> Vladimir '?-coder/phcoder' Serbinenko [mailto:phcoder at gmail.com] wrote" ]On 10.08.2014 21:06, John de la Garza wrote: ]> I understand that the calling functions in 32 bit C uses the stack and ]> this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use ]> registers to pass arguments to functions? If this is the case why not ]> run in 64 bit mode? ]> ]> Also, even if cache as RAM is used and a stack is available, why not just ]> build a 64 bit binary? What are the advantages to using a 32 bit binary? ]> ]> ]long mode (64-bit) needs paging table in RAM. So no 64-bit for preram ]binary. For rest it's theoretically possible but it's too much hassle ]for no benefit. The page table requirement is certainly a negative for x64 mode. Another is code size. Code grows by several percent when compiled for x64 mode. Use of x32 ABI could reduce the code size penalty, but page tables are still required. Most UEFI uses 32-bit mode until RAM is ready, then x64 mode after that. Unlike coreboot, UEFI doesn't prioritize code size minimization. Minimum code size is needed for fast boot, because the code must be read from the relatively slow flash chip before it can execute. Coreboot does prioritize fast boot. Switching coreboot to x64 mode would result in a measurable boot time degradation I believe. One advantage of x64 mode is easy use of DRAM structures larger then 4GB. Boot firmware is unlikely to benefit from this. Another benefit of x64 mode is use of additional registers. The additional registers can lead to faster code. But boot firmware is usually I/O bound, so it is unlikely the extra registers could lead to a measurable boot time reduction. Thanks, Scott From marcj303 at gmail.com Mon Aug 11 00:37:26 2014 From: marcj303 at gmail.com (Marc Jones) Date: Sun, 10 Aug 2014 16:37:26 -0600 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: <001001cfb4e9$59a8d450$0cfa7cf0$@notabs.org> References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> <001001cfb4e9$59a8d450$0cfa7cf0$@notabs.org> Message-ID: Nice answer, Scott. You pointed out everything I was going to say. I think this is something we should put on the wiki in a FAQ. A 64bit ramstage has questionable value, but a 64bit payload might be useful. Marc On Sun, Aug 10, 2014 at 4:20 PM, Scott Duplichan wrote: > Vladimir '?-coder/phcoder' Serbinenko [mailto:phcoder at gmail.com] wrote" > > > ]On 10.08.2014 21:06, John de la Garza wrote: > ]> I understand that the calling functions in 32 bit C uses the stack and > ]> this is why coreboot needs to use cache as RAM. Doesn't 64 bit C use > ]> registers to pass arguments to functions? If this is the case why not > ]> run in 64 bit mode? > ]> > ]> Also, even if cache as RAM is used and a stack is available, why not just > ]> build a 64 bit binary? What are the advantages to using a 32 bit binary? > ]> > ]> > ]long mode (64-bit) needs paging table in RAM. So no 64-bit for preram > ]binary. For rest it's theoretically possible but it's too much hassle > ]for no benefit. > > The page table requirement is certainly a negative for x64 mode. > Another is code size. Code grows by several percent when compiled > for x64 mode. Use of x32 ABI could reduce the code size penalty, > but page tables are still required. > > Most UEFI uses 32-bit mode until RAM is ready, then x64 mode > after that. Unlike coreboot, UEFI doesn't prioritize code size > minimization. Minimum code size is needed for fast boot, because > the code must be read from the relatively slow flash chip before > it can execute. Coreboot does prioritize fast boot. Switching > coreboot to x64 mode would result in a measurable boot time > degradation I believe. > > One advantage of x64 mode is easy use of DRAM structures larger > then 4GB. Boot firmware is unlikely to benefit from this. Another > benefit of x64 mode is use of additional registers. The additional > registers can lead to faster code. But boot firmware is usually I/O > bound, so it is unlikely the extra registers could lead to a > measurable boot time reduction. > > Thanks, > Scott > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com From rminnich at gmail.com Mon Aug 11 01:33:35 2014 From: rminnich at gmail.com (ron minnich) Date: Sun, 10 Aug 2014 16:33:35 -0700 Subject: [coreboot] why is firmware 32 bit as opposed to 64 bit In-Reply-To: References: <20140810190643.GA16519@vega.jjdev.com> <53E7CFBF.9040608@gmail.com> <001001cfb4e9$59a8d450$0cfa7cf0$@notabs.org> Message-ID: I understand the arguments. It's worth remembering that coreboot has to date run on 5 different architectures. 4 of those used paging. The x86 has always been the outlier. Lack of paging has costs not discussed much. Rmodules would be a lot simpler if we had paging. We could make the code space readonly, which we should be doing anyway. We would have less fighting with the granularity and alignment restrictions of MTRRs. We could catch NULL pointers in hardware. These are clear benefits. And they all apply to the ramstage as well as other stages. As to 64 bit ramstage, I see lots of benefits for my use cases, but I may be the only one. In any event, this is all stuff that can be measured, and I propose to implement and measure it. Then we can see. I'm not convinced that a few percent either way on code size is a showstopper. ron From pietrushnic at gmail.com Mon Aug 11 11:09:38 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Mon, 11 Aug 2014 11:09:38 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140810221532.18133.qmail@stuge.se> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> Message-ID: <20140811090937.GD26493@echad> On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote: > > There is no coreboot gdb support > > There is some gdb support in coreboot, but maybe not for ARM? What I tried to say is that it happens to early to connect to coreboot using gdb support, but maybe I'm wrong. > > > so I used qemu '-s -S'. Whole qemu command: > > > > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom > > Is -kernel really correct for coreboot.rom ? This is option from commit message when qemu-armv7 was introduced (7635a60). I also tried '-bios' but it gives same result but with different address (not 0x6001024f but 0x0000024f). What I see now is that I made mistake during bisect and it was not the correct commit that I point to. The correct change causing problem is exactly one before: http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101111fc7f0 Sorry for confusion - first time bisect user. This commit is directly related to vexpress-a9 board. Piotr From rminnich at gmail.com Mon Aug 11 16:36:42 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 07:36:42 -0700 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140811090937.GD26493@echad> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> Message-ID: So, if you comment that one line out, do things work for you? Just double checking. ron On Mon, Aug 11, 2014 at 2:09 AM, Piotr Kr?l wrote: > On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote: >> > There is no coreboot gdb support >> >> There is some gdb support in coreboot, but maybe not for ARM? > > What I tried to say is that it happens to early to connect to coreboot > using gdb support, but maybe I'm wrong. > >> >> > so I used qemu '-s -S'. Whole qemu command: >> > >> > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom >> >> Is -kernel really correct for coreboot.rom ? > > This is option from commit message when qemu-armv7 was introduced > (7635a60). I also tried '-bios' but it gives same result but with > different address (not 0x6001024f but 0x0000024f). > > What I see now is that I made mistake during bisect and it was not the > correct commit that I point to. The correct change causing problem is > exactly one before: > > http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101111fc7f0 > > Sorry for confusion - first time bisect user. This commit is directly > related to vexpress-a9 board. > > Piotr > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From rminnich at gmail.com Mon Aug 11 16:44:17 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 07:44:17 -0700 Subject: [coreboot] coreboot bof at ELC Europe oct. 13-15 Message-ID: got accepted. See you there. ron From rminnich at gmail.com Mon Aug 11 17:18:42 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 08:18:42 -0700 Subject: [coreboot] global changes and checking programs Message-ID: There's lots of really nice work going on with clang and other tools. I just want to put out a word of caution, based on what I'm seeing. A number of these tests are going in with global changes, no testing, and in some examples, no clear improvement or bug fix, e.g. "remove all blank lines at the end of a file", which can cause issues for others to pick over later. We all make mistakes. It is a given that some of these changes will have errors. In many cases there is no testing because most people only have one board, and they are changing many boards. Worse, they are changing them at the behest of warnings from a new toolchain or checker. I can't tell you how many issues we've had with toolchain over the years; they've been frequent. Changes driven by toolchain warnings worry me. I was just involved in a port last week and one of the coreboot utilities was always exiting via core dump. We don't know why yet as it does not fail under gdb. But it's disconcerting to find a formerly-working tool suddenly breaking. So here are the things that can happen. 1. code change for N boards, test none, break 1 or more or N 2. code change for N boards, test one, break 2 or more or N 3. cosmetic change for N boards, create a bug due to a later merge issue (latest greatest example: changing 'haven't' to 'have not' caused a bad merge) 4. code change for a tool, fixes no real problem, creates a future problem due to incorrect coding -- but the audit tool reports no errors (this means that in part the audit tool has errors) e.g. main(){ char *s = malloc(x); lots of code some of which uses s point A: lots of code NONE of which uses s } cppcheck reports a non-freed variable. Somebody puts a free(s) at point A: But they don't set s to NULL -- a common mistake. Result: s is pointing to freed memory, which is unquestionably far worse than the leak cppcheck claims is there. cppcheck and poor practice induced a bug. 5. Add broken cpp guards which cause more troubles than they might solve due to "best practices" -- which IMHO they are not. These are five types of errors I've seen in the last week, there are certainly more. Just please be very careful. Code check tools are no replacement for careful code changing. We've had lots of situations where people broke boards or tools by "improving" code. The time delay from a coreboot change to someone testing a board can be long. It's no fun to spend time debugging an ugly problem arising from a misguided attempt to clean up code. To give you some idea of what a reasonable test infrastructure looks like, see this: http://build.chromium.org/p/chromiumos/waterfall?reload=60 For every coreboot patch, these tests run on real hardware. Every one. It's why I'm so willing to trust the chromeos upstreaming: if I'm familiar with the CL, and it looks the same as it did when I wrote or reviewed it, and jenkins is happy, it's been through a good testing cycle. It's very hard to do that for all coreboot boards, however. So, please, take care. ron From pietrushnic at gmail.com Mon Aug 11 22:11:02 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Mon, 11 Aug 2014 22:11:02 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> Message-ID: <20140811201055.GG22602@echad> On Mon, Aug 11, 2014 at 07:36:42AM -0700, ron minnich wrote: > So, if you comment that one line out, do things work for you? Just > double checking. Comment is not enough to make it work. VE_NORFLASHALIAS has to be -1, then it works for me. So patch for QEMU is: diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c index a88732c..67f266a 100644 --- a/hw/arm/vexpress.c +++ b/hw/arm/vexpress.c @@ -84,7 +84,7 @@ enum { }; static hwaddr motherboard_legacy_map[] = { - [VE_NORFLASHALIAS] = 0, + [VE_NORFLASHALIAS] = -1, /* CS7: 0x10000000 .. 0x10020000 */ [VE_SYSREGS] = 0x10000000, [VE_SP810] = 0x10001000, Unfortunately this won't fix '-bios' option only '-kernel'. So it looks like the difference is that with VE_NORFLASHALIAS=0 we have vexpress.flash0 as alias to 0x0-0x3ffffff, but without it this range is mapped to vexpress.highmem. '-kernel' parameter put coreboot.rom into highmem. Does anyone know what is the correct memory map for qemu-armv7 and where coreboot.rom should be placed ? I will try to debug '-bios' option as Peter points that address in lowmem looks better for him. I will see if this option worked in the past. Thanks, Piotr > > ron > > On Mon, Aug 11, 2014 at 2:09 AM, Piotr Kr?l wrote: > > On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote: > >> > There is no coreboot gdb support > >> > >> There is some gdb support in coreboot, but maybe not for ARM? > > > > What I tried to say is that it happens to early to connect to coreboot > > using gdb support, but maybe I'm wrong. > > > >> > >> > so I used qemu '-s -S'. Whole qemu command: > >> > > >> > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom > >> > >> Is -kernel really correct for coreboot.rom ? > > > > This is option from commit message when qemu-armv7 was introduced > > (7635a60). I also tried '-bios' but it gives same result but with > > different address (not 0x6001024f but 0x0000024f). > > > > What I see now is that I made mistake during bisect and it was not the > > correct commit that I point to. The correct change causing problem is > > exactly one before: > > > > http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101111fc7f0 > > > > Sorry for confusion - first time bisect user. This commit is directly > > related to vexpress-a9 board. > > > > Piotr > > > > -- > > coreboot mailing list: coreboot at coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From rminnich at gmail.com Mon Aug 11 22:51:16 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 13:51:16 -0700 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140811201055.GG22602@echad> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> Message-ID: I can't recall for ARM, it's been more than a year since I used qemu on that platform. That said, ... on the platforms we use ROM is in low memory. What's your coreboot system.map say? ron On Mon, Aug 11, 2014 at 1:11 PM, Piotr Kr?l wrote: > On Mon, Aug 11, 2014 at 07:36:42AM -0700, ron minnich wrote: >> So, if you comment that one line out, do things work for you? Just >> double checking. > > Comment is not enough to make it work. VE_NORFLASHALIAS has to be -1, then it > works for me. So patch for QEMU is: > > diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c > index a88732c..67f266a 100644 > --- a/hw/arm/vexpress.c > +++ b/hw/arm/vexpress.c > @@ -84,7 +84,7 @@ enum { > }; > > static hwaddr motherboard_legacy_map[] = { > - [VE_NORFLASHALIAS] = 0, > + [VE_NORFLASHALIAS] = -1, > /* CS7: 0x10000000 .. 0x10020000 */ > [VE_SYSREGS] = 0x10000000, > [VE_SP810] = 0x10001000, > > Unfortunately this won't fix '-bios' option only '-kernel'. So it looks like > the difference is that with VE_NORFLASHALIAS=0 we have vexpress.flash0 as alias > to 0x0-0x3ffffff, but without it this range is mapped to vexpress.highmem. > '-kernel' parameter put coreboot.rom into highmem. Does anyone know what is the > correct memory map for qemu-armv7 and where coreboot.rom should be placed ? > > I will try to debug '-bios' option as Peter points that address in lowmem looks > better for him. I will see if this option worked in the past. > > Thanks, > Piotr > >> >> ron >> >> On Mon, Aug 11, 2014 at 2:09 AM, Piotr Kr?l wrote: >> > On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote: >> >> > There is no coreboot gdb support >> >> >> >> There is some gdb support in coreboot, but maybe not for ARM? >> > >> > What I tried to say is that it happens to early to connect to coreboot >> > using gdb support, but maybe I'm wrong. >> > >> >> >> >> > so I used qemu '-s -S'. Whole qemu command: >> >> > >> >> > qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom >> >> >> >> Is -kernel really correct for coreboot.rom ? >> > >> > This is option from commit message when qemu-armv7 was introduced >> > (7635a60). I also tried '-bios' but it gives same result but with >> > different address (not 0x6001024f but 0x0000024f). >> > >> > What I see now is that I made mistake during bisect and it was not the >> > correct commit that I point to. The correct change causing problem is >> > exactly one before: >> > >> > http://git.qemu.org/?p=qemu.git;a=commit;h=6ec1588e09770ac7e9c60194faff6101111fc7f0 >> > >> > Sorry for confusion - first time bisect user. This commit is directly >> > related to vexpress-a9 board. >> > >> > Piotr >> > >> > -- >> > coreboot mailing list: coreboot at coreboot.org >> > http://www.coreboot.org/mailman/listinfo/coreboot >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From pietrushnic at gmail.com Tue Aug 12 00:37:20 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Tue, 12 Aug 2014 00:37:20 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> Message-ID: <20140811223719.GH22602@echad> On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron minnich wrote: > I can't recall for ARM, it's been more than a year since I used qemu > on that platform. That said, ... on the platforms we use ROM is in low > memory. What's your coreboot system.map say? > I'm not sure what 'coreboot system.map' is but I will assume that you mean {bootblock, romstage, ramstage}.map. CONFIG_BOOTBLOCK_BASE is 0x10000 CONFIG_ROMSTAGE_BASE is 0x20000 CONFIG_SYS_SDRAM_BASE is 0x1000000 Uploaded files: https://gist.github.com/pietrushnic/7fea530d3498cf5ac5cfo Meanwhile I objdumped bootblock and found that ldmia instruction that breaks qemu execution came from dcache_foreach method. Anyone know how to load bootblock debug symbols to gdb when debugging using '-s -S' option ? Thanks, Piotr From rminnich at gmail.com Tue Aug 12 00:59:05 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 15:59:05 -0700 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140811223719.GH22602@echad> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> Message-ID: So what this is saying is that we expect the ROM for coreboot to start at 64K. I hope this makes sense to you. Does this conflict with some qemu expectation, do you know? ron On Mon, Aug 11, 2014 at 3:37 PM, Piotr Kr?l wrote: > On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron minnich wrote: >> I can't recall for ARM, it's been more than a year since I used qemu >> on that platform. That said, ... on the platforms we use ROM is in low >> memory. What's your coreboot system.map say? >> > I'm not sure what 'coreboot system.map' is but I will assume that you mean > {bootblock, romstage, ramstage}.map. > > CONFIG_BOOTBLOCK_BASE is 0x10000 > CONFIG_ROMSTAGE_BASE is 0x20000 > CONFIG_SYS_SDRAM_BASE is 0x1000000 > > Uploaded files: https://gist.github.com/pietrushnic/7fea530d3498cf5ac5cfo > > Meanwhile I objdumped bootblock and found that ldmia instruction that > breaks qemu execution came from dcache_foreach method. > > Anyone know how to load bootblock debug symbols to gdb when debugging > using '-s -S' option ? > > Thanks, > Piotr > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From rminnich at gmail.com Tue Aug 12 01:00:19 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Aug 2014 16:00:19 -0700 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> Message-ID: Sorry, in other words, how much ROM are you setting up on that qemu board? The 'execute outside ram or rom' is usually a jump to an IP that qemu does not recognize as ROM/RAM. I suspect our emulator is assuming SRAM in there somewhere, can you check? Certainly we depend on SRAM on the real hardware. From venture37 at gmail.com Tue Aug 12 03:27:45 2014 From: venture37 at gmail.com (Sevan / Venture37) Date: Tue, 12 Aug 2014 02:27:45 +0100 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 Message-ID: Hi, It seems that the status-to-wiki.sh script is broken, apart from being non-portable, it appears that the board model/manufacturer is being used as the date on Linux when run in a bash shell date: invalid date `yangtze' date: invalid date `yabel' date: invalid date `xe7501devkit' date: invalid date `xcompile' date: invalid date `x86emu' date: invalid date `x86' date: invalid date `x86' date: invalid date `x86' date: invalid date `x7db8' date: invalid date `x6dhr_ig2' date: invalid date `x6dhr_ig' date: invalid date `x6dhe_g2' date: invalid date `x6dhe_g' date: invalid date `x6dai_g' date: invalid date `x60' date: invalid date `wtm2' date: invalid date `wpcm450' date: invalid date `winnetp680' date: invalid date `winnet100' grep: src/mainboard/lenovo/x230/revision.txt: No such file or directory date: invalid date `w83977tf' date: invalid date `w83977f' date: invalid date `w83795' date: invalid date `w83793' date: invalid date `w83697hf' date: invalid date `w83627uhg' date: invalid date `w83627thg' date: invalid date `w83627hf' date: invalid date `w83627ehg' Hence I couldn't follow through with making a submission so instead, I've uploaded the contents of the text files created by board_status.sh to pastebin if anyone is interested. http://pastebin.com/r4H5ceN7 Regards Sevan / Venture37 From patrick at georgi-clan.de Tue Aug 12 05:30:03 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 12 Aug 2014 05:30:03 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <20140811223719.GH22602@echad> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> Message-ID: <53E98A3B.6060502@georgi-clan.de> Am 12.08.2014 um 00:37 schrieb Piotr Kr?l: > Anyone know how to load bootblock debug symbols to gdb when debugging > using '-s -S' option ? add-symbol-file $filename $loadaddr Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From patrick at georgi-clan.de Tue Aug 12 05:31:51 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Tue, 12 Aug 2014 05:31:51 +0200 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: References: Message-ID: <53E98AA7.6010308@georgi-clan.de> Am 12.08.2014 um 03:27 schrieb Sevan / Venture37: > It seems that the status-to-wiki.sh script is broken, apart from being > non-portable, it appears that the board model/manufacturer is being > used as the date on Linux when run in a bash shell The status-to-wiki script is run hourly on the server, parsing the data submitted to the board-status repository (eg through board_status.sh -u) Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From pierwien at wp.pl Wed Aug 6 15:56:42 2014 From: pierwien at wp.pl (Krzysztof Pierwieniecki) Date: Wed, 06 Aug 2014 15:56:42 +0200 Subject: [coreboot] events from GPIO in ACPI Message-ID: <53e2341a8c1951.65490803@wp.pl> I know why it didn't work. For GPIO8 it should be: 'Method(_L18, 0, NotSerialized)' instead of: 'Method(_L08, 0, NotSerialized)' I don't know why but I heard that gpio in acpi have to be with offset 0x10. Now it works. Chris From JulienSnell at cc-e.co.uk Thu Aug 7 09:34:17 2014 From: JulienSnell at cc-e.co.uk (Julien Snell) Date: Thu, 7 Aug 2014 07:34:17 +0000 Subject: [coreboot] Baytrail SD card interface In-Reply-To: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> Message-ID: Wen, SD Card , SD Card Boot work. We have designed several Boards with SD Card Boot. Although I would recommend USB3 Boot as it's a magnitude faster. Regards Julien Snell Cocom www.cc-e.co.uk ???? ?????? Cocom design and manufacture internet connected devices (IoT) Introducing two new brands Mi-ProtoPCB, UK made lightning fast assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. -----Original Message----- From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen Wang Sent: 06 August 2014 20:45 To: coreboot at coreboot.org Subject: [coreboot] Baytrail SD card interface Hello all, Does the current baytrail fsp coreboot code support SD/uSD card interface? Is anybody able to get it to work on Bayley Bay CRB? It does not seem to work on our CRB. We checked the SD3_PWREN signal, it always remains high and therefore the SD card doesn't get any power. Thanks, Wen -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot From JulienSnell at cc-e.co.uk Thu Aug 7 17:21:43 2014 From: JulienSnell at cc-e.co.uk (Julien Snell) Date: Thu, 7 Aug 2014 15:21:43 +0000 Subject: [coreboot] Baytrail SD card interface In-Reply-To: <53E39656.2010800@se-eng.com> References: <000801cfb1ae$e3f4a280$abdde780$@adiengineering.com> <000c01cfb24a$355b3e90$a011bbb0$@adiengineering.com> <53E39656.2010800@se-eng.com> Message-ID: Hi Martin, Wen. Sorry.. Reading my post I did not make it clear. SD / USB Boot works well under a full UEFI Bios on Baytrail - I. As Martin says it's not in Seabios yet for Baytrail - I. But I am sure an updated patch will be coming very soon. Regards Julien Snell Cocom www.cc-e.co.uk Tel :-? ??+44 (0) 1444 461620 Mob:-? +44 (0) 7834 548755 Skype? julien.cocom ???? ?????? Cocom design and manufacture internet connected devices (IoT) Introducing two new brands Mi-ProtoPCB, UK made lightning fast assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. -----Original Message----- From: Martin Roth [mailto:martin.roth at se-eng.com] Sent: 07 August 2014 16:08 To: Wen Wang; Julien Snell; coreboot at coreboot.org Subject: Re: [coreboot] Baytrail SD card interface Wen, I'll push a patch for the muxing - I'd been meaning to do this and just got behind. I don't believe that SeaBIOS yet supports boot from SD (without a USB translator). Sage pushed a preliminary patch supporting SD boot on specific platforms to the SeaBIOS mailing list a while back, but I don't believe that worked on Bay Trail, and I don't believe that any additional work has been done on the patches since then. The thread starts here: http://www.coreboot.org/pipermail/seabios/2014-June/008105.html Here's a link to the patch: http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351/attachment-0001.gz Hi Julien, Were those boards using Bay Trail and booting coreboot / SeaBIOS? I'm assuming you just meant that SD boot works in general. Martin On 08/07/2014 08:16 AM, Wen Wang wrote: > Julien, > > Thanks much for the information! We must have missed something. For > SD card, we have SD enabled in fsp, and the GPIO mux configured in > coreboot. Is there anything else we need to do? Did you have to do anything in seabios? > > Thanks, > > Wen > > > > -----Original Message----- > From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] > Sent: Thursday, August 7, 2014 3:34 AM > To: Wen Wang; coreboot at coreboot.org > Subject: Re: [coreboot] Baytrail SD card interface > > Wen, > > SD Card , SD Card Boot work. We have designed several Boards with SD > Card Boot. > Although I would recommend USB3 Boot as it's a magnitude faster. > > Regards > Julien Snell > Cocom > www.cc-e.co.uk > > Cocom design and manufacture internet connected devices (IoT) > Introducing two new brands Mi-ProtoPCB, UK made lightning fast > assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. > > -----Original Message----- > From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Wen > Wang > Sent: 06 August 2014 20:45 > To: coreboot at coreboot.org > Subject: [coreboot] Baytrail SD card interface > > Hello all, > > Does the current baytrail fsp coreboot code support SD/uSD card interface? > Is anybody able to get it to work on Bayley Bay CRB? It does not seem > to work on our CRB. We checked the SD3_PWREN signal, it always remains > high and therefore the SD card doesn't get any power. > > Thanks, > > Wen > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > > > > From stefan.reinauer at coreboot.org Tue Aug 12 07:27:06 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Tue, 12 Aug 2014 07:27:06 +0200 Subject: [coreboot] good news on video init In-Reply-To: References: Message-ID: <20140812052706.GA32548@coreboot.org> * ron minnich [140809 05:24]: > Some of furquan's very fine work from -- yegads! -- a year ago is just > now coming upstream. Take a look. Ron! If you have a link for us, that would be great! I want to endorse Furquan's great work, however. Not only did it open up new ways of making sure we get rid of yet another blob in our systems, but it also opens up coreboot on a variety of systems in the future while silicon vendors slowly but steadily migrate away from x86 VGA option ROMs and towards UEFI option roms and (sic!) GOP drivers. Also, at this time, thank you very much to every one in the community who put endless hours of effort into porting native graphics init to their mainboard / system. This is really where we have to put a lot of effort in, in the near future to keep coreboot free. Stefan From paulepanter at users.sourceforge.net Tue Aug 12 08:11:28 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 12 Aug 2014 08:11:28 +0200 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: References: Message-ID: <1407823888.4788.98.camel@mattotaupa> Dear Sevan, Am Dienstag, den 12.08.2014, 02:27 +0100 schrieb Sevan / Venture37: > It seems that the status-to-wiki.sh script is broken, apart from being > non-portable, it appears that the board model/manufacturer is being > used as the date on Linux when run in a bash shell > > date: invalid date `yangtze' [?] Hmm, I have never seen this with `board_status.sh` on Debian. The last time I tried was last Sunday I believe. > Hence I couldn't follow through with making a submission so instead, > I've uploaded the contents of the text files created by > board_status.sh to pastebin if anyone is interested. > http://pastebin.com/r4H5ceN7 Thanks a lot. Could you please enable CBMEM console (menu Console) and time stamp capture (menu General)? Please check if CBMEM console is enabled in your payload (GRUB/SeaBIOS) too. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Tue Aug 12 08:41:27 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 12 Aug 2014 08:41:27 +0200 Subject: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device (was: [coreboot-gerrit] Patch merged into coreboot/master: a438049 model_106cx: don't blindly set Kconfig settings) In-Reply-To: References: Message-ID: <1407825687.4788.108.camel@mattotaupa> Dear coreboot folks, Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb gerrit at coreboot.org: > the following patch was just integrated into master: > commit a438049422fae85fe4df3ab3f89dbca797d6f5a9 > Author: Aaron Durbin > Date: Tue Sep 17 22:01:48 2013 -0500 > > model_106cx: don't blindly set Kconfig settings > > The CPU_ADDR_BITS was being unconditionally set. > Don't do that. [?] > See http://review.coreboot.org/6535 for details. since the submission of the commit above `CONFIG_CPU_ADDR_BITS` is set to 36 bits on most Intel devices instead of 32 bit, which it has been since almost two years after a bad conflict resolution in the revert commit 51676b14 (Revert "Use broadcast SIPI to startup siblings) [1], where the checks from commit c7fb2ae6 (Intel cpus: use CPU_ADDR_BITS from Kconfig during CAR) [2] were removed. I was told it should not make a difference for machines below 4 GB, but it?d be great if you could test it on your Intel boards. Thanks, Paul [1] http://review.coreboot.org/1381 [2] http://review.coreboot.org/639 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From r.marek at assembler.cz Tue Aug 12 10:13:49 2014 From: r.marek at assembler.cz (Rudolf Marek) Date: Tue, 12 Aug 2014 10:13:49 +0200 Subject: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set In-Reply-To: <53C2C1D1.6050300@assembler.cz> References: <53B07FED.5050402@assembler.cz> <53C2C1D1.6050300@assembler.cz> Message-ID: <53E9CCBD.4040704@assembler.cz> Hi all, I would like to remind you our Prague hackaton meeting in October (16-19). I managed to get patronage from dean of the Faculty of Information Technology, Czech Technical University and also patronage from CESNET (Czech education and science network) To properly size the event room (so far I counted with 15 people, but we are nearly there!) and also for the hotel booking, I would like to ask you to sign in on doodle ASAP! If you intend to come, please use http://doodle.com/h6yar2mtxarvhv3x and sign in. If you are still unsure, but you want to most likely to come. Indicate that in the doodle too. I can do you some speculative booking of the hotel (which is penalty free, up to 16 september) I'm handling the people which are already on the doodle, via a private emails except for Cris Sommerland. He is prehaps using a nickname and I dont have any email of him. Cris, please can you write me an email? Or someone who has yours ;) If your email is not in the email conference archive, please write me an email too. The hotel is part of student dormitory, just google for "The Masarykova Dormitory" hotel and it has very reasonable prices and it is not far from the actual event place. The people which are already on the doodle list received an email from me where I'm asking them to fill in some details in the form, please do so! (if you dont have my email, please ping me too) I want to do the hotel booking tomorrow afternoon GMT +2. That does not mean that the hotel is full, I just can't promise you the room later. For late birds, I will try to get reservation in the early september, but I can't promise anything. Thanks Rudolf From venture37 at gmail.com Tue Aug 12 10:48:45 2014 From: venture37 at gmail.com (Sevan / Venture37) Date: Tue, 12 Aug 2014 09:48:45 +0100 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: <1407823888.4788.98.camel@mattotaupa> References: <1407823888.4788.98.camel@mattotaupa> Message-ID: Hi Paul, On 12 August 2014 07:11, Paul Menzel wrote: > Hmm, I have never seen this with `board_status.sh` on Debian. The last > time I tried was last Sunday I believe. I'll try & dig a little further tonight to see what's going on, I'm using voyager linux which is a minimal debian derivative intended for Alix & Soekris boards. >> Hence I couldn't follow through with making a submission so instead, >> I've uploaded the contents of the text files created by >> board_status.sh to pastebin if anyone is interested. >> http://pastebin.com/r4H5ceN7 > > Thanks a lot. Could you please enable CBMEM console (menu Console) and > time stamp capture (menu General)? Please check if CBMEM console is > enabled in your payload (GRUB/SeaBIOS) too. Sure, will build a new image tonight & post up the results for you. Sevan From wangfei.jimei at gmail.com Tue Aug 12 12:01:35 2014 From: wangfei.jimei at gmail.com (WANG FEI) Date: Tue, 12 Aug 2014 11:01:35 +0100 Subject: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device (was: [coreboot-gerrit] Patch merged into coreboot/master: a438049 model_106cx: don't blindly set Kconfig settings) In-Reply-To: <1407825687.4788.108.camel@mattotaupa> References: <1407825687.4788.108.camel@mattotaupa> Message-ID: I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36 src\cpu\x86\Kconfig. To avoid this issue, you have to override CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has done. On Tue, Aug 12, 2014 at 7:41 AM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > Dear coreboot folks, > > > Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb gerrit at coreboot.org: > > the following patch was just integrated into master: > > commit a438049422fae85fe4df3ab3f89dbca797d6f5a9 > > Author: Aaron Durbin > > Date: Tue Sep 17 22:01:48 2013 -0500 > > > > model_106cx: don't blindly set Kconfig settings > > > > The CPU_ADDR_BITS was being unconditionally set. > > Don't do that. > > [?] > > > See http://review.coreboot.org/6535 for details. > > since the submission of the commit above `CONFIG_CPU_ADDR_BITS` is set > to 36 bits on most Intel devices instead of 32 bit, which it has been > since almost two years after a bad conflict resolution in the revert > commit 51676b14 (Revert "Use broadcast SIPI to startup siblings) [1], > where the checks from commit c7fb2ae6 (Intel cpus: use CPU_ADDR_BITS > from Kconfig during CAR) [2] were removed. > > I was told it should not make a difference for machines below 4 GB, but > it?d be great if you could test it on your Intel boards. > > > Thanks, > > Paul > > > [1] http://review.coreboot.org/1381 > [2] http://review.coreboot.org/639 > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexhenrie24 at gmail.com Tue Aug 12 13:44:39 2014 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 12 Aug 2014 05:44:39 -0600 Subject: [coreboot] Intel HM76 support In-Reply-To: References: Message-ID: 2014-08-08 18:18 GMT-06:00 David Hendricks : > The good news is that HM76 (or at least very similar chipsets) are already > supported in coreboot :-) > > The bad news is that there are many other factors to consider which are > specific to the platform you intend to target. Look around the codebase and > try to find something that most matches the criteria you are targeting. The > Kconfig files under src/mainboard/* list the components of each mainboard > pretty well. > > Porting to a totally new mainboard can take a few days or maybe weeks if you > have all the CPU/chipset documentation, mainboard schematics, and requisite > vendor-provided binaries (especially for Intel platforms). If you have none > of the documentation or binaries then it can take several months assuming > you're skilled and knowledgeable of x86 platforms, years if not. > > Start with the Lenovo x230 (Ivy Bridge) since phcoder (a highly skilled and > knowledgeable dude) wrote native RAM init code on his own, an impressive > feat that probably took him a few months. If you have a business > relationship with Intel you can ask them for a binary to do the same thing > for whatever northbridge you are targeting. > > HTH. Thanks for the detailed response! Unfortunately, it doesn't look like I'll have time to work on this project for several months, if at all. The specific motherboard I'd like to add support for comes from the Lenovo IdeaPad Z500 Touch. It has an i5-3230M and an HM76. Again, I'd be happy to donate hardware to anyone willing to work on support for this or similar motherboards. -Alex From wen.wang at adiengineering.com Tue Aug 12 22:15:38 2014 From: wen.wang at adiengineering.com (Wen Wang) Date: Tue, 12 Aug 2014 16:15:38 -0400 Subject: [coreboot] Baytrail SD card / eMMC interface Message-ID: <000101cfb66a$2fac18b0$8f044a10$@adiengineering.com> Marc, I don't seem to see an FSP configuration in BCT for eMMC in PCI or ACPI mode ... Martin - Is eMMC currently supported in coreboot? Thanks, Wen -----Original Message----- From: Marc Jones [mailto:marcj303 at gmail.com] Sent: Thursday, August 7, 2014 3:09 PM To: Wen Wang Cc: Martin Roth; Julien Snell; Coreboot Subject: Re: [coreboot] Baytrail SD card interface Wen, The emmc device can be set to PCI mode or ACPI mode. If you can't find it in lspci, it is probably in ACPI mode. I'm not certain what mode the FSP sets up the device as. Marc On Thu, Aug 7, 2014 at 11:43 AM, Wen Wang wrote: > Thanks Martin! We probably missed something in the muxing setting. > Looking forward to your patch. > > By the way, I also have started looking into the eMMC4.5. I do have > it enabled in fsp and device tree, but it does not seem to work. lspci > does not list eMMC device either. Is it currently supported in > coreboot? - should I start a new thread on this topic? > > Thanks, > > Wen > > -----Original Message----- > From: Martin Roth [mailto:martin.roth at se-eng.com] > Sent: Thursday, August 7, 2014 11:08 AM > To: Wen Wang; 'Julien Snell'; coreboot at coreboot.org > Subject: Re: [coreboot] Baytrail SD card interface > > Wen, > I'll push a patch for the muxing - I'd been meaning to do this > and just got behind. > > I don't believe that SeaBIOS yet supports boot from SD (without a > USB translator). Sage pushed a preliminary patch supporting SD boot > on specific platforms to the SeaBIOS mailing list a while back, but I > don't believe that worked on Bay Trail, and I don't believe that any > additional work has been done on the patches since then. > > The thread starts here: > http://www.coreboot.org/pipermail/seabios/2014-June/008105.html > > Here's a link to the patch: > http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351 > /attac > hment-0001.gz > > Hi Julien, > Were those boards using Bay Trail and booting coreboot / SeaBIOS? > I'm assuming you just meant that SD boot works in general. > > Martin > > > On 08/07/2014 08:16 AM, Wen Wang wrote: >> Julien, >> >> Thanks much for the information! We must have missed something. For >> SD card, we have SD enabled in fsp, and the GPIO mux configured in >> coreboot. Is there anything else we need to do? Did you have to do > anything in seabios? >> >> Thanks, >> >> Wen >> >> >> >> -----Original Message----- >> From: Julien Snell [mailto:JulienSnell at cc-e.co.uk] >> Sent: Thursday, August 7, 2014 3:34 AM >> To: Wen Wang; coreboot at coreboot.org >> Subject: Re: [coreboot] Baytrail SD card interface >> >> Wen, >> >> SD Card , SD Card Boot work. We have designed several Boards with SD >> Card Boot. >> Although I would recommend USB3 Boot as it's a magnitude faster. >> >> Regards >> Julien Snell >> Cocom >> www.cc-e.co.uk >> >> Cocom design and manufacture internet connected devices (IoT) >> Introducing two new brands Mi-ProtoPCB, UK made lightning fast >> assembled PCB proto-types and Mi-Embedded, your very own customised > embedded board. >> >> -----Original Message----- >> From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of >> Wen Wang >> Sent: 06 August 2014 20:45 >> To: coreboot at coreboot.org >> Subject: [coreboot] Baytrail SD card interface >> >> Hello all, >> >> Does the current baytrail fsp coreboot code support SD/uSD card interface? >> Is anybody able to get it to work on Bayley Bay CRB? It does not seem >> to work on our CRB. We checked the SD3_PWREN signal, it always >> remains high and therefore the SD card doesn't get any power. >> >> Thanks, >> >> Wen >> >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> >> >> >> > > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com From pietrushnic at gmail.com Wed Aug 13 00:13:07 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Wed, 13 Aug 2014 00:13:07 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> Message-ID: <20140812221303.GA4100@echad> On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote: > Sorry, in other words, how much ROM are you setting up on that qemu > board? The 'execute outside ram or rom' is usually a jump to an IP > that qemu does not recognize as ROM/RAM. ROM is probably represented in vexpress-a9 as vexpress.flash0 and vexpress.flash1. Both are 64M (0x4000000). > > I suspect our emulator is assuming SRAM in there somewhere, can you > check? Certainly we depend on SRAM on the real hardware. > vexpress.sram is 32M (0x2000000). This is memory map (info mtree) form qemu console - VE_NORFLASHALIAS=0 https://gist.github.com/pietrushnic/afe7bd2e036150888609 Same thing with VE_NORFLASHALIAS=-1: https://gist.github.com/pietrushnic/be916c58de8c9a710297 Thanks, Piotr From pietrushnic at gmail.com Wed Aug 13 00:51:47 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Wed, 13 Aug 2014 00:51:47 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: <53E98A3B.6060502@georgi-clan.de> References: <20140810195745.GB19278@echad> <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> <53E98A3B.6060502@georgi-clan.de> Message-ID: <20140812225146.GB4100@echad> On Tue, Aug 12, 2014 at 05:30:03AM +0200, Patrick Georgi wrote: > Am 12.08.2014 um 00:37 schrieb Piotr Kr?l: > > Anyone know how to load bootblock debug symbols to gdb when debugging > > using '-s -S' option ? > add-symbol-file $filename $loadaddr When I try: gdb$ target remote :1234 Remote debugging using :1234 gdb$ add-symbol-file build/cbfs/fallback/bootblock.debug 0x0 add symbol table from file "build/cbfs/fallback/bootblock.debug" at .text_addr = 0x0 Reading symbols from /home/pietrushnic/src/coreboot/build/cbfs/fallback/bootblock.debug...warning: section .text not found in /home/pietrushnic/src/coreboot/build/cbfs/fallback/bootblock.debug done. Same thing for romstage.debug. When using ramstage without address: gdb$ add-symbol-file build/cbfs/fallback/ramstage.debug The address where build/cbfs/fallback/ramstage.debug has been loaded is missing And with address: gdb$ add-symboadd-symbol-file build/cbfs/fallback/ramstage.debug 0x0 add symbol table from file "build/cbfs/fallback/ramstage.debug" at .text_addr = 0x0 Reading symbols from /home/pietrushnic/src/coreboot/build/cbfs/fallback/ramstage.debug...done. But util/crossgcc/xgcc/bin/armv7-a-eabi-gdb doesn't break on methods and does not show executed line of code. Symbols seems to be loaded but I cannot use them to debug. Any ideas how to debug qemu system using armv7-a-eabi-gdb ? Thanks, Piotr From john at jjdev.com Wed Aug 13 05:27:32 2014 From: john at jjdev.com (John de la Garza) Date: Tue, 12 Aug 2014 23:27:32 -0400 Subject: [coreboot] earliest running code with qemu Message-ID: <20140813032732.GA16902@vega.jjdev.com> I have just started looking at coreboot and trying to get familure with how a machine actually boots from the moment the power is turned on. Is the first piece of code to run (using qemu) found here in src/arch/x86/lib/c_start.S in _start? I was hoping to be able to play with the cache as RAM code but it seems this is not done with qemu (I understand it doesn't need to done as qemu sets things up a bit). I know it isn't necessary but, out of curiosity, could cache as RAM code run on qemu? From rminnich at gmail.com Wed Aug 13 07:05:10 2014 From: rminnich at gmail.com (ron minnich) Date: Tue, 12 Aug 2014 22:05:10 -0700 Subject: [coreboot] earliest running code with qemu In-Reply-To: <20140813032732.GA16902@vega.jjdev.com> References: <20140813032732.GA16902@vega.jjdev.com> Message-ID: I'm sure it could run were someone to implement it. ron From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 13 09:23:13 2014 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 13 Aug 2014 09:23:13 +0200 Subject: [coreboot] earliest running code with qemu In-Reply-To: References: <20140813032732.GA16902@vega.jjdev.com> Message-ID: <53EB1261.7010906@gmx.net> Am 13.08.2014 07:05 schrieb ron minnich: > I'm sure it could run were someone to implement it. A few years ago, I implemented partial MTRR support in Qemu. To be exact, I added support for not throwing away the MTRR contents after a write and now you can actually read the MTRRs after writing. That said, you'd have to add real MTRR handling to get CAR (cache-as-RAM) to work in Qemu. I once had some half-finished patches, but that was before Qemu used QOM. It might be possible to salvage these half-finished patches once I dig up my old hard drive. The mechanics of implementing CAR are a bit tricky, but I think overall maybe 200 lines of code should suffice. If you're still interested, tell me and I'll try to dig up my old patch over the next few weeks (old hard drive is in a pile, and I don't know which one has that patch). Regards, Carl-Daniel From john at jjdev.com Wed Aug 13 17:56:59 2014 From: john at jjdev.com (John de la Garza) Date: Wed, 13 Aug 2014 11:56:59 -0400 Subject: [coreboot] earliest running code with qemu In-Reply-To: <53EB1261.7010906@gmx.net> References: <20140813032732.GA16902@vega.jjdev.com> <53EB1261.7010906@gmx.net> Message-ID: <20140813155658.GA77243@John-de-la-Garzas-Macbook-Pro.local> On Wed, Aug 13, 2014 at 09:23:13AM +0200, Carl-Daniel Hailfinger wrote: > The mechanics of implementing CAR are a > bit tricky, but I think overall maybe 200 lines of code should suffice. > If you're still interested, tell me and I'll try to dig up my old patch > over the next few weeks (old hard drive is in a pile, and I don't know > which one has that patch). > I was just curious, I have almost no experience in this type of thing and am trying to learn more about low level programming. I don't want to create work for you. Thanks for the offer. From paulepanter at users.sourceforge.net Wed Aug 13 22:48:35 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Wed, 13 Aug 2014 22:48:35 +0200 Subject: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device In-Reply-To: References: <1407825687.4788.108.camel@mattotaupa> Message-ID: <1407962915.5471.58.camel@mattotaupa> Am Dienstag, den 12.08.2014, 11:01 +0100 schrieb WANG FEI: > I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with > the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36 > src\cpu\x86\Kconfig. To avoid this issue, you have to override > CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has > done. Indeed. As the change set #6535 [1] has been submitted, you do not need to do that anymore. Thanks, Paul PS: Did you report that issue to the list? It might have been fixed earlier if you had done that. [1] http://review.coreboot.org/6535 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From venture37 at gmail.com Thu Aug 14 00:25:19 2014 From: venture37 at gmail.com (Sevan / Venture37) Date: Wed, 13 Aug 2014 23:25:19 +0100 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: References: <1407823888.4788.98.camel@mattotaupa> Message-ID: > On 12 August 2014 07:11, Paul Menzel wrote: >> Thanks a lot. Could you please enable CBMEM console (menu Console) and >> time stamp capture (menu General)? Please check if CBMEM console is >> enabled in your payload (GRUB/SeaBIOS) too. > > Sure, will build a new image tonight & post up the results for you. done, this time there was no coreboot_timestamp.txt created http://pastebin.com/16LBAfBL Sevan / Venture37 From pietrushnic at gmail.com Thu Aug 14 01:51:19 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Thu, 14 Aug 2014 01:51:19 +0200 Subject: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU In-Reply-To: References: <20140810221017.GA26493@echad> <20140810221532.18133.qmail@stuge.se> <20140811090937.GD26493@echad> <20140811201055.GG22602@echad> <20140811223719.GH22602@echad> Message-ID: <20140813235116.GA11560@echad> On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote: During debugging I found that stack is initialized in range 0x40000-0x7FF00 (using .Stack and .Stack_size). When coreboot code is executed: reset init_stack_loop call_bootblock main +- armv7_invalidate_caches +- icache_invalidate_all +- dcache_invalidate_all +- dcache_foreach <- here we have ldmia instruction that cause execution out of RAM/ROM I see that SP value change but stack memory dump (x/50x 0x7FE00) show all 0xffffffff. So my questions are: - how to check on qemu-system-arm that stack was correctly initialized and works fine ? - it looks like instruction like stmdb sp!, {r0, r1, r4, r5, r6, r7, r9, r10, r11, lr} is unable to dump register values on the stack - is above range initialized for stack really correct for qemu ? - memory map show that in that range flash0 is mapped (for '-bios' option), when I memsaved this range I get all 0xffffffff, or maybe I'm confusing some different types of memory ? Thanks, Piotr From paulepanter at users.sourceforge.net Thu Aug 14 07:50:52 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Thu, 14 Aug 2014 07:50:52 +0200 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: References: <1407823888.4788.98.camel@mattotaupa> Message-ID: <1407995452.5221.47.camel@mattotaupa> Am Mittwoch, den 13.08.2014, 23:25 +0100 schrieb Sevan / Venture37: > > On 12 August 2014 07:11, Paul Menzel wrote: > >> Thanks a lot. Could you please enable CBMEM console (menu Console) and > >> time stamp capture (menu General)? Please check if CBMEM console is > >> enabled in your payload (GRUB/SeaBIOS) too. > > > > Sure, will build a new image tonight & post up the results for you. > > done, this time there was no coreboot_timestamp.txt created You did not enable time stamp collection. You need to enable them. Please verify with the following command. $ grep TIMES .config CONFIG_COLLECT_TIMESTAMPS=y > http://pastebin.com/16LBAfBL Thanks. Could you please attach the files to save the work to create and cop- paste the contents manually? In my opinion paste bin services are only useful for IRC. For emails you should always paste directly or attach the content. Thanks, Paul PS: It?d be great if you opened a separate thread about your issue with `board_status.sh -u`. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From wangfei.jimei at gmail.com Thu Aug 14 12:54:42 2014 From: wangfei.jimei at gmail.com (WANG FEI) Date: Thu, 14 Aug 2014 11:54:42 +0100 Subject: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device In-Reply-To: <1407962915.5471.58.camel@mattotaupa> References: <1407825687.4788.108.camel@mattotaupa> <1407962915.5471.58.camel@mattotaupa> Message-ID: Good news! On Wed, Aug 13, 2014 at 9:48 PM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > Am Dienstag, den 12.08.2014, 11:01 +0100 schrieb WANG FEI: > > I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with > > the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36 > > src\cpu\x86\Kconfig. To avoid this issue, you have to override > > CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has > > done. > > Indeed. As the change set #6535 [1] has been submitted, you do not need > to do that anymore. > > > Thanks, > > Paul > > > PS: Did you report that issue to the list? It might have been fixed > earlier if you had done that. > > > [1] http://review.coreboot.org/6535 > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaac.christensen at se-eng.com Thu Aug 14 23:25:14 2014 From: isaac.christensen at se-eng.com (Isaac) Date: Thu, 14 Aug 2014 15:25:14 -0600 Subject: [coreboot] nvidia/tegra build tool Message-ID: <53ED293A.3070206@se-eng.com> The new nvidia/tegra124 support requires a build tool from NVIDIA called cbootimage (https://github.com/NVIDIA/cbootimage). I'm not sure of the best way to add support into coreboot so I'd like to get some feedback. Would it make sense to just add it into the util directory and build as needed? From vidwer at gmail.com Thu Aug 14 23:29:05 2014 From: vidwer at gmail.com (Idwer Vollering) Date: Thu, 14 Aug 2014 23:29:05 +0200 Subject: [coreboot] nvidia/tegra build tool In-Reply-To: <53ED293A.3070206@se-eng.com> References: <53ED293A.3070206@se-eng.com> Message-ID: 2014-08-14 23:25 GMT+02:00 Isaac : > The new nvidia/tegra124 support requires a build tool from NVIDIA called > cbootimage (https://github.com/NVIDIA/cbootimage). I'm not sure of the best > way to add support into coreboot so I'd like to get some feedback. > > Would it make sense to just add it into the util directory and build as > needed? So it's GPL2 licenced, that's a plus. Is NVIDIA's maintainer involved, or will the tool bitrot once imported? From peter at stuge.se Thu Aug 14 23:31:25 2014 From: peter at stuge.se (Peter Stuge) Date: Thu, 14 Aug 2014 23:31:25 +0200 Subject: [coreboot] nvidia/tegra build tool In-Reply-To: <53ED293A.3070206@se-eng.com> References: <53ED293A.3070206@se-eng.com> Message-ID: <20140814213125.2609.qmail@stuge.se> Isaac wrote: > The new nvidia/tegra124 support requires a build tool from NVIDIA called > cbootimage (https://github.com/NVIDIA/cbootimage). I'm not sure of the best > way to add support into coreboot so I'd like to get some feedback. I would suggest either a git submodule or the manual equivalent like is done by the coreboot build system when building SeaBIOS. > Would it make sense to just add it into the util directory and build > as needed? No, not that. It's important that the coreboot repo only has a reference to the tool's repo and the commit hash we want to use. //Peter From stefan.reinauer at coreboot.org Fri Aug 15 00:26:40 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Fri, 15 Aug 2014 00:26:40 +0200 Subject: [coreboot] nvidia/tegra build tool In-Reply-To: <20140814213125.2609.qmail@stuge.se> References: <53ED293A.3070206@se-eng.com> <20140814213125.2609.qmail@stuge.se> Message-ID: <20140814222640.GA16114@coreboot.org> * Peter Stuge [140814 23:31]: > Isaac wrote: > > The new nvidia/tegra124 support requires a build tool from NVIDIA called > > cbootimage (https://github.com/NVIDIA/cbootimage). I'm not sure of the best > > way to add support into coreboot so I'd like to get some feedback. > > I would suggest either a git submodule or the manual equivalent like > is done by the coreboot build system when building SeaBIOS. I think either would be a good approach. submodule might be easier because iirc jenkins instances are not allowed to connect to the network while they're building. Stefan From venture37 at gmail.com Fri Aug 15 11:29:28 2014 From: venture37 at gmail.com (Sevan / Venture37) Date: Fri, 15 Aug 2014 10:29:28 +0100 Subject: [coreboot] board_status.sh output from PC Engines ALIX 2c3 In-Reply-To: <1407995452.5221.47.camel@mattotaupa> References: <1407823888.4788.98.camel@mattotaupa> <1407995452.5221.47.camel@mattotaupa> Message-ID: On 14 August 2014 06:50, Paul Menzel wrote: > Am Mittwoch, den 13.08.2014, 23:25 +0100 schrieb Sevan / Venture37: >> > On 12 August 2014 07:11, Paul Menzel wrote: >> >> Thanks a lot. Could you please enable CBMEM console (menu Console) and >> >> time stamp capture (menu General)? Please check if CBMEM console is >> >> enabled in your payload (GRUB/SeaBIOS) too. >> > >> > Sure, will build a new image tonight & post up the results for you. >> >> done, this time there was no coreboot_timestamp.txt created > > You did not enable time stamp collection. You need to enable them. > Please verify with the following command. > > $ grep TIMES .config > CONFIG_COLLECT_TIMESTAMPS=y > >> http://pastebin.com/16LBAfBL > > Thanks. Could you please attach the files to save the work to create and > cop- paste the contents manually? In my opinion paste bin services are > only useful for IRC. For emails you should always paste directly or > attach the content. > > > Thanks, > > Paul > > > PS: It?d be great if you opened a separate thread about your issue with > `board_status.sh -u`. I'd assumed that attachment where stripped & for common courtesy to subscribers, hence the use of paste bin. Attached is a screenshot of the output from the command mentioned about, the VM is running Debian 7.6. The image I generated the reports from where build with those settings. > PS: It?d be great if you opened a separate thread about your issue with > `board_status.sh -u`. I was not using board_status.sh -u, the script errors for the submission were from trying to follow: http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=util/board_status/to-wiki/README;h=2bdff5a6afc19e24eaec4b6ff102ac7777d47299;hb=HEAD -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-08-14 at 23.22.26.png Type: image/png Size: 67150 bytes Desc: not available URL: From patrick at georgi-clan.de Fri Aug 15 18:02:52 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Fri, 15 Aug 2014 18:02:52 +0200 Subject: [coreboot] nvidia/tegra build tool In-Reply-To: <20140814222640.GA16114@coreboot.org> References: <53ED293A.3070206@se-eng.com> <20140814213125.2609.qmail@stuge.se> <20140814222640.GA16114@coreboot.org> Message-ID: <53EE2F2C.9000606@georgi-clan.de> Am 15.08.2014 um 00:26 schrieb Stefan Reinauer: > I think either would be a good approach. submodule might be easier > because iirc jenkins instances are not allowed to connect to the network > while they're building. Submodule, using a local mirror. I'll set things up. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From pietrushnic at gmail.com Sat Aug 16 15:25:06 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Sat, 16 Aug 2014 15:25:06 +0200 Subject: [coreboot] qemu-armv7: memcpy to ROMSTAGE_BASE Message-ID: <20140816132503.GA5992@echad> Hi all, during debugging of qemu-armv7 I found that coreboot performs memcpy to ROMSTAGE_BASE area. This is in src/arch/armv7/memcpy.S: 3: PLD( pld [r1, #124] ) 4: ldr8w r1, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f subs r2, r2, #32 str8w r0, r3, r4, r5, r6, r7, r8, ip, lr, abort=20f bge 3b r0 at this moment (for qemu-armv7) is 0x10000 (ROMSTAGE_BASE). Is it ok that ROM area is used as storage during memory copying ? Shouldn't it be considered read only ? Am I missing something here ? Because coreboot execute from RAM this is not the problem but when I try to execute it from flash ('-bios' option) I'm unable to boot because qemu emulates flash as read only area. Is it ok to move ROMSTAGE_BASE to SRAM or this is violation of general rule ? Thanks, Piotr From rminnich at gmail.com Sat Aug 16 22:15:05 2014 From: rminnich at gmail.com (ron minnich) Date: Sat, 16 Aug 2014 13:15:05 -0700 Subject: [coreboot] qemu-armv7: memcpy to ROMSTAGE_BASE In-Reply-To: <20140816132503.GA5992@echad> References: <20140816132503.GA5992@echad> Message-ID: The ROMSTAGE on ARM is expected to be SRAM. When you know the SRAM address for a given mainboard, you need to set it up in Kconfig for *just* that mainboard. Nice work, I think you're getting close! ron From pietrushnic at gmail.com Sat Aug 16 23:13:03 2014 From: pietrushnic at gmail.com (Piotr =?iso-8859-1?Q?Kr=F3l?=) Date: Sat, 16 Aug 2014 23:13:03 +0200 Subject: [coreboot] qemu-armv7: memcpy to ROMSTAGE_BASE In-Reply-To: References: <20140816132503.GA5992@echad> Message-ID: <20140816211302.GB5992@echad> On Sat, Aug 16, 2014 at 01:15:05PM -0700, ron minnich wrote: > The ROMSTAGE on ARM is expected to be SRAM. When you know the SRAM > address for a given mainboard, you need to set it up in Kconfig for > *just* that mainboard. > > Nice work, I think you're getting close! Thanks :) Meanwhile I was able to boot qemu-armv7. It was all about memory map. All changes that I did: --- a/src/mainboard/emulation/qemu-armv7/Kconfig +++ b/src/mainboard/emulation/qemu-armv7/Kconfig @@ -64,11 +64,11 @@ config DRAM_SIZE_MB config BOOTBLOCK_BASE hex - default 0x00010000 + default 0x00000000 config ROMSTAGE_BASE hex - default 0x00020000 + default 0x48040000 config RAMSTAGE_BASE hex @@ -88,11 +88,11 @@ config CBFS_ROM_OFFSET config STACK_TOP hex - default 0x0007ff00 + default 0x4803ff00 config STACK_BOTTOM hex - default 0x00040000 + default 0x48000000 config STACK_SIZE hex I also asked qemu developers about vexpress-a9 memory map [1] and submit a noob-like blog post about debugging session of this issue [2]. If you want I can commit above changes (after I figure out how to use gerrit and all that stuff). This of course mean that '-bios' option in qemu-system-arm should be used. One last questions which bootloader you will suggest to boot Linux kernel ? U-Boot ? Or maybe it is possible to boot it directly from coreboot ? Is there tutorial/manual how to do that ? [1] http://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02599.html [2] http://pietrushnic.github.io/blog/2014/08/07/debugging-coreboot-for-qemu-armv7-vexpress-a9-emulated-mainboard/ From you2bepie at yahoo.com Sun Aug 17 15:01:48 2014 From: you2bepie at yahoo.com (a a) Date: Sun, 17 Aug 2014 06:01:48 -0700 Subject: [coreboot] problem with wake from suspend (asus chromebox 2955u) Message-ID: <1408280508.28718.YahooMailBasic@web120206.mail.ne1.yahoo.com> I have a chrombox (asus 2995u) that in setup last weekend using coreboot and seabios fix to install linux (ubuntu 14.04) The system runs fine with one flaw and I can't find the fix; it only wakes from suspend if I hit the power button - usb devices (mouse, keyboard, ...) does not wake the system. Given that I installed it last weekend (~Aug 9) I thought it carried the wake from usb fix that was added in july are there any suggestion for fix or work around ? From you2bepie at yahoo.com Sun Aug 17 19:51:52 2014 From: you2bepie at yahoo.com (ak) Date: Sun, 17 Aug 2014 13:51:52 -0400 Subject: [coreboot] problem with wake from suspend (asus chromebox 2955u) In-Reply-To: <1408280508.28718.YahooMailBasic@web120206.mail.ne1.yahoo.com> References: <1408280508.28718.YahooMailBasic@web120206.mail.ne1.yahoo.com> Message-ID: <53F0EBB8.50702@yahoo.com> I used the openeec script found here: curl -L -Ohttp://goo.gl/3Tfu5W sudo bash 3Tfu5W - I then selected #5 when it was finsihed I inserted usb stick with boot image for ubutnu 14.04; rebooted and installed ubuntu replacing all of chrome. - I've been told by the author that seabios does not handle wake on usb and it is most likely a firmware issue (or kernel issue). I'm unsure if anyone else on this mailing list runs ubuntu or if they ahve the same issue. On 08/17/14 09:01, a a wrote: > I have a chrombox (asus 2995u) that in setup last weekend using coreboot and > seabios fix to install linux (ubuntu 14.04) The system runs fine with one flaw > and I can't find the fix; it only wakes from suspend if I hit the power button - > usb devices (mouse, keyboard, ...) does not wake the system. Given that I > installed it last weekend (~Aug 9) I thought it carried the wake from usb fix > that was added in july are there any suggestion for fix or work around ? > From it21 at compuserve.com Sun Aug 17 22:53:13 2014 From: it21 at compuserve.com (Foli Ayivoh) Date: Sun, 17 Aug 2014 22:53:13 +0200 Subject: [coreboot] coreboot for old mainboard Message-ID: <2586192.H7VVjhoFBl@linux-book.home> Hi, just wanted to know if I could install coreboot onto my old board? Thanks in advance! The requested data: board vendor: Shuttle board name: AN35N Ultra V1.1 CPU: AMD Athlon XP 3200+ northbridge: Nvidia nForce2 southbridge: Nvidia MCP vendor board info: http://www.shuttle.eu/_archive/older/en/an35n_faq.htm lspci -tvnn: -[0000:00]-+-00.0 NVIDIA Corporation nForce2 IGP2 [10de:01e0] +-00.1 NVIDIA Corporation nForce2 Memory Controller 1 [10de:01eb] +-00.2 NVIDIA Corporation nForce2 Memory Controller 4 [10de:01ee] +-00.3 NVIDIA Corporation nForce2 Memory Controller 3 [10de:01ed] +-00.4 NVIDIA Corporation nForce2 Memory Controller 2 [10de:01ec] +-00.5 NVIDIA Corporation nForce2 Memory Controller 5 [10de:01ef] +-01.0 NVIDIA Corporation nForce2 ISA Bridge [10de:0060] +-01.1 NVIDIA Corporation nForce2 SMBus (MCP) [10de:0064] +-02.0 NVIDIA Corporation nForce2 USB Controller [10de:0067] +-02.1 NVIDIA Corporation nForce2 USB Controller [10de:0067] +-02.2 NVIDIA Corporation nForce2 USB Controller [10de:0068] +-04.0 NVIDIA Corporation nForce2 Ethernet Controller [10de:0066] +-06.0 NVIDIA Corporation nForce2 AC97 Audio Controler (MCP) [10de:006a] +-08.0-[01-02]--+-04.0 Adaptec AIC-7892B U160/m [9005:0081] | +-07.0 Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller [1095:3512] +-09.0 NVIDIA Corporation nForce2 IDE [10de:0065] \-1e.0-[03]-- superiotool -dV: superiotool r6158 Found ITE IT8712F (id=0x8712, rev=0x5) at 0x2e flashrom -p internal -V: flashrom v0.9.7-r1711 on Linux 3.11.10-17-pae (i686) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.2.0, GCC 4.8.1 20130909 [gcc-4_8-branch revision 202388], little endian Command line (3 args): /usr/sbin/flashrom -p internal -V Calibrating delay loop... OS timer resolution is 1 usecs, 901M loops per second, delay more than 10% too short (got 82% of expected delay), recalculating... 824M loops per second, delay more than 10% too short (got 75% of expected delay), recalculating... 1013M loops per second, 10 myus = 9 us, 100 myus = 163 us, 1000 myus = 919 us, 10000 myus = 33256 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: " " DMI string system-product-name: " " DMI string system-version: " " DMI string baseboard-manufacturer: "Shuttle Inc" DMI string baseboard-product-name: "AN35 " DMI string baseboard-version: " " DMI string chassis-type: "Desktop" Found ITE Super I/O, ID 0x8712 on port 0x2e Found chipset "NVIDIA NForce2" with PCI ID 10de:0060. Enabling flash write... OK. Super I/O ID 0x8712 is not on the list of flash capable controllers. The following protocols are supported: Non-SPI. *** Probing output reduced to findings *** Probing for Winbond W49V002A, 256 kB: probe_jedec_common: id1 0xda, id2 0xb0 Found Winbond flash chip "W49V002A" (256 kB, LPC) at physical address 0xfffc0000. Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xda, id2 0xb0 Found Winbond flash chip "W49V002A" (256 kB, LPC). No operations were specified. Restoring PCI config space for 00:01:0 reg 0x6d Restoring PCI config space for 00:01:0 reg 0x92 From info at gluglug.org.uk Mon Aug 18 05:36:27 2014 From: info at gluglug.org.uk (The Gluglug) Date: Mon, 18 Aug 2014 04:36:27 +0100 Subject: [coreboot] f2a85m and e350m1 dmidecode Message-ID: <53F174BB.2070909@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can someone with one of these boards attach their dmidecode output (from factory bios)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT8XS7AAoJEP9Ft0z50c+U268H/RmIiirFcC9GadB8v/94mkq6 beiXEMqwOPTb7+vC4JF2AsQ7n7pFLY8GRoox2LlcbyPdJMt5UEun1mlpndB381Sb SNaNzUZjxfnGVZPxsNx5PaAlzBfBC2ZjwJrW/Mk8iTdZrsVRINulMOooI6ohW66X iN+mtzz4ns/csGKrXKzcr0B01zMIbqVVPSGdHJzq29o+tUbMRL4LCVU7/vSOLn4V 8OwkwlZETJEBxDFGH/vR75wOFb+uX6BGPf3E18Cegz/N90f6fYScVkeovMetXaum cGyb8lH/04QJX90C08tx1IMjlOlEDenn2CUn6idvfXftuvCCpvyXD8XAgSZgmWQ= =JpFo -----END PGP SIGNATURE----- From david.c.hubbard+coreboot at gmail.com Mon Aug 18 05:47:21 2014 From: david.c.hubbard+coreboot at gmail.com (David Hubbard) Date: Sun, 17 Aug 2014 20:47:21 -0700 Subject: [coreboot] f2a85m and e350m1 dmidecode In-Reply-To: <53F17675.2020204@gluglug.org.uk> References: <53F174BB.2070909@gluglug.org.uk> <53F17675.2020204@gluglug.org.uk> Message-ID: On Sun, Aug 17, 2014 at 8:43 PM, The Gluglug wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > thanks! Do you know anyone with an e350m1? > Hmm, I think you can find some recent emails that mention the e350m1, within the last 6 months, by looking at the coreboot mailing list archive. I can't remember off the top of my head, though. > On 18/08/14 04:43, David Hubbard wrote: > > For f2a85 BIOS rev 5103 (an older version): > > > > # dmidecode 2.11 SMBIOS 2.7 present. 66 structures occupying 2602 > > bytes. Table at 0x000EB330. > > > > Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: > > American Megatrends Inc. Version: 5103 Release Date: 09/19/2012 > > Address: 0xF0000 Runtime Size: 64 kB ROM Size: 8192 kB > > Characteristics: PCI is supported BIOS is upgradeable BIOS > > shadowing is allowed Boot from CD is supported Selectable boot is > > supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy > > services are supported (int 13h) 3.5"/720 kB floppy services are > > supported (int 13h) 3.5"/2.88 MB floppy services are supported (int > > 13h) Print screen service is supported (int 5h) 8042 keyboard > > services are supported (int 9h) Serial services are supported (int > > 14h) Printer services are supported (int 17h) ACPI is supported USB > > legacy is supported BIOS boot specification is supported Targeted > > content distribution is supported UEFI is supported BIOS Revision: > > 4.6 > > > > Handle 0x0001, DMI type 1, 27 bytes System Information > > Manufacturer: System manufacturer Product Name: System Product > > Name Version: System Version Serial Number: System Serial Number > > UUID: [redacted] Wake-up Type: Power > > Switch SKU Number: SKU Family: To be filled by O.E.M. > > > > Handle 0x0002, DMI type 2, 15 bytes Base Board Information > > Manufacturer: ASUSTeK COMPUTER INC. Product Name: F2A85-M Version: > > Rev X.0x Serial Number: 000000000000000 Asset Tag: To be filled by > > O.E.M. Features: Board is a hosting board Board is replaceable > > Location In Chassis: To be filled by O.E.M. Chassis Handle: 0x0003 > > Type: Motherboard Contained Object Handles: 0 > > > > Handle 0x0003, DMI type 3, 22 bytes Chassis Information > > Manufacturer: Chassis Manufacture Type: Desktop Lock: Not Present > > Version: Chassis Version Serial Number: Chassis Serial Number Asset > > Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe > > Thermal State: Safe Security Status: None OEM Information: > > 0x00000000 Height: Unspecified Number Of Power Cords: 1 Contained > > Elements: 0 SKU Number: To be filled by O.E.M. > > > > Handle 0x0004, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: PS/2 Keyboard/Mouse Internal > > Connector Type: None External Reference Designator: PS/2 > > Keyboard/Mouse External Connector Type: PS/2 Port Type: Keyboard > > Port > > > > Handle 0x0005, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB34 Internal Connector Type: None > > External Reference Designator: USB34 External Connector Type: > > Access Bus (USB) Port Type: USB > > > > Handle 0x0006, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SPDIFO Internal Connector Type: > > None External Reference Designator: SPDIFO External Connector Type: > > Other Port Type: Other > > > > Handle 0x0007, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: HDMI Internal Connector Type: None > > External Reference Designator: HDMI port External Connector Type: > > Other Port Type: Other > > > > Handle 0x0008, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: D-SUB Internal Connector Type: None > > External Reference Designator: D-SUB port External Connector Type: > > Other Port Type: Other > > > > Handle 0x0009, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: DVI Internal Connector Type: None > > External Reference Designator: DVI port External Connector Type: > > Other Port Type: Other > > > > Handle 0x000A, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: ESATA Internal Connector Type: None > > External Reference Designator: ESATA External Connector Type: > > SAS/SATA Plug Receptacle Port Type: SATA > > > > Handle 0x000B, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB3_12 Internal Connector Type: > > None External Reference Designator: USB3_12 External Connector > > Type: Access Bus (USB) Port Type: USB > > > > Handle 0x000C, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: LAN Internal Connector Type: None > > External Reference Designator: LAN External Connector Type: RJ-45 > > Port Type: Network Port > > > > Handle 0x000D, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB12 Internal Connector Type: None > > External Reference Designator: USB12 External Connector Type: > > Access Bus (USB) Port Type: USB > > > > Handle 0x000E, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Line_In Internal Connector > > Type: None External Reference Designator: Audio_Line_In External > > Connector Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x000F, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Line_Out Internal Connector > > Type: None External Reference Designator: Audio_Line_Out External > > Connector Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x0010, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Mic_In Internal Connector > > Type: None External Reference Designator: Audio_Mic_In External > > Connector Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x0011, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Center/Sub Internal Connector > > Type: None External Reference Designator: Audio_Center/Sub External > > Connector Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x0012, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Rear Internal Connector Type: > > None External Reference Designator: Audio_Rear External Connector > > Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x0013, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: Audio_Side Internal Connector Type: > > None External Reference Designator: Audio_Side External Connector > > Type: Mini Jack (headphones) Port Type: Audio Port > > > > Handle 0x0014, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_1 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x0015, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_2 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x0016, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_3 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x0017, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_4 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x0018, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_5 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x0019, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_6 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x001A, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SATA6G_7 Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x001B, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: ESATA6G Internal Connector Type: > > SAS/SATA Plug Receptacle External Reference Designator: Not > > Specified External Connector Type: None Port Type: SATA > > > > Handle 0x001C, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB3_34 Internal Connector Type: > > Access Bus (USB) External Reference Designator: Not Specified > > External Connector Type: None Port Type: USB > > > > Handle 0x001D, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB78 Internal Connector Type: > > Access Bus (USB) External Reference Designator: Not Specified > > External Connector Type: None Port Type: USB > > > > Handle 0x001E, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB910 Internal Connector Type: > > Access Bus (USB) External Reference Designator: Not Specified > > External Connector Type: None Port Type: USB > > > > Handle 0x001F, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB34 Internal Connector Type: > > Access Bus (USB) External Reference Designator: Not Specified > > External Connector Type: None Port Type: USB > > > > Handle 0x0020, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: USB56 Internal Connector Type: > > Access Bus (USB) External Reference Designator: Not Specified > > External Connector Type: None Port Type: USB > > > > Handle 0x0021, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: PANEL Internal Connector Type: > > Other External Reference Designator: Not Specified External > > Connector Type: None Port Type: Other > > > > Handle 0x0022, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: COM1 Internal Connector Type: 9 Pin > > Dual Inline (pin 10 cut) External Reference Designator: Not > > Specified External Connector Type: None Port Type: Other > > > > Handle 0x0023, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: SPDIF_OUT Internal Connector Type: > > Other External Reference Designator: Not Specified External > > Connector Type: None Port Type: Other > > > > Handle 0x0024, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: AAFP Internal Connector Type: Mini > > Jack (headphones) External Reference Designator: Not Specified > > External Connector Type: None Port Type: Audio Port > > > > Handle 0x0025, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: CPU_FAN Internal Connector Type: > > Other External Reference Designator: Not Specified External > > Connector Type: None Port Type: Other > > > > Handle 0x0026, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: CHA_FAN Internal Connector Type: > > Other External Reference Designator: Not Specified External > > Connector Type: None Port Type: Other > > > > Handle 0x0027, DMI type 8, 9 bytes Port Connector Information > > Internal Reference Designator: PWR_FAN Internal Connector Type: > > Other External Reference Designator: Not Specified External > > Connector Type: None Port Type: Other > > > > Handle 0x0028, DMI type 9, 17 bytes System Slot Information > > Designation: PCIEX16_1 Type: 32-bit PCI Express Current Usage: In > > Use Length: Short ID: 1 Characteristics: 3.3 V is provided Opening > > is shared PME signal is supported Bus Address: 0000:00:01.0 > > > > Handle 0x0029, DMI type 9, 17 bytes System Slot Information > > Designation: PCIEX1_2 Type: 32-bit PCI Express Current Usage: In > > Use Length: Short ID: 2 Characteristics: 3.3 V is provided Opening > > is shared PME signal is supported Bus Address: 0000:00:1c.4 > > > > Handle 0x002A, DMI type 9, 17 bytes System Slot Information > > Designation: PCI1 Type: 32-bit PCI Current Usage: In Use Length: > > Short ID: 3 Characteristics: 3.3 V is provided Opening is shared > > PME signal is supported Bus Address: 0000:00:1c.6 > > > > Handle 0x002B, DMI type 9, 17 bytes System Slot Information > > Designation: PCIEX16_2 Type: 32-bit PCI Express Current Usage: In > > Use Length: Short ID: 4 Characteristics: 3.3 V is provided Opening > > is shared PME signal is supported Bus Address: 0000:00:01.0 > > > > Handle 0x002C, DMI type 10, 10 bytes On Board Device 1 Information > > Type: Video Status: Enabled Description: To Be Filled By O.E.M. > > On Board Device 2 Information Type: Ethernet Status: Enabled > > Description: To Be Filled By O.E.M. On Board Device 3 Information > > Type: Sound Status: Enabled Description: To Be Filled By O.E.M. > > > > Handle 0x002D, DMI type 11, 5 bytes OEM Strings String 1: To Be > > Filled By O.E.M. > > > > Handle 0x002E, DMI type 12, 5 bytes System Configuration Options > > Option 1: To Be Filled By O.E.M. > > > > Handle 0x002F, DMI type 16, 23 bytes Physical Memory Array > > Location: System Board Or Motherboard Use: System Memory Error > > Correction Type: None Maximum Capacity: 8 GB Error Information > > Handle: Not Provided Number Of Devices: 4 > > > > Handle 0x0030, DMI type 19, 31 bytes Memory Array Mapped Address > > Starting Address: 0x00000000000 Ending Address: 0x003FFFFFFFF Range > > Size: 16 GB Physical Array Handle: 0x002F Partition Width: 255 > > > > Handle 0x0031, DMI type 17, 34 bytes Memory Device Array Handle: > > 0x002F Error Information Handle: Not Provided Total Width: 64 bits > > Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None > > Locator: DIMM_A1 Bank Locator: A1_BANK0 Type: DDR3 Type Detail: > > Synchronous Unbuffered (Unregistered) Speed: 800 MHz Manufacturer: > > Undefined Serial Number: 00000000 Asset Tag: A1_AssetTagNum1 Part > > Number: F3-17000CL11-4GBXL Rank: 2 Configured Clock Speed: Unknown > > > > Handle 0x0032, DMI type 20, 35 bytes Memory Device Mapped Address > > Starting Address: 0x00000000000 Ending Address: 0x000FFFFFFFF Range > > Size: 4 GB Physical Device Handle: 0x0031 Memory Array Mapped > > Address Handle: 0x0030 Partition Row Position: 1 > > > > Handle 0x0033, DMI type 17, 34 bytes Memory Device Array Handle: > > 0x002F Error Information Handle: Not Provided Total Width: 64 bits > > Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None > > Locator: DIMM_A2 Bank Locator: A1_BANK1 Type: DDR3 Type Detail: > > Synchronous Unbuffered (Unregistered) Speed: 800 MHz Manufacturer: > > Undefined Serial Number: 00000000 Asset Tag: A1_AssetTagNum0 Part > > Number: F3-17000CL11-4GBXL Rank: 2 Configured Clock Speed: 39335 > > MHz > > > > Handle 0x0034, DMI type 20, 35 bytes Memory Device Mapped Address > > Starting Address: 0x00100000000 Ending Address: 0x001FFFFFFFF Range > > Size: 4 GB Physical Device Handle: 0x0033 Memory Array Mapped > > Address Handle: 0x0030 Partition Row Position: 1 > > > > Handle 0x0035, DMI type 17, 34 bytes Memory Device Array Handle: > > 0x002F Error Information Handle: Not Provided Total Width: 64 bits > > Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None > > Locator: DIMM_B1 Bank Locator: A1_BANK2 Type: DDR3 Type Detail: > > Synchronous Unbuffered (Unregistered) Speed: 800 MHz Manufacturer: > > Undefined Serial Number: 00000000 Asset Tag: A1_AssetTagNum2 Part > > Number: F3-17000CL11-4GBXL Rank: 2 Configured Clock Speed: Unknown > > > > Handle 0x0036, DMI type 20, 35 bytes Memory Device Mapped Address > > Starting Address: 0x00200000000 Ending Address: 0x002FFFFFFFF Range > > Size: 4 GB Physical Device Handle: 0x0035 Memory Array Mapped > > Address Handle: 0x0030 Partition Row Position: 1 > > > > Handle 0x0037, DMI type 17, 34 bytes Memory Device Array Handle: > > 0x002F Error Information Handle: Not Provided Total Width: 64 bits > > Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None > > Locator: DIMM_B2 Bank Locator: A1_BANK3 Type: DDR3 Type Detail: > > Synchronous Unbuffered (Unregistered) Speed: 800 MHz Manufacturer: > > Undefined Serial Number: 00000000 Asset Tag: A1_AssetTagNum3 Part > > Number: F3-17000CL11-4GBXL Rank: 2 Configured Clock Speed: 1 MHz > > > > Handle 0x0038, DMI type 20, 35 bytes Memory Device Mapped Address > > Starting Address: 0x00300000000 Ending Address: 0x003FFFFFFFF Range > > Size: 4 GB Physical Device Handle: 0x0037 Memory Array Mapped > > Address Handle: 0x0030 Partition Row Position: 1 > > > > Handle 0x0039, DMI type 32, 20 bytes System Boot Information > > Status: No errors detected > > > > Handle 0x003A, DMI type 41, 11 bytes Onboard Device Reference > > Designation: Onboard IGD Type: Video Status: Enabled Type > > Instance: 1 Bus Address: 0000:00:02.0 > > > > Handle 0x003B, DMI type 41, 11 bytes Onboard Device Reference > > Designation: Onboard LAN Type: Ethernet Status: Enabled Type > > Instance: 1 Bus Address: 0000:00:19.0 > > > > Handle 0x003C, DMI type 41, 11 bytes Onboard Device Reference > > Designation: Onboard 1394 Type: Other Status: Enabled Type > > Instance: 1 Bus Address: 0000:03:1c.2 > > > > Handle 0x003D, DMI type 7, 19 bytes Cache Information Socket > > Designation: L1 CACHE Configuration: Enabled, Not Socketed, Level > > 1 Operational Mode: Write Back Location: Internal Installed Size: > > 192 kB Maximum Size: 192 kB Supported SRAM Types: Pipeline Burst > > Installed SRAM Type: Pipeline Burst Speed: 1 ns Error Correction > > Type: Multi-bit ECC System Type: Unified Associativity: 2-way > > Set-associative > > > > Handle 0x003E, DMI type 7, 19 bytes Cache Information Socket > > Designation: L2 CACHE Configuration: Enabled, Not Socketed, Level > > 2 Operational Mode: Write Back Location: Internal Installed Size: > > 4096 kB Maximum Size: 4096 kB Supported SRAM Types: Pipeline Burst > > Installed SRAM Type: Pipeline Burst Speed: 1 ns Error Correction > > Type: Multi-bit ECC System Type: Unified Associativity: 16-way > > Set-associative > > > > Handle 0x0047, DMI type 4, 42 bytes Processor Information Socket > > Designation: FM2 Type: Central Processor Family: > > Manufacturer: AuthenticAMD ID: 31 0F 61 00 FF FB 8B 17 Version: AMD > > A10-6800K APU with Radeon(tm) HD Graphics Voltage: 1.3 V External > > Clock: 100 MHz Max Speed: 4100 MHz Current Speed: 4100 MHz Status: > > Populated, Enabled Upgrade: L1 Cache Handle: 0x003D > > L2 Cache Handle: 0x003E L3 Cache Handle: Not Provided Serial > > Number: Not Specified Asset Tag: Not Specified Part Number: Not > > Specified Core Count: 4 Core Enabled: 4 Thread Count: 4 > > Characteristics: 64-bit capable > > > > Handle 0x0048, DMI type 13, 22 bytes BIOS Language Information > > Language Description Format: Long Installable Languages: 8 > > en|US|iso8859-1 fr|FR|iso8859-1 es|ES|iso8859-1 de|DE|iso8859-1 > > ru|RU|iso8859-5 ja|JP|unicode zh|TW|unicode zh|CN|unicode Currently > > Installed Language: en|US|iso8859-1 > > > > Handle 0x0049, DMI type 127, 4 bytes End Of Table > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJT8XZ1AAoJEP9Ft0z50c+Uqt8IALfc2WPv27t1LqqoW5h3Db5n > Nkfv1IIu/yungrFLuigu93HcnDO7Xg4A4rboWOhbiOyNIFAc35lPeyJ/wtv4qhjX > 3Oo+NJ3IFJMuFSRK7/PikIPcb8fEAwbmmEkKWn0c9s2QtmHmdxmaEcY6jQ9GPdNs > lrMY/jUjUgJxcgHMidPw55xAL+0m9c9VhLuaenk9xX1EvdFU/fk4QuftpX5bGdAS > FDtOxIxTv/HQ0yGnUKfcDx8p7BYae3lv2g7QR5u/GEZKon72hlmtc9PvYAPH0wda > NTj8u+wI2sX5vx+mdi2K05F6hI4Ic2jKaI7SavImFCUXTOIAcKDkW81PY8dkctI= > =X277 > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulepanter at users.sourceforge.net Mon Aug 18 07:31:02 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Mon, 18 Aug 2014 07:31:02 +0200 Subject: [coreboot] coreboot for old mainboard Shuttle AN35N Ultra V1.1 (Nvidia nForce2) In-Reply-To: <2586192.H7VVjhoFBl@linux-book.home> References: <2586192.H7VVjhoFBl@linux-book.home> Message-ID: <1408339862.4112.29.camel@mattotaupa> Dear Foli, Am Sonntag, den 17.08.2014, 22:53 +0200 schrieb Foli Ayivoh: > Hi, just wanted to know if I could install coreboot onto my old board? > Thanks in advance! > > The requested data: > > board vendor: Shuttle > board name: AN35N Ultra V1.1 > CPU: AMD Athlon XP 3200+ > northbridge: Nvidia nForce2 that northbridge is not supported and is unlikely it ever will be considering how Nvidia does not release any documentation at all for x86 device ? same as for graphic device. I heard they are much better with ARM devices though. So there is hope. So better use AMD based boards if you want to use x86 devices. [?] Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From manuel.h87 at gmail.com Mon Aug 18 17:18:16 2014 From: manuel.h87 at gmail.com (Manuel Huber) Date: Mon, 18 Aug 2014 17:18:16 +0200 Subject: [coreboot] Try to get Intel Atom based COMe-cXLi2 Kontron board running Message-ID: Hello coreboot community, I'm currently trying to add support for the cXLi2 COM Express board from Kontron (I'm working for TTTech Automotive GmbH). On IRC, I have already talked to members of the coreboot community and started to prepare the new board. I'm basing my work on the iWave/iWRainbowG6 (which is quite different). Most important components are: - Processor: Intel Atom Z520PT - Chipset: Intel SCH US15WPT (Poulsbo) - Super-IO: Winbond W83627HG - BIOS flash chip: SST49LF008A Unfortunately, there was no output on the serial line and I haven't got a POST card yet. So I thought it should be easy to get the chipset to beep. I checked under Linux (using the vendor BIOS) and in the datasheet and it seems to be correct. I added the beep code to romstage.cc:main(). But nothing happened... I checked again, and thought that maybe, the boot process gets stuck earlier, so I rewrote the beep-code in ASM and added it just after entering protected mode (which seems to be pretty early...) -> but again, no sound. (under Linux both, the asm code, and the C-code work). Beep code: diff --git a/src/cpu/x86/32bit/entry32.inc b/src/cpu/x86/32bit/entry32.inc index f74e1b8..d46b883 100644 --- a/src/cpu/x86/32bit/entry32.inc +++ b/src/cpu/x86/32bit/entry32.inc @@ -52,6 +52,18 @@ __protected_start: /* Save the BIST value */ movl %eax, %ebp + /* Beep ! */ + movb $0xb6, %al + outb %al, $0x43 + movb $0xa9, %al + outb %al, $0x52 + movb $0x04, %al + outb %al, $0x52 + inb $0x61, %al + orb $0x03, %al + outb %al, $0x61 + movl %ebp, %eax + post_code(POST_ENTER_PROTECTED_MODE) movw $ROM_DATA_SEG, %ax ---------------------------------------------------------------------- 0xb6 => 10 11 011 0 Timer2 | Write LSB then MSB | Square Wave Output | binary ---------------------------------------------------------------------- So I guess I'm doing something completely wrong. I have to use an external flash programmer (DATAMAN-48Pro2) to actually program the flash chip since the SCH and my vendor bios image block access to the chip. So I can't use flashrom to program the device. The Dataman just loads the coreboot.rom image and write it to the memory. I'm currently just using the iWRainbowG6 code base directly (I though there that maybe I got my Kconfigs and Makefiles wrong)... (I have already created the new board and of course I want to prepare my code to be able to push it upstream if it ever works) However, using the original BIOS (which also takes 8192KB) and flashing it with the DATAMAN can boot. Is there something I'm forgetting, shouldn't the 'beep' work? Am I missing some initialization code? Sorry if my questions | assumptions are somehow stupid. I hope you can help me and point me in the right direction. Best regards, Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Aug 18 18:24:20 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 18 Aug 2014 09:24:20 -0700 Subject: [coreboot] Try to get Intel Atom based COMe-cXLi2 Kontron board running In-Reply-To: References: Message-ID: These are not stupid questions at all. Have you considered getting an EM100? That would give you a little more debugging. A post card is about the single most useful thing to have in the early going, so you should probably get that before you go much further. Beep is a lot harder than it used to be. While simple code may work on Linux, there's a lot more going on under the hood, because the simple beep can be driven by a very complex audio pipeline. Beep may not be a good place to start. Here's a slightly bigger question: does it have to be an x86? Could it be ARM? Because here's a true story. I'm answering questions from some security researchers who *were* working on a haswell chromebook (Acer C720). Last week they realized that Intel was not going to make the blobs available for the memory startup (MRC) and the ME for haswell chromebooks. Those blobs are available for the sandy and ivybridge chromebooks, but nothing that came after. Result: all the researcher's work is moving to the Samsung ARM Chromeook because the ARM vendors tend to be a lot more helpful (save for AMD, nowadays; there are lots of unanswered questions there). I'm sad about that because Acer C720 is a great laptop and haswell is a great chipset, but what can you do? Note that the new Acer 13 is an ARM Tegra system that runs coreboot. So, just to be sure: it has to be an Atom? It's a much harder road than an ARM nowadays. ron From manuel.h87 at gmail.com Mon Aug 18 22:03:32 2014 From: manuel.h87 at gmail.com (Manuel Huber) Date: Mon, 18 Aug 2014 22:03:32 +0200 Subject: [coreboot] Try to get Intel Atom based COMe-cXLi2 Kontron board running In-Reply-To: References: Message-ID: <53F25C14.3040208@gmail.com> Thanks for your quick reply :) - EM100 sounds like a good idea; It seems to me as if I should wait for the POST card. By reading the Intel specification of the SCH I got the feeling that issuing a 'beep' would be quite easy (well - it took me a day to just understand what Intel tried to say - but that's probably my fault...) as there is a simple buzzer connected to some transistor on the output pin of the SCH. Just configuring the Timer and enabling the output... (clock source seems to be the main clock source...) But that would have been too easy, I guess... Toggling some GPIO won't be any easier I suppose... Unfortunately it has to be an Intel Atom as we try to decrease the boot time of our current DataLogger: https://www.tttech.com/products/automotive/testing-tools/data-logging/ttx-datalogger/ I have already been pointed to SageBios, but while project leaders are deciding where to go it's my task to at least try to get the old system running - to be able to estimate the effort and what we can expect as result... I'm pretty sure the Intel Atom board is not the best starting-point - but there was some hope to at least get some debug message out of the board as the chipset seems to have been supported at some point in time... I'm a little frightened that when I finally get the POST card, it will not output anything... Manuel From rminnich at gmail.com Mon Aug 18 23:42:04 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 18 Aug 2014 14:42:04 -0700 Subject: [coreboot] Try to get Intel Atom based COMe-cXLi2 Kontron board running In-Reply-To: <53F25C14.3040208@gmail.com> References: <53F25C14.3040208@gmail.com> Message-ID: If Time is of the Essence I don't see how you can do better than getting Sage into the picture. Just my opinion. Deep expertise, smart people, and they're committed to coreboot. Disclaimer: Not speaking for anyone but me, myself, and I; I've got no financial stake, I just know the people and like them very much :-) Other than that, again, yeah, beep always sounds easy. I've seen what it takes on some chipsets and it starts to sound less easy over time. Your call. It's not your fault that you don't understand the docs. The docs suck, always, and they're always missing little things. Just part of the game. ron From dnc at hipplanet.com Tue Aug 19 09:19:59 2014 From: dnc at hipplanet.com (David Melik) Date: Tue, 19 Aug 2014 00:19:59 -0700 Subject: [coreboot] Coreboot on an Asus P9X79 LE (2) Message-ID: <20140819001959.A7D1568E@m0048136.ppops.net> I had missed the part I have to give info on the type of BIOS chip. It looks like a DIP8 and says the below. Winbond 25064FVAIG 1231 --David _____________________________________________________________ Find out what's HIP! Visit Hip Planet for news, shopping, forums, chatrooms, free personal and classified ads and much more! Get FREE E-MAIL! at HipPlanet now! It's all waiting for you, at http://www.hipplanet.com From dnc at hipplanet.com Tue Aug 19 09:10:19 2014 From: dnc at hipplanet.com (David Melik) Date: Tue, 19 Aug 2014 00:10:19 -0700 Subject: [coreboot] Coreboot on an Asus P9X79 LE Message-ID: <20140819001019.A7D156C0@m0048136.ppops.net> I would like to find out if Coreboot could work for a couple relatively new Asus systemboards--for now a P9X79 LE. I am not sure about all the details about the north & south bridges, but the manual says it has an Intel X79 chipset and does not really show another large chip on the diagram (I also looked and did not see one, but there is a lot of stuff in my case)... let me know how else I would find out anything else necessary. I am attaching text files with the output of the three commands listed as needed in the FAQ. The specification page is http://www.asus.com/us/Motherboards/P9X79_LE/specifications/ . David http://www.cwu.edu/~melikd/ _____________________________________________________________ Find out what's HIP! Visit Hip Planet for news, shopping, forums, chatrooms, free personal and classified ads and much more! Get FREE E-MAIL! at HipPlanet now! It's all waiting for you, at http://www.hipplanet.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: flashrom_output.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci_output.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: superiotool_output.txt URL: From jlewis at johnlewis.ie Tue Aug 19 17:00:52 2014 From: jlewis at johnlewis.ie (John Lewis) Date: Tue, 19 Aug 2014 16:00:52 +0100 Subject: [coreboot] ASUS C200 Chromebook Message-ID: <53F366A4.6080209@johnlewis.ie> Hi Guys, long time no speak. I'm building a ROM for the subject using ChromiumOS coreboot with the relevant branch, and I'm just wondering if the external reference code binary is needed? It builds okay without it (commenting out ChromeOS specific bits that it complains about), and I can even get it to compile cleanly with the option enabled. However, I can't seem to correctly extract the binary from the shell-ball ROM using cbfstool, because at build time, it complains "E: The stage file is not in ELF format!". Can one of you point me in the right direction? Thanks, John. From adurbin at chromium.org Tue Aug 19 17:22:26 2014 From: adurbin at chromium.org (Aaron Durbin) Date: Tue, 19 Aug 2014 10:22:26 -0500 Subject: [coreboot] ASUS C200 Chromebook In-Reply-To: <53F366A4.6080209@johnlewis.ie> References: <53F366A4.6080209@johnlewis.ie> Message-ID: On Tue, Aug 19, 2014 at 10:00 AM, John Lewis wrote: > Hi Guys, long time no speak. > > I'm building a ROM for the subject using ChromiumOS coreboot with the > relevant branch, and I'm just wondering if the external reference code > binary is needed? > I think so. It has a lot of hardware specific bits for enabling clocks, etc for pci and usb iirc. That's about all there is in there. > > It builds okay without it (commenting out ChromeOS specific bits that it > complains about), and I can even get it to compile cleanly with the option > enabled. However, I can't seem to correctly extract the binary from the > shell-ball ROM using cbfstool, because at build time, it complains "E: The > stage file is not in ELF format!". Can one of you point me in the right > direction? > > How are you extracting it? Does cbfstool list the file? You could add it as a raw file as a workaround. Alternatively, it's possible to re-make it into an elf. This is the same problem as any other stage. Once you add it and pull it out it can't be added back w/ add-stage. It's not loaded like a stage, and to be honest I can't remember why I chose to use add-stage to begin with. I have a feeling I didn't want to change anything for relocatable ramstage in the Makefile so I did it like that. Then just did something similar. > Thanks, > > John. > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlewis at johnlewis.ie Tue Aug 19 17:30:48 2014 From: jlewis at johnlewis.ie (John Lewis) Date: Tue, 19 Aug 2014 16:30:48 +0100 Subject: [coreboot] ASUS C200 Chromebook In-Reply-To: References: <53F366A4.6080209@johnlewis.ie> Message-ID: <53F36DA8.4080808@johnlewis.ie> On 19/08/14 16:22, Aaron Durbin wrote: > > How are you extracting it? Does cbfstool list the file? You could add > it as a raw file as a workaround. Alternatively, it's possible to > re-make it into an elf. This is the same problem as any other stage. > Once you add it and pull it out it can't be added back w/ add-stage. > It's not loaded like a stage, and to be honest I can't remember why I > chose to use add-stage to begin with. I have a feeling I didn't want to > change anything for relocatable ramstage in the Makefile so I did it > like that. Then just did something similar. > Yeah, cbfstool lists the file, and I can extract it, just the make process doesn't like sticking it back in. Okay, I'm fine with editing the make file, and adding it as a raw file. Now to get someone daft enough to test it. ;) Thank you! From jlewis at johnlewis.ie Tue Aug 19 17:56:19 2014 From: jlewis at johnlewis.ie (John Lewis) Date: Tue, 19 Aug 2014 16:56:19 +0100 Subject: [coreboot] CBFS size Message-ID: <53F373A3.1050906@johnlewis.ie> Another question - At the moment CBFS size seems to be restricted to a maximum of 4 MB in an 8 MB ROM, and I'm wondering if there is any way to get around the "power of 2" and use a 6 MB CBFS? I've disabled the check, but it results in floppy images which fail to decompress/extract correctly, presumably due to some technical alignment reason. Thanks in advance, John. From matt.devillier at gmail.com Tue Aug 19 18:45:00 2014 From: matt.devillier at gmail.com (Matt DeVillier) Date: Tue, 19 Aug 2014 11:45:00 -0500 Subject: [coreboot] problem with wake from suspend (asus chromebox 2955u) In-Reply-To: <53F0EBB8.50702@yahoo.com> References: <1408280508.28718.YahooMailBasic@web120206.mail.ne1.yahoo.com> <53F0EBB8.50702@yahoo.com> Message-ID: As I mentioned on G+, it's almost definitely a kernel/distro config/device issue, as USB wake from suspend is working perfectly well for the Asus/HP ChromeBox (panther/zako) on other setups (OpenELEC, Fedora). Since you're using Ubuntu, ubuntuforums.com would be a good starting point I'd expect. On Sun, Aug 17, 2014 at 12:51 PM, ak wrote: > I used the openeec script found here: > curl -L -Ohttp://goo.gl/3Tfu5W > sudo bash 3Tfu5W > - > I then selected #5 when it was finsihed I inserted usb stick with boot > image for ubutnu 14.04; rebooted and installed ubuntu replacing all of > chrome. > - > I've been told by the author that seabios does not handle wake on usb and > it is most likely a firmware issue (or kernel issue). I'm unsure if anyone > else on this mailing list runs ubuntu or if they ahve the same issue. > > > > > On 08/17/14 09:01, a a wrote: > >> I have a chrombox (asus 2995u) that in setup last weekend using coreboot >> and >> seabios fix to install linux (ubuntu 14.04) The system runs fine with >> one flaw >> and I can't find the fix; it only wakes from suspend if I hit the power >> button - >> usb devices (mouse, keyboard, ...) does not wake the system. Given that >> I >> installed it last weekend (~Aug 9) I thought it carried the wake from usb >> fix >> that was added in july are there any suggestion for fix or work around ? >> >> > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at gluglug.org.uk Thu Aug 21 23:08:29 2014 From: info at gluglug.org.uk (The Gluglug) Date: Thu, 21 Aug 2014 22:08:29 +0100 Subject: [coreboot] X60: ethernet LED still on when machine is powered off or suspended Message-ID: <53F65FCD.70806@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A little quirk I noticed. If I put the machine in suspend while an ethernet cable is plugged in to a switch (or if plugging it in after suspending), the green light from the ethernet/eth0 is still active. Any ideas? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT9l/NAAoJEP9Ft0z50c+UaF4H/jqCZlmVadTnM0YZidrhRL2Q 6V6dUaskvg9CjXr6H4p8LvFVsBek3A2id9yRvqidbR98+O3Q2OUSgqhdMNNN9Kqh eWAhJ6Pni2qV4OmVkHhTIWZxVQwbVJGbQP1RLQ1hRsPfBxVcQIr/uhyYqZCov5BB VXCRGJD9n5gysr2QN9ccuKhqWXqqdUi00tGwXgqO3SIQ61piNJGgUZlWObDeEB23 whZV3Sqf0zn9wT61euTtEghspisM4ihi8oDe78Aav9SthmagVr6DSz3wr/Ww+cti BIFTtbK9y+RHRvlLH35F8OFGr+X2le5QQtEhonqh4yoRuIAEN1w13lm55Y6XlpU= =T1KC -----END PGP SIGNATURE----- From info at gluglug.org.uk Thu Aug 21 23:10:32 2014 From: info at gluglug.org.uk (The Gluglug) Date: Thu, 21 Aug 2014 22:10:32 +0100 Subject: [coreboot] X60: ethernet LED still on when machine is powered off or suspended In-Reply-To: <53F65FCD.70806@gluglug.org.uk> References: <53F65FCD.70806@gluglug.org.uk> Message-ID: <53F66048.2080701@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/08/14 22:08, The Gluglug wrote: > A little quirk I noticed. If I put the machine in suspend while an > ethernet cable is plugged in to a switch (or if plugging it in > after suspending), the green light from the ethernet/eth0 is still > active. > > Any ideas? > The same thing also happens while the machine is powered off, if I leave the AC adapter/charger connected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT9mBIAAoJEP9Ft0z50c+UmxwH/Rn7Gdxk+Vp9uqdp8XD3AeoV D2Lr5YC3j6bnF3sg9I0dDE+UJatXUHXlgF8lemsyrSfHx/4CFXKvT6FtTgkW08lt E01q5Z71mgB6rGkjX4gLf3wQPldtPj4QElCGaHB1K/vO2vuYg/YqdR83B38VkVdH uSoakYvlw6Q4EWRTkTcya0mo9JQu3DCpfd+m5HTSR/aTYxpIExWsb6OiC8DKdYrO sSWReZIPBYKbnyIg6dDJu3reqiQG0uNBI9fkWX6dHJQse+WMQAAMLHPadgLt67+p 5pKurKiJdyYDuzwntiXESXN1cF3SnWWnTEfJoiR6oWGqFnL5s+HAhtwtTxahv9I= =Hqca -----END PGP SIGNATURE----- From rminnich at gmail.com Fri Aug 22 00:41:02 2014 From: rminnich at gmail.com (ron minnich) Date: Thu, 21 Aug 2014 15:41:02 -0700 Subject: [coreboot] X60: ethernet LED still on when machine is powered off or suspended In-Reply-To: <53F66048.2080701@gluglug.org.uk> References: <53F65FCD.70806@gluglug.org.uk> <53F66048.2080701@gluglug.org.uk> Message-ID: On Thu, Aug 21, 2014 at 2:10 PM, The Gluglug wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 21/08/14 22:08, The Gluglug wrote: >> A little quirk I noticed. If I put the machine in suspend while an >> ethernet cable is plugged in to a switch (or if plugging it in >> after suspending), the green light from the ethernet/eth0 is still >> active. >> >> Any ideas? >> > > The same thing also happens while the machine is powered off, if I > leave the AC adapter/charger connected. and only on coreboot? I can't recall but I did have laptops that would light the LED even when off, I always assumed it was the ME ron From info at gluglug.org.uk Fri Aug 22 03:22:01 2014 From: info at gluglug.org.uk (The Gluglug) Date: Fri, 22 Aug 2014 02:22:01 +0100 Subject: [coreboot] X60: ethernet LED still on when machine is powered off or suspended In-Reply-To: References: <53F65FCD.70806@gluglug.org.uk> <53F66048.2080701@gluglug.org.uk> Message-ID: <53F69B39.6040406@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/08/14 23:41, ron minnich wrote: > On Thu, Aug 21, 2014 at 2:10 PM, The Gluglug > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> >> On 21/08/14 22:08, The Gluglug wrote: >>> A little quirk I noticed. If I put the machine in suspend >>> while an ethernet cable is plugged in to a switch (or if >>> plugging it in after suspending), the green light from the >>> ethernet/eth0 is still active. >>> >>> Any ideas? >>> >> >> The same thing also happens while the machine is powered off, if >> I leave the AC adapter/charger connected. > > > and only on coreboot? > > I can't recall but I did have laptops that would light the LED even > when off, I always assumed it was the ME > > ron > Haven't tried it on factory.bin. Will let you know. i945 doesn't have ME/AMT, as far as I know. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT9ps5AAoJEP9Ft0z50c+UWKsIAJn5w/+6RxZ6oyhqaHSuJoBq 2/YHDL5TYM7EW0XoBstcB2NS7W/lWtWfwpCvNvM9R3ynliqPoAjErMZIuTwPM4p9 wBFvNdSWJGHOgxi8KEDA1n2Af0Dhfoys6Wb+uI3hflGGunJHz05QWiMEos0dWkmU JsZVr2HCrjIKTGooXJxZXfRlD6SY2S3PNY7myDcfeAaTnx6kCsySFCqBkfIUTIhf Mtg1NosYrbmNAXqROwrHf5LO3oAJ41zODZraMspYy+QDE8XvO2wbzkDBtglV4rBn V7qO7PaS1l1jfOlERTd3A6ZEXI4ltzr8BTwe3ZTZod+zrs9R9/May4JasN4lKe4= =on0Y -----END PGP SIGNATURE----- From xchip at hush.ai Sat Aug 23 11:41:34 2014 From: xchip at hush.ai (xchip at hush.ai) Date: Sat, 23 Aug 2014 11:41:34 +0200 Subject: [coreboot] Problems with Coreboot and SeaBIOS on VIA EPIA-M Message-ID: <20140823094135.2005B601F3@smtp.hushmail.com> Hello, I have been trying to use Coreboot (with SeaBIOS as payload) on a VIA EPIA-M mainboard, but had some problems with it. I have built everything with the toolchain that comes with Coreboot. To make everything (Coreboot + VGA BIOS + SeaBIOS) fit in the 256 KB flash memory, I had to LZMA compress both Coreboot and SeaBIOS. Unfortunately LZMA compression did not work for either Coreboot, nor for the payload. When compressing Coreboot's ramstage with LZMA, on boot it fails with the following error message when trying to decompress it: Trying CBFS ramstage loader. CBFS: loading stage fallback/ramstage @ 0x100000 (151600 bytes), entry @ 0x100000 CBFS: tried to decompress 43540 bytes with algorithm #1,but that algorithm id is unsupported. Ramstage was not loaded! The next thing I tried was to omit the VGA BIOS, so I could fit Coreboot and SeaBIOS uncompressed in the flash memory. With that configuration Coreboot was able to finish successfully and then load SeaBIOS. Unfortunately, SeaBIOS did not do much besides printing two lines of text: SeaBIOS (version rel-1.7.5-42-g275672e-20140817_233743-themachine) 0 After that, it would reboot the machine and it would do the same thing over and over again. It made no difference when I increased the debug output level of SeaBIOS. Next I tried to figure out why LZMA compression did not work. LZMA compression is compiled when CBFS_CORE_WITH_LZMA is defined. I figured out that it gets defined at the beginning of src/lib/cbfs.c, depending on a few conditions. Even though I had enabled LZMA compression through the configuration menu, the constant did not get defined, though. So what I then tried was to define it unconditionally in that cbfs.c file. I did not investigate further which condition prevented it from being defined in the first place, but that change allowed me to build a Coreboot ROM where the romstage LZMA decompression worked fine. LZMA decompression of the payload still did not work, though. It failed with an error message: CBFS: located payload @ fffed238, 48776 bytes. Loading segment from rom address 0xfffed238 code (compression=1) New segment dstaddr 0xe9880 memsize 0x16780 srcaddr 0xfffed270 filesize 0xbe50 (cleaned up) New segment addr 0xe9880 size 0x16780 offset 0xfffed270 filesize 0xbe50 Loading segment from rom address 0xfffed254 Entry Point 0x000fd1e9 Bounce Buffer at 0df95000, 303200 bytes Loading Segment: addr: 0x00000000000e9880 memsz: 0x0000000000016780 filesz: 0x000000000000be50 lb: [0x0000000000100000, 0x0000000000125030) Post relocation: addr: 0x00000000000e9880 memsz: 0x0000000000016780 filesz: 0x000000000000be50 using LZMA lzma: Decoding error = 1 Could not load payload Using a compressed Coreboot and uncompressed SeaBIOS did not change SeaBIOS' behavior. It still prints only its version string and a 0 on the next line. I tried both the default configuration of SeaBIOS and with a more stripped down configuration (leaving out unused stuff like XHCI and OHCI, no splash screen etc. to reduce its size). None of the changes I tried made a difference in SeaBIOS' behavior. Any help or hints on what I might be missing are very appreciated. If you need any more information, please let me know. I did not attach any config files/log files yet, because I tried so many different things. Thanks xchip -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulepanter at users.sourceforge.net Sat Aug 23 13:53:00 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Sat, 23 Aug 2014 13:53:00 +0200 Subject: [coreboot] Problems with coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: <20140823094135.2005B601F3@smtp.hushmail.com> References: <20140823094135.2005B601F3@smtp.hushmail.com> Message-ID: <1408794780.2724.52.camel@mattotaupa> Dear xchip, welcome again to coreboot and thank you for following the advice in IRC channel and contacting the mailing list! Am Samstag, den 23.08.2014, 11:41 +0200 schrieb xchip at hush.ai: > I have been trying to use Coreboot (with SeaBIOS as payload) on a VIA > EPIA-M mainboard, but had some problems with it. I have built > everything with the toolchain that comes with Coreboot. [?] > I tried both the default configuration of SeaBIOS and with a more > stripped down configuration (leaving out unused stuff like XHCI and > OHCI, no splash screen etc. to reduce its size). None of the changes I > tried made a difference in SeaBIOS' behavior. could you please check that SeaBIOS? log level is set to 8 and attach the .config from it? But probably non-working LZMA decompression is an indicator for an incorrect set up already. But we?ll see and maybe somebody else has an idea. [?] Thanks, Paul PS: If you can, it?d be great if you could just send plain text messages to mailing lists. PPS: coreboot is officially spelled all lowercase. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From xchip at hush.ai Sun Aug 24 00:53:03 2014 From: xchip at hush.ai (xchip at hush.ai) Date: Sun, 24 Aug 2014 00:53:03 +0200 Subject: [coreboot] Problems with coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: <1408794780.2724.52.camel@mattotaupa> References: <20140823094135.2005B601F3@smtp.hushmail.com> <1408794780.2724.52.camel@mattotaupa> Message-ID: <20140823225303.6F614601F3@smtp.hushmail.com> Hi again, > >could you please check that SeaBIOS? log level is set to 8 and >attach >the .config from it? But probably non-working LZMA decompression >is an >indicator for an incorrect set up already. But we?ll see and maybe >somebody else has an idea. > I have attached my SeaBIOS .config file. Log level was set to 9. > >PS: If you can, it?d be great if you could just send plain text >messages to mailing lists. Sorry for not sending plaintext. That wasn't my intention. I'm using a web interface right now, which has done that without me noticing. I've tried to disable any formatting now. Hope that helps. xchip -------------- next part -------------- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 1516 bytes Desc: not available URL: From rminnich at gmail.com Sun Aug 24 01:47:58 2014 From: rminnich at gmail.com (ron minnich) Date: Sat, 23 Aug 2014 16:47:58 -0700 Subject: [coreboot] Problems with Coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: <20140823094135.2005B601F3@smtp.hushmail.com> References: <20140823094135.2005B601F3@smtp.hushmail.com> Message-ID: Hi, when I'm having trouble with lzma what I do is not build a payload, and run the ramstage uncompressed, and at least make sure that works. I think this is your real problem, as you say. Trying CBFS ramstage loader. CBFS: loading stage fallback/ramstage @ 0x100000 (151600 bytes), entry @ 0x100000 CBFS: tried to decompress 43540 bytes with algorithm #1,but that algorithm id is unsupported. Ramstage was not loaded! This is really weird. But I don't think you should go one step further until you see why this is happening, because it points to other bigger problems. BTW, when you omitted the vga bios, did you rebuild seabios to not expect vga to be present? I don't think the issue is the lzma compression does not work. Somehow the config step is broken, and if that variable is not set right, others may not be set right either. The integrity of your build is questionable. When's the last time we had a success with EPIA-M? I just don't recall, anyone know? ron From xchip at hush.ai Sun Aug 24 10:01:38 2014 From: xchip at hush.ai (xchip at hush.ai) Date: Sun, 24 Aug 2014 10:01:38 +0200 Subject: [coreboot] Problems with Coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: References: <20140823094135.2005B601F3@smtp.hushmail.com> Message-ID: <20140824080139.0AB0A601F3@smtp.hushmail.com> Hi, On 8/24/2014 at 1:48 AM, "ron minnich" wrote: > >Hi, > >when I'm having trouble with lzma what I do is not build a payload, >and run the ramstage uncompressed, and at least make sure that >works. I tried that as well and it does work indeed. It does basically the same thing as if I apply that "hack" to define that LZMA constant, as I mentioned before. In both cases the coreboot initializations seems to be fine, as far as I can tell. > >I think this is your real problem, as you say. > >Trying CBFS ramstage loader. >CBFS: loading stage fallback/ramstage @ 0x100000 (151600 bytes), >entry >@ 0x100000 >CBFS: tried to decompress 43540 bytes with algorithm #1,but that >algorithm id is unsupported. >Ramstage was not loaded! > > >This is really weird. But I don't think you should go one step >further >until you see why this is happening, because it points to other >bigger >problems. > >BTW, when you omitted the vga bios, did you rebuild seabios to not >expect vga to be present? > I think I did. I thought the CONFIG_NO_VGABIOS=y in my SeaBIOS config was what I needed, but if there is anything else I need to configure, maybe I have missed it. >I don't think the issue is the lzma compression does not work. >Somehow >the config step is broken, and if that variable is not set right, >others may not be set right either. The integrity of your build is >questionable. You are probably right. The reason I wanted to get that LZMA compression to work was that I then could use a more default SeaBIOS configuration. I figured that there would be less possibilities for me to break the SeaBIOS configuration, when I don't have to disable lots of features to save space to make it fit uncompressed on the flash chip. > >When's the last time we had a success with EPIA-M? I just don't >recall, anyone know? > >ron xchip From paulepanter at users.sourceforge.net Sun Aug 24 10:25:38 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Sun, 24 Aug 2014 10:25:38 +0200 Subject: [coreboot] Problems with coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: <20140823225303.6F614601F3@smtp.hushmail.com> References: <20140823094135.2005B601F3@smtp.hushmail.com> <1408794780.2724.52.camel@mattotaupa> <20140823225303.6F614601F3@smtp.hushmail.com> Message-ID: <1408868738.16504.13.camel@mattotaupa> Dear xchip, Am Sonntag, den 24.08.2014, 00:53 +0200 schrieb xchip at hush.ai: > >could you please check that SeaBIOS? log level is set to 8 and attach > >the .config from it? But probably non-working LZMA decompression is an > >indicator for an incorrect set up already. But we?ll see and maybe > >somebody else has an idea. > > I have attached my SeaBIOS .config file. Log level was set to 9. looking at my log files, the next line should be something like. [?] Found coreboot cbmem console @ c7fc0400 Found mainboard ASROCK E350M1 malloc preinit [?] As you probably do not have CBMEM console enabled in coreboot, please disable it also in SeaBIOS by unselecting the Kconfig option `DEBUG_COREBOOT`. (You can search in `make menuconfig` by pressing the key / and then entering some part of the option name.) By the way, for now you can also disable a lot of the USB stuff in SeaBIOS to save space, if that is still an issue. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Sun Aug 24 10:36:45 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Sun, 24 Aug 2014 10:36:45 +0200 Subject: [coreboot] Problems with coreboot and SeaBIOS on VIA EPIA-M In-Reply-To: <1408868738.16504.13.camel@mattotaupa> References: <20140823094135.2005B601F3@smtp.hushmail.com> <1408794780.2724.52.camel@mattotaupa> <20140823225303.6F614601F3@smtp.hushmail.com> <1408868738.16504.13.camel@mattotaupa> Message-ID: <1408869405.16504.18.camel@mattotaupa> Dear xchip, Am Sonntag, den 24.08.2014, 10:25 +0200 schrieb Paul Menzel: > Am Sonntag, den 24.08.2014, 00:53 +0200 schrieb xchip at hush.ai: > > > >could you please check that SeaBIOS? log level is set to 8 and attach > > >the .config from it? But probably non-working LZMA decompression is an > > >indicator for an incorrect set up already. But we?ll see and maybe > > >somebody else has an idea. > > > > I have attached my SeaBIOS .config file. Log level was set to 9. > > looking at my log files, the next line should be something like. > > [?] > Found coreboot cbmem console @ c7fc0400 > Found mainboard ASROCK E350M1 > malloc preinit > [?] I am sorry, that was from the CBMEM console. The serial console log should contain the messages below. SeaBIOS (version rel-1.7.5-42-g275672e-20140816_084721-asrock-e350m1) Attempting to find coreboot table Found coreboot table forwarder. Now attempting to find coreboot memory map SeaBIOS (version rel-1.7.5-42-g275672e-20140816_084721-asrock-e350m1) Found coreboot cbmem console @ c7fc0400 Found mainboard ASROCK E350M1 malloc preinit [?] Adding more print statements should get you further to find out if `coreboot_preinit()` is even reached. > As you probably do not have CBMEM console enabled in coreboot, please > disable it also in SeaBIOS by unselecting the Kconfig option > `DEBUG_COREBOOT`. (You can search in `make menuconfig` by pressing the > key / and then entering some part of the option name.) > > By the way, for now you can also disable a lot of the USB stuff in > SeaBIOS to save space, if that is still an issue. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From coreboot at guylhem.net Mon Aug 25 04:39:10 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Sun, 24 Aug 2014 22:39:10 -0400 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete Message-ID: Hello Previously (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I mentioned that 3 bugs seemed to be related to the DSDT: - missing ACPI events when the stylus is inserted/removed - errors when trying to make the leds blink with tpacpi - errors during TPM initialization The first bug is x60t specific, but the other 2 should also affect the other x60 models. At the moment, I'm trying various kernel to see how boot time can be improved, and took 5 minutes to test with a custom DSDT table created from acpi_3.rom (extracted with bios_extract, then decompiled into a dsl, then recompiled into a hex file (see for ex https://wiki.archlinux.org/index.php/DSDT) I do confirm this fixes both the stylus (I now get ACPI events) and the blinking leds issues (they now blink just fine), which confirms these bugs come from missing entries in coreboot DSDT, and can be corrected by fixing it. However, since the factory DSDT causes other issues (such as the CPU running quite hot and wake-up issues) I do not recommend using the factory DSDT, even as a temporary solution. Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Alternatively, I plan to release a patched x60t DSDT for use with libreboot. Charles [PS: I forgot to test the TPM module, but it should also work now] -------------- next part -------------- An HTML attachment was scrubbed... URL: From coreboot at guylhem.net Mon Aug 25 05:25:12 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Sun, 24 Aug 2014 23:25:12 -0400 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds Message-ID: Hello I'm still trying to improve boot time. After some further optimizations (previous results : 2.2s for the kernel, 0.6s for the daemons), I believe it should be possible to get a command line in less than 2 seconds, since most of the time is spend re-initializing the video chip (almost a full second) while there are some features to prevent just that. It seems that coreboot is spending some time initializing the video chip for grub, then linux spends some time again - even when grub option "set gfxpayload=keep" is set (which should prevent that) and when coreboot is compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE in kernel 3.10.45 : [ 0.291014] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit ban ging on pin 3 [ 0.321926] [drm] initialized overlay support [ 0.384013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit bangi ng on pin 2 [ 0.570068] fbcon: inteldrmfb (fb0) is primary device [ 1.230010] Console: switching to colour frame buffer device 128x48 [ 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 1.258984] i915 0000:00:02.0: registered panic notifier [ 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 I'm currently trying a recent kernel since some i915 patches have been backported (cf http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), introducing the i915.fastboot option to do just that, but it does not help. I must be doing something terribly wrong, but I just don't realize what exactly. Has anyone succeeded in keeping the vesa mode? Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From phcoder at gmail.com Mon Aug 25 08:42:57 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Mon, 25 Aug 2014 08:42:57 +0200 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: References: Message-ID: <53FADAF1.6010509@gmail.com> On 25.08.2014 04:39, Charles Devereaux wrote: > Hello > > Previously > (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I > mentioned that 3 bugs seemed to be related to the DSDT: > - missing ACPI events when the stylus is inserted/removed How is the OS supposed to react to them? > - errors when trying to make the leds blink with tpacpi details? usecase? > - errors during TPM initialization Some people here would call it a feature. > Ideally, the DSDT should be fixed within coreboot, but this goes beyond > my present abilities. Not true. Just do the same changes to the corresponding *.asl files in coreboot repo and send the patch to gerrit. Other than a layer of preprocessing, it's exactly the same code as you got from disassembly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From david.c.hubbard+coreboot at gmail.com Mon Aug 25 11:54:25 2014 From: david.c.hubbard+coreboot at gmail.com (David Hubbard) Date: Mon, 25 Aug 2014 03:54:25 -0600 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: References: Message-ID: On Sun, Aug 24, 2014 at 8:39 PM, Charles Devereaux wrote: > > Hello > > Previously ( http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I mentioned that 3 bugs seemed to be related to the DSDT: > - missing ACPI events when the stylus is inserted/removed > - errors when trying to make the leds blink with tpacpi > - errors during TPM initialization > > The first bug is x60t specific, but the other 2 should also affect the other x60 models. > > At the moment, I'm trying various kernel to see how boot time can be improved, and took 5 minutes to test with a custom DSDT table created from acpi_3.rom (extracted with bios_extract, then decompiled into a dsl, then recompiled into a hex file (see for ex https://wiki.archlinux.org/index.php/DSDT) > > I do confirm this fixes both the stylus (I now get ACPI events) and the blinking leds issues (they now blink just fine), which confirms these bugs come from missing entries in coreboot DSDT, and can be corrected by fixing it. > > However, since the factory DSDT causes other issues (such as the CPU running quite hot and wake-up issues) I do not recommend using the factory DSDT, even as a temporary solution. > > Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Alternatively, I plan to release a patched x60t DSDT for use with libreboot. Is there a version of acpi_3.rom or the decompiled dsl version I could look at? Others might also be interested to take a look. If there are copyright issues preventing the distribution of acpi_3.rom, what steps would be required to extract it from the firmware available on lenovo.com? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at gluglug.org.uk Mon Aug 25 14:52:24 2014 From: info at gluglug.org.uk (The Gluglug) Date: Mon, 25 Aug 2014 13:52:24 +0100 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: References: Message-ID: <53FB3188.8040803@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Ideally, the DSDT should be fixed within coreboot, but this goes > beyond my present abilities. Alternatively, I plan to release a > patched x60t DSDT for use with libreboot. > Please submit it to upstream (coreboot). The same applies for any other patch. Libreboot is a distribution and not a fork of coreboot. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+zGIAAoJEP9Ft0z50c+US2cH/2WZuCYg2NN210Q5x7JFQ2RP UvQ/OCmnY3KeVyt2Rxwa81xVf0qHH9VkfyxZhmYMVRN3OUCjlryBMYAcKcC5jV88 ohTHNTXj10Zej0RB5iQ+wkDHKKviAHKFpJXve5ns2CVVI5n6UFq1KQmPEvJVwU5z bcJjHByaRW7Ej/pg4rGvMkvcNTiBPsliasOmuKzRtKtYRIdpcG21geCamJLGkf2L eLHx/tn8/hqSJwJMt4K6RsHoBhr302eLRfVPFXyRaIdlBf6OD4DqnK0OppUhT/Hu 4Jkr7F7BuB0YRTOAB5PwXUzqaZUdLp+L1HktuyquQCn8zf8CVF4G5tLMKO0gUUU= =a/XJ -----END PGP SIGNATURE----- From coreboot at guylhem.net Mon Aug 25 15:45:00 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Mon, 25 Aug 2014 09:45:00 -0400 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: <53FADAF1.6010509@gmail.com> References: <53FADAF1.6010509@gmail.com> Message-ID: Hello On Mon, Aug 25, 2014 at 2:42 AM, Vladimir '?-coder/phcoder' Serbinenko < phcoder at gmail.com> wrote: > > > - missing ACPI events when the stylus is inserted/removed > How is the OS supposed to react to them? > Issue stylus insert and remove messages which can then be mapped to scripts [ 1778.225577] acpid[440]: completed netlink event "ibm/hotkey IBM0068:00 00000080 0000500c" [ 1778.734936] acpid[440]: received netlink event "ibm/hotkey IBM0068:00 00000080 0000500b" > > - errors when trying to make the leds blink with tpacpi > details? usecase? > echo "0 blink" > /proc/acpi/ibm/led Currently fails with : [ 104.727409] ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, found 2 (20130328/nspredef-272) Blinking leds are a simple way to do many things (ex: indicate successful system boot on a screenless computer) > - errors during TPM initialization > Some people here would call it a feature. > I do not call non working hardware a feature, especially if linux drivers exist. Letting users be able to use or not use their hardware in anyway they chose is a feature. TPM is just a glorified way to store hashes, but it could have some uses say. > Ideally, the DSDT should be fixed within coreboot, but this goes beyond > > my present abilities. > Not true. Just do the same changes to the corresponding *.asl files in > coreboot repo and send the patch to gerrit. Other than a layer of > preprocessing, it's exactly the same code as you got from disassembly. > I did not realize that and thought it interacted with static defines - and so I would have to create a coreboot version-specific DSDT. Thanks. I will see if I can have that work. For the ACPI Warning about SystemIO, I have no idea though. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From coreboot at guylhem.net Mon Aug 25 15:48:20 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Mon, 25 Aug 2014 09:48:20 -0400 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: References: Message-ID: Hello, On Mon, Aug 25, 2014 at 5:54 AM, David Hubbard < david.c.hubbard+coreboot at gmail.com> wrote: > > Is there a version of acpi_3.rom or the decompiled dsl version I could > look at? Others might also be interested to take a look. > Sure. Sent. > If there are copyright issues preventing the distribution of acpi_3.rom, > what steps would be required to extract it from the firmware available on > lenovo.com? > I do not know about copyright issues. If you saved your factory bios, run bios_extract on it from http://www.coreboot.org/Bios_extract, then use the iasl tools : iasl -d (to decompile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at gluglug.org.uk Mon Aug 25 17:49:43 2014 From: info at gluglug.org.uk (The Gluglug) Date: Mon, 25 Aug 2014 16:49:43 +0100 Subject: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer. Message-ID: <53FB5B17.3020203@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using 6725 to enable text-mode gfx init on X60 when using native graphics initialization. This relies on the (merged) patch 6723 that enables text-mode graphics initialization on i945 platforms. The code is there. I then disabled "Keep VESA framebuffer" in menuconfig, to enable text-mode. error: no video mode activated This is what I see when I try to use the net install iso for Debian with the isolinux parser in grub. I also saw the same thing when trying to start Trisquel 6 isolinux menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from seabios's rom that I built). See attached image of what happens when I try to boot the net install from Debian (same thing happens with the Trisquel net install), using the following: linux (usb0)/install.386/vmlinuz initrd (usb0)/install.386/initrd.gz boot As you can see, there is quite a lot of flicker and parts of the screen are missing or corrupt. I think this is related to the issue above ("error: no video mode activated"). The net install for Debian and Trisquel both work when using corebootfb initialization method, but they fail (as seen in the image) for text-mode method. In case the attachment was scrubbed by the mailing list, I also put it here: http://dev.libreboot.org/x60txtmode.jpg Trisquel graphical install works (I wasn't able to figure out how to boot the Debian graphical install). I also enabled it for T60 (adding the keep/drop vesa fb option for t60/Kconfig, based on 6725, and cherry picking 5345) and the same behaviour was observed there. What does work in text-mode init (tested): memtest86+ and grub invaders. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+1sXAAoJEP9Ft0z50c+UhtwH/jegmqnaQPzGn58veEWMN9Ik 3TNG0QpTlyVvuikY3ARsIz4FQuwN26wdTsGTg3s9pbDLbGjUkxYTWKSGvxhwDm9D 9IRu2cYiE5RMFxQx0V6074ytIJtqCc6JGuzeihHJhP9rgRXfWedSuGnIeCwcoMUB GffxXClF9SSLEgtVugPiYUVVM/E2HuFH+b0nG3aZ8mnAFMe/sqaWJkPC5+AHnuFO aRavxBUk8b+Q5AK3sGhvVBAso8YSAJY52PMtxr5ucTzGtoARi1ffa47ZQJf6pS2H tii6dYuQ1Xbr84snOKAiQYfyRJygbY9EEcH3OlupN4IaLA+tz5cnidcC3q1n6f8= =G4tP -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: x60txtmode.jpg Type: image/jpeg Size: 137913 bytes Desc: not available URL: From info at gluglug.org.uk Mon Aug 25 17:50:37 2014 From: info at gluglug.org.uk (The Gluglug) Date: Mon, 25 Aug 2014 16:50:37 +0100 Subject: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer. Message-ID: <53FB5B4D.1050004@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using 6725 to enable text-mode gfx init on X60 when using native graphics initialization. Affected machines: X60, T60. It may also affect: macbook21/macbook11, X60 Tablet This relies on the (merged) patch 6723 that enables text-mode graphics initialization on i945 platforms. The code is there. I then disabled "Keep VESA framebuffer" in menuconfig, to enable text-mode. error: no video mode activated This is what I see when I try to use the net install iso for Debian with the isolinux parser in grub. I also saw the same thing when trying to start Trisquel 6 isolinux menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from seabios's rom that I built). See attached image of what happens when I try to boot the net install from Debian (same thing happens with the Trisquel net install), using the following: linux (usb0)/install.386/vmlinuz initrd (usb0)/install.386/initrd.gz boot As you can see, there is quite a lot of flicker and parts of the screen are missing or corrupt. I think this is related to the issue above ("error: no video mode activated"). The net install for Debian and Trisquel both work when using corebootfb initialization method, but they fail (as seen in the image) for text-mode method. In case the attachment was scrubbed by the mailing list, I also put it here: http://dev.libreboot.org/x60txtmode.jpg Trisquel graphical install works (I wasn't able to figure out how to boot the Debian graphical install). I also enabled it for T60 (adding the keep/drop vesa fb option for t60/Kconfig, based on 6725, and cherry picking 5345) and the same behaviour was observed there. What does work in text-mode init (tested): memtest86+ and grub invaders. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+1tNAAoJEP9Ft0z50c+UEpwH/jpnNQqSS1IfbU0K2y+y2YcJ NS8j1MyYCyrVjFh+bVEbmd6ObDjM0lo8GSPeqlcMY0GvPj7YwXUf0ZGMnlDbj3KP zazDpqMQaCnbcFApg6cxqCkxA1CNeRFlpFslkzt4cht7nBpkV/kdGNnJ2XLfIlDn AwhMVOK/pT6osgVO5hc2VUDrHBnO2LLHE3K0KPsbyMVWWqvWeLPZWZ0baZY60OAk 4g+NxyZMWtBhSVmcrrVQu1NjqXlnYUALx7XxKuB9fsjr+HQfHWoH0ZBYUYuGHrXA /ATYQuuP06teeur70ya/sN1t/e0czU1CBGV3yp57VhvomQtlQTucp9f+am/Gmxw= =POgA -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: x60txtmode.jpg Type: image/jpeg Size: 137913 bytes Desc: not available URL: From david.c.hubbard+coreboot at gmail.com Mon Aug 25 19:21:38 2014 From: david.c.hubbard+coreboot at gmail.com (David Hubbard) Date: Mon, 25 Aug 2014 11:21:38 -0600 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: References: <53FADAF1.6010509@gmail.com> Message-ID: Hi Charles, I'm focusing in on this error message first: ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, found 2 Can you take a look at the .asl files in your coreboot build? I believe you will find something like "Method (LED, 2, NotSerialized)" which means the LED method wants 2 arguments. Then look for calls to "LED ()" and if you find one only passing 1 argument, that is the problem. Looking at the decompiled vendor DSDT did not really reveal much in this area, except that it is likely coreboot already has a "clean room" re-implementation of the vendor DSDT since they both use a method called "LED ()" David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Aug 25 19:44:28 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 25 Aug 2014 10:44:28 -0700 Subject: [coreboot] AMD PSP Message-ID: I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and how scared should we be of it? Is it as closed off and mysterious? ron From patrick at georgi-clan.de Mon Aug 25 20:37:05 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 25 Aug 2014 20:37:05 +0200 Subject: [coreboot] AMD PSP In-Reply-To: References: Message-ID: <53FB8251.4090100@georgi-clan.de> Am 25.08.2014 um 19:44 schrieb ron minnich: > Is it as closed off and mysterious? Its firmware is signed. So yes, closed off. My hope is that it is (and stays) like early ME: no firmware, no harm, since it deactivates itself silently. But since AMD prefers to parrot Intel's worst ideas these days... Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dhendrix at google.com Mon Aug 25 22:24:25 2014 From: dhendrix at google.com (David Hendricks) Date: Mon, 25 Aug 2014 13:24:25 -0700 Subject: [coreboot] AMD PSP In-Reply-To: <53FB8251.4090100@georgi-clan.de> References: <53FB8251.4090100@georgi-clan.de> Message-ID: After glancing thru this PSP (Platitude Spewing Presentation), it looks more like they are grafting the security model of ARM-based SoCs onto x86 where a masked ROM loads the next stage. A couple kind of nice things they mention: - "Isolated on-chip ROM and SRAM" - So this may be somewhat more constrained than the multi-megabyte blobs for MEs? - "Secure Boot does not require the system ROM image to be signed" Not so nice: "Access to system memory / resources". Ugh. On Mon, Aug 25, 2014 at 11:37 AM, Patrick Georgi wrote: > Am 25.08.2014 um 19:44 schrieb ron minnich: > > Is it as closed off and mysterious? > Its firmware is signed. So yes, closed off. > > My hope is that it is (and stays) like early ME: no firmware, no harm, > since it deactivates itself silently. > But since AMD prefers to parrot Intel's worst ideas these days... > > > Patrick > > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Mon Aug 25 22:33:25 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 25 Aug 2014 13:33:25 -0700 Subject: [coreboot] AMD PSP In-Reply-To: References: <53FB8251.4090100@georgi-clan.de> Message-ID: On Mon, Aug 25, 2014 at 1:24 PM, David Hendricks wrote: > After glancing thru this PSP (Platitude Spewing Presentation), it looks more > like they are grafting the security model of ARM-based SoCs onto x86 where a > masked ROM loads the next stage. > > A couple kind of nice things they mention: > - "Isolated on-chip ROM and SRAM" - So this may be somewhat more constrained > than the multi-megabyte blobs for MEs? > - "Secure Boot does not require the system ROM image to be signed" > > Not so nice: "Access to system memory / resources". Ugh. well, we all know how well that's worked fro the ME. so, another insecure x86 platform. Great. ron From phcoder at gmail.com Mon Aug 25 22:53:00 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Mon, 25 Aug 2014 22:53:00 +0200 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: <53FADAF1.6010509@gmail.com> References: <53FADAF1.6010509@gmail.com> Message-ID: <53FBA22C.4050308@gmail.com> >> Ideally, the DSDT should be fixed within coreboot, but this goes beyond >> my present abilities. > Not true. Just do the same changes to the corresponding *.asl files in > coreboot repo and send the patch to gerrit. Other than a layer of > preprocessing, it's exactly the same code as you got from disassembly. > Sorry, I misread you. I thought that you extracted coreboot DSDT from running system then patched it and used as custom DSDT. I'm going to make few experiments on my x220t. From phcoder at gmail.com Mon Aug 25 23:02:06 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Mon, 25 Aug 2014 23:02:06 +0200 Subject: [coreboot] IBM x60t test - DSDT is in fact incomplete In-Reply-To: <53FBA22C.4050308@gmail.com> References: <53FADAF1.6010509@gmail.com> <53FBA22C.4050308@gmail.com> Message-ID: <53FBA44E.2000908@gmail.com> On 25.08.2014 22:53, Vladimir '?-coder/phcoder' Serbinenko wrote: >>> Ideally, the DSDT should be fixed within coreboot, but this goes beyond >>> my present abilities. >> Not true. Just do the same changes to the corresponding *.asl files in >> coreboot repo and send the patch to gerrit. Other than a layer of >> preprocessing, it's exactly the same code as you got from disassembly. >> > Sorry, I misread you. I thought that you extracted coreboot DSDT from > running system then patched it and used as custom DSDT. I'm going to > make few experiments on my x220t. > > This may interest you: On X220t stylus removal: [17424.931729] ACPI : EC: ===== TASK ===== [17424.931747] ACPI : EC: ---> status = 0x28 [17424.931755] ACPI : EC: <--- command = 0x84 [17424.931852] ACPI : EC: ===== IRQ ===== [17424.931865] ACPI : EC: ---> status = 0x09 [17424.931874] ACPI : EC: ---> data = 0x5d [17424.931885] ACPI : EC: ---> status = 0x08 So it's _Q5D Stylus reinsert: [17493.249126] ACPI : EC: push gpe query to the queue [17493.249198] ACPI : EC: ===== TASK ===== [17493.249207] ACPI : EC: ---> status = 0x28 [17493.249213] ACPI : EC: <--- command = 0x84 [17493.249293] ACPI : EC: ===== IRQ ===== [17493.249306] ACPI : EC: ---> status = 0x09 [17493.249316] ACPI : EC: ---> data = 0x5c [17493.249329] ACPI : EC: ---> status = 0x08 So it's _Q5C Turning LID around: [17582.701907] ACPI : EC: push gpe query to the queue [17582.701979] ACPI : EC: ===== TASK ===== [17582.701987] ACPI : EC: ---> status = 0x28 [17582.701994] ACPI : EC: <--- command = 0x84 [17582.702075] ACPI : EC: ===== IRQ ===== [17582.702092] ACPI : EC: ---> status = 0x09 [17582.702096] ACPI : EC: ---> data = 0x5e [17582.702104] ACPI : EC: ---> status = 0x08 So it's _Q5E Back to laptop layout: [17590.610440] ACPI : EC: push gpe query to the queue [17590.610513] ACPI : EC: ===== TASK ===== [17590.610521] ACPI : EC: ---> status = 0x28 [17590.610527] ACPI : EC: <--- command = 0x84 [17590.610610] ACPI : EC: ===== IRQ ===== [17590.610620] ACPI : EC: ---> status = 0x09 [17590.610628] ACPI : EC: ---> data = 0x5f [17590.610641] ACPI : EC: ---> status = 0x08 so it's _Q5F Do you get the same events on X60t? >From thinkpad-acpi.c: TP_HKEY_EV_TABLET_TABLET = 0x5009, /* tablet swivel up */ TP_HKEY_EV_TABLET_NOTEBOOK = 0x500a, /* tablet swivel down */ TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted */ TP_HKEY_EV_PEN_REMOVED = 0x500c, /* tablet pen removed */ So those are the values MHKP has to return. http://review.coreboot.org/6765 implements it. Please test. From rminnich at gmail.com Mon Aug 25 23:28:41 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 25 Aug 2014 14:28:41 -0700 Subject: [coreboot] disabling bios usb stack Message-ID: A friend asks me how to disable the usb stack in his bios. I have no clue, anyone? ron From phcoder at gmail.com Mon Aug 25 23:32:38 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Mon, 25 Aug 2014 23:32:38 +0200 Subject: [coreboot] disabling bios usb stack In-Reply-To: References: Message-ID: <53FBAB76.1020906@gmail.com> On 25.08.2014 23:28, ron minnich wrote: > A friend asks me how to disable the usb stack in his bios. I have no > clue, anyone? > Doesn't sound like end goal. But I'd go through setup menu to see if something fits his *end* goal (disabling usb stack sounds like means to goal, not the goal itself). > ron > From paulepanter at users.sourceforge.net Tue Aug 26 00:21:32 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 26 Aug 2014 00:21:32 +0200 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds In-Reply-To: References: Message-ID: <1409005292.20046.87.camel@users.sourceforge.net> Dear Charles, Am Sonntag, den 24.08.2014, 23:25 -0400 schrieb Charles Devereaux: > I'm still trying to improve boot time. nice. Thank you for keeping us in the loop. > After some further optimizations (previous results : 2.2s for the kernel, > 0.6s for the daemons), 1. So what are your coreboot numbers? (Also what `.config` and what payload (with `.config`) do you use?) 2. What hardware do you use? Especially what SSD? 3. Do you use the default Linux kernel shipped with Debian? 4. Which Debian release do you use? 5. Which init system do you use? > I believe it should be possible to get a command line in less than 2 > seconds, since most of the time is spend re-initializing the video > chip (almost a full second) while there are some features to prevent > just that. That sounds indeed possible. How do you measure the timings? > It seems that coreboot is spending some time initializing the video chip > for grub, then linux spends some time again - even when grub option "set > gfxpayload=keep" is set (which should prevent that) and when coreboot is > compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE > > in kernel 3.10.45 : > [ 0.291014] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 > [ 0.321926] [drm] initialized overlay support > [ 0.384013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 > [ 0.570068] fbcon: inteldrmfb (fb0) is primary device > [ 1.230010] Console: switching to colour frame buffer device 128x48 > [ 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device > [ 1.258984] i915 0000:00:02.0: registered panic notifier > [ 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 > > I'm currently trying a recent kernel since some i915 patches have been > backported (cf http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), > introducing the i915.fastboot option to do just that, but it does not help. > > I must be doing something terribly wrong, but I just don't realize what > exactly. > > Has anyone succeeded in keeping the vesa mode? Sorry, I have not played with this. But I think the way to go is to contact the Linux Intel graphics folks. Best is to submit a bug report. Let?s hope to get that fixed for Debian Jessie, which is going to be frozen in November [1]. Another approach would be to do it like the Chromium OS folks do it on the Google Chromebooks. In normal mode they do not initalize the graphic device (just place the Video BIOS/VGA Option ROM for VBT information), so you cannot see GRUB, and let just Linux initialize the graphics. Then they have a developer mode and only in this mode coreboot does graphics initialization. As these are smart people and they probably did a lot of testing, that might be the only viable solution if you want to have quick boot times. Though I have no idea why they did not go the `gfxpayload=keep` route. Thanks, Paul [1] https://release.debian.org/jessie/freeze_policy.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From rminnich at gmail.com Tue Aug 26 00:22:55 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 25 Aug 2014 15:22:55 -0700 Subject: [coreboot] disabling bios usb stack In-Reply-To: <53FBAB76.1020906@gmail.com> References: <53FBAB76.1020906@gmail.com> Message-ID: disabling the usb stack is the goal in this case. ron On Mon, Aug 25, 2014 at 2:32 PM, Vladimir '?-coder/phcoder' Serbinenko wrote: > On 25.08.2014 23:28, ron minnich wrote: >> A friend asks me how to disable the usb stack in his bios. I have no >> clue, anyone? >> > Doesn't sound like end goal. But I'd go through setup menu to see if > something fits his *end* goal (disabling usb stack sounds like means to > goal, not the goal itself). > >> ron >> > From rminnich at gmail.com Tue Aug 26 00:24:41 2014 From: rminnich at gmail.com (ron minnich) Date: Mon, 25 Aug 2014 15:24:41 -0700 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds In-Reply-To: <1409005292.20046.87.camel@users.sourceforge.net> References: <1409005292.20046.87.camel@users.sourceforge.net> Message-ID: On Mon, Aug 25, 2014 at 3:21 PM, Paul Menzel wrote: > Another approach would be to do it like the Chromium OS folks do it on > the Google Chromebooks. In normal mode they do not initalize the graphic > device (just place the Video BIOS/VGA Option ROM for VBT information), > so you cannot see GRUB, and let just Linux initialize the graphics. Then > they have a developer mode and only in this mode coreboot does graphics > initialization. That's actually slower than having coreboot do native graphics init. That's why we did the coreboot graphics work in the first place. ron From info at gluglug.org.uk Tue Aug 26 00:26:06 2014 From: info at gluglug.org.uk (The Gluglug) Date: Mon, 25 Aug 2014 23:26:06 +0100 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds In-Reply-To: References: Message-ID: <53FBB7FE.4090700@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/08/14 04:25, Charles Devereaux wrote: > Hello > > I'm still trying to improve boot time. > > After some further optimizations (previous results : 2.2s for the > kernel, 0.6s for the daemons), I believe it should be possible to > get a command line in less than 2 seconds, since most of the time > is spend re-initializing the video chip (almost a full second) > while there are some features to prevent just that. > > It seems that coreboot is spending some time initializing the video > chip for grub, then linux spends some time again - even when grub > option "set gfxpayload=keep" is set (which should prevent that) and > when coreboot is compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE > > in kernel 3.10.45 : [ 0.291014] [drm] GMBUS [i915 gmbus panel] > timed out, falling back to bit ban ging on pin 3 [ 0.321926] > [drm] initialized overlay support [ 0.384013] [drm] GMBUS [i915 > gmbus vga] timed out, falling back to bit bangi ng on pin 2 [ > 0.570068] fbcon: inteldrmfb (fb0) is primary device [ 1.230010] > Console: switching to colour frame buffer device 128x48 [ > 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ > 1.258984] i915 0000:00:02.0: registered panic notifier [ > 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 > on minor 0 > > I'm currently trying a recent kernel since some i915 patches have > been backported (cf > http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), > introducing the i915.fastboot option to do just that, but it does > not help. > > I must be doing something terribly wrong, but I just don't realize > what exactly. > > Has anyone succeeded in keeping the vesa mode? > > Charles > > > Do you get those same errors in 3.10.45 when booting factory bios or coreboot+vgarom? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+7f9AAoJEP9Ft0z50c+UBxoH/0LJoojt+KLktA3lXWO+wPTs 1u2dRykqxzT0vkcCvi53WiEq3tO3rLJE+PudopjfBZk1kbH08VLKKLKkXO+Q4Fp+ VwZiV6F2R+2gKsTlyGXgnm/2qqPdH16nZ+oEV25wJtPkGcLYJaBmwuYzI5fr8NSa cTmCzpmzT+0bl4SPo0PtlwcIFYzCPTCgs8QTd2Ly8tutnmDqV9iib9Wy7K1+igAT e+hiqGz9Npn54gd1drNr+cc7QYZiuMx65V6rAipl8LeuaybkSmQxy+N6qWHS3IlE ioG3/2r3J4Q7KzJiX3M9RD0+NSPoSkN4XkkzEdOtXLFjjoe+3l3F1rneIE1Fuss= =dLQ7 -----END PGP SIGNATURE----- From info at gluglug.org.uk Tue Aug 26 03:06:05 2014 From: info at gluglug.org.uk (The Gluglug) Date: Tue, 26 Aug 2014 02:06:05 +0100 Subject: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer. In-Reply-To: <53FB5B4D.1050004@gluglug.org.uk> References: <53FB5B4D.1050004@gluglug.org.uk> Message-ID: <53FBDD7D.3000705@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The same issue does not occur when using coreboot with the vga rom extracted from factory bios. On 25/08/14 16:50, The Gluglug wrote: > Using 6725 to enable text-mode gfx init on X60 when using native > graphics initialization. > > Affected machines: X60, T60. It may also affect: > macbook21/macbook11, X60 Tablet > > This relies on the (merged) patch 6723 that enables text-mode > graphics initialization on i945 platforms. The code is there. > > I then disabled "Keep VESA framebuffer" in menuconfig, to enable > text-mode. > > error: no video mode activated This is what I see when I try to use > the net install iso for Debian with the isolinux parser in grub. I > also saw the same thing when trying to start Trisquel 6 isolinux > menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin > from seabios's rom that I built). > > See attached image of what happens when I try to boot the net > install from Debian (same thing happens with the Trisquel net > install), using the following: linux (usb0)/install.386/vmlinuz > initrd (usb0)/install.386/initrd.gz boot > > As you can see, there is quite a lot of flicker and parts of the > screen are missing or corrupt. I think this is related to the > issue above ("error: no video mode activated"). > > The net install for Debian and Trisquel both work when using > corebootfb initialization method, but they fail (as seen in the > image) for text-mode method. > > In case the attachment was scrubbed by the mailing list, I also put > it here: http://dev.libreboot.org/x60txtmode.jpg > > Trisquel graphical install works (I wasn't able to figure out how > to boot the Debian graphical install). > > I also enabled it for T60 (adding the keep/drop vesa fb option for > t60/Kconfig, based on 6725, and cherry picking 5345) and the same > behaviour was observed there. > > What does work in text-mode init (tested): memtest86+ and grub > invaders. > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT+919AAoJEP9Ft0z50c+UIFcIALLWwrcgoPINTBBOdsAUjVYD 300SAz9NgVdpnxBc0/k+G7maVf0JLccNVCen3kmdWTwkSwccZHrUb4sjfqNhiCJY YQ+CjoISrs1bCkDhgNAPxG+5wpHAO5VOClmfAmdkl2hzeT4UlCwK9gflQyOe4OIu /bKg01tGlqwK2nIsfYKW8P99uhHIdopdSqwZ8XSynHMdOeO39dE28rEEAooOO3JC w/Og7sJoygeAlB61bu1u6my8zLuWUvKlBbE8ILKLVzBDlM6dFnvrDo8mSwKZe0kP 4x5yR55ucU7lk8DGxmAAIjGpeZ7lgMd657EV1Wtu7yXi2Wn5TJIco1/DmhI5FpI= =XHHN -----END PGP SIGNATURE----- From coreboot at guylhem.net Tue Aug 26 05:40:43 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Mon, 25 Aug 2014 23:40:43 -0400 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds In-Reply-To: <1409005292.20046.87.camel@users.sourceforge.net> References: <1409005292.20046.87.camel@users.sourceforge.net> Message-ID: Hello On Mon, Aug 25, 2014 at 6:21 PM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > 1. So what are your coreboot numbers? (Also what `.config` and what > payload (with `.config`) do you use?) > Coreboot delays are not added to the reported boot delays. I do not try to optimize coreboot yet, as my knowledge of coreboot is too limited. Suggestions would be welcome though (it will be a second step, along with a minimal grub2) Here is the .config I use on a coreboot version from GNUtoo. I plan to transition to a libreboot version as soon as I have solved a few things > 2. What hardware do you use? Especially what SSD? > The cheapest Kingston 120G I could find on Amazon, reported to the kernel as: KINGSTON SV300S37A120G, 521ABBF0, 3. Do you use the default Linux kernel shipped with Debian? > No, I compile my own kernel using vanilla kernel.org sources. The first attempt was with a 3.10.45 without any module (cf http://libreboot.org/docs/future/fastboot/x60.config), but I plan to use a more recent kernel with a minimum number of modules to have a faster boot. The .config is attached for 3.14.16 which I'm using > 4. Which Debian release do you use? > At the moment, jessie, but the initial test was with a stable, so I will keep reporting test results with a debian stable. 5. Which init system do you use? > systemd 2.10, compiled using the scripts on http://libreboot.org/docs/future/fastboot/get-systemd.sh. I'm preparing an blog entry explaining that in more details. > That sounds indeed possible. How do you measure the timings? > With systemd-analyze > contact the Linux Intel graphics folks. Best is to submit a bug report. > Let?s hope to get that fixed for Debian Jessie, which is going to be frozen in November [1]. > Will do. It might indeed be a kernel bug, or incomplete support of i915.fastboot for systems without a bios. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 13004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 103463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: .config Type: application/octet-stream Size: 107830 bytes Desc: not available URL: From paulepanter at users.sourceforge.net Tue Aug 26 08:45:08 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 26 Aug 2014 08:45:08 +0200 Subject: [coreboot] x60 : trying to boot to a debian in less than 2 seconds In-Reply-To: References: <1409005292.20046.87.camel@users.sourceforge.net> Message-ID: <1409035508.6334.9.camel@users.sourceforge.net> Am Montag, den 25.08.2014, 15:24 -0700 schrieb ron minnich: > On Mon, Aug 25, 2014 at 3:21 PM, Paul Menzel wrote: > > > Another approach would be to do it like the Chromium OS folks do it on > > the Google Chromebooks. In normal mode they do not initalize the graphic > > device (just place the Video BIOS/VGA Option ROM for VBT information), > > so you cannot see GRUB, and let just Linux initialize the graphics. Then > > they have a developer mode and only in this mode coreboot does graphics > > initialization. > > That's actually slower than having coreboot do native graphics init. > That's why we did the coreboot graphics work in the first place. Sorry for getting that wrong and thank you for the clarification. Could you please elaborate about the difference between normal and developer mode regarding graphics setup? Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From paulepanter at users.sourceforge.net Tue Aug 26 08:50:11 2014 From: paulepanter at users.sourceforge.net (Paul Menzel) Date: Tue, 26 Aug 2014 08:50:11 +0200 Subject: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2 (was: IBM x60t test - DSDT is in fact incomplete) In-Reply-To: References: <53FADAF1.6010509@gmail.com> Message-ID: <1409035811.6334.12.camel@users.sourceforge.net> Dear Charles, dear David, Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard: > I'm focusing in on this error message first: > > ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, > found 2 > > Can you take a look at the .asl files in your coreboot build? I believe you > will find something like "Method (LED, 2, NotSerialized)" which means the > LED method wants 2 arguments. Then look for calls to "LED ()" and if you > find one only passing 1 argument, that is the problem. I also noticed that message and quickly looked through the coreboot ASL files, but could not find anything calling that message. Looking at the Linux kernel sources I was also unable to find a call site. But I?d say the OS call this method incorrectly. [?] Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From echelon at free.fr Tue Aug 26 11:11:43 2014 From: echelon at free.fr (echelon at free.fr) Date: Tue, 26 Aug 2014 11:11:43 +0200 (CEST) Subject: [coreboot] =?utf-8?b?UmXCoDogUmU6ICBBTUQgUFNQ?= In-Reply-To: Message-ID: <286641253.38127652.1409044303690.JavaMail.root@zimbra6-e1.priv.proxad.net> So we can kiss goodbye coreboot on AMD platforms in the future?.. How sad! :-/ Does this thing "Platform Security Processor" exist in any AMD CPUs buyable today (Q3 2014) or it will begin to be implemented later? Thank you for this information! Florentin ----- Mail d'origine ----- De: ron minnich ?: David Hendricks Cc: Coreboot Envoy?: Mon, 25 Aug 2014 22:33:25 +0200 (CEST) Objet: Re: [coreboot] AMD PSP On Mon, Aug 25, 2014 at 1:24 PM, David Hendricks wrote: > After glancing thru this PSP (Platitude Spewing Presentation), it looks more > like they are grafting the security model of ARM-based SoCs onto x86 where a > masked ROM loads the next stage. > > A couple kind of nice things they mention: > - "Isolated on-chip ROM and SRAM" - So this may be somewhat more constrained > than the multi-megabyte blobs for MEs? > - "Secure Boot does not require the system ROM image to be signed" > > Not so nice: "Access to system memory / resources". Ugh. well, we all know how well that's worked fro the ME. so, another insecure x86 platform. Great. ron -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot From info at gluglug.org.uk Tue Aug 26 17:50:15 2014 From: info at gluglug.org.uk (The Gluglug) Date: Tue, 26 Aug 2014 16:50:15 +0100 Subject: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer. In-Reply-To: <53FBDD7D.3000705@gluglug.org.uk> References: <53FB5B4D.1050004@gluglug.org.uk> <53FBDD7D.3000705@gluglug.org.uk> Message-ID: <53FCACB7.7090306@gluglug.org.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is some further notes that I collected: There are issues with i945 text mode graphics initialization: http://www.coreboot.org/pipermail/coreboot/2014-August/078468.html look into it, follow up on that post and try to fix it. Trisquel isolinux menu doesn't show up in seabios (seavgabios) with text-mode, it just says 'Error setting up gfxboot', but it works in text-mode with the extract vbios. Looking at gma.c, it looks like this isn't setup in text-mode by native init, but obviously when using the extracted vbios, it is setting everything up properly? Debian/Trisquel net-install shows graphical corruption (see mailing list link) when booting directly from GRUB in text-mode, but works just fine when using the extracted vbios instead of seavgabios. Are these using text-mode or trying to use graphics? (graphical installers work just fine in native init or with extracted vbios) Debian net-installer (graphical one) fails (trisquel graphical installer is ok) in native graphics and text-mode (works fine in vesa/cbfb, or in text-mode plus extracted vbios): Scrolling/flickering text in a loop (segmentation fault): Xorg (xorg_backtrace+0x49) [0xb7*******] (numbers change) Xorg (0xb75******) [0xb7*******] (numbers change (vdso) (__kernel_rt_sigreturn+0x0) [0xb7******] (numbers change) /lib/libc.so.6 (cfree+0x49) [0xb7******] (numbers change) Xorg (xf86DeleteMode+0x51) [0xb7******] (numbers change) Segmentation fault at address 0xb7200000 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting phcoder says that there are limitations in native graphic: for example, he says native init doesn't provide int10h at all, and that it lacks VBT. Are there other issues? He says that there are also lots of ACPI issues in general. On 26/08/14 02:06, The Gluglug wrote: > The same issue does not occur when using coreboot with the vga rom > extracted from factory bios. > > On 25/08/14 16:50, The Gluglug wrote: >> Using 6725 to enable text-mode gfx init on X60 when using native >> graphics initialization. > >> Affected machines: X60, T60. It may also affect: >> macbook21/macbook11, X60 Tablet > >> This relies on the (merged) patch 6723 that enables text-mode >> graphics initialization on i945 platforms. The code is there. > >> I then disabled "Keep VESA framebuffer" in menuconfig, to enable >> text-mode. > >> error: no video mode activated This is what I see when I try to >> use the net install iso for Debian with the isolinux parser in >> grub. I also saw the same thing when trying to start Trisquel 6 >> isolinux menu from SeaBIOS (with SeaVGABIOS added at >> vgaroms/vgabios.bin from seabios's rom that I built). > >> See attached image of what happens when I try to boot the net >> install from Debian (same thing happens with the Trisquel net >> install), using the following: linux (usb0)/install.386/vmlinuz >> initrd (usb0)/install.386/initrd.gz boot > >> As you can see, there is quite a lot of flicker and parts of the >> screen are missing or corrupt. I think this is related to the >> issue above ("error: no video mode activated"). > >> The net install for Debian and Trisquel both work when using >> corebootfb initialization method, but they fail (as seen in the >> image) for text-mode method. > >> In case the attachment was scrubbed by the mailing list, I also >> put it here: http://dev.libreboot.org/x60txtmode.jpg > >> Trisquel graphical install works (I wasn't able to figure out >> how to boot the Debian graphical install). > >> I also enabled it for T60 (adding the keep/drop vesa fb option >> for t60/Kconfig, based on 6725, and cherry picking 5345) and the >> same behaviour was observed there. > >> What does work in text-mode init (tested): memtest86+ and grub >> invaders. > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT/Ky2AAoJEP9Ft0z50c+UCcAH/1JmvBSLQOHn6kPZT+vvrLjq 8tZnc0PBlfLyJ+AKy+e+DWXS8UI0VShoSDrnZeGwSH/6jmay0OcLfzlicnrS90e0 5omqe9Iay7QY4yl0DJ5mgb6VadKIhMB7Rr7eRGJaipbQPmlQIvvTHOsPpYwz8ER8 ODCBMdmPlSNO8Gh8oTC6ggNIq3SLBZh6EZUn70Aa9PJJTaalsVdnCYuU2Ca4Xf1L /HVQHPiKU75ni2GrKGaTPF+9+cFvzu/pP6M9jamcw3TW/Zbt41TQPGWvQ1Xv3QLA 0zvPochd3LSHCJH4dvj8yryE0ovhQkUAlIKcJ38TGPa3l/KyKlQtK4eiXovr8i4= =RAIK -----END PGP SIGNATURE----- From coreboot at guylhem.net Tue Aug 26 17:53:24 2014 From: coreboot at guylhem.net (Charles Devereaux) Date: Tue, 26 Aug 2014 11:53:24 -0400 Subject: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2 (was: IBM x60t test - DSDT is in fact incomplete) In-Reply-To: <1409035811.6334.12.camel@users.sourceforge.net> References: <53FADAF1.6010509@gmail.com> <1409035811.6334.12.camel@users.sourceforge.net> Message-ID: Hello Not sure! Apparently, after doing echo "0 blink" >/proc/acpi/ibm/led, this is handled led_set_status in drivers/platform/x86/thinkpad_acpi.c : the first argument is the led, the second the status : acpi_evalf(led_handle, NULL, NULL, "vdd", led, led_led_arg1[ledstatus])) For the LED string, see in led_init_detect_mode : status = acpi_get_handle(ec_handle, "LED", &led_handle); My understanding is that the OS does the call that correctly, but that coreboot ASL tables only expect one argument. In coreboot/build/mainboard/lenovo/x60/dsdt.ramstage.asl, you will see Method (LED, 1, NotSerialized) which seems to confirm that, since in acpi-3.dsl I see instead Method (LED, 2, NotSerialized) On Tue, Aug 26, 2014 at 2:50 AM, Paul Menzel < paulepanter at users.sourceforge.net> wrote: > Dear Charles, dear David, > > > Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard: > > > I'm focusing in on this error message first: > > > > ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, > > found 2 > > > > Can you take a look at the .asl files in your coreboot build? I believe > you > > will find something like "Method (LED, 2, NotSerialized)" which means the > > LED method wants 2 arguments. Then look for calls to "LED ()" and if you > > find one only passing 1 argument, that is the problem. > > I also noticed that message and quickly looked through the coreboot ASL > files, but could not find anything calling that message. Looking at the > Linux kernel sources I was also unable to find a call site. But I?d say > the OS call this method incorrectly. > > [?] > > > Thanks, > > Paul > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bruce.Griffith at se-eng.com Tue Aug 26 20:00:55 2014 From: Bruce.Griffith at se-eng.com (Bruce Griffith) Date: Tue, 26 Aug 2014 12:00:55 -0600 Subject: [coreboot] AMD PSP Message-ID: <0f87bc8a4ced4babc8261265a5fec092@mail.gmail.com> Here's what I know about PSP: > I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and how scared should we be of it? Somewhat scared. The PSP is an actual processor that takes control when reset is released. The x86 does not start fetching code until the PSP is satisfied that BIOS meets whatever constraints have been programmed into the PSP firmware. There are TPM-like characteristics but I don't know any specifics. The PSP is capable of "locking" additional processor features that could be exploited to take over a system. > My hope is that it ... deactivates itself silently. For the coreboot implementation, it runs, decides that the x86 code is not its concern, and the x86 starts fetching code. From that point on, I think the PSP is transparent to the x86. > After glancing thru [the PSP presentation], it looks more like they are > grafting the security model of ARM-based SoCs onto x86 where a masked > ROM loads the next stage. A masked processor and associated firmware (the PSP) validate the first "stage" of x86 code. What comprises the first stage is arbitrary and gets signed with an AMD private key. Your first stage could be bootblock, bootblock plus romstage, something more involved, or something less involved. You need a legal arrangement with AMD to get your first stage signed. For coreboot, none of the x86 code is signed. > So we can kiss goodbye coreboot on AMD platforms in the future?.. How sad! :-/ That isn't true for the first processor with PSP. Coreboot support for "Steppe Eagle" is already posted to Gerrit. Steppe Eagle is the AMD Embedded variant of Mullins. The Olive Hill+ platform demonstrates building a coreboot ROM without requiring that AMD sign any part of the coreboot code. I expect to have the final version of support posted by the end of the week. Give me some +2's and we could have PSP support available next week! ;-) > Does this thing ... exist in any AMD CPUs buyable today? The processors are released as AMD Beema (A6-6310, A4-6210, E2-6110,E1-6010), AMD Mullins (A10 micro-6700T, A4 micro-6400T, E1 Micro-6200T), and AMD Steppe Eagle processors. AMD has developed reference boards similar to what was developed for AMD Kabini SoCs. I have not seen any retail "bare-bones" motherboards, but maybe there are low-end notebooks and desktops that use Mullins/Beema (perhaps Acer Aspire AXC-115-UR20)? From phcoder at gmail.com Tue Aug 26 20:39:15 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Tue, 26 Aug 2014 20:39:15 +0200 Subject: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2 In-Reply-To: <1409035811.6334.12.camel@users.sourceforge.net> References: <53FADAF1.6010509@gmail.com> <1409035811.6334.12.camel@users.sourceforge.net> Message-ID: <53FCD453.8080202@gmail.com> On 26.08.2014 08:50, Paul Menzel wrote: > Dear Charles, dear David, > > > Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard: > >> I'm focusing in on this error message first: >> >> ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1, >> found 2 >> >> Can you take a look at the .asl files in your coreboot build? I believe you >> will find something like "Method (LED, 2, NotSerialized)" which means the >> LED method wants 2 arguments. Then look for calls to "LED ()" and if you >> find one only passing 1 argument, that is the problem. > > I also noticed that message and quickly looked through the coreboot ASL > files, but could not find anything calling that message. Looking at the > Linux kernel sources I was also unable to find a call site. But I?d say > the OS call this method incorrectly. > It's called by acpi_thinkpad module: status = acpi_get_handle(ec_handle, "LED", &led_handle); if (!acpi_evalf(led_handle, NULL, NULL, "vdd", led, led_led_arg1[ledstatus])) static const unsigned int led_led_arg1[] = { 0, 0x80, 0xc0 }; So first argument is 0-based LED number and the second is 0/0x80/0xc0 for state which matches EC bits pretty closely (up to some shifts). We probably should rename out LED method to sth else and provide a compatible LED method. Technically whole acpi_thinkpad is outside of ACPI spec but it's needed to use some features like Lock hotkey which is outside of ACPI spec as well. > [?] > > > Thanks, > > Paul > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From phcoder at gmail.com Tue Aug 26 20:41:55 2014 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Tue, 26 Aug 2014 20:41:55 +0200 Subject: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2 In-Reply-To: References: <53FADAF1.6010509@gmail.com> <1409035811.6334.12.camel@users.sourceforge.net> Message-ID: <53FCD4F3.80208@gmail.com> On 26.08.2014 17:53, Charles Devereaux wrote: > My understanding is that the OS does the call that correctly, but that > coreboot ASL tables only expect one argument. Please provide a refrence when doing such bold claims. LED method is not specified in ACPI, so assuming that it takes any particular arguments is wrong from OS side. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From wen.wang at adiengineering.com Tue Aug 26 22:09:22 2014 From: wen.wang at adiengineering.com (Wen Wang) Date: Tue, 26 Aug 2014 16:09:22 -0400 Subject: [coreboot] Rangeley reset Message-ID: <003701cfc169$a0980d40$e1c827c0$@adiengineering.com> Hello, Has anybody tested reset signal (PMU_RESETBUTTON_B) on Rangeley/Avoton? The board seems to shut down after asserting the signal (pushing the reset button). I turn on an LED in early_mainboard_romstage_entry(). The LED was not on indicating the function was not executed. Below is what printed out on console after reset: coreboot-0f49404 Tue Aug 26 15:28:40 EDT 2014 starting... POST: 0x41 POST: 0x42 Setting up static southbridge registers... done. Disabling Watchdog timer... done. RTC Init POST: 0x46 POST: 0x47 Starting the Intel FSP (early_init) Configure Default UPD Data PcdEnableIQAT 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableLan 1 PcdEnableUsb20 1 PcdEnableSata2 1 PcdEnableSata3 1 find_current_mrc_cache_local: No valid fast boot cache found. FSP MRC cache not present. For cold boot, it will continue to spit out boot messages. Thanks! -- Wen Wang From c-d.hailfinger.devel.2006 at gmx.net Tue Aug 26 23:23:42 2014 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 26 Aug 2014 23:23:42 +0200 Subject: [coreboot] disabling bios usb stack In-Reply-To: References: <53FBAB76.1020906@gmail.com> Message-ID: <53FCFADE.6070603@gmx.net> Hi Ron, Am 26.08.2014 00:22 schrieb ron minnich: > disabling the usb stack is the goal in this case. AFAIK it's called "USB keyboard support", "USB legacy support" or something similar in most BIOSes. This internally maps a USB keyboard to a virtual PS/2 keyboard and sometimes has quite a few issues. If that's what your friend meant, disabling it should be straightforward in the BIOS menu. However, if your friend is a victim of EFI, I fear he is beyond help except for trying coreboot. Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Tue Aug 26 23:54:28 2014 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 26 Aug 2014 23:54:28 +0200 Subject: [coreboot] AMD PSP In-Reply-To: <0f87bc8a4ced4babc8261265a5fec092@mail.gmail.com> References: <0f87bc8a4ced4babc8261265a5fec092@mail.gmail.com> Message-ID: <53FD0214.7040904@gmx.net> Am 26.08.2014 20:00 schrieb Bruce Griffith: > Here's what I know about PSP: > >> I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and >> how scared should we be of it? > Somewhat scared. > > The PSP is an actual processor that takes control when reset is released. > The x86 does not start fetching code until the PSP is satisfied that BIOS > meets whatever constraints have been programmed into the PSP firmware. I can see this as a way to prevent modification of some signed parts of coreboot, i.e. it can be a usable and desirable security mechanism against unauthorized firmware replacement. However, if the key used for verification is under control of a foreign entity and can't be changed, some users (especially government users) won't consider this to be additional security. > There are TPM-like characteristics but I don't know any specifics. > > The PSP is capable of "locking" additional processor features that could > be exploited to take over a system. > >> My hope is that it ... deactivates itself silently. > For the coreboot implementation, it runs, decides that the x86 code is not > its concern, and the x86 starts fetching code. From that point on, I > think the PSP is transparent to the x86. > >> After glancing thru [the PSP presentation], it looks more like they are >> grafting the security model of ARM-based SoCs onto x86 where a masked >> ROM loads the next stage. > A masked processor and associated firmware (the PSP) validate the first > "stage" of x86 code. What comprises the first stage is arbitrary and gets > signed with an AMD private key. Your first stage could be bootblock, > bootblock plus romstage, something more involved, or something less > involved. You need a legal arrangement with AMD to get your first stage > signed. For coreboot, none of the x86 code is signed. Hm. Is there a way to have AMD exchange that key for your own, possibly by paying decent money? That way, the platform can be under your own control which would make security-conscious users (governments, military, ...) happy. Regards, Carl-Daniel From anton.kochkov at gmail.com Wed Aug 27 00:14:53 2014 From: anton.kochkov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQmtC+0YfQutC+0LI=?=) Date: Wed, 27 Aug 2014 02:14:53 +0400 Subject: [coreboot] disabling bios usb stack In-Reply-To: <53FCFADE.6070603@gmx.net> References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> Message-ID: Hello, Just checked some binaries - PEI USB driver is loading anyway, no checking for any setup option, so I guess it will be very hard even with the unpacking UEFI image and removing these drivers. Also in most UEFI systems big part of USB driver working in SMM mode, so it will be hard to patch this code on the fly. Best regards, Anton Kochkov. On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger wrote: > Hi Ron, > > Am 26.08.2014 00:22 schrieb ron minnich: >> disabling the usb stack is the goal in this case. > > AFAIK it's called "USB keyboard support", "USB legacy support" or > something similar in most BIOSes. This internally maps a USB keyboard to > a virtual PS/2 keyboard and sometimes has quite a few issues. If that's > what your friend meant, disabling it should be straightforward in the > BIOS menu. > However, if your friend is a victim of EFI, I fear he is beyond help > except for trying coreboot. > > Regards, > Carl-Daniel > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot From mgoppold5 at yahoo.com Wed Aug 27 13:44:51 2014 From: mgoppold5 at yahoo.com (Mike) Date: Wed, 27 Aug 2014 07:44:51 -0400 Subject: [coreboot] for more working mainboards Message-ID: <53FDC4B3.6060504@yahoo.com> treacherous computing, like amd trustzone... http://www.arm.com/products/processors/technologies/trustzone/index.php ... could spawn all over. We have to stop this by giving end users more purchasing choice. Someone suggested that fsf actually produce mainboards without it. Sounds like a plan. Is fsf up to it? Are they willing to sign NDAs? If not, then we should start a company to do the mainboards. Producing amd/intel/etc boards. The current coreboot code would be fully applicable, and the mainboards would ship with coreboot. At least, coreboot might disable trusted computing functionality. Agree? From patrick at georgi-clan.de Wed Aug 27 14:03:37 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 27 Aug 2014 14:03:37 +0200 Subject: [coreboot] for more working mainboards In-Reply-To: <53FDC4B3.6060504@yahoo.com> References: <53FDC4B3.6060504@yahoo.com> Message-ID: <53FDC919.5020207@georgi-clan.de> Am 27.08.2014 um 13:44 schrieb Mike: > Someone suggested that fsf actually produce mainboards without it. > Sounds like a plan. Is fsf up to it? Are they willing to sign NDAs? Questions to the FSF should be posed on FSF channels, not ours. > If not, then we should start a company to do the mainboards. Producing > amd/intel/etc boards. "we" typically means "someone else should do it". > At least, coreboot might disable trusted computing functionality. If it may. Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mgoppold5 at yahoo.com Wed Aug 27 14:47:26 2014 From: mgoppold5 at yahoo.com (Mike) Date: Wed, 27 Aug 2014 08:47:26 -0400 Subject: [coreboot] for more working mainboards In-Reply-To: <53FDC919.5020207@georgi-clan.de> References: <53FDC4B3.6060504@yahoo.com> <53FDC919.5020207@georgi-clan.de> Message-ID: <53FDD35E.7000605@yahoo.com> On 08/27/2014 08:03 AM, Patrick Georgi wrote: > Questions to the FSF should be posed on FSF channels, not ours. ok > >> If not, then we should start a company to do the mainboards. Producing >> amd/intel/etc boards. > "we" typically means "someone else should do it". Let's split up "doing it" into 3 parts: purchasing equipment/software, spending time, and signing NDAs. Which of these is problematic? NDAs? -Mike From rminnich at gmail.com Wed Aug 27 18:34:03 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 09:34:03 -0700 Subject: [coreboot] for more working mainboards In-Reply-To: <53FDC919.5020207@georgi-clan.de> References: <53FDC4B3.6060504@yahoo.com> <53FDC919.5020207@georgi-clan.de> Message-ID: I was talking to a friend about this the other day. Back when I were a mere lad, one could buy chips and build boards with CPUs that were every bit as good as what any company could sell you. I interned at HP working with engineers on boards, and I saw both sides, the company and the garage/basement. There was not a lot of difference. I built boards with many different microprocessors, and even designed DRAM controllers. It was doable. I got a chance to watch the very talented engineers in the chromebook part of Google for two years.After a few months watching them fix problems that were very subtle, I found myself realizing that the era of the Apple ][ was gone for good. I just don't see how "we can build our own mainboards" model gets you to high quality, fast, low power boards. I'd love to be shown wrong. But this "we should start a company" thing that has been appearing in this list for 15 years is now less practical than it was in 2000. Sorry, I don't like it either. If you really want a high quality, blob-free, open platform, you're probably best off with ARM, and a good choice is the new Acer 13: coreboot, no blobs, and it's really fine hardware at least for me. ron From rminnich at gmail.com Wed Aug 27 18:43:45 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 09:43:45 -0700 Subject: [coreboot] apologies in advance for a question I may have asked Message-ID: I need to set up qemu with a 64MiB ROM. I figure supporting EFI has made QEMU capable of such things, but if anyone has direct experience with this, please let me know. I tried it a few years back (2008) and it did not work at all ... I guess worst case I can make an NE2000 "device" with a giant ROM, but I'd prefer to just do it with a 64MiB device at top of 4GiB address space. TIA ron From rminnich at gmail.com Wed Aug 27 19:28:36 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 10:28:36 -0700 Subject: [coreboot] disabling bios usb stack In-Reply-To: References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> Message-ID: This is really interesting information, thanks. This embedded USB stack problem actually impacts HPC applications. This type of periodic interference can cause big troubles when you have lots of nodes. Look for "the case of the missing supercomputer performance" for a classic paper. In that case, a 1/30 hz (i.e. lpd dropping out of select every 30 seconds on 2048 nodes) was worth a couple tens of millions of dollars of performance. I'm amazed that the embedded USB stack problems are WORSE, not better, than they were a few years back. The x86 world just keeps getting more backwards. I'm sorry to see the ARM V8 world trying to emulate it. ron On Tue, Aug 26, 2014 at 3:14 PM, ????? ?????? wrote: > Hello, > > Just checked some binaries - PEI USB driver is loading anyway, no > checking for any setup option, so I guess it will be very hard even > with the unpacking UEFI image and removing these drivers. Also in most > UEFI systems big part of USB driver working in SMM mode, so it will be > hard to patch this code on the fly. > Best regards, > Anton Kochkov. > > > On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger > wrote: >> Hi Ron, >> >> Am 26.08.2014 00:22 schrieb ron minnich: >>> disabling the usb stack is the goal in this case. >> >> AFAIK it's called "USB keyboard support", "USB legacy support" or >> something similar in most BIOSes. This internally maps a USB keyboard to >> a virtual PS/2 keyboard and sometimes has quite a few issues. If that's >> what your friend meant, disabling it should be straightforward in the >> BIOS menu. >> However, if your friend is a victim of EFI, I fear he is beyond help >> except for trying coreboot. >> >> Regards, >> Carl-Daniel >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot From echelon at free.fr Wed Aug 27 20:11:24 2014 From: echelon at free.fr (echelon at free.fr) Date: Wed, 27 Aug 2014 20:11:24 +0200 (CEST) Subject: [coreboot] =?utf-8?q?Re=C2=A0=3A_Re=3A__for_more_working_mainboar?= =?utf-8?q?ds?= In-Reply-To: Message-ID: <1727698341.40300509.1409163084900.JavaMail.root@zimbra6-e1.priv.proxad.net> Hello Ron, Could you be more speciffic about "what is not doable" today? (and why?) Sorry to be annoying.. Regards, Florentin ----- Mail d'origine ----- De: ron minnich ?: Patrick Georgi Cc: coreboot Envoy?: Wed, 27 Aug 2014 18:34:03 +0200 (CEST) Objet: Re: [coreboot] for more working mainboards .... I got a chance to watch the very talented engineers in the chromebook part of Google for two years.After a few months watching them fix problems that were very subtle, I found myself realizing that the era of the Apple ][ was gone for good... .... From dhendrix at google.com Wed Aug 27 20:52:50 2014 From: dhendrix at google.com (David Hendricks) Date: Wed, 27 Aug 2014 11:52:50 -0700 Subject: [coreboot] for more working mainboards In-Reply-To: <53FDC4B3.6060504@yahoo.com> References: <53FDC4B3.6060504@yahoo.com> Message-ID: On Wed, Aug 27, 2014 at 4:44 AM, Mike wrote: > If not, then we should start a company to do the mainboards. Producing > amd/intel/etc boards. > You're in luck, some enterprising people already did: http://www.gizmosphere.org/why-gizmo/gizmoboard/ http://www.minnowboard.org/ -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reinauer at coreboot.org Wed Aug 27 21:07:06 2014 From: stefan.reinauer at coreboot.org (Stefan Reinauer) Date: Wed, 27 Aug 2014 21:07:06 +0200 Subject: [coreboot] apologies in advance for a question I may have asked In-Reply-To: References: Message-ID: <20140827190705.GA13176@coreboot.org> * ron minnich [140827 18:43]: > I need to set up qemu with a 64MiB ROM. > > I figure supporting EFI has made QEMU capable of such things, but if > anyone has direct experience with this, please let me know. I tried it > a few years back (2008) and it did not work at all ... I guess worst > case I can make an NE2000 "device" with a giant ROM, but I'd prefer to > just do it with a 64MiB device at top of 4GiB address space. I assume you don't mean MBit, so you're out of luck. Most likely with both the NE2000 approach and the system firwmware approach. >From hw/i386/pc_sysfw.c: /* We don't have a theoretically justifiable exact lower bound on the * base * address of any flash mapping. In practice, the IO-APIC MMIO range is * [0xFEE00000..0xFEE01000[ -- see IO_APIC_DEFAULT_ADDRESS --, leaving * free * only 18MB-4KB below 4G. For now, restrict the cumulative mapping to * 8MB in * size. */ #define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 8*1024*1024)) Stefan From scott at notabs.org Wed Aug 27 20:43:37 2014 From: scott at notabs.org (Scott Duplichan) Date: Wed, 27 Aug 2014 13:43:37 -0500 Subject: [coreboot] disabling bios usb stack In-Reply-To: References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> Message-ID: <001c01cfc226$d20a9b50$761fd1f0$@notabs.org> ron minnich [mailto:rminnich at gmail.com] wrote: ]This is really interesting information, thanks. ] ]This embedded USB stack problem actually impacts HPC applications. ]This type of periodic interference can cause big troubles when you ]have lots of nodes. ] ]Look for "the case of the missing supercomputer performance" for a ]classic paper. In that case, a 1/30 hz (i.e. lpd dropping out of ]select every 30 seconds on 2048 nodes) was worth a couple tens of ]millions of dollars of performance. ] ]I'm amazed that the embedded USB stack problems are WORSE, not better, ]than they were a few years back. The x86 world just keeps getting more ]backwards. I'm sorry to see the ARM V8 world trying to emulate it. ] ]ron I have seen concern about BIOS SMI overhead from server customers running certain applications. These customers do not want avoidable interruptions of even a few uS. Some server BIOS enable a periodic SMI for various server management uses. This never ending periodic SMI is not wanted by these customers. But I thought all USB related SMI activity ends after a legacy BIOS hands control to an operating system that supports USB. For pure UEFI, I don't believe the USB uses SMI at all. So it would seem like disabling USB in the operating system would be just as good as doing it in BIOS. If an OS that predates USB is used, SMI will continue in order to support legacy 60/64 emulation. In this case, the easiest solution might be to set the global SMI mask in the south bridge, assuming this is the only source of SMI. Thanks, Scott On Tue, Aug 26, 2014 at 3:14 PM, ????? ?????? wrote: > Hello, > > Just checked some binaries - PEI USB driver is loading anyway, no > checking for any setup option, so I guess it will be very hard even > with the unpacking UEFI image and removing these drivers. Also in most > UEFI systems big part of USB driver working in SMM mode, so it will be > hard to patch this code on the fly. > Best regards, > Anton Kochkov. > > > On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger > wrote: >> Hi Ron, >> >> Am 26.08.2014 00:22 schrieb ron minnich: >>> disabling the usb stack is the goal in this case. >> >> AFAIK it's called "USB keyboard support", "USB legacy support" or >> something similar in most BIOSes. This internally maps a USB keyboard to >> a virtual PS/2 keyboard and sometimes has quite a few issues. If that's >> what your friend meant, disabling it should be straightforward in the >> BIOS menu. >> However, if your friend is a victim of EFI, I fear he is beyond help >> except for trying coreboot. >> >> Regards, >> Carl-Daniel >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot From mgoppold5 at yahoo.com Wed Aug 27 21:19:32 2014 From: mgoppold5 at yahoo.com (Mike) Date: Wed, 27 Aug 2014 15:19:32 -0400 Subject: [coreboot] for more working mainboards In-Reply-To: References: <53FDC4B3.6060504@yahoo.com> <53FDC919.5020207@georgi-clan.de> Message-ID: <53FE2F44.8070900@yahoo.com> Sounds very good. Please clarify, you mean the Acer Chromebook 13? Thanks in advance. On 08/27/2014 12:34 PM, ron minnich wrote: > I was talking to a friend about this the other day. > > Back when I were a mere lad, one could buy chips and build boards with > CPUs that were every bit as good as what any company could sell you. I > interned at HP working with engineers on boards, and I saw both sides, > the company and the garage/basement. There was not a lot of > difference. I built boards with many different microprocessors, and > even designed DRAM controllers. It was doable. > > I got a chance to watch the very talented engineers in the chromebook > part of Google for two years.After a few months watching them fix > problems that were very subtle, I found myself realizing that the era > of the Apple ][ was gone for good. I just don't see how "we can build > our own mainboards" model gets you to high quality, fast, low power > boards. I'd love to be shown wrong. But this "we should start a > company" thing that has been appearing in this list for 15 years is > now less practical than it was in 2000. > > Sorry, I don't like it either. > > If you really want a high quality, blob-free, open platform, you're > probably best off with ARM, and a good choice is the new Acer 13: > coreboot, no blobs, and it's really fine hardware at least for me. > > ron > From rminnich at gmail.com Wed Aug 27 22:05:05 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 13:05:05 -0700 Subject: [coreboot] for more working mainboards Message-ID: On Wed, Aug 27, 2014 at 11:11 AM, wrote: > Hello Ron, > Could you be more speciffic about "what is not doable" today? (and why?) > Sorry to be annoying.. You are not being annoying at all. And I wish I could say more. Let me just say that some of the hardware bugs I saw were very complex, and very subtle, and only observable on some very expensive logic analyzers. The resolution of them required a lot of help from the vendors. They took lots of time with lots of engineers and resolved down, typically, to very small changes. I was left feeling that the small outfits that used to do hardware in the early days (I mean the 70s and 80s) could never make it in this new world. It's very expensive and very hard. I realize some might see the raspberry pi is a counterpoint, but I don't think it really is, because the level of complexity of that system is so much less. ron From rminnich at gmail.com Wed Aug 27 22:06:35 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 13:06:35 -0700 Subject: [coreboot] disabling bios usb stack In-Reply-To: <001c01cfc226$d20a9b50$761fd1f0$@notabs.org> References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> <001c01cfc226$d20a9b50$761fd1f0$@notabs.org> Message-ID: Thanks scott! So, what does an OS do to disable USB in the operating system? We have seen Linux do it, we're not quite sure just what place it gets done. ron From rminnich at gmail.com Wed Aug 27 22:07:52 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 13:07:52 -0700 Subject: [coreboot] apologies in advance for a question I may have asked In-Reply-To: <20140827190705.GA13176@coreboot.org> References: <20140827190705.GA13176@coreboot.org> Message-ID: well, stefan, I was hoping not to hear that answer, but I guess that's the way it goes :-) Thanks ron From rminnich at gmail.com Wed Aug 27 23:14:43 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 14:14:43 -0700 Subject: [coreboot] bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer. In-Reply-To: <53FCACB7.7090306@gluglug.org.uk> References: <53FB5B4D.1050004@gluglug.org.uk> <53FBDD7D.3000705@gluglug.org.uk> <53FCACB7.7090306@gluglug.org.uk> Message-ID: Just FYI, the native graphics work for the chromebooks works fine. But it was a long hard road to get there -- it basically took 18 months of hard off-again, on-again work. Further, in our case, we set up the max res and bpp and use that. No modes. No text mode. No interrupts. We pass the details in the tables and the payload is expected to work it out. The kernel works it out by seeing that graphics hardware is initialized and using what it finds. We had no desire to support text mode or int10 or any 1981-era services. Our goal was to provide a canvas in which depth charge and/or the X server could paint graphics. So our use case is more limited than yours. I would argue that you should try to get around the need for text mode and INT10, but that's just me, since the goal of coreboot from the start was to get rid of INTxx; as wonderful as things like seabios are, they are not what we intended to have when we started the project. In short, native graphics is nowhere near complete if your goal is a full text mode, INT10 supporting, standard PC world. ron From todd at m2n.com Wed Aug 27 23:16:46 2014 From: todd at m2n.com (Todd Weaver) Date: Wed, 27 Aug 2014 14:16:46 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO Message-ID: <1409174206.5189.15.camel@pure15.puri.sm> It appears (from following the instructions) that I have a new board with unsupported cpu, chipset, and superIO. 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06) 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 05) >From this page: http://www.coreboot.org/Developer_Manual#Supporting_a_new_board_with_a_unsupported_cpu.2C_chipset_or_superIO It appears "If it is not supported by coreboot then you will have a lot of work in front of you." What I need to find out is: a) If it is even possible to get coreboot to work with this board? b) How much time would it take to get coreboot to work with this board? c) If there is any coreboot developers that would be willing to contract for hire to develop coreboot for this board? It is a requirement to replace the bios with coreboot, so I am tasked with making sure it is possible (a), a rough idea of how long (b), and if we can hire somebody to develop it (c). I appreciate any replies to any parts of the above, and I am hopeful somebody would be able to have the time needed to get paid to get coreboot onto this board. Thank you! Todd Weaver From stefan.tauner at alumni.tuwien.ac.at Thu Aug 28 00:01:29 2014 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Thu, 28 Aug 2014 00:01:29 +0200 Subject: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set In-Reply-To: <53E9CCBD.4040704@assembler.cz> References: <53B07FED.5050402@assembler.cz> <53C2C1D1.6050300@assembler.cz> <53E9CCBD.4040704@assembler.cz> Message-ID: <201408272201.s7RM1Tof013715@mail2.student.tuwien.ac.at> Hi Rudolf and everybody else preparing for Prague! I'd like to know when everybody will arrive and at which time we get access to the hacking place on Thursday. Also, do you have any specific plans? I'd like to get my t410s ported: http://www.coreboot.org/Board:lenovo/t410s and if Carl-Daniel comes too, discuss/hack on flashrom of course. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From rminnich at gmail.com Thu Aug 28 00:22:10 2014 From: rminnich at gmail.com (ron minnich) Date: Wed, 27 Aug 2014 15:22:10 -0700 Subject: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set In-Reply-To: <201408272201.s7RM1Tof013715@mail2.student.tuwien.ac.at> References: <53B07FED.5050402@assembler.cz> <53C2C1D1.6050300@assembler.cz> <53E9CCBD.4040704@assembler.cz> <201408272201.s7RM1Tof013715@mail2.student.tuwien.ac.at> Message-ID: I want to get paging in for real. I'll bring a chromebook to do the work on. ron From mgoppold5 at yahoo.com Thu Aug 28 06:10:08 2014 From: mgoppold5 at yahoo.com (Mike) Date: Wed, 27 Aug 2014 21:10:08 -0700 Subject: [coreboot] for more working mainboards In-Reply-To: References: Message-ID: <53FEABA0.9090608@yahoo.com> That puts ideas to rest. :) Thanks. No more questions from me. Have a good day, guys -Mike On 8/27/2014 1:05 PM, ron minnich wrote: > On Wed, Aug 27, 2014 at 11:11 AM, wrote: >> Hello Ron, >> Could you be more speciffic about "what is not doable" today? (and why?) >> Sorry to be annoying.. > > You are not being annoying at all. And I wish I could say more. Let me > just say that some of the hardware bugs I saw were very complex, and > very subtle, and only observable on some very expensive logic > analyzers. The resolution of them required a lot of help from the > vendors. They took lots of time with lots of engineers and resolved > down, typically, to very small changes. > > I was left feeling that the small outfits that used to do hardware in > the early days (I mean the 70s and 80s) could never make it in this > new world. It's very expensive and very hard. I realize some might see > the raspberry pi is a counterpoint, but I don't think it really is, > because the level of complexity of that system is so much less. > > ron > From wilcoxbaker at gmail.com Thu Aug 28 18:59:01 2014 From: wilcoxbaker at gmail.com (Paul Wilcox-Baker) Date: Thu, 28 Aug 2014 09:59:01 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <1409174206.5189.15.camel@pure15.puri.sm> References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: Dear Todd, > It appears (from following the instructions) that I have a new board > with unsupported cpu, chipset, and superIO. > 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core > Processor DRAM Controller (rev 06) > 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev > 05) We are interested in a BIOS for the same processor family, but a different PCH device. > c) If there is any coreboot developers that would be willing to contract > for hire to develop coreboot for this board? There is a company, Sage Engineering that ports coreboot to various processors. We are probably going to use them. See http://www.se-eng.com or to ask a question use: http://www.se-eng.com/contact/ >From what I have been able to find out you need some binary "secret sauce" that comes from Intel. This allows coreboot to do things like set up the DRAM controller and video. The problem is that Intel only lets a few people have access to this code. For instance, for one of the people who could get this code, they claim the process is this simple: http://www.coreboot.org/pipermail/coreboot/2014-July/078275.html > It appears "If it is not supported by coreboot then you will have a lot > of work in front of you." This view, is based on not having the Intel code and writing your own code to set up the DRAM controllers. I imagine that it would be very difficult to write code for modern DRAM controllers, you have to read the EEPROMs on the DIMMs to determine the DRAM size and other characteristics, then set up the controller to match. Finally, DDR3 (used by this processor) has a training phase to get data accesses aligned in time. This might be implemented in hardware, or you might have to write code to do it. I don't know! If you get a different story about this, I would love to hear it. Thanks, Paul From todd at m2n.com Thu Aug 28 19:28:44 2014 From: todd at m2n.com (Todd Weaver) Date: Thu, 28 Aug 2014 10:28:44 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: Wonderful writeup Paul, thank you. see below? On Aug 28, 2014, at 9:59 AM, Paul Wilcox-Baker wrote: > Dear Todd, > >> It appears (from following the instructions) that I have a new board >> with unsupported cpu, chipset, and superIO. > >> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core >> Processor DRAM Controller (rev 06) >> 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev >> 05) > > We are interested in a BIOS for the same processor family, but a different > PCH device. Maybe we can work together in this effort, I did track down a longtime developer relationship I have, who did BIOS development for Xerox, and is available to get involved with coreboot. >> c) If there is any coreboot developers that would be willing to contract >> for hire to develop coreboot for this board? > > There is a company, Sage Engineering that ports coreboot to various > processors. We are probably going to use them. See > http://www.se-eng.com or to ask a question use: > http://www.se-eng.com/contact/ I was referred to them yesterday, and am in contact with them, we will very likely use their expertise. > From what I have been able to find out you need some binary "secret sauce" > that comes from Intel. This allows coreboot to do things like set up the > DRAM controller and video. The problem is that Intel only lets a few > people have access to this code. > > For instance, for one of the people who could get this code, they claim > the process is this simple: > http://www.coreboot.org/pipermail/coreboot/2014-July/078275.html > The above information is remarkably helpful in figuring out how to proceed! I really appreciate getting this overview. >> It appears "If it is not supported by coreboot then you will have a lot >> of work in front of you." > > This view, is based on not having the Intel code and writing your own code > to set up the DRAM controllers. I imagine that it would be very difficult > to write code for modern DRAM controllers, you have to read the EEPROMs > on the DIMMs to determine the DRAM size and other characteristics, then > set up the controller to match. Finally, DDR3 (used by this processor) has a > training phase to get data accesses aligned in time. This might be implemented > in hardware, or you might have to write code to do it. I don't know! > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > If you get a different story about this, I would love to hear it. > > Thanks, Paul The story I?ve heard thus far is exactly as you spell it out, even though you have provided more information in certain parts. Thanks Paul, and let me know if we can pool resources to get this to happen! Todd. From david.c.hubbard+coreboot at gmail.com Thu Aug 28 19:36:22 2014 From: david.c.hubbard+coreboot at gmail.com (David Hubbard) Date: Thu, 28 Aug 2014 11:36:22 -0600 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: On Thu, Aug 28, 2014 at 11:28 AM, Todd Weaver wrote: > >> It appears "If it is not supported by coreboot then you will have a lot > >> of work in front of you." > > > > This view, is based on not having the Intel code and writing your own code > > to set up the DRAM controllers. I imagine that it would be very difficult > > to write code for modern DRAM controllers, you have to read the EEPROMs > > on the DIMMs to determine the DRAM size and other characteristics, then > > set up the controller to match. Finally, DDR3 (used by this processor) has a > > training phase to get data accesses aligned in time. This might be implemented > > in hardware, or you might have to write code to do it. I don't know! > > > > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) The reality is that Intel has no plans to release code for Xeon E3-1200 v3 and HM86 Express. Coreboot's progress so far has been to integrate the blobs. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at georgi-clan.de Thu Aug 28 19:52:15 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 28 Aug 2014 19:52:15 +0200 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: <53FF6C4F.4070609@georgi-clan.de> Am 28.08.2014 um 18:59 schrieb Paul Wilcox-Baker: > From what I have been able to find out you need some binary "secret sauce" > that comes from Intel. This allows coreboot to do things like set up the > DRAM controller and video. The problem is that Intel only lets a few > people have access to this code. Relevant binaries for several chipsets can be found on http://www.intel.com/fsp Support for FSP on this list is limited (since we're stuck at the same binary boundaries as everyone else), but we'll try. Regards, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rminnich at gmail.com Thu Aug 28 19:59:21 2014 From: rminnich at gmail.com (ron minnich) Date: Thu, 28 Aug 2014 10:59:21 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: On Thu, Aug 28, 2014 at 10:28 AM, Todd Weaver wrote: > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) How much time and money for the RE effort did you have again? It needs to be a lot. Were I you I would not expect much help from the vendor to RE their code :-) And you're still going to need the microcode blob, almost certainly, unless you don't like having a working mainboard. If you NEED blob-free, you may need to go ARM. ron From todd at m2n.com Thu Aug 28 20:09:48 2014 From: todd at m2n.com (Todd Weaver) Date: Thu, 28 Aug 2014 11:09:48 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: On Aug 28, 2014, at 10:36 AM, David Hubbard wrote: > > The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > > The reality is that Intel has no plans to release code for Xeon E3-1200 v3 and HM86 Express. Coreboot's progress so far has been to integrate the blobs. That is helpful to know, I was considering funding coreboot development, coupled with a libreboot (to deblob it) dual effort, and now I know it will be more than just a consideration. From todd at m2n.com Thu Aug 28 20:26:34 2014 From: todd at m2n.com (Todd Weaver) Date: Thu, 28 Aug 2014 11:26:34 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: On Aug 28, 2014, at 10:59 AM, ron minnich wrote: >> The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) > > How much time and money for the RE effort did you have again? It needs > to be a lot. Were I you I would not expect much help from the vendor > to RE their code :-) Time was measured in months. Not weeks nor years. Funds varied, which is why we are gathering interested developers to get some quotes to propose funding the effort. > And you're still going to need the microcode blob, almost certainly, > unless you don't like having a working main board. We require blob-free and a working main board, so this sounds like a really challenging RE effort indeed! > If you NEED blob-free, you may need to go ARM. We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Todd. From patrick at georgi-clan.de Thu Aug 28 20:29:54 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 28 Aug 2014 20:29:54 +0200 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: <53FF7522.7060408@georgi-clan.de> Am 28.08.2014 um 20:26 schrieb Todd Weaver: > We require blob-free and a working main board, so this sounds like a really challenging RE effort indeed! > We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. In that case you will probably have to stick to GM45 or older, or Quark X1000. All other Intel chipsets require - to my knowledge - management engine firmware. Regards, Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From scott at notabs.org Thu Aug 28 21:52:29 2014 From: scott at notabs.org (Scott Duplichan) Date: Thu, 28 Aug 2014 14:52:29 -0500 Subject: [coreboot] disabling bios usb stack In-Reply-To: References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> <001c01cfc226$d20a9b50$761fd1f0$@notabs.org> Message-ID: <00be01cfc2f9$9b10d2d0$d1327870$@notabs.org> ron minnich [mailto:rminnich at gmail.com] wrote: ]Thanks scott! ] ]So, what does an OS do to disable USB in the operating system? We have ]seen Linux do it, we're not quite sure just what ]place it gets done. ] ]ron If I understand your question, I am not sure I know the answer. If you boot linux with grub option 'nousb', or reboot Windows after disabling usb controllers from device manager, what happens? I assume the operating system just ignores USB controllers. It seems unlikely that the OS would take some action to ensure that they are properly disabled. Does UEFI disable USB controllers before handoff to the OS loader? I do not know. Having the OS not load USB drivers should eliminate USB related interrupts, but I know EHCI can generate memory accesses even when idle. Thanks, Scott From rminnich at gmail.com Thu Aug 28 22:20:18 2014 From: rminnich at gmail.com (ron minnich) Date: Thu, 28 Aug 2014 13:20:18 -0700 Subject: [coreboot] disabling bios usb stack In-Reply-To: <00be01cfc2f9$9b10d2d0$d1327870$@notabs.org> References: <53FBAB76.1020906@gmail.com> <53FCFADE.6070603@gmx.net> <001c01cfc226$d20a9b50$761fd1f0$@notabs.org> <00be01cfc2f9$9b10d2d0$d1327870$@notabs.org> Message-ID: The guys found it, bit in southbridge to enable SMI interrupts, they turned it off and are now seeing a 40 hz. interrupt. It never ends. From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 28 22:29:36 2014 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 28 Aug 2014 22:29:36 +0200 Subject: [coreboot] apologies in advance for a question I may have asked In-Reply-To: References: <20140827190705.GA13176@coreboot.org> Message-ID: <53FF9130.2020403@gmx.net> Am 27.08.2014 22:07 schrieb ron minnich: > well, stefan, I was hoping not to hear that answer, but I guess that's > the way it goes :-) Well, 16 MByte are doable and also happen on real hardware, but with bigger chips you're out of luck. Both for SPI addressing reasons (24 bit addresses by default) and for legacy reasons. I heard rumors that newer x86 can handle larger flash chips, but AFAIK only with the help of PIO, not directly mapped. Similar rule for Qemu. That said, changing FLASH_MAP_BASE_MIN to #define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 16*1024*1024)) should work. Regards, Carl-Daniel From rminnich at gmail.com Thu Aug 28 22:31:14 2014 From: rminnich at gmail.com (ron minnich) Date: Thu, 28 Aug 2014 13:31:14 -0700 Subject: [coreboot] apologies in advance for a question I may have asked In-Reply-To: <53FF9130.2020403@gmx.net> References: <20140827190705.GA13176@coreboot.org> <53FF9130.2020403@gmx.net> Message-ID: turns out 16 MiB will do it! Thanks all! I really am glad you are here to answer silly questions :-) ron On Thu, Aug 28, 2014 at 1:29 PM, Carl-Daniel Hailfinger wrote: > Am 27.08.2014 22:07 schrieb ron minnich: >> well, stefan, I was hoping not to hear that answer, but I guess that's >> the way it goes :-) > > Well, 16 MByte are doable and also happen on real hardware, but with > bigger chips you're out of luck. Both for SPI addressing reasons (24 bit > addresses by default) and for legacy reasons. I heard rumors that newer > x86 can handle larger flash chips, but AFAIK only with the help of PIO, > not directly mapped. Similar rule for Qemu. > > That said, changing FLASH_MAP_BASE_MIN to > > #define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 16*1024*1024)) > > should work. > > > Regards, > Carl-Daniel From todd at m2n.com Thu Aug 28 23:16:25 2014 From: todd at m2n.com (Todd Weaver) Date: Thu, 28 Aug 2014 14:16:25 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: References: <1409174206.5189.15.camel@pure15.puri.sm> Message-ID: <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: > On Aug 28, 2014, at 10:59 AM, ron minnich wrote: >>> The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) >> If you NEED blob-free, you may need to go ARM. > > We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS? From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 28 23:29:27 2014 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 28 Aug 2014 23:29:27 +0200 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> References: <1409174206.5189.15.camel@pure15.puri.sm> <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> Message-ID: <53FF9F37.8070404@gmx.net> Am 28.08.2014 23:16 schrieb Todd Weaver: > On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: >> On Aug 28, 2014, at 10:59 AM, ron minnich wrote: >>>> The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) >>> If you NEED blob-free, you may need to go ARM. >> We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. > Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS? You can, but with chipsets/CPUs released in the last few months you may be out of luck. Right now, it appears AMD does not see compelling enough business reasons to publish the source code for the newest hardware generations, but you may be able to get the source code for the blobs under NDA. That said, there are quite a few pieces of recent (and still in production) AMD hardware which do have full coreboot support. Exceptions from the blob-free guarantee are graphics firmware and USB3 firmware, which are both not executed on the main CPU. Depending on how big your order is (not just "enthusiasts all over the world will surely buy it", but real money spent by your company/organization), you might have some real leverage, even for getting code published. Regards, Carl-Daniel From todd at m2n.com Thu Aug 28 23:38:48 2014 From: todd at m2n.com (Todd Weaver) Date: Thu, 28 Aug 2014 14:38:48 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <53FF9F37.8070404@gmx.net> References: <1409174206.5189.15.camel@pure15.puri.sm> <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> <53FF9F37.8070404@gmx.net> Message-ID: <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> On Aug 28, 2014, at 2:29 PM, Carl-Daniel Hailfinger wrote: > Am 28.08.2014 23:16 schrieb Todd Weaver: >> On Aug 28, 2014, at 11:26 AM, Todd Weaver wrote: >>> On Aug 28, 2014, at 10:59 AM, ron minnich wrote: >>>>> The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) >>>> If you NEED blob-free, you may need to go ARM. >>> We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. >> Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS? > > You can, but with chipsets/CPUs released in the last few months you may > be out of luck. Right now, it appears AMD does not see compelling enough > business reasons to publish the source code for the newest hardware > generations, but you may be able to get the source code for the blobs > under NDA. Thanks, that helps set the stage with AMD discussions. > That said, there are quite a few pieces of recent (and still in > production) AMD hardware which do have full coreboot support. Exceptions > from the blob-free guarantee are graphics firmware and USB3 firmware, > which are both not executed on the main CPU. Comparing the blob-free versions from Intel (which are apparently signed, so according to http://www.coreboot.org/Binary_situation are at a 9000+ panic level), would it be possible to have blob-free (probably through RE) that would work (meaning does not require signed binaries) on an AMD board? > Depending on how big your order is (not just "enthusiasts all over the > world will surely buy it", but real money spent by your > company/organization), you might have some real leverage, even for > getting code published. We will do what we can here. The issue is even with immense leverage, having the source released (from AMI, or AMD, (or Intel for that matter)) would undermine tremendous profit that these companies make by keeping this proprietary. So I?m leaning toward the direction that we?d have to RE the missing pieces (but could be wrong, thus the questions). Todd. From curt at cumulusnetworks.com Fri Aug 29 01:08:55 2014 From: curt at cumulusnetworks.com (Curt Brune) Date: Thu, 28 Aug 2014 16:08:55 -0700 Subject: [coreboot] cbfstool, Linux trampoline and SeaBIOS Message-ID: <20140828230855.GA8108@cumulusnetworks.com> Hello - First time poster, so take it easy on me :) This is a great project -- I was able to get a kvm+coreboot+SeaBIOS environment going pretty easily. I started with the master branch of coreboot and went from there. I am having a problem trying to load a Linux kernel+initramfs cbfs payload from SeaBIOS. I can successfully boot the same kernel+initramfs straight from coreboot (without SeaBIOS) as a payload. I started this topic on the SeaBIOS list -- there's a lot of good background in the replies there: http://www.seabios.org/pipermail/seabios/2014-August/008215.html I now think my problem lies in the cbfstool and the Linux trampoline. Summarizing the analysis from those posts: the Linux trampoline code does not set up the segment descriptors for __BOOT_CS and __BOOT_DS as described in the Linux kernel documentation: ... a GDT must be loaded with the descriptors for selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat segment; __BOOT_CS must have execute/read permission, and __BOOT_DS must have read/write permission; Now in the working coreboot case it turns out the segment descriptors at selectors 0x10 and 0x18, setup in the coreboot ramstage, match what the Linux kernel expects (see coreboot/src/arch/x86/lib/c_start.S). In the non-working SeaBIOS case the segment descriptors are configured differently and the cbfs Linux payload does not work. If the cbfs Linux payload is to be used in multiple environments should the trampoline take care of descriptors that Linux requires? Attached is a patch to util/cbfstool/linux_trampoline.c that does just that. Basically I borrowed the descriptor configs from coreboot/src/arch/x86/lib/c_start.S for selectors 0x10 and 0x18. Apologies for my poor x86 assembly coding -- first time. Cheers, Curt -------------- next part -------------- A non-text attachment was scrubbed... Name: linux_trampoline.patch Type: text/x-diff Size: 4194 bytes Desc: not available URL: From rminnich at gmail.com Fri Aug 29 01:30:57 2014 From: rminnich at gmail.com (ron minnich) Date: Thu, 28 Aug 2014 16:30:57 -0700 Subject: [coreboot] cbfstool, Linux trampoline and SeaBIOS In-Reply-To: <20140828230855.GA8108@cumulusnetworks.com> References: <20140828230855.GA8108@cumulusnetworks.com> Message-ID: Curt, this is super great news for me to hear, and if you can show me how to do the linux boot with linux as payload I need to see it. I screwed it up and it did not work for me :) one thing I wonder: if you can boot linux as the payload, what's the reason to use seabios? I'm missing something. Many thanks ron From patrick at georgi-clan.de Fri Aug 29 07:39:20 2014 From: patrick at georgi-clan.de (Patrick Georgi) Date: Fri, 29 Aug 2014 07:39:20 +0200 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> References: <1409174206.5189.15.camel@pure15.puri.sm> <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> <53FF9F37.8070404@gmx.net> <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> Message-ID: <1742496644041924095ba97fff2af82c@mail.georgi-clan.de> Am 2014-08-28 23:38, schrieb Todd Weaver: > Comparing the blob-free versions from Intel (which are apparently > signed, so according to http://www.coreboot.org/Binary_situation are > at a 9000+ panic level), would it be possible to have blob-free > (probably through RE) that would work (meaning does not require signed > binaries) on an AMD board? Newer chipsets (as in yet to be released) come with signed parts, but it seems the scope of the signature is configurable somehow by AMD. There were some mails about that a couple of days ago ("AMD PSP"). > We will do what we can here. The issue is even with immense leverage, > having the source released (from AMI, or AMD, (or Intel for that > matter)) would undermine tremendous profit that these companies make > by keeping this proprietary. AMD claims that they stopped working on open sourcing their initialization code because it's lots of work (ie. money) with limited return on investment. How much work that is isn't here or there (most of that is because their internal development process is less than optimal and, like most processes in most organizations, hard to change). But it means that someone could make it worth their while given the right kind of project. What they don't provide sources for is CPU microcode updates (no one does since it's of limited value without the microcode development toolchain and the microcode itself that is getting updated) and various smaller firmware (USB3 which is a licensed core, IMC, an embedded controller, and the SMU). For IMC and SMU there's some reverse engineering effort, partially documented in the wiki, so by asking the right questions to the right people in this community, plus some development, it might be possible to get them opened up even without AMD's help. Patrick From todd at m2n.com Fri Aug 29 15:45:08 2014 From: todd at m2n.com (Todd Weaver) Date: Fri, 29 Aug 2014 06:45:08 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> References: <1409174206.5189.15.camel@pure15.puri.sm> <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> <53FF9F37.8070404@gmx.net> <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> Message-ID: <7524FC4B-B4CE-4898-A614-A34F74CF8847@m2n.com> > Am 2014-08-28 23:38, schrieb Todd Weaver: >> Comparing the blob-free versions from Intel (which are apparently >> signed, so according to http://www.coreboot.org/Binary_situation are >> at a 9000+ panic level), would it be possible to have blob-free >> (probably through RE) that would work (meaning does not require signed >> binaries) on an AMD board? > Newer chipsets (as in yet to be released) come with signed parts, but it > seems the scope of the signature is configurable somehow by AMD. There > were some mails about that a couple of days ago ("AMD PSP?). Thank you I will research that. >> We will do what we can here. The issue is even with immense leverage, >> having the source released (from AMI, or AMD, (or Intel for that >> matter)) would undermine tremendous profit that these companies make >> by keeping this proprietary. > AMD claims that they stopped working on open sourcing their > initialization code because it's lots of work (ie. money) with limited > return on investment. How much work that is isn't here or there (most of > that is because their internal development process is less than optimal > and, like most processes in most organizations, hard to change). > But it means that someone could make it worth their while given the > right kind of project. Very helpful, thank you! > What they don't provide sources for is CPU microcode updates (no one > does since it's of limited value without the microcode development > toolchain and the microcode itself that is getting updated) and various > smaller firmware (USB3 which is a licensed core, IMC, an embedded > controller, and the SMU). > For IMC and SMU there's some reverse engineering effort, partially > documented in the wiki, so by asking the right questions to the right > people in this community, plus some development, it might be possible to > get them opened up even without AMD's help. This is extremely helpful in making the case against Intel (which was better received than I had thought) we are at least working with the board manufacturer about AMD instead of Intel? Here?s hoping. Thank you all! Todd. From rminnich at gmail.com Fri Aug 29 16:39:40 2014 From: rminnich at gmail.com (ron minnich) Date: Fri, 29 Aug 2014 07:39:40 -0700 Subject: [coreboot] New board with unsupported cpu, chipset, and superIO In-Reply-To: <7524FC4B-B4CE-4898-A614-A34F74CF8847@m2n.com> References: <1409174206.5189.15.camel@pure15.puri.sm> <06BE3FE7-6C40-472D-9767-3AB65045469C@m2n.com> <53FF9F37.8070404@gmx.net> <9ABFBE73-1EC7-4A58-AF0B-57A13C5887D9@m2n.com> <7524FC4B-B4CE-4898-A614-A34F74CF8847@m2n.com> Message-ID: Just a word to whoever does this next: figure out your firmware picture first, THEN pick the hardware. It's never been a good idea to start the other way around. ron From curt at cumulusnetworks.com Fri Aug 29 17:58:45 2014 From: curt at cumulusnetworks.com (Curt Brune) Date: Fri, 29 Aug 2014 08:58:45 -0700 Subject: [coreboot] cbfstool, Linux trampoline and SeaBIOS In-Reply-To: References: <20140828230855.GA8108@cumulusnetworks.com> Message-ID: <20140829155845.GD27619@cumulusnetworks.com> Hello Ron, On Thu Aug 28 16:30, ron minnich wrote: > Curt, this is super great news for me to hear, and if you can show me > how to do the linux boot with linux as payload I need to see it. I > screwed it up and it did not work for me :) If this patch and idea are acceptable I will make a proper git patch and send it along. For Linux SeaBIOS payload, it was pretty easy, most of the directions are on the coreboot and SeaBIOS wiki. The only problem I had was for the patch I sent. Here are the steps I used -- I'll take for granted you know how to build coreboot with SeaBIOS as the payload. I did all this work using the emulated i440 qemu machine with a 16Mbyte rom size. 1. once you have your coreboot.rom, use the cbfstool to add images to the rom. 2. For the Linux kernel and initramfs I built a small Linux OS from the Open Network Install Environment (ONIE) project. It is a very simple OS that just runs from a ramdisk. 3. To add a Linux payload to SeaBIOS run the cbfstool like this: ONIE_IMAGE_DIR="$HOME/onie/build/images" KERNEL="${ONIE_IMAGE_DIR}/kvm_x86_64-r0.vmlinuz" INITRD="${ONIE_IMAGE_DIR}/kvm_x86_64-r0.initrd" CMDLINE="console=tty0 console=ttyS0,115200n8 seabios" $CBFSTOOL $COREBOOT_BUILDDIR/coreboot.rom add-payload -f $KERNEL -n img/LINUX -I $INITRD -C "$CMDLINE" The only real trick is the image needs to be in the "img" directory in the cbfs for SeaBIOS to find it. See the "-n" argument above. If you need more info I'm happy to send you the .config for both coreboot and SeaBIOS. > one thing I wonder: if you can boot linux as the payload, what's the > reason to use seabios? I'm missing something. Great question! I am working on the Open Network Install Environment (ONIE) project: http://www.opencompute.org/wiki/Networking/ONIE http://opencomputeproject.github.io/onie/docs You can think of ONIE as a "Linux based PXE, with more features". Currently ONIE runs on open, bare metal networking hardware, including PowerPC and x86 machines. For x86 platforms, I want to have ONIE available in the SeaBIOS boot menu. Having ONIE boot straight from coreboot is interesting (and fast!), but that is not ONIE's sole purpose. The systems and users we are targeting still need a boot menu to select things like "boot from USB", "boot from hard disk", etc. At the end of the day the point of the networking hardware is to boot the network operating system, not boot ONIE. This is similar to the server world, where the point is to boot the server OS, not PXE. Cheers, Curt From rminnich at gmail.com Fri Aug 29 18:20:46 2014 From: rminnich at gmail.com (ron minnich) Date: Fri, 29 Aug 2014 09:20:46 -0700 Subject: [coreboot] cbfstool, Linux trampoline and SeaBIOS In-Reply-To: <20140829155845.GD27619@cumulusnetworks.com> References: <20140828230855.GA8108@cumulusnetworks.com> <20140829155845.GD27619@cumulusnetworks.com> Message-ID: Curt, what you are doing is similar to what linuxbios was designed for. At Los Alamos in 2001, we were booting thousand node systems with linux as the "payload" (the payload name came later -- at the time, linuxbios always used linux as the payload). Note that linuxbios was renamed to coreboot, it's the same code base. We did this on powerpc, x86, and alpha. The parallels between then and now are interesting. Our path to boot linux from "whatever" (usb, disk, network) was via bash scripts, which we bundled into the initramfs. My preferred interface for a boot menu is still the shell command line. That way, when things go wrong, you have more there than just a menu. So I'm not yet convinced, once you can put linux and initramfs in flash, that you need seabios, unless the issue is INTxx support for things like grub. But as a Plan 9 GSOC project we put Plan 9 in the boot sector, and that worked fine; I'm not convinced that at any step we need old-fashioned boot loaders at all. The kernels do just fine, in flash, in the boot sector, and over the network. But that's me ;-) We could boot small (128) node clusters in well under a minute, including the 'linux boots linux' part of the boot; individual nodes took seconds from power on to full functioning; and medium clusters (1500 nodes) would boot in under 150 seconds from power on to all nodes usable, including all the infiniband network config and 'linux boots linux' step. As a contrast, the rom-based iPXE bootstraps were unable to finish configuring ONE interface in the time it took us to boot 1000 nodes.More here: http://lacsi.rice.edu/workspace/downloads/symposium/lacsi_2004/pap124.pdf/ My latest work involves embedding go programs as source in the flash, and compiling them on demand into a ramfs. I'll be talking about this at ELC Europe. Go programs are far more compact than even busybox binaries, and it looks like I can fit the go compilers, all packages, and all the programs into about 8M in flash as part of a linux payload. I've got a ways to go but so far I have not seen any showstoppers. That code is all available on github if you're interested. Once you get a real kernel in your boot path, life can get very interesting. Have you considered using the payload chooser (bayou) to let you choose linux as the payload or seabios? Then you would not need to have seabios boot linux from flash. Life might be simpler. Bayou can be made to work again -- I did it recently, even for ARM -- and it is kind of handy. My interest is purely in getting back to the linuxbios scenario -- the only payload being linux. The ONIE thing is just what I've been looking for for the Go project; I'll be taking a close look. ron