Curt Brune | 29 Aug 01:08 2014

cbfstool, Linux trampoline and SeaBIOS

Hello -

First time poster, so take it easy on me :)

This is a great project -- I was able to get a kvm+coreboot+SeaBIOS
environment going pretty easily.  I started with the master branch of
coreboot and went from there.

I am having a problem trying to load a Linux kernel+initramfs cbfs
payload from SeaBIOS.  I can successfully boot the same
kernel+initramfs straight from coreboot (without SeaBIOS) as a
payload.

I started this topic on the SeaBIOS list -- there's a lot of good
background in the replies there:

  http://www.seabios.org/pipermail/seabios/2014-August/008215.html

I now think my problem lies in the cbfstool and the Linux trampoline.

Summarizing the analysis from those posts: the Linux trampoline code
does not set up the segment descriptors for __BOOT_CS and __BOOT_DS as
described in the Linux kernel documentation:

  ... a GDT must be loaded with the descriptors for selectors
  __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G
  flat segment; __BOOT_CS must have execute/read permission, and
  __BOOT_DS must have read/write permission;

Now in the working coreboot case it turns out the segment descriptors
(Continue reading)

Todd Weaver | 27 Aug 23:16 2014

New board with unsupported cpu, chipset, and superIO


It appears (from following the instructions) that I have a new board
with unsupported cpu, chipset, and superIO.

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06)
00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev
05)

From this page:
http://www.coreboot.org/Developer_Manual#Supporting_a_new_board_with_a_unsupported_cpu.2C_chipset_or_superIO

It appears "If it is not supported by coreboot then you will have a lot
of work in front of you."

What I need to find out is:

a) If it is even possible to get coreboot to work with this board?
b) How much time would it take to get coreboot to work with this board?
c) If there is any coreboot developers that would be willing to contract
for hire to develop coreboot for this board?

It is a requirement to replace the bios with coreboot, so I am tasked
with making sure it is possible (a), a rough idea of how long (b), and
if we can hire somebody to develop it (c).

I appreciate any replies to any parts of the above, and I am hopeful
somebody would be able to have the time needed to get paid to get
coreboot onto this board.

(Continue reading)

ron minnich | 27 Aug 18:43 2014
Picon

apologies in advance for a question I may have asked

I need to set up qemu with a 64MiB ROM.

I figure supporting EFI has made QEMU capable of such things, but if
anyone has direct experience with this, please let me know. I tried it
a few years back (2008) and it did not work at all ... I guess worst
case I can make an NE2000 "device" with a giant ROM, but I'd prefer to
just do it with a 64MiB device at top of 4GiB address space.

TIA

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Mike | 27 Aug 13:44 2014
Picon

for more working mainboards

treacherous computing, like amd trustzone...
http://www.arm.com/products/processors/technologies/trustzone/index.php

... could spawn all over.  We have to stop this by giving end users more 
purchasing choice.

Someone suggested that fsf actually produce mainboards without it. 
Sounds like a plan.  Is fsf up to it?  Are they willing to sign NDAs?

If not, then we should start a company to do the mainboards.  Producing 
amd/intel/etc boards.

The current coreboot code would be fully applicable, and the mainboards 
would ship with coreboot.  At least, coreboot might disable trusted 
computing functionality.

Agree?

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Wen Wang | 26 Aug 22:09 2014

Rangeley reset

Hello,

Has anybody tested reset signal (PMU_RESETBUTTON_B) on Rangeley/Avoton? The
board seems to shut down after asserting the signal (pushing the reset
button). I turn on an LED in early_mainboard_romstage_entry(). The LED was
not on indicating the function was not executed. Below is what printed out
on console after reset:

coreboot-0f49404 Tue Aug 26 15:28:40 EDT 2014 starting...
POST: 0x41
POST: 0x42
Setting up static southbridge registers... done.
Disabling Watchdog timer... done.
RTC Init
POST: 0x46
POST: 0x47
Starting the Intel FSP (early_init)
Configure Default UPD Data
PcdEnableIQAT 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableUsb20 1
PcdEnableSata2 1
PcdEnableSata3 1
find_current_mrc_cache_local: No valid fast boot cache found.
FSP MRC cache not present.

For cold boot, it will continue to spit out boot messages.
(Continue reading)

ron minnich | 25 Aug 23:28 2014
Picon

disabling bios usb stack

A friend asks me how to disable the usb stack in his bios. I have no
clue, anyone?

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

ron minnich | 25 Aug 19:44 2014
Picon

AMD PSP

I'm utterly ignorant of the PSP -- is this thing like the Intel ME,
and how scared should we be of it?

Is it as closed off and mysterious?

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

