Does anyone have a view on the state of xHCI on baytrail_fsp platforms?
I've enabled xHCI ( and disabled eHCI ) in devicetree.cb, but the resulting build with SeaBIOS as a payload will not go further than displaying the SeaBIOS header string.
With both xHCI and eHCI enabled in devicetree.cb - which the comments in that file say I should not do - SeaBIOS loads, and can recognize a DVD drive attached to a USB3 USB hub.
I'm not sure whether this is a safe combination, or whether there are other settings I should change.
Cheers,
Mike
On 30.05.2014 17:47, Charles Devereaux wrote:
> Hello
>
> I recently purchased a x60s tablet to learn more about coreboot, and
> how to make the boot process as fast as possible. The wacom
> capabilities are important as this machine will also be used to take
> notes - so I figured I would just apply the patches for the video fix
> and serial ports support
>
> I applied in this order:
>
> - the video fix described on http://www.libreboot.org/howto.html :
> $ git clone http://review.coreboot.org/coreboot
> $ cd coreboot
> $ git fetch http://review.coreboot.org/coreboot refs/changes/20/5320/6
> && git checkout FETCH_HEAD
> $ git fetch http://review.coreboot.org/coreboot refs/changes/45/5345/1
> && git cherry-pick FETCH_HEAD
>
> In src/mainboard/lenovo/x60/devicetree.cb, change register
> "gpu_backlight" = "0x1280128" to register "gpu_backlight" = "0x879F879E"
>
> - the motherboard recon (needed by serial port)
> on http://review.coreboot.org/#/c/5246/5
>
> git fetch http://review.coreboot.org/coreboot refs/changes/46/5246/6
> && git checkout FETCH_HEAD
>
> - the serial port on http://review.coreboot.org/#/c/5239/ :
>
> git fetch http://review.coreboot.org/coreboot refs/changes/39/5239/17
> && git checkout FETCH_HEAD
>
> - the irda fix on http://review.coreboot.org/#/c/5242/:
>
> git fetch http://review.coreboot.org/coreboot refs/changes/42/5242/15
> && git checkout FETCH_HEAD
>
> Problem is, after running the sequence of git commands, the video fix
> is gone.
>
> I created a new branch as suggested by git to keep the patches (git
> branch new_branch_name ....), but since I never played with git before
> I guess I did something wrong.
>
> I could take the patches and manually apply them (in fact I'm about to
> do that!), but I wonder what is the proper way to do it - and also if
> I'm missing any important recent patch not mentioned in the online guides.
>
> Also, would anyone here already have a .config for a more or less
> kernel finetuned (ie no useless peripherals or modules) for a x60
> using coreboot? Starting from a good base would save some time.
I tried this last month. I cherrypickt everything execpt the video fix
and got a working coreboot.
Sadly i could not bring the wacom to work but i'm not sure if its a
problem of coreboot or linux.
As soon as i'm at the place where the maschine is i will copy my image
and the patched coreboot
so you can have a trie with it. I assume this won't happen bevor end of
the week.
>
> Thanks for any help !
cheers derpeter
>
>
>
Hi folks, first time posting here. I was wondering if it would be
possible to modify smbios values once a system is up and running. Has
anyone ever looked into that? If not, any pointers on how to implement
this would be greatly appreciated. I'm fairly new to coreboot but would
like to look into this.
This is with coreboot + seabios, btw.
Thanks,
Rafael
Hi Marc,
There is indeed a port80 4 digit hex display on that board, so Gerald
should be getting something from that.
Hi Gerald,
If you had serial output from the BIOS, then I think you probably have
the UART connected properly. I always use the microUSB connector,
though, with a standard phone cable to get serial from those boards. It
has an on-board usb to serial adapter. Coreboot usually sets baud rate
to 115200, but it is configurable. Check your .config:
CONFIG_CONSOLE_SERIAL=y
CONFIG_TTYS0_BASE=0x3f8
CONFIG_CONSOLE_SERIAL_115200=y
CONFIG_TTYS0_BAUD=115200
CONFIG_TTYS0_LCS=3
CONFIG_POST_IO=y
CONFIG_POST_DEVICE=y
CONFIG_POST_DEVICE_NONE=y
CONFIG_POST_IO_PORT=0x80
Regardless of these settings, FSP will send info to the port80 so
something should have shown.
Other things you can check:
1) Properly configured FSP for BayleyBay with the bct program. BayleyBay
is a non-ECC RAM board and won't boot with ECC FSP.
2) Have the appropriate microcode for your stepping of CPU. B0 steppings
are harder to get correct and the microcode is not in git.
Cheers,
Sean
On 06/11/2014 03:04 AM, Marc Jones wrote:
> Gerald,
>
> Does the crb have a port80? You should get early postcodes from
> coreboot and the FSP. You are also correct that there might be
> something different in the descriptor.bin that isn't anticipated. You
> may want to use the coreboot util/ifdtool to get a look at the entire
> image.
>
> Marc
>
>
> On Tue, Jun 3, 2014 at 6:03 AM, Gerald Otter <gerald.otter(a)gmail.com> wrote:
>> Hi all,
>>
>> I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far.
>> This crb uses the bay trail I (now atom e3800) soc from intel.
>>
>> Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact.
>> I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2.
>> Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
>>
>> The issue I’m running into is that I have no idea if anything is running at all.
>> There is no output on the VGA/HDMI ports or uart.
>>
>> The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image.
>> I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar.
>> The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly.
>> Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
>>
>> I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
>>
>> Thanks in advance!
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
On 6/4/2014 1:06 PM, Duncan Laurie wrote:
> On Tue, May 27, 2014 at 3:17 PM, Matt DeVillier
> <matt.devillier(a)gmail.com> wrote:
>> Greetings,
>>
>> I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg.
>>
>> I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit.
>>
>> CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference. The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect.
>>
>> Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue.
>>
>> Appreciate any pointers on how to proceed
>>
> USB/XHCI devices disconnecting in the kernel before the system goes to
> suspend suggests it may be an intentional OS (via udev?) action.
> Which distro are you using?
>
> I think the panther mainboard has not been upstreamed yet so I assume
> you are using a checkout from the chromium coreboot? Or is this
> pulling the chromium panther mainboard into the upstream coreboot?
>
> Here are a few things to check:
>
> - Is there an XHCI device visible (and set as enabled) in
> /proc/acpi/wakeup output?
>
> - When you go to suspend what does the kernel print about XHCI
> controller itself? (ignoring the devices for the moment)
>
> I would expect to see lines like this before it actually goes to suspend:
>
> xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
> xhci_hcd 0000:00:14.0: power state changed by ACPI to D3cold
>
> And then after resume:
>
> xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
> xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
>
> In an attempt to debug further it could help to send some additional output:
>
> - dmesg after a suspend/resume cycle
> - /sys/firmware/acpi/tables/DSDT (after run through iasl -d) I don't
> expect issues here if wake-on-lan is working, but worth a check.
>
> Thanks,
> -duncan
Hi Duncan,
I'm currently testing on OpenELEC 4.0.4 (k 3.14.5, 3.15.0) and Ubuntu 14.04 (k 3.14.1).
This is using upstream coreboot with the panther mainboard info pulled from the panther chromium branch. I also pulled over any changes to the northbridge/haswell and southbridge/lynxpoint directories that hadn't made it back upstream yet.
'cat /proc/acpi/wakeup' shows the xhci controller as enabled, as does 'cat /sys/bus/usb/devices/<dev #>/power/wakeup' for all connected devices.
dmesg shows the following prior to entering suspend:
xhci_hcd 0000:00:14.0: remove, state 4
usb usb2: USB disconnect, device number 1
xhci_hcd 0000:00:14.0: USB bus 2 deregistered
xhci_hcd 0000:00:14.0: remove, state 1
usb usb1: USB disconnect, device number 1
usb 1-2: USB disconnect, device number 2
usb 1-4: USB disconnect, device number 5
usb 1-5: USB disconnect, device number 4
xhci_hcd 0000:00:14.0: USB bus 1 deregistered
<snip>
PM: Entering mem sleep
and coming out of resume, nothing xhci related prior to 'PM: Finishing wakeup.'
afterwards, it re-inits the xhci controller identically to at boot:
xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
etc etc. Nothing related to setting the power states either prior to or after suspend.
thanks,
Matt
Hi all,
I am trying to run coreboot + seabios payload on the bayley bay crb with the recently committed FSP integration, but have had no luck so far.
This crb uses the bay trail I (now atom e3800) soc from intel.
Following the instructions from commit d75800c7f , I have built a 2MB image and flashed it to the upper 2MB of the 8MB flash, leaving the TXE / flash descriptor intact.
I have added the config from the build. The FSP I used is BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014, together with the flash descriptor and TXE from the 80.21 bios provided by intel, and vga bios 36.2.2.
Fwiw, I have tried both the 32bit and 64bit releases of the bios, even though the flash descriptor and TXE binary seem to be exactly the same.
The issue I’m running into is that I have no idea if anything is running at all.
There is no output on the VGA/HDMI ports or uart.
The legacy uart referred to in the source is working correctly with the original intel bios, but does not produce any output with the coreboot image.
I have tried the most common baud rates (115200, 19200, 9600 ) and did some measurements with a scope in case I got the baud rate wrong, but no cigar.
The uart I’m using is the PCU uart, as opposed to hsuart1/2 and the superIO uart. This matches with the configuration in coreboot when compared to the datasheet, so I’m assuming I got this set up correctly.
Unfortunately, this is about all the information I have, so I hope I am missing something obvious when building the image / flashing it, etc.
I have also used intel’s flash image tool (fitc) to build a complete image, thinking that maybe the flash descriptor needed to contain some specific information regarding the coreboot image (size/checksums), but given the original instructions I wasn’t surprised this didn’t work.
Thanks in advance!
Aaron Durbin wrote:
> Intel made a change to their driver to rely on the VBT for
> initializing the graphics device. The VBT is usually carried
> in the Video BIOS so that's where that dependency comes in.
It's not a horrible move.
What it means is that coreboot should grow a data model (have we
heard that before?) to expose the relevant data to the graphics
driver.
For compatibility it might be wise to use the legacy VBT format.
Perhaps we can do something clever with coreboot tables, like putting
the VBT into a table entry located in low memory.
//Peter
Dear coreboot folks,
following up on [1], could you please test latest Linux kernels (3.12,
3.13, 3.14, 3.15) on Intel based laptops and check if the Intel driver
is able to initialize the IGD [2] without a Video BIOS or coreboot’s
native graphics init? If you know if that was ever possible, for example
with Linux 3.2, that’d be also interesting.
Thanks,
Paul
[1] http://www.coreboot.org/pipermail/coreboot/2014-June/078104.html
[2] Integrated Graphics Device
Dear Ron,
Am Montag, den 09.06.2014, 20:18 -0700 schrieb ron minnich:
> Folks, do I correctly understand this regression is X60-only?
I only have confirmation on the Lenovo X60 [1]. I am not sure about the
Lenovo T60 and the Apple MacBook 2,1.
Unfortunately my requests for tests on other Intel hardware were not
heard yet.
> In that case, I suspect there will not be lots of interest in fixing
> it from the kernel side :-(
Well, luckily for us the Linux kernel has a no-regression policy. And
this is clearly a regression. Unfortunately the Lenovo X60 owners have
not bisected or reported this yet.
Thanks,
Paul
[1] http://www.coreboot.org/Lenovo_x60x_vgainit_todos#No_video_at_all_even_af...
Folks, do I correctly understand this regression is X60-only? In that case,
I suspect there will not be lots of interest in fixing it from the kernel
side :-(
sorry
ron
