Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
Hi Ian. First of all I want to clarify some things so that all of us have the same understanding: 1. On our current coreboot-based products we just use coreboot itself with no other payload (e.g. SeaBIOS). We use instead a Linux as a payload which is self-tailored for every dedicated mainboard. 2. The vast majority of our products is sold to OEMs. 3. We provide the OS to the OEM which remains the one and only OS in the system. The OEMs uses our OS and it's provided interfaces to build his own applications on top of it. 4. Every mainboard/hardware belongs to a complete system which will in any case have a way to show informations to the end-customer (it might be a LCD-panel, a VNC-connection or a dedicated engineering system which is able to communicate with the devices). > With a few minutes spent looking, it is not at all clear to me how Siemens handles their GPL responsibility and whether they attempt to provide compliance for their customers or not. The way we decided to deal with the GPL-obligations is: 1. Make sure all our mainboards are on master! We always build the final image based on the latest master. Of course one version freezes the time it is released while master keeps going forward. But one can easily get the git-commit which was the latest once the version has been released (by looking at the console output for example). 2. Provide a screen (very similar to your About-Screen) on the system where every one who is interested in can see all the needed informations (version, licenses, ...). The information is gathered in a text file which is located in the CBFS on the flash. Therefore this information is bound to the hardware itself. We do provide a built-in text-viewer so that one can see all the information when ever there is a need for it. So if there is someone out there who wants to run its own copy of coreboot on our hardware: Go to coreboot.org, get the latest tree, select the matching mainboard and...make! Beside the fact that you will loose the warranty if you install your own firmware (which was not verified by Siemens) on our hardware you are free to go! Do I oversee something? Werner signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Long boot delay with a large CBFS
Hi Ben.
I currently use a Bay Trail design with 16 MB SPI flash
of which 14 MB are used for CBFS. I Never have seen such effects on my
system.
Do you use the latest coreboot tree (master)?
Werner
Am 16.11.2015 um 19:32 schrieb Ben Gardner:
[The previous email got chopped. This is a re-send.]
Hi all,
I have a 16 MB BIOS flash on a fsp_baytrail based design.
I tried expanding the CBFS to fill the whole space, but found that to
cause a 10-15 sec boot delay.
The offending code appears to be in cbfs_locate() in lib/cbfs.c:
if (memcmp(file.magic, CBFS_FILE_MAGIC, sizeof(file.magic))) {
offset++;
offset = ALIGN_UP(offset, CBFS_ALIGNMENT);
continue;
}
In SeaBIOS, the equivalent code does a break instead of a continue.
I'n not terribly familiar with the design goals of the CBFS.
What is the purpose behind continuing if a bad entry is encountered?
It appears that a 'bad' entry only occurs at the end of the CBFS.
Thanks,
Ben
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New interface for I2C in coreboot
Yes Patrick, you get me right. Why should we spread the work that can be commonly done by the I2C controller driver over several slave drivers. I was concerned of several issues on the I2C bus due to the following policy: I2C is a slow, low bandwidth bus, let us do the single transfers byte wise in the background task. This has two disadvantages: 1. If you have a serious bug and you have to look at the physical bus level to get a clue what is going on there, you have to capture a lot of time with an oscilloscope and your single transfers will be interrupted by huge gaps (because the transfers are spitted and other things happens in between). This makes it really hard to analyze. 2. There is a bigger chance to mess up the slave. If that is happen, you can get a hanging I2C bus. And in the worst case you will have to power-cycle your slave (and in the most cases your board as well) to get the slave in the working condition again. In my point of view, it is much better to keep transfers on I2C bus as close as possible together to avoid errors. Werner Am 20.02.2015 um 17:30 schrieb Patrick Georgi via coreboot: 2015-02-19 21:12 GMT+01:00 Peter Stuge pe...@stuge.se: 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. From discussing things with Werner, one of his concerns (as I understood them) was higher stability in light of picky I2C devices: When you schedule the entire communication in one pass, the (sufficiently capable) controller makes sure that things happen in the right order and at the right time. If some of that is arbitrated by CPU code, there's more room for error. Even for the I2C controllers that essentially bitbang things with no help by the controller chip, that should help avoid mistakes, since all the nasty warts of I2C (of which were seem to be many) are managed in the bus driver, not in every single slave driver. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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
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 for the old one (full write, full read, raw write and raw read). If that means we end up not using the do-everything-in-one-transaction feature of some controllers in favor of more controllable low-level accesses, I don't see a problem with that. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New interface for I2C in coreboot
Hi coreboot community. Although I am working on coreboot for now more than one year mostly behind the scenes I am fairly new on the contributor side. Yesterday, I have started contribution and one of my first value that I would like to give back to the community is a driver for I2C controllers that starts to get integrated into x86-chips from intel (Baytrail has one as well as X1000 Quark). Please be aware that this is not a driver for the well-known SMBus controller. I have written the driver a few weeks ago and at this time there was a pretty simple and therefore really generic interface for I2C buses in coreboot. The interface is described in src/include/device/i2c.h and was consist of two simple functions: i2c_read() and i2c_write(). With this interface the user of the driver (which in most of the cases will be another driver for let’s say an EEPROM) can simply call for instance the i2c_read()-function and provide as arguments the i2c-bus, the chip-address of the slave (EEPROM here), the address inside the slave, a length and a buffer where to store the driver. With these parameters, the I2C driver is able to read the desired data in one call and store them into the buffer provided. Similar procedure is for the write function. You can see that one logical transfer can be directly mapped to one function call of the driver (i2c_read or i2c_write). In mid-December 2014, the interface was changed massive by this two commits: 7947 and 7751. I have had a look at the new interface and what should I say: It is not only completely different (what in general would be OK for me) but it is in my point of view a step back. Let’s see what is happened here. The functions i2c_read() and i2c_write() where replaced by i2c_readb(), i2c_writeb(), i2c_read_raw() and i2c_write_raw(). The first two functions can read a single byte from a slave on a given register address (EEPROM address in my example here). The second two are meant to read a chunk of data from the slave. Both of the functions actually are a wrapper to call the real i2c driver interface called i2c_transfer(). But wait a moment…with the last two functions there is no way to tell the driver _where_ to start reading inside the slave. Let us have a closer look to how this interface can be used to transfer a chunk of data from a given address inside the slave. To do this, let us consider we want to read 10 bytes starting at offset 20. 1. Store the offset we need (in this case 20) into a buffer 2. Call i2c_write_raw(bus, chip_adr, buffer, 1); 3. Call i2c_read_raw(bus, chip_adr, buffer,10); Here are my personal problems with this kind of interface: 1. Where we earlier had one simple call to i2c_read(), we now have to fill one variable with the length we need and call two different functions (i2c_write_raw and i2c_read_raw). 2. Though the read transfer is one logical access to the slave, we have split it into two (without any benefit I can see now) 3. We have added two wrapper layers where we earlier had none! Unfortunately, the first two mentioned functions of the interface cannot be used for transferring more than byte because the length field is missing. In contrast, the two functions that have a length field do not have a slave address field. This is frustrating! If one have a hardware implemented I2C-controller in mind, this interface is really not that intuitive and simple. This is because we have to perform a function switch in the middle of a logical bus action. And: why should one perform i2c_write operation in order to read the data? This is not logical to me. I know that I2C bus works this way, but it is the responsibility of the driver to hide this from the user. And with this interface, this “hiding” is simply impossible because now the user have to do it! I do not see any benefits of this interface and I really cannot see the need for the introduced change in the interface. Of course it is technical possible to read and write data over I2C with this interface…but to be honest: I would not be proud of this solution! Of course we can add an address field to the i2c_read_raw and i2c_write_raw functions. But at the end we will end up with a complex interface for a very simple bus. And we will have several wrapper layers compared to the interface we had before. There is even no need of _one_ wrapper layer for this bus! I hope I was able to point out what my concern is about and want to discuss this with the community. I want to hear more opinions on this interface and at the end want to know whether it is worse to change my I2C driver to be used with this interface. The last point I will do if one can show me the _real_ benefit of the new interface. Thank you Werner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
Hi Kevin.
I have tried your fix but it doesn't help.
You can find a (huge) log with loglevel 5 here: http://pastebin.com/21rrAhfA
Werner
Gesendet: Donnerstag, 11. Dezember 2014 um 19:46 Uhr
Von: Kevin O'Connor ke...@koconnor.net
An: Werner Zeh werner@gmx.net
Cc: coreboot@coreboot.org, seab...@seabios.org
Betreff: Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the
hub
On Wed, Dec 10, 2014 at 07:21:54AM +0100, Werner Zeh wrote:
Hi all.
I have made some tests with SeaBIOS and XHCI and found, that on my board
(which is baytrail-based)
a USB3.0 hub won't work. For those who are familar with SeaBIOS I have
attached two
logfiles from SeaBIOS. One of them is with the USB3.0 flash drive directly
connected to one of the root ports of SoC
(in which case the boot process starts from the flash drive) and the other
is with the same flash drive but a USB3.0 hub in between
(I have used a hub from Delock #62534,
http://www.delock.de/produkte/F_247_extern_62534/merkmale.html). In the
hub-case, I see the
No bootable device screen and no boot will happen.
Maybe someone more experienced can see the cause from the logs.
?SeaBIOS (version rel-1.7.5-116-g56b252e-dirty-20141210_064921-deerlf0x73)
[...]
|1ad7d000| xhci_process_events: ring 0x1adcb200 [trb 0x1adcb200, evt
0x1adcb300, type 32, eidx 1, cc 1]
|1ad7d000| device rev=0300 cls=09 sub=00 proto=03 size=512
|1ad7d000| xhci_realloc_pipe: usbdev 0x1ad82bc0, ring 0x1adba600, slotid 4,
epid 1
[...]
|1ad7f000| xhci_process_events: ring 0x1adba600 [trb 0x1adba6c0, evt
0x1adba700, type 32, eidx 13, cc 6]
It looks like the hub is found, but responds with a stall error on
the get_hub_desc() request. Looks like usb3 hubs use a different
descriptor id. You could try the patch below - it's a lot of guess
work though.
-Kevin
diff --git a/src/hw/usb-hub.c b/src/hw/usb-hub.c
index c21cbfb..7688ef2 100644
--- a/src/hw/usb-hub.c
+++ b/src/hw/usb-hub.c
@@ -17,7 +17,10 @@ get_hub_desc(struct usb_pipe *pipe, struct
usb_hub_descriptor *desc)
struct usb_ctrlrequest req;
req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_DEVICE;
req.bRequest = USB_REQ_GET_DESCRIPTOR;
-req.wValue = USB_DT_HUB8;
+if (pipe-speed == USB_SUPERSPEED)
+req.wValue = USB_DT_HUB38;
+else
+req.wValue = USB_DT_HUB8;
req.wIndex = 0;
req.wLength = sizeof(*desc);
return usb_send_default_control(pipe, req, desc);
@@ -105,7 +108,9 @@ usb_hub_reset(struct usbhub_s *hub, u32 port)
ret = get_port_status(hub, port, sts);
if (ret)
goto fail;
-if (!(sts.wPortStatus USB_PORT_STAT_RESET))
+if (!(sts.wPortStatus USB_PORT_STAT_RESET)
+ (hub-usbdev-speed != USB_SUPERSPEED
+|| !(sts.wPortStatus USB_PORT_STAT_LINK_MASK)))
break;
if (timer_check(end)) {
warn_timeout();
@@ -119,6 +124,8 @@ usb_hub_reset(struct usbhub_s *hub, u32 port)
// Device no longer present
return -1;
+if (hub-usbdev-speed == USB_SUPERSPEED)
+return USB_SUPERSPEED;
return ((sts.wPortStatus USB_PORT_STAT_SPEED_MASK)
USB_PORT_STAT_SPEED_SHIFT);
diff --git a/src/hw/usb-hub.h b/src/hw/usb-hub.h
index 5b09947..f7436a5 100644
--- a/src/hw/usb-hub.h
+++ b/src/hw/usb-hub.h
@@ -11,6 +11,7 @@ int usb_hub_setup(struct usbdevice_s *usbdev);
/
#define USB_DT_HUB (USB_TYPE_CLASS | 0x09)
+#define USB_DT_HUB3 (USB_TYPE_CLASS | 0x0a)
struct usb_hub_descriptor {
u8 bDescLength;
@@ -48,7 +49,8 @@ struct usb_port_status {
#define USB_PORT_STAT_SUSPEND 0x0004
#define USB_PORT_STAT_OVERCURRENT 0x0008
#define USB_PORT_STAT_RESET 0x0010
-#define USB_PORT_STAT_L10x0020
+#define USB_PORT_STAT_LINK_SHIFT5
+#define USB_PORT_STAT_LINK_MASK (0x7 USB_PORT_STAT_LINK_SHIFT)
#define USB_PORT_STAT_POWER 0x0100
#define USB_PORT_STAT_SPEED_SHIFT 9
#define USB_PORT_STAT_SPEED_MASK(0x3 USB_PORT_STAT_SPEED_SHIFT)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
Great. It was my pleasure to help you :) Am 04.11.2014 um 18:49 schrieb Gailu Singh: Hi Werner, Thanks for your help and support. It was indeed due to wrong FSP. D0 stepping is installed and it only worked now with Gold3 FSP and updated microcode. Thank you very much. On Tue, Nov 4, 2014 at 12:48 AM, Werner Zeh werner@gmx.net mailto:werner@gmx.net wrote: Hi. Now you have coreboot running. coreboot searches for FSP, finds it and executes the first call into it. FSP returns with an error and what you see is this (taken from src/drivers/intel/fsp/cache_as_ram.inc): /* * Failures for postcode 0xBB - failed in the FSP: * * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode region. * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met. * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked */ So what you actually see is error code 0x07 from FSP. This can mean that your CPU is not supported by this FSP version. If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you have in advance a D0 stepping installed on your board, than you have to use GOLD3 FSP release as it was already mentioned. I had the same issue and it was due to missing D0-Support in GOLD1 release. So, I would suggest to try the right FSP-release from Intel. Bye Werner Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: With the changed TXE/descriptor, it moved ahead but now toggling between POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h and these POST codes are not defined there so I doubt that these are coming from coreboot code. Are these post codes coming from FSP code? If yes, How do I interpret them? Do I need to ask Intel? Any pointers please? On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com mailto:seanmcne...@gmail.com mailto:seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote: You mentioned just copying the .fd file, so I assumed it was being used directly in your coreboot image. FSP needs to be incorporated into flash, yes. It should, however, be patched with the BCT program as what is provided in the .fd is usually not patched with the a configuration that you desire. Thus you should run bct and configure/patch the .fd and generate a .bin to include into coreboot. I am a little confused by your email below. You state that you are not using the .fd directly then contradict yourself in the next sentence. Bottom line is I would not include any .fd file from the FSP archive directly. Use BCT to patch it and do not name it .fd. This avoids any confusion regarding whether you are including a patched FSP or not. Just because there is a bsf file included in the GOLD release doesn't mean that the .fd was patched with those settings and that it is valid. Best of luck to you. There are many issues you will have to resolve dealing with new hardware. I've gone through the process with a lot of support from Intel and it is not that easy. Especially when certain components found on the CRB are not provided on custom hardware. Cheers, Sean On 11/02/2014 08:01 PM, Gailu Singh wrote: Hi Sean, 1. This is not for a real project and we are trying to understand FSP interaction with coreboot to look at feasibility for considering coreboot in our future projects. Unfortunately I do not have board documentation so was not able to determine which one is serial port 0 though I know that port 0 is specified in coreboot config. That was the reason I was trying on all 3 available ports. 2. I am not using .fd directly. I believe that FSP need to be included in bootloader (coreboot in this case) and we are providing path to coreboot so that it can be included in coreboot. In my original post I only said that I copied .fd to a path expected by coreboot configuration. May I know how did you conclude that I am using it directly? May
Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
Hi. Now you have coreboot running. coreboot searches for FSP, finds it and executes the first call into it. FSP returns with an error and what you see is this (taken from src/drivers/intel/fsp/cache_as_ram.inc): /* * Failures for postcode 0xBB - failed in the FSP: * * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode region. * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met. * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked */ So what you actually see is error code 0x07 from FSP. This can mean that your CPU is not supported by this FSP version. If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you have in advance a D0 stepping installed on your board, than you have to use GOLD3 FSP release as it was already mentioned. I had the same issue and it was due to missing D0-Support in GOLD1 release. So, I would suggest to try the right FSP-release from Intel. Bye Werner Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: With the changed TXE/descriptor, it moved ahead but now toggling between POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h and these POST codes are not defined there so I doubt that these are coming from coreboot code. Are these post codes coming from FSP code? If yes, How do I interpret them? Do I need to ask Intel? Any pointers please? On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote: You mentioned just copying the .fd file, so I assumed it was being used directly in your coreboot image. FSP needs to be incorporated into flash, yes. It should, however, be patched with the BCT program as what is provided in the .fd is usually not patched with the a configuration that you desire. Thus you should run bct and configure/patch the .fd and generate a .bin to include into coreboot. I am a little confused by your email below. You state that you are not using the .fd directly then contradict yourself in the next sentence. Bottom line is I would not include any .fd file from the FSP archive directly. Use BCT to patch it and do not name it .fd. This avoids any confusion regarding whether you are including a patched FSP or not. Just because there is a bsf file included in the GOLD release doesn't mean that the .fd was patched with those settings and that it is valid. Best of luck to you. There are many issues you will have to resolve dealing with new hardware. I've gone through the process with a lot of support from Intel and it is not that easy. Especially when certain components found on the CRB are not provided on custom hardware. Cheers, Sean On 11/02/2014 08:01 PM, Gailu Singh wrote: Hi Sean, 1. This is not for a real project and we are trying to understand FSP interaction with coreboot to look at feasibility for considering coreboot in our future projects. Unfortunately I do not have board documentation so was not able to determine which one is serial port 0 though I know that port 0 is specified in coreboot config. That was the reason I was trying on all 3 available ports. 2. I am not using .fd directly. I believe that FSP need to be included in bootloader (coreboot in this case) and we are providing path to coreboot so that it can be included in coreboot. In my original post I only said that I copied .fd to a path expected by coreboot configuration. May I know how did you conclude that I am using it directly? May be that can give me some pointer. 3. I had checked the bsf file in the FSP kit with BCT tool and it is configured for non-ECC RAM, so I believe that no change is required in .fd. Am I wrong? 4. Yes, I agree that there is no documentation available on how to create entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe route I only touched upper 2 MB as recommended in one of the initial commit for baytrail FSP integration and some posts related to similar discussion. On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote: Coreboot and FSP are not as easy to understand as you can see. I also would suggest that you seek assistance from either Sage (who has good experience that I understand serves the USA and Europe markets and contributed the current Coreboot+FSP code) or perhaps a company in Asia such as Zien Solutions (of Vietnam). There are a number of issues that you are failing to understand: 1) As stated, the first serial port is actually connected to a
Re: [coreboot] coreboot Prague meeting - details
Hi Rudolf. Do you know from which time the hotel is accessible on Thursday? I just need to know if I can arrive at the hotel directly and leave my car there or if I should go to the university first. Thanks Werner Am 14.10.2014 um 13:31 schrieb Rudolf Marek: Hi all, Sorry for the noise I managed to exchange euros already. I did a favor to a colleague who needed urgently cash in CZK. If you need to exchange, I would try either ATMs or as I have written on wiki page the exchange8.cz (todays rate is 1 EUR =27.68 CZK) or any other exchange office where is acceptable ratio and no fees. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] X60: ethernet LED still on when machine is powered off or suspended
Is it possible that NIC is left on due to Wake on LAN feature? Is it enabled at all in your case? Werner Am 02.10.2014 um 06:45 schrieb Denis 'GNUtoo' Carikli: On Fri, 22 Aug 2014 02:22:01 +0100 The Gluglug i...@gluglug.org.uk wrote: Haven't tried it on factory.bin. Will let you know. i945 doesn't have ME/AMT, as far as I know. I remember reading about such things in intel datasheets. I remember (very vaguely) reading about the fact that i945 can have AMT, but that the BIOS flash has to be partitioned to allow that. I'm also unsure where would the AMT run, maybe in the NIC? In that case it may be able to fetch its firmware from a flash directly connected to the NIC, and it may have nothing to do with the BIOS flash, I really can't remember, sorry. In any case, all the lenovo i945 laptops that we have in coreboot are not setup for AMT. I should try to find the datasheets I was talking about, and document that since that question comes up way too often. Denis. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Linux-kernel as payload
Hi Ron.
Thank you for the command line suggestion.
My kernel was booting in qemu but I was not able to see output due to the
missing command line.
Especially the eralyprintk-thing helped me!
Now every thing seems to work just fine. There is no need to use mkelfImage.
Great, I love it!
Thanks guys
Werner
Gesendet: Montag, 08. September 2014 um 17:54 Uhr
Von: ron minnich rminn...@gmail.com
An: John Lewis jle...@johnlewis.ie
Cc: coreboot coreboot@coreboot.org
Betreff: Re: [coreboot] Linux-kernel as payload
As of last week, I am booting a bzimage+initramfs combination just
fine. bzimage will be fine.
It's a good idea to set the command line args, and I recomment, for testing
console=ttyS0,115200 earlyprintk=ttyS0,115200,keep
Your best bet is to do the standard trivial initramfs with a simple program:
main(){printf(hi\n); while (1);}
Let's pretend it's called mymain.c
cc -o mymain -static mymain.c
put that in your prototype root file system with the name init. make
sure you create /dev/console. Then bundle it all up with cpio and
you've got an initramfs
I can start some notes on the wiki if you're still stuck.
ron
--
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
[coreboot] Linux-kernel as payload
Hi. I try to use the linux kernel as payload in coreboot. I use a bzImage of the kernel. When I compile, I get the following message: OBJCOPY cpu/x86/smm/smm_wrap.ramstage.o CC generated/ramstage.o CC cbfs/fallback/ramstage.debug OBJCOPY cbfs/fallback/ramstage.elf CBFS coreboot.rom PAYLOAD ../bzImage (compression: none) E: The stage file is not in ELF format! CONFIG .config CBFSPRINT coreboot.rom coreboot.rom: 4096 kB, bootblocksize 848, romsize 4194304, offset 0x0 alignment: 64 bytes Name Offset Type Size fallback/romstage 0x0 stage 20906 fallback/ramstage 0x5200 stage 62994 fallback/payload 0x14880 payload 1392465 config 0x168840 raw 3366 (empty) 0x1695c0 null 2713240 Am I wrong assumimg that the image may be a real (compressed) bzImage? Should I use a vmlinuz better? Or is my bzImage is not suitable (maybe parts of it are compressed or so)? Thanks. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