The Gluglug | 25 Aug 17:50 2014
Picon

bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.


Using 6725 to enable text-mode gfx init on X60 when using native
graphics initialization.

Affected machines: X60, T60.
It may also affect: macbook21/macbook11, X60 Tablet

This relies on the (merged) patch 6723 that enables text-mode graphics
initialization on i945 platforms. The code is there.

I then disabled "Keep VESA framebuffer" in menuconfig, to enable
text-mode.

error: no video mode activated
This is what I see when I try to use the net install iso for Debian
with the isolinux parser in grub.
I also saw the same thing when trying to start Trisquel 6 isolinux
menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from
seabios's rom that I built).

See attached image of what happens when I try to boot the net install
from Debian (same thing happens with the Trisquel net install), using
the following:
linux (usb0)/install.386/vmlinuz
initrd (usb0)/install.386/initrd.gz
boot

As you can see, there is quite a lot of flicker and parts of the
screen are missing or corrupt. I think this is related to the issue
above ("error: no video mode activated").
(Continue reading)

The Gluglug | 25 Aug 17:49 2014
Picon

bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.


Using 6725 to enable text-mode gfx init on X60 when using native
graphics initialization.

This relies on the (merged) patch 6723 that enables text-mode graphics
initialization on i945 platforms. The code is there.

I then disabled "Keep VESA framebuffer" in menuconfig, to enable
text-mode.

error: no video mode activated
This is what I see when I try to use the net install iso for Debian
with the isolinux parser in grub.
I also saw the same thing when trying to start Trisquel 6 isolinux
menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from
seabios's rom that I built).

See attached image of what happens when I try to boot the net install
from Debian (same thing happens with the Trisquel net install), using
the following:
linux (usb0)/install.386/vmlinuz
initrd (usb0)/install.386/initrd.gz
boot

As you can see, there is quite a lot of flicker and parts of the
screen are missing or corrupt. I think this is related to the issue
above ("error: no video mode activated").

The net install for Debian and Trisquel both work when using
corebootfb initialization method, but they fail (as seen in the image)
(Continue reading)

Charles Devereaux | 25 Aug 05:25 2014
Picon

x60 : trying to boot to a debian in less than 2 seconds

Hello

I'm still trying to improve boot time.

After some further optimizations (previous results : 2.2s for the kernel, 0.6s for the daemons),  I believe it should be possible to get a command line in less than 2 seconds, since most of the time is spend re-initializing the video chip (almost a full second) while there are some features to prevent just that.

It seems that coreboot is spending some time initializing the video chip for grub, then linux spends some time again - even when grub option "set gfxpayload=keep" is set (which should prevent that) and when coreboot is compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE

in kernel 3.10.45 :
[    0.291014] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit ban
ging on pin 3
[    0.321926] [drm] initialized overlay support
[    0.384013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit bangi
ng on pin 2
[    0.570068] fbcon: inteldrmfb (fb0) is primary device
[    1.230010] Console: switching to colour frame buffer device 128x48
[    1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    1.258984] i915 0000:00:02.0: registered panic notifier
[    1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I'm currently trying a recent kernel since some i915 patches have been backported (cf http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html), introducing the i915.fastboot option to do just that, but it does not help.

I must be doing something terribly wrong, but I just don't realize what exactly.

Has anyone succeeded in keeping the vesa mode?

Charles
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Charles Devereaux | 25 Aug 04:39 2014
Picon

IBM x60t test - DSDT is in fact incomplete

Hello

Previously (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I mentioned that 3 bugs seemed to be related to the DSDT:
 - missing ACPI events when the stylus is inserted/removed
 - errors when trying to make the leds blink with tpacpi
 - errors during TPM initialization

The first bug is x60t specific, but the other 2 should also affect the other x60 models.

At the moment, I'm trying various kernel to see how boot time can be improved, and took 5 minutes to test with a custom DSDT table created from acpi_3.rom (extracted with bios_extract, then decompiled into a dsl, then recompiled into a hex file (see for ex https://wiki.archlinux.org/index.php/DSDT)

I do confirm this fixes both the stylus (I now get ACPI events) and the blinking leds issues (they now blink just fine), which confirms these bugs come from missing entries in coreboot DSDT, and can be corrected by fixing it.

However, since the factory DSDT causes other issues (such as the CPU running quite hot and wake-up issues) I do not recommend using the factory DSDT, even as a temporary solution.

Ideally, the DSDT should be fixed within coreboot, but this goes beyond my present abilities. Alternatively, I plan to release a patched x60t DSDT for use with libreboot.

Charles
[PS: I forgot to test the TPM module, but it should also work now]

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Gmane