[coreboot] Goodies for Bonn meeting
Hello, all. My girlfriend Maria (CC'ed) would like to organize some goodies for coreboot meeting. Already available are black T-shirts: 2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't double-check now as I'm travelling. Expected price is under €20 for any of items. Capacity is limited, first come first serve, respond to this e-mail to order. What else we can do: - White t-shirt - white cups - colour cups - Fridge magnets - case for iPhone (indicate which one), not sure which ones are available - Beer coaster - mouse pad - baseball cap In addition, if you're ok with waiting about a month + delivery time we can order: - Black t-shirt (other than the sizes mentioned above, or once the stock is out) - Colour t-shirt over €20 We're doing it just for fun and to serve the community, the price is only to cover our costs. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: Coreboot T-shirts
Good news: now it's possible to have them in black as well. I received up to now only one request to which I replied by personal mail. If you didn't receive any reply, please resend your request. Please specify in request the size, color (white, black, few other colors if someone is interested), quantity and if you want it single or double-sided printing. Please tell me until Friday. @Carl-Daniel: Still waiting for that PDF. On 21.05.2015 15:41, Vladimir 'phcoder' Serbinenko wrote: Apparently original mail didn't make it to the list. Resent -- Forwarded message -- From: Vladimir 'phcoder' Serbinenko phco...@gmail.com Date: Thu, May 21, 2015 at 2:29 PM Subject: Re: [coreboot] Coreboot T-shirts To: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Cc: coreboot coreboot@coreboot.org Le 21 mai 2015 13:01, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net a écrit : On 21.05.2015 12:51, Vladimir 'phcoder' Serbinenko wrote: A contact of mine proposes to print coreboot T-shirts for the community. Black printing on white T-shirt. Expected price is 30€-35€ + shipping from CH or DE, double-sided printing, one-sided is 5-8€ less. It will be printed in Russia. Please note that the coreboot T-Shirt I am wearing is black, with the logo being a white plastic foil melted/glued to the t-shirt. Could you ask your contact whether such a variant would be possible as well? The foil variant is extremely durable and IMHO a black T-Shirt fits a bit better with all the other hacker culture T-Shirts. I already did. Unfortunately it's not possible at this point I need to know who wants one and sizes by June 5th. For payment I accept paypal and bank wiring. It will be available in ~August. Do we have some kind of dev meeting in autumn where I could bring them? @carldani: could you give me the file used for printing? Sure. Regards, Carl-Daniel signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: Coreboot T-shirts
On 31.05.2015 19:27, Matthias Apitz wrote: El día Sunday, May 31, 2015 a las 06:45:48PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko escribió: Good news: now it's possible to have them in black as well. I received up to now only one request to which I replied by personal mail. If you didn't receive any reply, please resend your request. Please specify in request the size, color (white, black, few other colors if someone is interested), quantity and if you want it single or double-sided printing. Please tell me until Friday. Please post again an URL of the t-shirt layout. Thanks I don't have the URL. I'm waiting for Carl-Daniel to give me the file (in any format) wit layout he used last time. matthias signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SPD CRC failed
On 21.05.2015 16:19, Michael Gerlach wrote: Okay here we go... I memtested the modules again and as expected no defect was found. So i retried latest master today and quite unusually it just boots up. Quite possibly you were just missing microcode update. It does not reach payload-state still, but ram and frequency is detected correctly. Fan is turning on and backlight gets activated but no output is displayed. Besides it seems to die at unpredictable states. I attached 3 different boot logs.. The only assumption could be a defect in some piece of hardware, but i do not had any trouble with this x230 yet.. On the other hand _this_ build was compiled on the x230 itself, while the other builds were compiled on a x201 with an identical bootstrapped toolchain.. Any idea what possibly cause a similar behavior too? It could be something with modules. They may have very unusual high-frequency characteristics. I didn't see it occur with code that we have currently but it remains a theoretical possibility. Best regards, n3ph On 05/20/15 23:45, David Hendricks wrote: On Wed, May 20, 2015 at 1:13 PM, Michael Gerlach n...@terminal21.de mailto:n...@terminal21.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I forgot to mention that somehow the ram frequency is not detected correctly... PLL busy...done PLL didn't lock. Retrying at lower frequency PLL busy...done PLL didn't lock. Retrying at lower frequency PLL busy...done PLL didn't lock. Retrying at lower frequency PLL busy...done PLL didn't lock. Retrying at lower frequency No lock frequency found The SPD data should be read via SMBus long before PLL locking for the DRAM itself takes place. If you're unable to successfully read the SPDs, then it makes sense that later init would fail. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] rfkill equivalent on the X60 - first partial success
On 08.12.2014 01:00, Charles Devereaux wrote: Sorry, but if it is like the X60 it can not be made the work. Just like in the WWAN slot, but in reverse, the USB lines are not wired on the WLAN slot. IIRC this is not the case on the X201 (a very nice machine, but coreboot support may not be as good for the moment. However the ACPI tables look more complete.) Please provide problem descriptions when doubting the quality of my work. Otherwise you're empty-talking. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] rfkill equivalent on the X60 - first partial success
On 03.12.2014 23:32, Charles Devereaux wrote: Hello As explained before, thinkpad-acpi can't control the non-wifi radio like bluetooth or wwan, because it expects some ACPI entries that aren't there - so there is no rfkill control for these, even if some non-working entries are shown with 'rfkill list' You have a hardware button to do an rfkill. I don't see why software should mess more with this. To emulate rfkill functionality, just write directly to the ec, for ex to turn on wwan and wifi: ./ec_access -w 0x3a -v 0x60 Usecase? It works great for bluetooth, basically physically unplugging the device so that if you have uhci_hcd as a module, an rmmod/modprobe will no longer show the device on lsusb. RCBA registers can disable any USB ports. But again: usecase? signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] rfkill equivalent on the X60 - first partial success
To emulate rfkill functionality, just write directly to the ec, for ex to turn on wwan and wifi: ./ec_access -w 0x3a -v 0x60 Usecase? Example: I have a wwan card, but I mostly use it for GPS. I can save some power by turning it off without rebooting, while keeping wifi on with: I'd like to see some real figures on power saved between idle wwan and disabled wwan, I really doubt it's anything noticeable The hardware button is not safe enough : register 0x3A hasthe H/W Override bitto enable to control wireless devices even if the global WAN disable switch is ON. Disabling the USB ports through the RCBA registers (nice idea!) would prevent such an override. Also, it would save more power on the wwan that the hardware button : the wwan module is not fully desactivated since it replies to AT commands Several persons do not fully trust a wwan module. Physically removing it is the solution suggested. Disabling the usb port would be a simpler solution for those than do not want to physically open their laptop yet do not trust the hardware button due to the override bit. wwan module is powered unconditionally. So if you don't trust it - remove it. Also none of disables discussed here is irreversible if you're concerned about rogue software. It seems to have several usecase. None of them looks valid signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] board-status binary
On 22.11.2014 12:22, John Lewis wrote: On 21/11/14 21:58, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 14.11.2014 12:44, John Lewis wrote: Hey y'all, I've modified the board-status script to have as few external dependencies as possible, be a self-extracting, self-running binary. and removed the time-stamp to keep the number initial commits down. Feel free to tell me how bad it is and how it murdered your children. :P Never send binaries to the list. A link could be just as malicious. What way should I do it? A link would be fine. It wouldn't make everybody uninterested in this topic but subscribed to the list download 1M file. And about the idea: current code needs git tree. I tried to make changes to make it possible to have board-status without git tree. Result: those change were ignored, bikeshed or vetoed. Long story short: nobody cares. At some point Ron did care, otherwise we wouldn't have been talking about it, and I certainly do. I can tell you anecdotally which Chromebooks are being used and should remain live in the code-base (hint: all of them) but I thought we were trying to be more scientific about it than that. Speaking is about where it usually stops. It's been very disappointing. Usual scenario is that we get lots of discussion to do sth, everybody is dissatisfied with current status and when I spend huge chunk of my personal time to fix it, nobody is there to even review the patches. That's understandable: otherwise what will we speak about next time if the issue is solved? Still it's disappointing and I have better things to do with my personal time than making patches nobody cares about. The top of rename stack is at 7185. It's automated test and Stefan agreed to it in principle in Prague, yet it's sitting there for already 3 weeks. John. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] board-status binary
On 22.11.2014 17:28, John Lewis wrote: On 22/11/14 15:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 22.11.2014 12:22, John Lewis wrote: On 21/11/14 21:58, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 14.11.2014 12:44, John Lewis wrote: Hey y'all, I've modified the board-status script to have as few external dependencies as possible, be a self-extracting, self-running binary. and removed the time-stamp to keep the number initial commits down. Feel free to tell me how bad it is and how it murdered your children. :P Never send binaries to the list. A link could be just as malicious. What way should I do it? A link would be fine. It wouldn't make everybody uninterested in this topic but subscribed to the list download 1M file. I understand what you mean now - people perhaps stuck on low-bandwidth links with expensive data plans. And about the idea: current code needs git tree. I tried to make changes to make it possible to have board-status without git tree. Result: those change were ignored, bikeshed or vetoed. Long story short: nobody cares. At some point Ron did care, otherwise we wouldn't have been talking about it, and I certainly do. I can tell you anecdotally which Chromebooks are being used and should remain live in the code-base (hint: all of them) but I thought we were trying to be more scientific about it than that. Speaking is about where it usually stops. It's been very disappointing. Usual scenario is that we get lots of discussion to do sth, everybody is dissatisfied with current status and when I spend huge chunk of my personal time to fix it, nobody is there to even review the patches. That's understandable: otherwise what will we speak about next time if the issue is solved? Still it's disappointing and I have better things to do with my personal time than making patches nobody cares about. The top of rename stack is at 7185. It's automated test and Stefan agreed to it in principle in Prague, yet it's sitting there for already 3 weeks. Okay, well the binary as is will upload stuff to the current board-status repo, so maybe that's enough. I'm trying to encourage people to use it. We'll see if we can get maybe a few hundred people to upload something, given time. Determining of mainboard is wrong for clones. I was trying to fix this a while ago but I stopped carying. John. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Infrastructure work
Hello, all. I know I've signed up to fix board-status and cmos but I don't want to go through painful reviews, so I'm not going to do this, even though maintaining current CMOS stuff is a pain in itself. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] board-status binary
On 14.11.2014 12:44, John Lewis wrote: Hey y'all, I've modified the board-status script to have as few external dependencies as possible, be a self-extracting, self-running binary. and removed the time-stamp to keep the number initial commits down. Feel free to tell me how bad it is and how it murdered your children. :P Never send binaries to the list. And about the idea: current code needs git tree. I tried to make changes to make it possible to have board-status without git tree. Result: those change were ignored, bikeshed or vetoed. Long story short: nobody cares. John. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 08:03, Vipin Gahlaut wrote:
Hi,
I have cloned latest coreboot and trying to build with grub2 as payload.
in make menuconfig I select grub2 instead of seabios. when I fire make
command it checkout latest grub and that fails to build. for 2 reasons.
1. Due to some initialization errors that I managed to fix with below
changes
- struct grub_linux_initrd_context initrd_ctx = { 0, };
+ struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
Sounds like you have an old gcc
2. grub size issue as below that I am unable to resolve and looking for
your help. I am building for QEMU and using QEMU version 2.1.2.
E: Could not add
[payloads/external/GRUB2/grub2/build/default_payload.elf, 268862 bytes
(262 KB)@0x0]; too big?
E: Failed to add
'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM image.
Increase ROM size.
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Prague meeting: hardware
Hello, all. I've updated http://www.coreboot.org/PragueMeetingHardware#phcoder . If somebody wants me to bring sth, please add a paragraph there, otherwise, I won't take almost anything. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 11:57, John Lewis wrote:
Hi,
It's in Chipset Options - Size of CBFS filesystem in ROM - 0x20
or 0x40 will work.
This is only for recent intel chipsets.
Cheers,
John.
On 12/10/14 10:51, Vipin Gahlaut wrote:
Thanks Vladimir,
Can you please let me know how to increase the ROM size?
-Original Message-
From: Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phco...@gmail.com
mailto:phco...@gmail.com]
Sent: Sunday, October 12, 2014 3:02 PM
To: Vipin Gahlaut; coreboot
Subject: Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 08:03, Vipin Gahlaut wrote:
Hi,
I have cloned latest coreboot and trying to build with grub2 as
payload.
in make menuconfig I select grub2 instead of seabios. when I fire make
command it checkout latest grub and that fails to build. for 2
reasons.
1. Due to some initialization errors that I managed to fix with below
changes
-struct grub_linux_initrd_context initrd_ctx = { 0, };
+struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
Sounds like you have an old gcc
2. grub size issue as below that I am unable to resolve and looking
for your help. I am building for QEMU and using QEMU version 2.1.2.
E: Could not add
[payloads/external/GRUB2/grub2/build/default_payload.elf, 268862 bytes
(262 KB)@0x0]; too big?
E: Failed to add
'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM
image.
Increase ROM size.
On Sun, Oct 12, 2014 at 11:33 AM, Vipin Gahlaut gail...@gmail.com
mailto:gail...@gmail.com wrote:
Hi,
I have cloned latest coreboot and trying to build with grub2 as
payload. in make menuconfig I select grub2 instead of seabios. when
I fire make command it checkout latest grub and that fails to build.
for 2 reasons.
1. Due to some initialization errors that I managed to fix with
below changes
- struct grub_linux_initrd_context initrd_ctx = { 0, };
+ struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
2. grub size issue as below that I am unable to resolve and looking
for your help. I am building for QEMU and using QEMU version 2.1.2.
E: Could not add
[payloads/external/GRUB2/grub2/build/default_payload.elf, 268862
bytes (262 KB)@0x0]; too big?
E: Failed to add
'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM
image.
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 12:44, Vipin Gahlaut wrote: I tried changing under main mainboard - rom chip size but does not seem to be helping. If I look at .config I suspect that the reason is CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I change ROM size in main board. CONFIG_BOARD_ROMSIZE_KB_* is the default used by CONFIG_COREBOOT_ROMSIZE_KB_* signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 13:03, Vipin Gahlaut wrote: Ok, I changed CONFIG_BOARD_ROMSIZE_KB_ to 512 directly in .config as this is can not be changed in menuconfig. Don't. You don't need to change it at all. My .config lokks like below and it still it says 262KB is too big? Always do make clean after config change # CONFIG_BOARD_ROMSIZE_KB_256 is not set CONFIG_BOARD_ROMSIZE_KB_512=y # CONFIG_COREBOOT_ROMSIZE_KB_64 is not set # CONFIG_COREBOOT_ROMSIZE_KB_128 is not set # CONFIG_COREBOOT_ROMSIZE_KB_256 is not set CONFIG_COREBOOT_ROMSIZE_KB_512=y # CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set # CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set # CONFIG_COREBOOT_ROMSIZE_KB_4096 is not set # CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set # CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set # CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set CONFIG_COREBOOT_ROMSIZE_KB=512 CONFIG_ROM_SIZE=0x8 On Sun, Oct 12, 2014 at 4:21 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: On 12.10.2014 12:44, Vipin Gahlaut wrote: I tried changing under main mainboard - rom chip size but does not seem to be helping. If I look at .config I suspect that the reason is CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I change ROM size in main board. CONFIG_BOARD_ROMSIZE_KB_* is the default used by CONFIG_COREBOOT_ROMSIZE_KB_* signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] unable to build coreboot with grub
On 12.10.2014 13:30, Vipin Gahlaut wrote: Thanks a lot Valdimir, After make clean ROM Size config changes kicked in as expected and I managed to build grub payload. Please keep the list CC'ed Thanks you very much for your help and support. On Sun, Oct 12, 2014 at 4:39 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: On 12.10.2014 13:03, Vipin Gahlaut wrote: Ok, I changed CONFIG_BOARD_ROMSIZE_KB_ to 512 directly in .config as this is can not be changed in menuconfig. Don't. You don't need to change it at all. My .config lokks like below and it still it says 262KB is too big? Always do make clean after config change # CONFIG_BOARD_ROMSIZE_KB_256 is not set CONFIG_BOARD_ROMSIZE_KB_512=y # CONFIG_COREBOOT_ROMSIZE_KB_64 is not set # CONFIG_COREBOOT_ROMSIZE_KB_128 is not set # CONFIG_COREBOOT_ROMSIZE_KB_256 is not set CONFIG_COREBOOT_ROMSIZE_KB_512=y # CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set # CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set # CONFIG_COREBOOT_ROMSIZE_KB_4096 is not set # CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set # CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set # CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set CONFIG_COREBOOT_ROMSIZE_KB=512 CONFIG_ROM_SIZE=0x8 On Sun, Oct 12, 2014 at 4:21 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com wrote: On 12.10.2014 12:44, Vipin Gahlaut wrote: I tried changing under main mainboard - rom chip size but does not seem to be helping. If I look at .config I suspect that the reason is CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I change ROM size in main board. CONFIG_BOARD_ROMSIZE_KB_* is the default used by CONFIG_COREBOOT_ROMSIZE_KB_* signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 3906937 amdfam14: Switch to per-device ACPI
Success. Addresses are slightly different and new XSDT table but both are ok and expected. On 11.10.2014 00:16, Paul Menzel wrote: Dear Vladimir, Am Mittwoch, den 08.10.2014, 21:29 +0200 schrieb Vladimir Serbinenko: Vladimir Serbinenko (phco...@gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/7031 -gerrit commit 390693798eebf2a371b32915a5ee239ba0b3a8bd Author: Vladimir Serbinenko phco...@gmail.com Date: Wed Oct 8 21:18:31 2014 +0200 amdfam14: Switch to per-device ACPI Change-Id: Icc663c28713f2d872bfeb1749303ce92db953bf5 Signed-off-by: Vladimir Serbinenko phco...@gmail.com --- src/mainboard/amd/inagua/acpi_tables.c | 206 src/mainboard/amd/persimmon/acpi_tables.c | 205 src/mainboard/amd/south_station/acpi_tables.c | 206 src/mainboard/amd/union_station/acpi_tables.c | 206 src/mainboard/asrock/e350m1/acpi_tables.c | 206 src/mainboard/gizmosphere/gizmo/acpi_tables.c | 206 src/mainboard/jetway/nf81-t56n-lf/acpi_tables.c| 207 - src/mainboard/lippert/frontrunner-af/acpi_tables.c | 206 src/mainboard/lippert/toucan-af/acpi_tables.c | 206 src/northbridge/amd/agesa/family14/Kconfig | 1 + src/northbridge/amd/agesa/family14/northbridge.c | 131 + 11 files changed, 132 insertions(+), 1854 deletions(-) […] please find the acpidump outputs from running on the ASRock E350M1 attached. Thanks, Paul signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] broken boards
On 11.10.2014 03:03, ron minnich wrote: Android defaults sometimes surprise me. When we've had this kind of issue in the past a disassembly diff of good vs bad has sometimes led to diagnosis. I think you have a rough idea what's broken so start there. Painful but necessary. .car.data is linked at wrong address. Working: 4 .car.data 00b4 ff7f ff7f 00012b00 2**5 CONTENTS Broken: 4 .car.data 00ac 00012b00 2**5 CONTENTS Ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] broken boards
On 11.10.2014 03:20, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 11.10.2014 03:03, ron minnich wrote: Android defaults sometimes surprise me. When we've had this kind of issue in the past a disassembly diff of good vs bad has sometimes led to diagnosis. I think you have a rough idea what's broken so start there. Painful but necessary. .car.data is linked at wrong address. Working: 4 .car.data 00b4 ff7f ff7f 00012b00 2**5 CONTENTS Broken: 4 .car.data 00ac 00012b00 2**5 CONTENTS http://review.coreboot.org/7042 Ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] X201i RAM upgrade not working
On 21.09.2014 04:12, ron minnich wrote: Here's the problem. There is caching of the DRAM configuration going on. So, a restart is not stateless. I would be happier if you could guarantee that the mrc cache is disabled, or never used, each time you change the dram setup (move DIMMs, whatever). Because from your earlier description it sounds to me like that is skewing your tests. If this makes no sense let me know. Cache is discarded if SPD is changed. But the easy way to be sure is to delete mrc.cache in cbfs. @Mono: Do you come to Prague? ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Unsupported hardware - information listed
On 09.09.2014 20:52, Luigi Bai wrote: Per the wiki, I am offering this information to try to determine the status of coreboot support, especially for Intel/PM965 or Intel/82801H. I didn't see either under the lists of supported hardware Unsupported, chipset unsupported. There is a very experimental CL http://review.coreboot.org/#/c/5807/ to make i965 work but I can bet it doesn't work as-is and probably very far from working. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] x86: add coreboot framebuffer support
I'm not a fan of Coreboot having invented its own nonstandard hacks, but I guess it is pretty much unavoidable. It's completely avoidable. The stub can copy this information to standard framebuffer info structure. The only missing thing is to apply patch by cjwatson or mjg59 (I'm not sure now who wrote it) for having an ID for linear framebuffer which implies no specific hardware (it can be any) or firmware (coreboot doesn't provide nay additional info or callback). Please don't apply this patch it will break SeaBIOS booting with VGABIOS. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] x86: add coreboot framebuffer support
On 06.09.2014 00:18, ron minnich wrote: Vladimir can you point me to that patch? This sounds interesting. https://lkml.org/lkml/2010/8/25/190 ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] X201i RAM upgrade not working
On 06.09.2014 00:19, ron minnich wrote: I don't think it's random at all. Vladimir can confirm, but if he is caching the RAM parameters, then this 'solution' will work for you until the next time you reflash coreboot, or change your dram type, at which point it will stop working. Nehalem code discards cache if there is any mismatch between cache and modules. There are 2 techniques in use: 1) If SPD mismatches, cache is discarded, so plugging new module will discard cache. 2) Series of witnesses ensure that cache is only used if full algorithm would yield the same result. E.g. if the result is a middle of timing segment, then it saves the ends of segments and checks on next boot that ends are the same. So even reseating the modules is likely to cause cache to be discarded. I think that his problem is either: 1) Badly seated modules 2) Only one permutation fails. 3) Code bug triggered by specific insertion of the said module Since I've spent countless hours will all kinds of modules inserted and reinserted on nehalem and the only bug I'm aware of is triggered by having over 8G (maximum for nehalem) worth of RAM which causes die() instead of proper ignore of extra RAM, without proof to contrary I'd guess 1 is the case. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] x86: add coreboot framebuffer support
On 06.09.2014 00:31, H. Peter Anvin wrote: On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 06.09.2014 00:18, ron minnich wrote: Vladimir can you point me to that patch? This sounds interesting. https://lkml.org/lkml/2010/8/25/190 I believe *most* of this patch has already gotten merged as we now use simplefb on x86 as well. So all we need is probably the ID. Yes, efifb has the same semantics. We just need some ID with clear documentation saying sth like implies framebuffer without anything else so that noone will get an idea to plug e.g. vga hooks into it. -hpa signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] x86: add coreboot framebuffer support
This code assumes that payload didn't change video mode which is
improper assumption if you're not a payload.
On 04.09.2014 12:25, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
arch/x86/Kconfig | 12 +++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/coreboot.c | 232
+
3 files changed, 245 insertions(+)
create mode 100644 arch/x86/kernel/coreboot.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 778178f..3aeb038 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2372,6 +2372,18 @@ config X86_SYSFB
If unsure, say Y.
+config COREBOOT
+ bool coreboot
+ depends on X86_SYSFB
+ depends on FB_SIMPLE
+ help
+ Add coreboot framebuffer support to the linux kernel. Say Y here
+ if you want the linux kernel find and use the firmware framebuffer
+ initialized by coreboot. Useful when using the linux kernel as
+ coreboot payload.
+
+ If unsure, or if you don't know what coreboot is, say N.
+
endmenu
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index ada2e2d..4b30b0e 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_UPROBES) += uprobes.o
obj-y+= sysfb.o
obj-$(CONFIG_X86_SYSFB) += sysfb_simplefb.o
obj-$(CONFIG_EFI)+= sysfb_efi.o
+obj-$(CONFIG_COREBOOT) += coreboot.o
obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o
obj-$(CONFIG_TRACING)+= tracepoint.o
diff --git a/arch/x86/kernel/coreboot.c b/arch/x86/kernel/coreboot.c
new file mode 100644
index 000..44ed3fa
--- /dev/null
+++ b/arch/x86/kernel/coreboot.c
@@ -0,0 +1,232 @@
+/*
+ * Find and parse coreboot tables. Register framebuffer if present.
+ * See src/include/boot/coreboot_tables.h in coreboot source tree.
+ */
+
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/mm.h
+#include linux/screen_info.h
+#include linux/platform_device.h
+#include linux/platform_data/simplefb.h
+#include video/vga.h
+
+#include asm/checksum.h
+#include asm/io.h
+#include asm/sysfb.h
+
+struct cb_header {
+ u32 signature;
+ u32 header_bytes;
+ u32 header_checksum;
+ u32 table_bytes;
+ u32 table_checksum;
+ u32 table_entries;
+};
+
+#define CB_TAG_MAINBOARD0x0003
+#define CB_TAG_VERSION 0x0004
+#define CB_TAG_FORWARD 0x0011
+#define CB_TAG_FRAMEBUFFER 0x0012
+
+struct cb_mainboard {
+ u8 vendor_idx;
+ u8 part_idx;
+ charstrings[0];
+};
+
+struct cb_framebuffer {
+ u64 physical_address;
+ u32 x_resolution;
+ u32 y_resolution;
+ u32 bytes_per_line;
+ u8 bits_per_pixel;
+ u8 red_mask_pos;
+ u8 red_mask_size;
+ u8 green_mask_pos;
+ u8 green_mask_size;
+ u8 blue_mask_pos;
+ u8 blue_mask_size;
+ u8 reserved_mask_pos;
+ u8 reserved_mask_size;
+};
+
+struct cb_entry {
+ u32 tag;
+ u32 size;
+ union {
+ charstring[0];
+ u64 forward;
+ struct cb_mainboard mb;
+ struct cb_framebuffer fb;
+ } u;
+};
+
+#define CB_SIGNATURE 0x4f49424C /* LBIO */
+
+/* Try to locate the coreboot header in a given address range. */
+static __init struct cb_header *coreboot_find_header(u32 addr, int len)
+{
+ struct cb_header *cbh, *copy;
+ int offset;
+ void *map;
+
+ map = ioremap(addr, len);
+ for (offset = 0; offset len; offset += 16) {
+ cbh = map + offset;
+ if (!cbh)
+ continue;
+ if (cbh-signature != CB_SIGNATURE)
+ continue;
+ if (!cbh-table_bytes)
+ continue;
+ if (ip_compute_csum(cbh, sizeof(*cbh)) != 0)
+ continue;
+ if (ip_compute_csum(cbh + 1, cbh-table_bytes)
+ != cbh-table_checksum)
+ continue;
+ pr_debug(coreboot: header found at 0x%x\n,
+ addr + offset);
+ copy = kzalloc(sizeof(*cbh) + cbh-table_bytes, GFP_KERNEL);
+ memcpy(copy, cbh, sizeof(*cbh) + cbh-table_bytes);
+ iounmap(map);
+ return copy;
+ }
+ iounmap(map);
+ return NULL;
+}
+
+static __init bool check_vga_text_mode(void)
+{
+ uint8_t reg;
+
+ if (screen_info.orig_video_isVGA != 1)
+ return false;
+
+ reg = inb(VGA_GFX_I);
+ if (reg == 0xff)
+ /* no vga present */
+ return false;
+
+ outb(VGA_GFX_MISC, VGA_GFX_I);
+ reg =
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
On 01.09.2014 22:08, Charles Devereaux wrote: Hello Keep list CC'ed. https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips Sorry for the late reply. Yesterday I tried acpi_debug with various values, but even with 0x I could not get logs similar to yours : [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 Could you please tell me the cmdline you use, or the options you set in /sys to activate that kind of output? In any case, I will soon try your patch even if I could not check the output (I have a test motherboard where I added an ISP wiring) Thanks Charles On Tue, Aug 26, 2014 at 12:28 AM, Charles Devereaux coreb...@guylhem.net mailto:coreb...@guylhem.net wrote: (offlist reply) Hello Very interesting, indeed, but I need to use my X60t tomorrow (and I already bricked it once while trying some simple coreboot patch so I'd rather not take any risk :-) However I will try to test that as soon as possible and let you know, tomorrow night or wednesday. I will also report you the ACPI EC results. Did you only had to activate CONFIG_ACPI_DEBUG to get these logs? Thanks Charles On Mon, Aug 25, 2014 at 5:02 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: On 25.08.2014 22 tel:25.08.2014%2022: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. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http
Re: [coreboot] x60 : adding WWAN support
On 01.09.2014 22:19, Charles Devereaux wrote: Hello I'm interested in WWAN support, mostly for the GPS features and the cool things you can do with them (like a stratum ntp server). Most GPS receivers don't have enough precision for any timing. I was told a EM770W doesn't even need a network registration to output NMEA coordinates (http://forum.thinkpads.com/viewtopic.php?f=30t=114426#p735612) so I got one. I looked at patch #4056 which enable WWAN for the EC, but it seems to only part of the job: the ACPI table should also contain a GWAN key for thinkpad-acpi Not necessary. Apparently, this last part cause the WWAN card not to be handled by thinkpad-acpi, which would otherwise provide rfkill support (usefull to save power, something I'd like to improve) Soft rfkill is always available through wwan driver. I believe similar entries should be added to coreboot asl, but I'm not sure of how integrated they should be. If I understand correctly, following the logic of patch #5242, there should be a conditional statement then some acpigen. 5242 is very special because of wacom tablet interaction (serial device naming) See src/ec/lenovo/h8/acpi/ec.asl and included files for the relevant scopes signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2
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
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2
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. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
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. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disabling bios usb stack
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] why is firmware 32 bit as opposed to 64 bit
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. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] iy my pc supported for coreboot?
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 signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ISP header for x60, fallback: indicating normal boot from grub2
On 19.07.2014 07:42, Charles Devereaux wrote:
Hello,
On Wed, Jul 9, 2014 at 2:15 AM, Denis 'GNUtoo' Carikli
gnu...@no-log.org mailto:gnu...@no-log.org wrote:
My pomona clip had issues with its contact pins(the ones in contact
with the flash chip) over time, so I unmounted it and repaired it.
I tried pushing the pins down - it looks better but it didn't help. Mine
only work with a lot of duct tape to keep it firmly pressed to the
motherboard. Otherwise, it slides up just a bit, enough to avoid making
contact. It seems more like a problem with the plastic
Example in grub.cfg:
menuentry 'Normal' {
cmosclean 0x30:0
cmosclean 0x30:1
cmosclean 0x30:2
cmosclean 0x30:3
cmosclean 0x30:4
cmosclean 0x30:5
halt
}
Interesting. Is there a reason why different values are used on gluglug
halt? cf http://samnoble.org/thinkpad/grub/gluglug.grub.custom.cfg:
The values are exactly the same. Search for hex.
There is only cbmemc, cbls and cbtime. They could be good menu options
but the output is displayed without a pager (so you can't see them as it
goes back to the menu - you have to enter a command line)
pager=1
Of all of these, cbtime would be especially interesting to add a title
to grub menu, to show if the boot was in normal or fallback and how long
it took.
I'll see if it's possible to add the result of a command to grub menu
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
On 20.06.2014 20:08, Patrick Georgi wrote: Am 20.06.2014 22:01, schrieb Rafael Vanoni: Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale. We have an .id section just below the 16bit entry point - that can (easily) be extended to host more fields, and our smbios table generator could fetch a number from there, overriding a compile time default. To start, see src/arch/x86/lib/id.inc. It's really two tables: one containing the offsets, one containing the data (strings are 0-terminated). Both tables need to be prepended with new fields, since we're in a top-aligned world here. I think it's more sound to have a CBFS plain-text file with serial numbers and other runtime configs. There is a fair number of board and chipset-specific config that should be modifiable without recompilation but are probably inappropriate for CMOS for various reasons as CMOS size shortage or the need for persistance even across RTC power well failure [aka bad clock battery] (think MAC address). having fixed indexes doesn't scale. Patches accepted :-) Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
On 20.06.2014 20:43, Patrick Georgi wrote: Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: (think MAC address). I guess PC technology is finally beyond requiring those at fixed magic offsets. Some of our chipsets still need it that way. having fixed indexes doesn't scale. Neither do text files. I disagree. If you have a file named e.g. config.txt with a syntax like: southbridge/ibexpeak/thermal_correction: 0x1222 one value per line, it perfectly scales. Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x60s tablet question : optimized kernel, coreboot with the video fix and serial ports support
On 11.06.2014 09:46, derpeter wrote: I tried this last month. I cherrypickt everything execpt the video fix and got a working coreboot. Sadly i could not bring the wacom to work but i'm not sure if its a problem of coreboot or linux. Submit logs then: Xorg log, dmesg and coreboot log. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
On 05.04.2014 19:02, mrnuke wrote: When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be. What do you mean by expected? Same as vendor BIOS? My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 29.03.2014 07:45, Stefan Reinauer wrote: * Andrew Wu andrewwu...@gmail.com [140327 14:00]: Sorry, I checked Vortex86EX CPU datasheet, but it seems there is no workaround can do it. So if I want to get rid of romcc, maybe I have to write DRAM init code in assembly, That is not very easy. :( Don't worry we'll figure something out that's better than writing ram init in assembly. Do I get it correctly that your main problem is the heavy use of #include romcc requires? If so why don't we just create a file with #include's from all files from romstage-y? This will remove the #include needs. Stefan signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 29.03.2014 08:41, Patrick Georgi wrote: Am Samstag, den 29.03.2014, 08:30 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: Do I get it correctly that your main problem is the heavy use of #include romcc requires? If so why don't we just create a file with #include's from all files from romstage-y? This will remove the #include needs. There are also a bunch of places where we stick to some less than perfect C code to accommodate romcc. The #include *.c stuff is mostly the visible effect, not the cause. Getting romcc raminits to compile self-contained (or with their own specific *.c files to include) fixes both. Do you mean having a separate stage raminit between bootblock and romstage? If so it raises a question of what's romostage scope is. Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Miniboot
On 26.03.2014 00:33, The Gluglug wrote: -- alternatively: ship coreboot without anything in src/mainboard. have git repositories for each vendor/mainboard. user downloads what they need, and a default .config for the board of their choosing. Git is developpement tree, not user-fetch tree. It's optimized for devs. If you feel like sth optimized for users is needed, feel free to create an interface you want that would piggyback on top of official git. On 25/03/14 23:29, The Gluglug wrote: This is focussed on users (non-developers). Most coreboot users only have perhaps a few machines that they are building for. Maybe even just one. Yet they are downloading the entire coreboot source tree and selecting which board they want, configuring it, etc. My idea: -- a small set of source files (such as from src/mainboard/vendor/board) -- a script (perhaps a simple git checkout) which fetches the needed parts of the source from the main branch, for building that board -- default/sane configurations pre-defined for that board. Advantages: -- less headache for developers (user already has most of what they need, less likely to request support) -- less to download (less waiting required, especially for people with slow connections) Essentially, I have in mind a more modular coreboot. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 02:33, Stefan Reinauer wrote: * David Hubbard david.c.hubbard+coreb...@gmail.com [140323 20:33]: On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. Tried to do so in the other mail... There's too much risk involved in working directly on upstream. The downsides just outweigh the benefits (for everybody, really) For example, when getting to the hot phase of a new product, we don't even use our chromium top of tree, but create a firmware branch specifically for a new product. Patches relevant to that product go into that branch (and top of tree, aka HEAD) but NOTHING else. For every firmware image that is released, there are also tests involving thousands and thousands of reboots and suspend/resume cycles to make sure that the product is absolutely stable. Because if 1/100k resumes crashes that means for a million users there are ten users every day whose computers crash. This level of testing is simply not possible when aiming at a moving target. I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. Stefan signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 06:34, ron minnich wrote: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? That's why I added *supposed to*. I'm aware that some boards are probably broken and not much we can do about it. ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 19:24, ron minnich wrote: I have friends who commit to grub2, and there seem to be gatekeepers there; how do you manage that process? In case of grub2 I admit we have exactly the problems I described. I'm open to having more maintainers but right now it doesn't seem to be feasible. I proposed co-maintaining to some skilled people but they didn't accept as of now. Here you have a chance of more people willing to help maintain coreboot. Use this resoiurce. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 20.03.2014 22:33, Stefan Reinauer wrote: During this time we collected over 250 different mainboards. A great achievement, I suppose that most of boards were contributed by non-commercial community. Yet now you propose to basically kill this chicken nesting golden eggs and make coreboot commercial-only. Sorry but your proposition with handling non-commercial community doesn't make any sense at all. You propose to represent the community by small number of people who most likely won't be available enough and who don't represent the community as whole. No single person or small team can represent an entire community, no matter how these persons are knowledgeable and competent. Commercial entity could be represented by one person but a community of independent volunteers can't. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On 20.03.2014 11:25, Allen Yan wrote: Hi, David, When at AsusTek Suzhou, my work is mainly responsible for bios porting and fixing bug. There were four mainboards P5KPL-S, P5QL-E, P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core In the second half year of 2008, I worked on pre-development of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module and added NTFS support(read only) for AutoRecovery module using AMI Apito platform (based on EFI). Do I understand it correctly, that you've had access to proprietary BIOS code? If so which papers did you sign and under what license did you get them? Depending on the answers it may partially or fully disqualify you from contributing to coreboot. Interesting experience, but memories will fade! Details can't be remembered clearly. As Vladimir said, if the chipset is unsupported then writing MRC for it will be a very long and difficult process. If the chipset is supported then adding mainboard support may be a relatively simple task that not sufficient for GSoC. Do we need to write MRC by ourselves in coreboot? Isn't MRC code supported by Intel? If you have experience with UEFI, perhaps you can implement features that are missing in our Tianocore support: http://www.coreboot.org/TianoCore . Implementing UEFI CBFS driver and GOP driver are very clear goal. questions: I don't know whether coreboot or some payload implement common flash interface for flash programming software. If not, why? https://trello.com/b/pEdlwYTb/tiano-payload It seems that Tiano payload is a very activity project. I think I can try my best to implement one feature or twp for the project! Like use a seperate Fv in CBFS as Fault Tolerant Variable Storage Look forward to your kind advice! On 3/20/14, David Hendricks dhend...@google.com wrote: Hi Jinyi, Can you provide more details about your work as a BIOS engineer? As Vladimir said, if the chipset is unsupported then writing MRC for it will be a very long and difficult process. If the chipset is supported then adding mainboard support may be a relatively simple task that not sufficient for GSoC. If you have experience with UEFI, perhaps you can implement features that are missing in our Tianocore support: http://www.coreboot.org/TianoCore . On Wed, Mar 19, 2014 at 6:06 AM, Allen Yan lex...@gmail.com wrote: Hi, I am Jinyi Yan , a second year PhD candidate from Shanghai Institute of Micro-system and Information Technology, Chinese Academy of Sciences. I used to be a mainboard BIOS engineer in ASUS Technology Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is optoelectronics. But I have a lot of fun while programming, in my heart the working experience of being a BIOS engineer is still very exciting. I think GsoC is a nice platform for me to participate the open source community. When I search the GsoC projects and organizations, the coreboot and flashrom projects are definitely the right choices for me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in the support list of coreboot project. As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard or implementing advanced coreboot features on exsiting mainboards are nice too. Now I'm not very familiar with the program structure of coreboot, so I expect your guidence and hope to contribute for coreboot and flashrom even if my application is not accpeted. Thanks! Look forward to your kind advice! Regards, Jinyi Yan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hey
On 20.03.2014 12:12, Shant Kehyeian wrote: Hello, I have Samsung ARM chromebook series 3 Snow and I am trying to flesh it and change the boot process. So I build a coreboot.rom for that, but before I start to do that I would like to ask about the payload. When I did the make menuconfig it wasn't by default the SeaBios., there wasn't at all ...there was GRUB 2 and I selected it...so My question is would it work as SeaBios to boot from usb ? There is no arm-coreboot GRUB2 port currently. Thank you. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hey
On 20.03.2014 13:10, Shant Kehyeian wrote: In fact I do need the SeaBios not the GRUB2 to be able to boot from usb with live CD which I can format and install my preferred OS... I think you're missing the ARM part. Only ARM distros have any chance to work. Given fragmentation of ARM it may even mean that only Linux-based works on your machine. On Thu, Mar 20, 2014 at 4:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: On 20.03.2014 12:12, Shant Kehyeian wrote: Hello, I have Samsung ARM chromebook series 3 Snow and I am trying to flesh it and change the boot process. So I build a coreboot.rom for that, but before I start to do that I would like to ask about the payload. When I did the make menuconfig it wasn't by default the SeaBios., there wasn't at all ...there was GRUB 2 and I selected it...so My question is would it work as SeaBios to boot from usb ? There is no arm-coreboot GRUB2 port currently. Thank you. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hey
On 20.03.2014 13:34, Shant Kehyeian wrote: No I just gave in menuconfig the snow board ...and then as a payload I chose the GRUB2...that's what I meant ...:) Keep list CC'ed. I'm surprised it compiled at all. It should have error'ed out. On Thu, Mar 20, 2014 at 12:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: On 20.03.2014 13:27, Shant Kehyeian wrote: Yess you are saying it right... So I installed the coreboot source code and I compiled it with GRUB2 so ...Do you think that I will get the grub options while the boot process ? Thank you... I don't know how you managed to compile GRUB2 for ARM coreboot but it's unlikely to work. I'm under impression that you compile for wrong mainboard altogether (you've chosen mobo in make menuconfig, right?) On Thu, Mar 20, 2014 at 12:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com wrote: On 20.03.2014 13:10, Shant Kehyeian wrote: In fact I do need the SeaBios not the GRUB2 to be able to boot from usb with live CD which I can format and install my preferred OS... I think you're missing the ARM part. Only ARM distros have any chance to work. Given fragmentation of ARM it may even mean that only Linux-based works on your machine. On Thu, Mar 20, 2014 at 4:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com mailto:phco...@gmail.com wrote: On 20.03.2014 12:12, Shant Kehyeian wrote: Hello, I have Samsung ARM chromebook series 3 Snow and I am trying to flesh it and change the boot process. So I build a coreboot.rom for that, but before I start to do that I would like to ask about the payload. When I did the make menuconfig it wasn't by default the SeaBios., there wasn't at all ...there was GRUB 2 and I selected it...so My question is would it work as SeaBios to boot from usb ? There is no arm-coreboot GRUB2 port currently. Thank you. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On 20.03.2014 13:45, Peter Stuge wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 20.03.2014 11:25, Allen Yan wrote: Hi, David, When at AsusTek Suzhou, my work is mainly responsible for bios porting and fixing bug. Do I understand it correctly, that you've had access to proprietary BIOS code? If so which papers did you sign and under what license did you get them? Vladimir, I would assume that Jinyi signed a standard employment agreement. Employment agreements contain a non-disclure clause which covers all non-public information which the employer has received from suppliers and customers. Depending on the answers it may partially or fully disqualify you from contributing to coreboot. I disagree, and I think your tone is rude. I didn't mean to be rude. I apologise if it sounded like this. I'm somewhat pessimistic generally and a mathematician and so I look for problems first. Please be supportive of GSoC candidates who are showing an interest in coreboot, especially candidates such as Jinyi who can obviously contribute with significant relevant experience from the firmware domain. I didn't mean to be dismissive, when I discuss problems it's to prevent and fix them. Employment agreements have clauses about not working on competing products. coreboot in summer of 2014 does not compete with BIOS for commercial mainboards in 2008. I am obviously not a lawyer but I can not see a problem here. They sometimes also have draconian non-disclosure parts. We can't know until such issues are checked by someone qualified. I'm not. Does coreboot has some kind of experts it can use for those cases? On GNU projects I'd refer to copyright clerk who would in turn refer further if needed. //Peter signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 20.03.2014 22:33, Stefan Reinauer wrote: coreboot for the 21st century setting up the project for the next decade Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855) coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden. * It is hard to keep 250+ mainboards working. Actually impossible. * Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases * We don’t test except on the very last stuff we’re working on The boards and chipsets are sufficiently well insulated from each other so that it's possible to improve one without breaking the others. With board-status the potential users and devs have a good overview which revisions work on which devices. The breakage will periodically occur no matter if it's 25 board or 250 boards. And it will be fixed by those who care about the particular board. Also I feel like the amount of boards supported is actually a relatively minor maintenance burden compared to number of *options* supported. I think we should first go on killing the options noone really uses like possibility disabling ACPI tables (I have a changeset for this, mixed reception), disabling SMBIOS tables. relocatable modules should be chosen by chipset, not be user-visible, and so on. There are more broken option configurations than broken boards. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 21.03.2014 01:39, Carl-Daniel Hailfinger wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. You cannot treat community as some kind of corporate entity. Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Sounds like a joke. While Peter is competent, he's also very busy. I'd expect his review thoughtput of perhaps a patch a week. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On 19.03.2014 21:06, Allen Yan wrote: As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard Just a quick note: for porting to new chipset to be accepted, you need to: 1) Justify why this chipset is relevant. E.g. old chipsets most probably aren't. 2) Prove that you're able to do it. New raminit isn't an easy task. Also from quick google it seems that this board uses i945 chipset which is already supported. Port with already supported chipset is a task for 3-5 days for experienced dev, most likeyl too small for GSoC. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Building a Thinkpad X230 coreboot image
On 17.03.2014 17:08, Bernie Innocenti wrote: Hello Vlad! First of all, thank you very much for porting Coreboot to the X230. I'm following your instructions [1] to build a coreboot image from head, but I'm not sure how to configure things in menuconfig. Would you mind sharing your .config file and a prebuilt, known-good rom file? Look at board-status repository. I will not share any known-good one as you need external flasher anyway. Sharing a binary would just encourage people to attempt stupid things like writing it with partially locked flash. Also, while I'm waiting for the SOIC test clip to ship: do you know if anyone is working on getting flashrom to work with the X230? flashrom with layout patches works once flash is unlocked. But the only way to unlock flash is to flash coreboot or slightly modified vendor firmware. Either requires external flash. [1] http://www.coreboot.org/Board:lenovo/x230 signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Building a Thinkpad X230 coreboot image
On 17.03.2014 20:39, Grim Schjetne wrote: Bernie Innocenti ber...@codewiz.org writes: First of all, thank you very much for porting Coreboot to the X230. Indeed, this has made me all the more interested in the Coreboot project. With an X201 and an X230 port, perhaps there is some hope for an X220 port as well? It's different chipsets. So, no X201, X220 and X230 are very different machines from coreboot point of view. I'm reading the wiki pages right now for ways I can help. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFT] Please test patch set intel/i945: Only write CID, PN and TCID once
On 17.03.2014 08:00, Mono wrote: Who knows, it might(!) fix some 5 year old bug? Then it should be no problem for you to point one to us. coreboot is not openhardware. It never was and never will be. Openhardware is the only way to know what your hardware actually. Coreboot is only how to kick the hardware into working. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] qemu
@ron: please provide more information about your qemu: version, how built, options, patches,... Try -M pc-q35-1.7 and -M pc-i440fx-1.7. Try specifying --no-kvm and --enable-kvm. Speyifying -cpu may help as well. From my experience with GRUB, qemu has following flaws: - From version to version they sometimes do subtle changes which break firmware. - On some CPUs kvm bugs or behaves unexpectedly. On 10.03.2014 14:43, David Hubbard wrote: On Sunday, March 09, 2014 08:26:05 PM you wrote: On Sunday, March 09, 2014 05:14:51 PM you wrote: Story so far: 1. pick q35 chipset 2. qemu -M q35 etc. etc. $ qemu-system-i386 -M q35 --bios build/coreboot.rom -ENOREPRODUCE 1. pick i440fx chipset. 2. qemu -M pc etc. etc. qemu-system-i386 --bios build/coreboot.rom -ENOREPRODUCE Endless repetitions of qemu: unsupported keyboard cmd cmd=0x00 or 0x80 -ENOREPRODUCE Same with qemu-kvm. This is with crossgcc. I'm disappointed it's this fragile. I'm worried that feature push has gotten ahead of reliability push. Or your qemu installation is b0rk3d. Perhaps if it is that easy to break the installation -- remember, he did a clean checkout -- then there could be a broken dependency, or something similar which involves digging deeply into the build system. In other words, even if what you say is true, we still need to have this conversation. I feel like Coreboot is a bit fiddly to get set up right. To a degree, that helps communicate that working with coreboot is hard stuff. But still, we should implement some better quality controls, imho. Hopefully we can figure out what Ron ran into. That would be a good start. David signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014- coreboot mainboard test suite
On 02.03.2014 09:01, Muhammad Ramshad wrote: When i search through the projects and organizations the coreboot project grabbed my focus towards it because i am more interested in Digital System Design and hardware a level development like processor design and ISA designs. And absolutely no idea that HTML messages are not welcome on mailing list. Use ASCII messages. It will also prevent you from screaming big letters in the middle of a message. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] `DEBUG_INTEL_ME` (incorrectly) only selected for Intel BD82x6x
On 26.02.2014 04:24, mrnuke wrote: On Wednesday, February 19, 2014 11:06:40 PM Paul Menzel wrote: looking through `src/console/Kconfig` I noticed You mean 'src/Kconfig' ? if SOUTHBRIDGE_INTEL_BD82X6X DEFAULT_CONSOLE_LOGLEVEL_8 This is a layering violation. We shouldn't have hardware-specific options in top-level Kconfig. This should be moved to southbridge Kconfig, and not depend on LOGLEVEL. Maybe we need to move ME handling to a common dir and handle the Kconfigs there. which seems odd as currently other chipsets needing the Intel Management Engine were submitted. $ git grep DEBUG_INTEL_ME [...] Smells like copypasta. Yet another reason to consider unifying ME handling across southbridges. Don't. This particular code is a good example why it shouldn't be done. On Ibexpeak this code (extended status print) would timeout. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 19.02.2014 23:03, Paul Menzel wrote: Am Mittwoch, den 19.02.2014, 00:47 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: On 19.02.2014 00:18, Paul Menzel wrote: But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed. I also agree, but it’ll take more time and the above is a good work-around for the mean time. Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work. CBMEM console does not work for romstage on all AMD based boards. Ask Rudolf and Kyösti for more details, but as far as I understood them, the solution is *not* easy and not within reach at all. As I already told the info from romstage is likely of minor importance if the board boots. And if it doesn't, well no board status. If any of the info from romstage is relevant it can be printed in ramstage as well Thanks, Paul signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
You do not get raminit debug output printed in ramstage. Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant. Just read this data from registers and print it. Kyösti signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A Growing Concern
On 18.02.2014 06:21, amlo...@tfwno.gf wrote: As a privacy and freedom oriented PC/Linux user, it scares me how modern day devices are becoming extremely proprietary. Companies are beginning to ship their laptops/tablets with proprietary EFI systems which have some nasty things in them. I recently purchased a Dell Venue 8 Pro(one of many upcoming 8 windows 8.1(x86) tablets) and while i was searching through its BIOS, i noticed that it had the computrace option activated. After disabling it, i decided to try to put coreboot on it, only to find that its non-existent for my device. Although it says that its disabled, i dont trust it one bit. While it is a beautiful, fast and ultra-portable PC, it bothers me how there are no free alternatives for it. These types of devices are growing in numbers and will most likely continue on through the years. All I ask of you is to try and make EFI alternatives to all these upcoming devices. All of them? Possible but will probably cost you millions in workforce. If you really want coreboot on some devices that interest you, you'll have to back it up with either work(do port yourself) or money (hire someone, you can post a bounty) signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 19.02.2014 00:18, Paul Menzel wrote: But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed. I also agree, but it’ll take more time and the above is a good work-around for the mean time. Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Trouble with coreboot for Roda RK9 (SOLVED)
On 14.02.2014 13:38, Dmitry Bagryanskiy wrote: //Enable Com3 pci_write_config32(LPC_DEV, D31F0_GEN2_DEC, 0x001c02e1); //Enable Com4 pci_write_config32(LPC_DEV, D31F0_GEN3_DEC, 0x001c03e1); GEN*_DEC should not be set to com* ports. Instead there are dedicated bits for enabling decode of serial port ranges. Consult southbridge documentation. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaVGABIOS with native vga init (Need testers)
On 13.02.2014 01:23, Kevin O'Connor wrote: Looking through the output of $ git grep k8t890 src/mainboard/ the boards Asus A8V-E Deluxe, Asus A8V-E SE, Asus K8V-X, Asus M2V-MX SE and Asus M2V should theoretically support that. Okay. The SeaVGABIOS implementation is expecting a coreboot table (LB_TAG_FRAMEBUFFER). So, as long as that is present it should work. LB_TAG_FRAMEBUFFER is present only if display is placed in graphics mode, otherwise EGA text mode is assumed. EGA text mode is much easier to make use of (including for oprom) and more compatible than graphics counterpart. Lenovo X201 init makes use of EGA text mode as well. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot port for macbook2,1
On 13.02.2014 23:47, Mono wrote: Hallo finally I managed to enable SPI on the Beaglebone Black and use it as external programmer with flashrom. I read the macbook's flash chip twice, as suggested. Both rom files are identical. But: a few days/week ago I read the flash chip with the macbook's internal programmer. This file differs from what the external programmer got. Some 9500 bytes (out of 2MiB) differ. apart from a few exeptions those bytes are 0xff read with the internal programmer, but have random hex code when read with the external programmer. Well, between the usage of internal and external programmer the macbook was in normal use. I didnt expect the OS or EC(?) or something to write to the flash chip while it is in normal use. what do you think? what could cause this differnce? I can paste the rom contents later somewhere if that would help any. That is pretty normal. Some firmwares store debug log or parameters in flash. best regards Mono On Sat, Feb 08, 2014 at 03:37:40PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 08.02.2014 15:27, Mono wrote: Hallo, On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: CY8C24794-24LFXI My guess: it's part of keyboard + touchpad Do you already know which port is USBdebug one? Yes, I found out with a USB stick, dmesg and lsusb -t. Did you already test USB debug with dbgp? Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same for Macbook. I meant that you can use debug port as early printk device. It's recommended to check dongle this way if your dongle is the real dbgp dongle. Um, there are much more 00's than for the Thinkpad X60. Not sure what this means Different firmware. Most likely less functions are on it (keyboard and touchpad are on USB and handled by another chip). You'll need to make directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable. What about those Block Protect things? Forget them for now, you'll be flashing externally until you have working version anyway I updated the webpage about what I did ( http://macbook.donderklumpen.de/coreboot/ ). At the moment I am looking at x60's romstage.c because I'd plan to copy as much as possible from it. At the function static void ich7_enable_lpc(void) I got stuck. I can make some guesses, but don't know where the details are documented. If you could point me to any documentation, I'd love to read it. I tried ich7 datasheet and LPC Interface Specification but did not spot what the function ich7_enable_lpc does. By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with coreboot and the Macbook with factory bios I get the following: on the Thinkpad $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 and on the Macbook $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Intel Corporation Device [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72 30: 00 00 00 00 e0 00 00 00 00 00 00 00
Re: [coreboot] Ram Init: Intel i945: Timing parameters
On 14.02.2014 00:03, Mohit Gupta wrote: I am having trouble understanding i945 ram init code especially timing parameters. Can some explain me in layman language? When I go through DDR2 specification, timing related text is too complex and confusing. Interested in getting very simple explanation. There isn't any. RAM init is difficult. Also, i945 ram init code is doing lot of settings in MCH. Is there any step by step documentation available? Sure: 1) Locate intel offices 2) Locate their top-secret safes 3) Observe security 4) Buy military gear 5) Recruit and train a company (~200 people) for a year 6) Launch assault on the office 7) Break into the safe 8) Get out of Intel building 9) Read the documentation Regards Mohit Gupta signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 10.02.2014 23:47, David Hendricks wrote: On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel paulepan...@users.sourceforge.net mailto:paulepan...@users.sourceforge.net wrote: Dear coreboot folks, currently no coreboot messages are stored for boards not supporting CBMEM console (or where this option is disabled (currently by default)) or no coreboot *romstage* messages are stored for boards, where the data cannot be preserved (passed to ramstage). Using the serial (or USB) console all these messages can be captured with no problem, so I propose to just add these captured messages into the file `serial_console.txt`. Of course this file probably contains also the payload and (Linux) kernel log, but I think that is fine. SeaBIOS’ `readserial.py` should be used for capturing the messages as it adds time stamps. Scripting this is going to be hard, as the log is captured on a different system. So for now I propose to add it manually. I don't think the script itself should be responsible for collecting serial output. Instead, how about adding an argument to override the default behavior of running cbmem -c on the target so that the user can pass in a filename? The user will simply capture the serial output using whatever tool they like, dump the output to a text file, and run the script with an argument to use the file instead of calling cbmem -c. Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 . This requires user to do right manipulations. While keyboard and chair are usually fine, the space between them exhibits strong bug-inducing properties. The idea of the script is to reduce a possibility of user error creating strange reports. In this case the common erro I expect is using a stale file fom some other version. It's a particularly nasty one as at first glance in may look fine but would be almost useless to track how details changed from one submit to the next. If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 11.02.2014 01:56, mrnuke wrote: On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt There is a point at which the information becomes too much. What is really relevant, in my opinion, are the following three points: 1. Is it an unmodified commit in master (AKA, not -dirty). 2. Does it boot? 3. What does not work, if any ? Point 1 and 2 are answered by cbmem -c | head. It answers point 1 with the first line of output, and point 2 by the fact that getting anything from cbmem means you've already booted your system. Point 3 is more complicated, and it seems it is because of this point that we want to collect any and all information we can possibly get our hands on. Other than cbmem -c | head and .config, a majority of people just don't care about all the pesky details. They're only useful when debugging problems some poor guy or gal is having. In that case, we can ask them for this info manually. It's not of any use in tracking down which revision + config works on _this_ board. This is not the only uses of board-status. It's also useful to see if some boards have an issue which one meets in particular board. This information is important in tracking bugs down but hard to collect unless it's in the board-status. Alex signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 09.02.2014 13:50, Paul Menzel wrote: Dear coreboot folks, currently no coreboot messages are stored for boards not supporting CBMEM console Is there any remaining? If so it's an issue to be fixed (or where this option is disabled (currently by default)) Change the defaults. or no coreboot *romstage* messages are stored for boards, where the data cannot be preserved (passed to ramstage). which boards are concerned? Which boards use ROMCC for romstage? Do they output anything useful in romstage? If so, can't it be compensated by ramstage? Using the serial (or USB) console all these messages can be captured with no problem, so I propose to just add these captured messages into the file `serial_console.txt`. Of course this file probably contains also the payload and (Linux) kernel log, but I think that is fine. SeaBIOS’ `readserial.py` should be used for capturing the messages as it adds time stamps. Scripting this is going to be hard, as the log is captured on a different system. So for now I propose to add it manually. Having to capture serial makes setup needed for board-status more difficult. Certainely, one needs to have a recovery method for case of brick but having a complete serial setup will heavily reduce board-status input which already isn't huge. Thanks, Paul signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 09.02.2014 14:34, Paul Menzel wrote: Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: On 09.02.2014 13:50, Paul Menzel wrote: currently no coreboot messages are stored for boards not supporting CBMEM console Is there any remaining? If so it's an issue to be fixed Sorry, no idea. I thought there were some. At least not all boards have been tested to my knowledge. board-status is all about testing. When we see incomplete coreboot_console.txt it means there is a bug to be fixed, not workarounded. (or where this option is disabled (currently by default)) Change the defaults. It is not safe or wanted for all boards I believe. But others are more knowledgeable to comment on that issue. I don't see any problem with enabling cbmemc by default on all boards. or no coreboot *romstage* messages are stored for boards, where the data cannot be preserved (passed to ramstage). which boards are concerned? Which boards use ROMCC for romstage? Do they output anything useful in romstage? If so, can't it be compensated by ramstage? In my case it is the Asus M2V-MX SE (AMD, pre-AGESA). What is the info we need from it? ROMCC boards usually don't output much. Using the serial (or USB) Your argument with USB console is completele broken as EHCI debug is not supported on ROMCC boards at all. console all these messages can be captured with no problem, so I propose to just add these captured messages into the file `serial_console.txt`. Of course this file probably contains also the payload and (Linux) kernel log, but I think that is fine. SeaBIOS’ `readserial.py` should be used for capturing the messages as it adds time stamps. Scripting this is going to be hard, as the log is captured on a different system. So for now I propose to add it manually. Having to capture serial makes setup needed for board-status more difficult. Surely it will not be a requirement to capture the serial output. My proposal is about adding it, when it is captured already and what file name to use. And who will care about it then? Certainly, one needs to have a recovery method for case of brick You always need that in case of a brick. What is special about serial log? I use debricking setup perhaps every 20 flashes on a supported board. Not every time. but having a complete serial setup will heavily reduce board-status input which already isn't huge. Again, it is not meant to be a requirement in addition to what is currently captured. Thanks, Paul signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot port for macbook2,1
On 08.02.2014 15:27, Mono wrote: Hallo, On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: CY8C24794-24LFXI My guess: it's part of keyboard + touchpad Do you already know which port is USBdebug one? Yes, I found out with a USB stick, dmesg and lsusb -t. Did you already test USB debug with dbgp? Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same for Macbook. I meant that you can use debug port as early printk device. It's recommended to check dongle this way if your dongle is the real dbgp dongle. Um, there are much more 00's than for the Thinkpad X60. Not sure what this means Different firmware. Most likely less functions are on it (keyboard and touchpad are on USB and handled by another chip). You'll need to make directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable. What about those Block Protect things? Forget them for now, you'll be flashing externally until you have working version anyway I updated the webpage about what I did ( http://macbook.donderklumpen.de/coreboot/ ). At the moment I am looking at x60's romstage.c because I'd plan to copy as much as possible from it. At the function static void ich7_enable_lpc(void) I got stuck. I can make some guesses, but don't know where the details are documented. If you could point me to any documentation, I'd love to read it. I tried ich7 datasheet and LPC Interface Specification but did not spot what the function ich7_enable_lpc does. By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with coreboot and the Macbook with factory bios I get the following: on the Thinkpad $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 and on the Macbook $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Intel Corporation Device [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 07 38 81 06 0c 00 41 16 0c 00 00 00 00 00 90: 01 03 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 04 02 00 00 01 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 08 80 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 00 00 67 45 00 00 00 ff 00 00 00 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 In the Thinkpad output I can spot the values written by coreboot: 0xd0 at 0x64 // Enable Serial IRQ, this is the same for what the Macbook outputs, but where can I read that this enables serial IRQ? 0x0210 and 0x1f0d at 0x80 and 0x82 // decode ranges, the Macbook outputs different values here 0x1601, 0x007c, 0x15e1, 0x000c, 0x1681, 0x001c from 0x84 to 0x8e // the Thinkpad has three ranges
Re: [coreboot] LinuxTag in Berlin from May 8–10, 2014
On 08.02.2014 23:13, Paul Menzel wrote: Dear coreboot folks, just a short announcement that after FOSDEM last weekend the next free software event (in Europe(?)) is going to be LinuxTag in Berlin from May 8–10, 2014. I won't be able to attend The location is going to be different this year. Since several years it won’t be happening at Messe Berlin but at STATION BERLIN [2]. So please mark that in your calender and let’s see what we can come up with coreboot wise for that event. Thanks, Paul [1] http://linuxtag.de/2014/en/ [2] http://www.station-berlin.de/en/location_directions/location.html signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
On 07.02.2014 17:57, Rubén Torrero Marijnissen wrote: Hi, I grew tired today of the default firmware that comes with my Google Chromebook 14; just when I had my Arch Linux install perfectly working somehow, by letting it attempt to boot Chrome OS, it messed up my partitions. If I have understood correctly (please, correct me if i'm wrong), the code for this model is alredy in place in the Git repository but no one has really tested it (or has reported anything on the wiki). Does anyone have more info? should I be able to flash it with flashrom after I build it? If you use upstream, please submit board-status result Any help is appreciated, I will update the wiki will all the info once i'm done. Thanks! signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Support for Dell desktop motherboard
On 06.02.2014 23:46, Ramkumar Ramachandra wrote: Hi, I have a Dell T5500 desktop, and I'd like to know if Coreboot supports this. No. http://www.coreboot.org/Supported_Motherboards According to dmidecode, the motherboard is a Dell 0D883F. Thanks. Ram signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [RFT] Lenovo convertible tablets X60t, X201t, X230t
Hello, all. I've uploaded digitizer support for X*t variants. Not tested in current form yet (was developped on Jens Erat's X201T during FOSDEM). Please test: - X60t owners: http://review.coreboot.org/#/c/5113/ - X201t owners: http://review.coreboot.org/#/c/5096 - X230t owners: should work without additional support (USB). Please report test result be it either positive or negative. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot port for macbook2,1
On 03.02.2014 21:43, Mono wrote: Hallo Vladimir, Peter and Stefan thank you for your emails! You already helped me alot. I don't expect to successfully close this project in a fast run and I'm willing to learn a number of tools. At the moment I am still collecting hardware informations about this computer. I dissembled it completely and documented the chip names of what I thought might be of interest. Please see http://macbook.donderklumpen.de/coreboot/ for what I got. That is good example of relevant info collection. My biggest concern is with the EC. It is a Renesas H8S/2116V. I read about this chip that it makes coreboot impossible on other machines, but I do not know whether this issue is machine specific, or if the chip definitely makes coreboot impossible for this macbook too. Could you comment on this? Type of EC doesn't matter. What matters is how it is connected. It may really get in the way or have almost no impact. My guess would be that on your system its influence is minor. X60 has H8 as well but with very different firmware which makes it a completely different chip from coreboot perspective. Also I do not know yet how I could verify whether the EC shares memory with the main system. That flashrom didn't create any ill effects when reading is an indication of separate flash. If you can flash externally you can leave the issue of internal flash for later and if you don't, don't flash. As for the ability of flashing the EPROM chip, I plan to test it in the near future (at first with an empty brand new chip, then with the soldered one). The EPROM is supported by flashrom and I plan to use a Beaglebone Black to be the programmer. (this page shows Beaglebone Black can flash a chip via SPI also flashrom is not used here: http://www.linux.com/learn/tutorials/746860-how-to-access-chips-over-the-spi-on-beaglebone-black ) I already learned how to use the Beaglebone Black to debug what coreboot outputs to the USB port on a Thinkpad X60. I assume this should work the same for the macbook (the debug port at the macbook seems to exist, but the factory BIOS does not write anything to it). Good One more question: The macbook atm uses a 32bit EFI which when it was purchased booted a 32bit kernel, and today boots a 64bit linux-libre kernel. Would I need to expect any additional problems from the fact that it is not a traditional BIOS, but some EFI which is to be replaced? My optimistic wish is to replace that EFI with coreboot plus a 64bit GRUB2 payload (same as done on my Thinkpad X60). Or would the payload need to be kept at 32bit? What Apple ships as firmware is irrelevant. However, decision to omit BIOS comes from higher-level decision of omiting compatibility with 95-era systems. So it's possible you won't be able to boot old OS even with coreboot due to lack of compatibility devices. I'd say it's a minor problem (95-era OS wouldn't work reliably on modern system anyway) thanks again and with best regards Mono On Wed, Jan 29, 2014 at 10:24:58PM +0100, Stefan Reinauer wrote: * Mono m...@posteo.de [140124 23:20]: Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! - Make sure you have the external tools in place to recover from a bad flash. You will notg boot successfully on the first attempt. - Keep a copy of the original firmware around - Try to make sure that your USB debug gadget is working before starting - Start with one of the existing i945 based notebooks - find out what EC is used, and if it shares flash with the main system - try to get hold of schematics Regards, Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Motherboard Not on Support MB List - Specs
On 03.02.2014 17:37, lee.changhan wrote: Hi, I have some info about my motherboard here according to the FAQ page to see if anyone can tell me about the compatibility between my BIOS and coreboot. Your motherboard is not compatible with coreboot. 1. Gigabyte GA-Z77-HD3 Motherboard Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz 2. lspci -tvnn -[:00]-+-00.0 Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller [8086:0150] +-01.0-[01]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450] [1002:6779] |\-00.1 Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] +-14.0 Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] +-16.0 Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] +-1a.0 Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] +-1b.0 Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] +-1c.0-[02]-- +-1c.2-[03]00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] +-1c.3-[04-05]00.0-[05]-- +-1d.0 Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] +-1f.0 Intel Corporation Z77 Express Chipset LPC Controller [8086:1e44] +-1f.2 Intel Corporation 7 Series/C210 Series Chipset Family 4-port SATA Controller [IDE mode] [8086:1e00] +-1f.3 Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] \-1f.5 Intel Corporation 7 Series/C210 Series Chipset Family 2-port SATA Controller [IDE mode] [8086:1e08] 3. superiotool -dV superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0x, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0x, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0x, id=0x Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0x8728, rev=0x1 Probing for ITE Super I/O (init=it8502e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0x Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0x, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0x Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0x, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data:
Re: [coreboot] coreboot port for macbook2,1
CY8C24794-24LFXI My guess: it's part of keyboard + touchpad Do you already know which port is USBdebug one? Did you already test USB debug with dbgp? Um, there are much more 00's than for the Thinkpad X60. Not sure what this means Different firmware. Most likely less functions are on it (keyboard and touchpad are on USB and handled by another chip). You'll need to make directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable. What about those Block Protect things? Forget them for now, you'll be flashing externally until you have working version anyway signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Please use Git commit hooks
On 02.02.2014 12:05, Paul Menzel wrote: Dear coreboot folks, if you push patches please either check them manually or simply let the Git commit hooks do it for you by running `make gitconfig`. I know they take a lot of time especially when you run them the first time in a session. This will be hopefully improved soon. The problem is not this. The problem is that they regularly fail and prevent you from doing any commit Thanks, Paul -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo Thinkpad T61
On 31.01.2014 17:08, Roberto A. Foglietta wrote: 2014-01-31 Peter Stuge pe...@stuge.se mailto:pe...@stuge.se: Roberto A. Foglietta wrote: I check the list of supported motherboards and laptops but I did not found in them the Lenovo Thinkpad T61 That means that it is not supported. Thanks Peter for the fast answer. I would like to understand the magnitude of probability to brick the laptop before. The probability is 1.0. I am interested in the probability after some development / adaption, not as-is. How much developing effort do you think the support of T61 would require? Northbridge (i965) is unsupported. It's almost impossible to write raminit without having a lot of low-level experience and even then it takes couple of months of quite intensive work. You may get lucky and i945 raminit may work with only minor adaptations but: 1) I wouldn't count on it 2) And even then find out what exactly needs adaptation is no easy task. I have a laptop with i965 as well, in storage but I have to tell it's simply not worth the effort. You'd be better off cuying some recent supported laptop (see supported mobos pages, especially chromebooks and Lenovos) or some almost supported laptop and adapt to it. But: a) Problems may pop up in unexpected places. b) While guys in #coreboot are extremely helpful you end up being on your own in 95% of problems (unless someone has a similar chipset and works on it, currently nobody AFAIK). c) Easiest (but not easy) to adapt would be (from easiest to difficult, no guarantee, problems may pop up in unexpected places): - T410. All components are already in the tree. The problem with this laptop is that it has TSOP chip, for which clip is very expensive, so you probably would have to solder to the chip with all the risks it entails. Actually for most people it means to ask someone to solder for you - Nehalem-based laptops. Main problem is likely EC - AMD-based laptops. Main problem is likely EC. - Lenovo *30 laptops (ivybridge). Dual graphics can be a headache but it's feasible. If chip is TSOP, see T410 comment. - Other ivy or sandy laptops. Depends on how much MRC code likes or dislikes your laptop. I repeat again that even the easiest ones are hard if you have no low-level experience and even if you do can become hard in case of unexpected problem. On the other hand if you're curious about it , do it! It's a fantastic learning experience. To answer to this second question I suppose you need logs, do not you? lspci -vvnn is available for most laptops with quick google. It (+some experience with individual manufacturers about EC interface) allows to estimate hardness. Cheers, R. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo Thinkpad T61
On 31.01.2014 17:21, ron minnich wrote: If your only way to flash the flash is via a program, or something embedded in the lenovo bios, stop now, or stockpile 20 or 30 of these laptops, because you're going to create some bricks along the way. Let me elaborate on this: RTFM http://flashrom.org/ISP RTFM http://flashrom.org/Technology RTFM http://flashrom.org/Supported_programmers ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo Thinkpad T61
On 31.01.2014 20:30, ron minnich wrote: If you want a laptop to tear into and learn from, the old samsung x86 chromebook is hard to beat. ram and disk are standard and upgradable, you can put a clip on the flash part, ... Lenovo X201 and X230 both have those characteristics as well. Unlike chromebooks it doesn't come with a nice firmware preinstalled though. But I have to admit that compared to other vendors (especially the one called To be filled by O.E.M.), lenovo's BIOS and EFI are good. it's just a very hackable machine. I still have one and really like it. More recent ones to mess around with include the acer c720. The difficulty of dealing with chipsets is what keeps me pushing on chromebooks. It's a real time saver. I'd still like to find an AMD solution however. I'm thinking of lenovo x140e. Not available in Europe though. ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote: http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing (which mentions another solution to the problem) Flashrom solution is interesting but it doesn't handle external flashing. It would be a nice addition to checksums for internal flashing though. Patrick's solution would have only one advantage compared to my prototype: possibility of coreboot migrating the options rather than resetting. Patrick's solution relies on mathematical impossibility. You can't have such function with only 16-bit salt. Let's take any partition of 248 (see http://mathworld.wolfram.com/PartitionFunctionP.html), then create options A,B,C,... with sizes according to this partition. The hashing function as per Patrick's proposal would have to map them to non-interlapping regions. By evaluating this function at A,B,C,... you can extract the partition if number of chunks is known. Since number of chunks is an integer from 1 to 248 so the function has to store at least: Log2[PartitionsP[248]]-Log2[248] 39 bits of information. So salt has to be at least 40 bits. Probably even more if you put into mix that we also need sub-byte options and you have to handle option names. This means: 1) You can't bruteforce such a parameter space during compile, so some structure is needed. 2) You'll need more than 40 bits of storage in CMOS. At this point I feel like Patrick's proposal is not practical. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing (which mentions another solution to the problem) Flashrom solution is interesting but it doesn't handle external flashing. It would be a nice addition to checksums for internal flashing though. Patrick's solution would have only one advantage compared to my prototype: possibility of coreboot migrating the options rather than resetting. But there is a problem with attempting this: when you request for option the hashing would always give a number, even if that option doesn't exist. And then we're back to reading garbage for new options. 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. (IIRC we already have problems with the Linux nvram driver which does checksumming somehow differently. Or maybe that was fixed already.) Ok. Let's hold 2a in reserve if 2 bytes is considered too expensive ...but the above reminded me that it is ultimately a responsibility of our source code and our design to never let booting fail simply due to some garbage in NVRAM. Code and design really must ensure a working state. There are number of problems with this: 1) Overclocking options. If you overclock too much, you don't boot successfully. 2) FILO uses options to control its behaviour. If by garbage tells to boot from bad filename, it will probably stop unable to find the file. 3) vbnv field may be a problem. Even if this goal is achieved we still need an upgrade way as new option with garbage may make the system bootable but uncomfortable to most of users, which is to avoid. E.g. disabling touchpad: I personally disable touchpad (but through OS facilities, not coreboot) but many users would get confused by disabled touchpad. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] cmos.layout upgradability
Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option trackpad_enable will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: Re: coreboot port for macbook2,1
Original Message Subject: Re: [coreboot] coreboot port for macbook2,1 Date: Sat, 25 Jan 2014 01:23:12 +0100 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: Mono m...@posteo.de On 24.01.2014 23:20, Mono wrote: Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! Good news is that other than EC and some minor points, your macbook is a copy of X60. With some luck a qualified dev can do it in a week (you may want to post bounty for it). You need to get console. EHCI debug would be the best option on your laptop. http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port Take USB 2.0 stick and plug it into different port until it appears as device one on bus 3. You'll have to make a USB debug dongle or buy one (short supply). You'll also need to find your flash chip. Your laptop has this chip: http://orzparts.com/index.php?main_page=product_infoproducts_id=732 You'll have to teardown the whole laptop, looking at every chip which seems similar. Remember to discharge from static electricity before opening your laptop and not to wear anything that produces it. This has a risk of breaking your laptop, proceed at your own risk, you've been warned. thanks Mono signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: Re: coreboot port for macbook2,1
On 25.01.2014 01:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Original Message Subject: Re: [coreboot] coreboot port for macbook2,1 Date: Sat, 25 Jan 2014 01:23:12 +0100 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: Mono m...@posteo.de On 24.01.2014 23:20, Mono wrote: Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! Good news is that other than EC and some minor points, your macbook is a copy of X60. With some luck a qualified dev can do it in a week (you may want to post bounty for it). You need to get console. EHCI debug would be the best option on your laptop. http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port Take USB 2.0 stick and plug it into different port until it appears as device one on bus 3. I meant port 1 on bus managed by ehci_pci (exact bus numbers are unstable) You'll have to make a USB debug dongle or buy one (short supply). You'll also need to find your flash chip. Your laptop has this chip: http://orzparts.com/index.php?main_page=product_infoproducts_id=732 You'll have to teardown the whole laptop, looking at every chip which seems similar. Remember to discharge from static electricity before opening your laptop and not to wear anything that produces it. This has a risk of breaking your laptop, proceed at your own risk, you've been warned. thanks Mono signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On 25.01.2014 01:28, mrnuke wrote: On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option trackpad_enable will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. You mean it won't write the cmos.default after upgrade? Not it won't. Checksum covers the same range and is at same position. So checksum is still valid. And why would you need to reset CMOS if trackpad is disabled? # nvramtool -a # nvramtool -w trackpad_enable=Enable You could do it in this particular case but user isn't required to know this. And settings may be something more drammatic. It may happen that the system doesn't boot with garbage settings at all. The fact that you have to handle garbage in saved option indicates that something is wrong. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Seeking for reviewers: X201 (enable S3 al) and X230
Hello, all. I've just uploaded 2 patchsets: X201 which fixes all known issues including S3 resume but except Gnome battery reporting. Top for x201 is at http://review.coreboot.org/#/c/4632/ and few separate patches with theme x201 (X201-specific) and thinkpad (having benefits for X60/T60 as well). X230 top is at http://review.coreboot.org/#/c/4679/ signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] does coreboot support kvm WPCE775x other questions
On 05.01.2014 07:15, Gregg Levine wrote: Part of the problem with laptops is that there is a thing on them called an Embedded Controller, EC for short. Those devices do all of the housekeeping chores that the main system has delegated to them. For example certain functions are on it. To that end most laptops aren't supported because these devices are proprietary in their designs and the programing of them. While ECs are a problem for flashrom (unless they run off a separate flash), they are usually of marginal importance to coreboot. You cn always use external flasher. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Remove GENERATE_ACPI_TABLES
By now most boards and OS don't run correctly if ACPI tables are not supplied. Ability by user to enable/disable their generation is just increasing configuration matrix for no benefit. So I propose to hardwire it to HAVE_ACPI_TABLES. I feel like in current config there are too many options of kind Do you want a working system? (y/n) and they should be hardwired to right answer rather than adding configuration. http://review.coreboot.org/#/c/4609/ signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Remove GENERATE_ACPI_TABLES
On 07.01.2014 00:12, mrnuke wrote: On Monday, January 06, 2014 07:52:20 PM Vladimir 'φ-coder/phcoder' Serbinenko wrote: By now most boards and OS don't run correctly if ACPI tables are not supplied. Ability by user to enable/disable their generation is just increasing configuration matrix for no benefit. So I propose to hardwire it to HAVE_ACPI_TABLES. You mean you haven't found a need for it in your recent use cases. I don't think this can be used to generalize for all boards, and is most certainly a naive proposal for ARM boards. So you end up depending this shit on ARCH_x86, then ARM adds ACPI, then it again makes sense to HAVE_ACPI_TABLES, but only for ARM, so now we make it depend on ARCH_ARM, and we get a clusterfuck by the end of the day. At the end of it all, you are proposing to take away a freedom that has hurt no-one. -2. I can't see the justification. You misunderstood. I don't propose to remove HAVE_ACPI_TABLES. HAVE_ACPI_TABLES remains per-board characteristic. The only thing I remove is GENERATE_ACPI_TABLES which is user-visible option. This way presence of ACPI-tables is determined by board porter based on the need and availability of ACPI tables I feel like in current config there are too many options of kind Do you want a working system? (y/n) and they should be hardwired to right answer rather than adding configuration. Flashing coreboot is a minefield of these questions: Do you want to brick your system? (ok/cancel). You can't make it fool proof, and nanny-state-ing users is not the solution. Provide sane defaults. Right now we're at opposite end when you almost have to use genetic algorithm to find which configuration works. Alex P.S. If you don't know what you're doing, you will brick your board, no matter how many coreboot condoms you wear. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New laptop: Lenovo ThinkPad X230 tablet, with dumps to go with it
On 15.09.2012 05:47, Keith Hui wrote: Hi all, I'm back. With a new laptop. I'm now rocking a Lenovo x230 tablet, http://review.coreboot.org/#/c/4614/ signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
