coreboot May 2014

coreboot@coreboot.org

39 participants
89 discussions

Fwd: [flashrom] A couple of bugs..
by Idwer Vollering 20 May '14

20 May '14

---------- Forwarded message ---------- From: Mike Hibbett <mhibbett(a)ircona.com> Date: 2014-05-20 14:06 GMT+02:00 Subject: [flashrom] A couple of bugs.. To: "flashrom(a)flashrom.org" <flashrom(a)flashrom.org> I spotted these two in yesterday’s code base. I’m not likely to commit code anytime soon so I will leave it to someone else to pick up if they are interested. src/vendorcode/intel/fsp/baytrail/include/fspplatform.h:78 Duplicate declaration of GetFspReservedMemoryFromGuid src/northbridge/intel/fsp_sandybridge/fsp/chipset_fsp_util.c:92 GetUpdDefaultFromFsp (fsp_ptr, fsp_upd_data);/home/martin/extra/git/coreboot Maybe martin would like to fix that one :o) Mike _______________________________________________ flashrom mailing list flashrom(a)flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom

1 0

Re: [coreboot] Booting an EFI OS
by ron minnich 20 May '14

20 May '14

I certainly like seeing the words 'mortem' and 'EFI' in the same email ;-)

1 0

Re: [coreboot] Booting an EFI OS
by Stefan Reinauer 20 May '14

20 May '14

* ron minnich <rminnich(a)gmail.com> [140514 19:22]: > what's an "EFI OS"? An OS that implements the UEFI standard, e.g. TianoCore / edk2 ;) This is under the assumption that every advanced boot loader eventually turns into an operating system. SCNR. Stefan

2 1

MMC support in libpayload
by Sean McNeil 19 May '14

19 May '14

Has anyone looked into this or made any effort to add MMC/sdcard support to libpayload? I need to be able to boot from eMMC connected to a PCI sdcard device and think that it would be very useful to have libpayload support. I found comments from Google about booting from eMMC for baytrail and I think they are using a u-boot payload, but I cannot find any effort that corresponds to this. It also looks like u-boot as a payload can only boot 32-bit kernels, so it seems limiting. Sean

2 1

build environment broken again
by Sean McNeil 19 May '14

19 May '14

