Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

2018-01-03 Thread Werner Zeh
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

2015-11-16 Thread Werner Zeh

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

2015-02-21 Thread Werner Zeh

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

2015-02-19 Thread Werner Zeh
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

2015-02-18 Thread Werner Zeh
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

2015-02-09 Thread Werner Zeh
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

2014-12-15 Thread Werner Zeh
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

2014-11-04 Thread Werner Zeh

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

2014-11-03 Thread Werner Zeh via coreboot

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

2014-10-15 Thread Werner Zeh

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

2014-10-08 Thread Werner Zeh



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

2014-09-09 Thread Werner Zeh


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

2014-09-08 Thread Werner Zeh
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