Re: [coreboot] New interface for I2C in coreboot
OK, forget my last Mail...I was to blind to see the truth :-) We already have my approach with the new interface. We maybe can expand it to have informations like time-out or retry count for a given segment. Werner Gesendet: Donnerstag, 19. Februar 2015 um 07:41 Uhr Von: Werner Zeh werner@gmx.net An: Julius Werner jwer...@chromium.org, gauml...@gmail.com, pgeo...@google.com Cc: coreboot@coreboot.org Betreff: Re: [coreboot] New interface for I2C in coreboot Hi all. I am fully aware of how I2C bus works and I never liked this interface. This is because you cannot really probe devices on the bus, there is not really a status information available on the bus and one can confuse a slave in that way that it will block the bus without a way to reset it (at least there is a trick available). After I have thought for a long time about this issue, I can understand the need of the change that has been done. Nevertheless, I still not want the place where the cut in the interface was done. With the new interface the driver for I2C bus is truncated because with this interface the driver do not have the knowledge of the whole transfer that must be performed on the bus. Instead, the driver is fed with small pieces of data. In this way, we cannot design a driver that is smarter and can use all the abilities a hardware given I2C controller can provide. I would like to discuss the following approach: Construct all the data you need to transmit/receive outside of the I2C driver (i.e. inside the user of I2C driver which can be itself a driver for the slave e.g. an EEPROM, tpm, whatever). We can use a similar structure approach the new interface already has and chain this structures to build a complete transaction. We can add control information (read/write data, start/stop condition...) to every piece of the transaction (let's call it chunk) as well as needed timeout or retry requirements. The list of all this chunks builds up the complete transaction. This transaction will be passed into the I2C driver. Now the driver can handle the list as it wants to. We can write simple drivers that consist of GPIO manipulation to emulate the I2C controller. But we also can write smart drivers which can use all the abilities a given hardware controller provide. In my opinion this approach will allow us to be more flexible without wasting hardware possibilities and with a comparable complexity we currently have with the new interface. Any thoughts are welcome. Werner Gesendet: Dienstag, 10. Februar 2015 um 20:36 Uhr Von: Julius Werner jwer...@chromium.org An: Werner Zeh werner@gmx.net Cc: coreboot@coreboot.org, Julius Werner jwer...@chromium.org, Marc Jones marc.jo...@se-eng.com, mar...@se-eng.com, Patrick Georgi pgeo...@google.com Betreff: Re: New interface for I2C in coreboot I think the idea behind this change was mostly that the old API was too inflexible and some I2C device drivers could not be properly written with it. Take a look at line 139 in this file from the first patch: http://review.coreboot.org/#/c/7751/3/src/drivers/i2c/tpm/tpm.c@139 . What this really does is trying to do all of the normal parts of an I2C read transaction manually, because TPMs can add so long delays at any point that the normal I2C controller drivers would already hit their timeout. With the old API this was only possible with a crude hack of setting the address length to 0 (so i2c_read() would skip the register address write completely). Doing a raw read with the new API does the same thing much clearer, and it's far more obvious to controller driver authors that they need to implement this (otherwise, it's easy to just assume alen == 0 is illegal until someone tries to use the TPM driver with it, which I think is what hit us on Tegra). The new API also makes the rules about when to use a repeated start vs a complete stop and start much clearer (which should not make a difference for the device, but in practice sometimes does). I think Werner's original issue is easy to solve: you can either just construct struct i2c_seg structures and call i2c_transfer() directly, or implement a new i2c_write() wrapper similar to i2c_writeb() (just with a variable data length). Maybe even just make i2c_writeb() a one-line wrapper macro on top of the new function... all fine by me, I think the only reason we didn't make more convenience functions is because we didn't need them at the time. The implementation problems Patrick mentioned are unfortunately true for some controllers which attempt to be more clever than they should... however, the thing is that we need to somehow implement raw I2C reads anyway (to support the alen == 0 case in the old API and make things like that TPM driver work). In the end we probably need to implement less primitives for the new API (raw write and raw read) than
Re: [coreboot] New interface for I2C in coreboot
Julius Werner wrote: We maybe can expand it to have informations like time-out or retry count for a given segment. One word of caution I'd like to add here is that making this API more complex/powerful requires significant effort, now and in the future. Not if the architecture is any good. We already have 4 I2C driver implementations in coreboot, and 4 more are going to be upstreamed soon from the Chromium tree. As we scale up to we'll probably add at least one new driver per SoC vendor, maybe even per SoC. Adding complex functionality like retries to the API will require us to account for it over an over again in every single implementation. No - that doesn't make any sense. Probably there will be a fair bit of code that can be shared among controllers. There aren't that many ways to implement I²C. I think the question is really what we would gain from this. I think it's less about performance and more about an accurate and clean model being available to mainboard code when needed. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New interface for I2C in coreboot
On Thu, Feb 19, 2015 at 12:21 AM, Werner Zeh werner@gmx.net wrote: OK, forget my last Mail...I was to blind to see the truth :-) We already have my approach with the new interface. We maybe can expand it to have informations like time-out or retry count for a given segment. One word of caution I'd like to add here is that making this API more complex/powerful requires significant effort, now and in the future. We already have 4 I2C driver implementations in coreboot, and 4 more are going to be upstreamed soon from the Chromium tree. As we scale up to we'll probably add at least one new driver per SoC vendor, maybe even per SoC. Adding complex functionality like retries to the API will require us to account for it over an over again in every single implementation. I think the question is really what we would gain from this. Even though some I2C controllers have more efficient modes that do multiple things at once, all I've yet seen could somehow be coerced to do real simple step-by-step transfers. Since we need to implement that anyway for the API, why do anything more? Efficiency? I think I2C transfers are generally so slow that a little more overhead here and there isn't going to make a measurable difference. These transaction-at-a-time hardware features are designed for operating systems that have other threads to schedule or the power impact of a high interrupt frequency to worry about, not us. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Need help with MSI MS-7260 (K9N Neo) / MSI MS-7250 (K9N SLI)
Hi, I'd like to run coreboot on my MSI MS-7250 (K9N SLI) mainboard. This board is apparently quite similar to the MSI MS-7260 (K9N Neo) which is already supported: http://www.coreboot.org/Board:msi/ms7260 This is what my board looks like, though mine is a version 2.2: http://www.msi.com/product/mb/K9N_SLI.html#hero-specification I tried booting the board with a coreboot ROM built for the MS-7260 (and an AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ CPU, 4 1GB DIMM sticks, and a Radeon 7000 graphics card). That didn't work, but I've attached the log. I've also attached the outputs from lspci, superiotool, and flashrom, for good measure. What needs to be done and what's a good place to start? Christian coreboot-boot.log Description: Binary data -[:00]-+-00.0 NVIDIA Corporation MCP55 Memory Controller [10de:0369] +-01.0 NVIDIA Corporation MCP55 LPC Bridge [10de:0360] +-01.1 NVIDIA Corporation MCP55 SMBus Controller [10de:0368] +-02.0 NVIDIA Corporation MCP55 USB Controller [10de:036c] +-02.1 NVIDIA Corporation MCP55 USB Controller [10de:036d] +-04.0 NVIDIA Corporation MCP55 IDE [10de:036e] +-05.0 NVIDIA Corporation MCP55 SATA Controller [10de:037f] +-05.1 NVIDIA Corporation MCP55 SATA Controller [10de:037f] +-05.2 NVIDIA Corporation MCP55 SATA Controller [10de:037f] +-06.0-[01]00.0 Advanced Micro Devices, Inc. [AMD/ATI] RV100 [Radeon 7000 / Radeon VE] [1002:5159] +-08.0 NVIDIA Corporation MCP55 Ethernet [10de:0373] +-09.0 NVIDIA Corporation MCP55 Ethernet [10de:0373] +-0a.0-[02]-- +-0b.0-[03]-- +-0c.0-[04]-- +-0d.0-[05]-- +-0e.0-[06]-- +-0f.0-[07]-- +-18.0 Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] +-18.1 Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] +-18.2 Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] \-18.3 Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] superiotool r4.0-8138-gd15bdda 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=0x0400, id=0x6888 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 0x20e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x20e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x20e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x20e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x20e... Failed. Returned data: id=0x, rev=0xf 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=0x, rev=0xf 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=0x8868, 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
Re: [coreboot] New interface for I2C in coreboot
Werner Zeh wrote: We already have my approach with the new interface. We maybe can expand it to have informations like time-out or retry count for a given segment. I think this is a really good idea. I also think that this structure applies to SPI as well. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Automated test system: Nominations wanted
2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: I am currently planning to set up a test system with 5 (later up to 10) machines boot testing each new coreboot commit. This test system will be serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. Current goals for every commit: - Check if coreboot + SeaBIOS are able to boot Linux to a point where network is up and running Current goals for every work day: - Check if screen, keyboard and touchpad/mouse work - Check if USB works and has the expected transfer speed (i.e. if USB High and Super Speed both work) http://blogs.coreboot.org/blog/author/ayushsagar/ documents last year's GSoC project to implement some of those - incl. a screen test using the display present signals. Through external flashing, there's also no need to handle unbricking manually. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] memtest86 reading 0k memory
On Wed, Feb 18, 2015 at 10:26:21PM +0100, Stefan Reinauer wrote: * Timothy Pearson tpear...@raptorengineeringinc.com [150205 19:23]: e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000f-0x000f] reserved BIOS-e820: [mem 0x0010-0x3ffacfff] usable BIOS-e820: [mem 0x3ffad000-0x3fff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved One of the issues seems to be that the coreboot table space is not marked as reserved (i.e. the lower 4k should be marked as reserved, and whatever is used at the top of memory) coreboot tends to reserve the first 4K, but this breaks lots of bootloaders. So, SeaBIOS always overrides coreboot and unreserves the first 4K. My experience is that the first one megabyte of the e820 is just magical and should always read as listed above. Separately, it is possible for SeaBIOS to remove the coreboot table forwarder, and thus force memtest86 to not use the coreboot tables. I'm not sure if this would affect other programs though. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Mohon Peak, Memtest86+ does not start
On Tue, Jan 27, 2015 at 03:59:27PM +0300, Kuzmichev Viktor wrote: Thank you very much, this helped a lot! Now memtest is loading and it successfully performs RAM tests. But there is another issue. Somehow, input via serial console does not work. And it seems like the problem is not in memtest, rather it's in SeaBIOS or coreboot. There is no any prompt for input in coreboot. But there is in SeaBIOS, and I was not able to enter boot menu since it did not respond to F12. Although, SeaBIOS responds to the keyboard that is directly connected to the board while memtest does not seem to respond at all (at least, I tried to hit Esc which should reboot the board). I've tried to search for this but so far found nothing. Will appreciate any help. I'm not sure if you found a solution to your issue. SeaBIOS only supports debug output on serial. For a serial console, one can use sgabios with seabios - there is a description on how one can do this at: http://www.coreboot.org/SeaBIOS#Adding_sgabios_support -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] updating coreboot SeaBIOS on an Acer C720
On Mon, Feb 09, 2015 at 08:32:40AM +0100, Matthias Apitz wrote: El día Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering escribió: 2015-02-08 21:55 GMT+01:00 Matthias Apitz g...@unixarea.de: El día Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G. escribió: Suspect number one is the device overheating. The shutdown is triggered by the EC. I don't know how you can enable ACPI debug output on BSD though. On linux, it would be echo 1 /sys/module/acpi/parameters/aml_debug_output, so whatever the FreeBSD equivalent of that is. hw.acpi.verbose=1 would be a start. ... Thanks for all the hints. As I said, the events are sporadic, seldom, but complete power-off (like as you would cut the cable from the motherboard). Of course the system has no chance to write anything to /var/log/messages or console. My hope while writing to coreboot@ was to get a pointer to the list of open ore solved issues within coreboot and/or SeaBIOS to see if this issue is somewhat known, solved or could be related to some known or solved issue. Where can I find such a list which is normally (as we do in my company) attached to the Release Notes of a new version of software. The SeaBIOS release notes are at http://www.seabios.org/Releases . It only provides a list of high level features though. One can also read through the SeaBIOS git commit history. The symptons you report do not sound like a SeaBIOS issue. SeaBIOS relies on coreboot to initialize most hardware. Once the OS starts, it's unlikely that SeaBIOS would adversely impact the machine behavior. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Need help with MSI MS-7260 (K9N Neo) / MSI MS-7250 (K9N SLI)
On 02/19/2015 10:44 PM, c...@post1.dansknet.dk wrote: Hi, I'd like to run coreboot on my MSI MS-7250 (K9N SLI) mainboard. This board is apparently quite similar to the MSI MS-7260 (K9N Neo) which is already supported: http://www.coreboot.org/Board:msi/ms7260 Hi I don't have experience with either of the boards. The log you attached suggests something is going wrong with cache coherency when doing MTRR setup. Seems like console spinlock no longer works as those printk() calls from different cores get interleaved. This problem may not be related to the exact board you have. Similarity does not mean it is easy to fix the remaining differences, the log seems fairly promising though. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Automated test system: Nominations wanted
On Thu, Feb 19, 2015 at 12:35:11PM +0100, Patrick Georgi via coreboot wrote: 2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: I am currently planning to set up a test system with 5 (later up to 10) machines boot testing each new coreboot commit. This test system will be serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. Current goals for every commit: - Check if coreboot + SeaBIOS are able to boot Linux to a point where network is up and running Current goals for every work day: - Check if screen, keyboard and touchpad/mouse work - Check if USB works and has the expected transfer speed (i.e. if USB High and Super Speed both work) http://blogs.coreboot.org/blog/author/ayushsagar/ documents last year's GSoC project to implement some of those - incl. a screen test using the display present signals. Through external flashing, there's also no need to handle unbricking manually. This is a bit off topic, but I've been thinking that a neat project would be to package up an automated test and recovery system using the Beagle Bone Black board. The Beagle Bone Black isn't too expensive ($55), it is widely available, it has an SPI interface (for emergency flashing), has GPIOs (which, with a level shifter, could be used to turn on/off the board and report LED status), and can emulate a USB client. The emulated USB client could (in theory) be used to emulate a USB boot drive, a USB networking adapter, a USB keyboard, a USB serial port, and/or a USB debug device. In theory, one could wrap many of the target board's standard interfaces so that automated testing and remote development could be done. It would be a bit of work to get the software working and packaged nicely - but if it was, I think it could enable many more users to participate in automated tests and remote development. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Automated test system: Nominations wanted
2015-02-19 17:22 GMT+01:00 Kevin O'Connor ke...@koconnor.net: It would be a bit of work to get the software working and packaged nicely - but if it was, I think it could enable many more users to participate in automated tests and remote development. That already was the hope of many coreboot related automated testing projects before. Wiring up some hardware isn't the problem. Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Automated test system: Nominations wanted
On Wed, Feb 18, 2015 at 3:14 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi, I am currently planning to set up a test system with 5 (later up to 10) machines boot testing each new coreboot commit. This test system will be serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours. Current goals for every commit: - Check if coreboot + SeaBIOS are able to boot Linux to a point where network is up and running Current goals for every work day: - Check if screen, keyboard and touchpad/mouse work - Check if USB works and has the expected transfer speed (i.e. if USB High and Super Speed both work) Future goals for every work day: - Run memtest86+ (short run) - Run GRUB2 and boot Linux - Check if USB works (see above) Once any test running once per work day can be automated with reasonable effort (i.e. not requiring robots or human interaction), it can be moved to a per-commit goal. The selection of target systems should include: 1. at least one x86 laptop without an active ME (present but inactive would be OK) 2. at least one x86 laptop which can boot x86-blob-free (except microcode) 3. at least one x86 board or laptop which needs neither blobs (except microcode) nor ME 4. at least one x86 board with reasonable (past or present) business market penetration 5. if the first two laptops use the same CPU vendor, a board using a different x86 CPU vendor Hi Carl-Daniel, Thanks for setting this up. I think it would be great to have Qemu and a couple of the boards supported by SimNOW. They don't really fit into your categories, but it is important to keep them working. Thanks, Myles 1+2 are designed to partially remove the potential for nasty surprises, 3 should remove nasty surprises completely, 4 is the one I need to show that the test system is actually relevant for our goals, 5 should give us better coverage outside the most common systems used by coreboot developers. Please nominate machines (e.g. Thinkpad T60 with Intel graphics) and tell me to which category they belong. If a system fits into multiple categories, please specify that as well. I will try to consolidate the recommendations and buy those machines. Once the system is up and running (hopefully in May), I will add more machines suggested by the community as time permits. The time window for suggestions will close at the end of February. Fire away! Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