Hi Patrick, The coreboot code is compiling, but FILO still does not: CC arch/x86/exec.libc.o gcc -MMD -Iinclude -Iinclude/x86 -Ibuild -D_LP64=0 -Icurses/PDCurses-3.4 -Icurses/pdcurses-backend -Icurses/menu -Icurses/form -Os -pipe -nostdinc -nostdlib -fno-builtin -ffreestanding -fomit-frame-pointer -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wstrict-aliasing -Wshadow -c -o build/arch/x86/exec.libc.o arch/x86/exec.S <command-line>:0:0: warning: "_LP64" redefined [enabled by default] arch/x86/exec.S:1:0: note: this is the location of the previous definition /* ^ arch/x86/exec.S: Assembler messages: arch/x86/exec.S:43: Error: invalid instruction suffix for `push' arch/x86/exec.S:45: Error: invalid instruction suffix for `push' arch/x86/exec.S:52: Error: invalid instruction suffix for `push' arch/x86/exec.S:53: Error: invalid instruction suffix for `push' arch/x86/exec.S:54: Error: invalid instruction suffix for `push' arch/x86/exec.S:61: Error: invalid instruction suffix for `push' arch/x86/exec.S:62: Error: invalid instruction suffix for `push' arch/x86/exec.S:70: Error: invalid instruction suffix for `push' arch/x86/exec.S:73: Error: operand type mismatch for `call' arch/x86/exec.S:81: Error: invalid instruction suffix for `pop' arch/x86/exec.S:91: Error: invalid instruction suffix for `pop' arch/x86/exec.S:92: Error: invalid instruction suffix for `pop' arch/x86/exec.S:93: Error: invalid instruction suffix for `pop' arch/x86/exec.S:97: Error: invalid instruction suffix for `pop'

1 0

build environment broken again
by Sean McNeil 19 May '14

19 May '14

I am not sure if this is only for CONFIG_ANY_TOOLCHAIN=y, but builds are not working again for me. This time I don't think it is some addition I am missing: The first problem seems to be that the wrong libgcc.a is found. I think toolchain.inc is missing flags: LIBGCC_FILE_NAME_$(1) = $(wildcard $(shell $(CC_$(2)) $(CFLAGS_$(2)) -print-libgcc-file-name)) Next, it would appear that the smm stage is still using 64-bit code: /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 (build/arch/x86/lib/memcpy.smm.o) to format elf64-x86-64 (build/cpu/x86/smm/smm.o) is not supported Looks like in src/cpu/x86/smm/Makefile.inc the CC_smm is not correct. $(obj)/cpu/x86/smm/smm.o: $$(smm-objs) $(LIBGCC_FILE_NAME_smm) $(CC_smm) $(LDFLAGS) -nostdlib -r -o $@ -Wl,--wrap,__divdi3 -Wl,--wrap,__udivdi3 -Wl,--wrap,__moddi3 -Wl,--wrap,__umoddi3 -Wl,--start-group $(smm-objs) $(LIBGCC_FILE_NAME_smm) -Wl,--end-group Cheers, Sean

2 2

Testers needed -native gpu init + backlight controls - X60 Tablet (1400x1050) and T60 14" (Intel GPU) 1400x1050
by The Gluglug 18 May '14

18 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 title says all -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTeI/pAAoJEP9Ft0z50c+U9KYIAL/N8z+XOWqSyemCPAiqWzdL hLa6Ye9Y7Z7SUxSlkIbarFnk1qPYO2IoFWGYGUNHG90sQT2lMAqMXuGkF9FvoXKn PtkWS73wtbhVXckafC0QkbMWyrPJ/kp9GORjaSWHGAXZn02AwrgtqwTdGWCfp+3S nbE7xpVFNikpr+6earHdUs44BVK3e3Q0Grcb/G+PTTHP4bow8vu89qcSe9mV+Gb7 DOwJEb5wLHUhAjhupQhy2zeSEjy+szUlGOEAYZITaPs0lAxt58lbmWt92iHME9uC vaYVYMGLnreUcbsmA1ZtFAEhCIUC6csSTlndG4U7i2gVBvwqI61fk2w5WnSmAHw= =8PXB -----END PGP SIGNATURE-----

1 0

results (testing 5345 with oprom trace)
by The Gluglug 16 May '14

16 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Testing 5345 for phcoder. <fchmmr> I bricked the T60. <fchmmr> I can't see anything. <fchmmr> 2002 git clone http://review.coreboot.org/coreboot <fchmmr> 2003 git fetch http://review.coreboot.org/coreboot refs/changes/45/5345/1 && git checkout FETCH_HEAD <fchmmr> 2004 cd coreboot <fchmmr> 2005 git fetch http://review.coreboot.org/coreboot refs/changes/45/5345/1 && git checkout FETCH_HEAD <fchmmr> 2006 wget http://minifree.org/vgarom.bin <fchmmr> 2007 ls -l <fchmmr> 2008 make menuconfig <fchmmr> 2009 make <fchmmr> (that url is where i put it to transfer it to my X60, which i used to compile the rom) <fchmmr> then i added grub.elf to the coreboot directory <fchmmr> here is my .config: <fchmmr> <fchmmr> http://paste.debian.net/100059/ (from IRC) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTdn5LAAoJEP9Ft0z50c+UkL0IALo7eXnqo43QbK6/1ZSgaPHw 7yRmfoaZIqPha4O7SZfO+G8Jz8MldpAg2vvR3grsiXx2S8GCFAX5Ykuvh0+wlTQy A61qj33nAH1irCq3BOpp7ukBDv0Xn1wIcB9S5XPkGLX1FQcZEgLK7a5OJ29Dx40v JtcRpTQmvrK5gCNrBF0Ab8t+JqBjKtATCkPnGybg/64caJ3snklmDPLktSrFSJGo rzwAgxXgsB2YrjKZ3TtXwoHGDR19cYYrCllL3d19ZLylTyKrP3dyqFveNht6DAqp YyLUoHUtqKoW0NPYvUxo4s2VZHCC0fcfAYVooUlX/io2+hAXS7pb1fm93utPBGs= =YD6x -----END PGP SIGNATURE-----

1 0

backlight controls working on X60 without vga option ROM (using native graphics instead)
by The Gluglug 15 May '14

15 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tested in current libreboot. should work in coreboot (using changeset 5320 or a rebase). <fchmmr> hey you! <fchmmr> I just got backlight controls working PERFECTLY <fchmmr> on an X60, running libreboot with native graphics init instead of vga oprom <fchmmr> Fn keys, that is. <fchmmr> it'll also work in coreboot (using change set 5320) <fchmmr> how i did it: <fchmmr> run coreboot on X60 with vgarom <fchmmr> do that to read from that address at each brightness level: <fchmmr> sudo devmem2 0xe4361254 w <fchmmr> it came back with 0x879F879E every time <fchmmr> so then I tried: <fchmmr> sudo devmem2 0xe4361254 w 0x879F879E <fchmmr> writing 0x879F879E to address 0xe4361254 <fchmmr> and then I try the Fn keys for brightness controls on the X60 <fchmmr> now it works. <fchmmr> brightenss controlls work <fchmmr> this is amazing. Yay! So: that address should be written with that value, by coreboot, at boot time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTdS0UAAoJEP9Ft0z50c+UdmkH/3G+I7NzMEWoTofSKVu3fUv4 DtoYhozX5GW7lnHGSoddgtn7SmYAtbbDucAZniXwfluRSpl/g44yTwKbvMh0So5O +zM3LED/f6NNifgmH3jTn8Shz2EsqN3medC8kKi912EpEhMhbvUlW3FoRkXMrCOM 7QXkJFbnh/zN0sJ3ffDJ0B1ZFkPSHIAfdkIljDL83RCHz+TZ9vXzjS2BKcFgXwOp 6MrdHaMrO1PtRl+XHCg4k0a/ego00LUjE5fP8cZRfL1vXTPya7KibCiOomlhs5/w kAPMHXy4G+nfrB1x/NtCW0LysmadasXylxPlNGwrrCKAsiI6BrpowQMOiSWcVIc= =Aaz0 -----END PGP SIGNATURE-----

1 3

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
by Scott Duplichan 14 May '14

14 May '14

ron minnich [mailto:rminnich@gmail.com] wrote: ]On Tue, May 13, 2014 at 5:29 AM, Peter Stuge <peter(a)stuge.se> wrote: ] ]> That's an important question, but I believe the answer is no. ] ]That's all I wanted to know, to start. ] ]So why don't we just get that CL in and see where we go from there. ] ]Thanks all. And sorry if I was too hard on kolibrios. It's totally ]wonderful that they are building a from-the-bottom-up OS that gives ]people a close view of how things really work. ] ]ron Thank you and everyone for all the ideas and suggestions. Rudolf pointed out that coreboot already has an option for setting up the PCI config space 3C register: CONFIG_PIRQ_ROUTE. This initially looked like the proper way to enable the PIC mode routing code. On the other hand, experiments suggest this might not be the best way to do it. Testing Ubuntu with the E350M1 OEM BIOS gives these results for the south bridge SATA controller: grub options: acpi=off noapic debugger: clear SATA controller 3C register before Ubuntu boot. result: ahci 0000:00:11.0: can't find IRQ for PCI INT A; please try using pci=biosirq irq 10: nobody cared (try booting with the "irqpoll" option) Disabling IRQ #10 ata4.00: qc timeout (cmd 0xa1) grub options: acpi=off noapic debugger: clear SATA controller PIC routing before Ubuntu boot. result: SATA operation is extremely slow. Apparently the SATA ISR is called occasionally due to interrupt sharing. In PIC mode with acpi=off, the OS can only look at the MPS table or PIR table for interrupt info. These don't tell the OS what interrupt BIOS has assigned. In addition, the tables don't give enough info to allow the OS to program the interrupt itself. So to make Ubuntu work in PIC mode using MPS or PIR tables, both the 3C register and SB routing register must be setup by BIOS. This leads to an argument that CONFIG_PIRQ_ROUTE shouldn't exist. Instead, the PIC routing and 3C reporting should be done any time the MPS or PIR tables are included. Thanks, Scott

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2014