April 2016 - coreboot - mail.coreboot.org

Re: [coreboot] coreboot 4.4 release coming soon
by Jonathan Neuschäfer April 20, 2016

April 20, 2016

On Thu, Apr 14, 2016 at 04:46:06PM -0600, Martin Roth wrote: > Hi Everyone, > We're planning on doing the coreboot 4.4 release in the next week or so. > > We'd like to request some help with testing platforms both ahead of > the release and when the release actually happens. If you have a > board in the coreboot tree, please try doing a build to help us verify > what's working and to let us know about anything that isn't working. I did a few tests with coreboot 4.3-774-g7fae59b on virtual platforms, because I don't have any hardware supported by coreboot. QEMU 2.5.0, QEMU x86 i440fx/piix4 mainboard ------------------------------------------- SeaBIOS/Linux boots fine, but cbmem fails with "Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory". I did all x86 tests with Debian's kernel 3.16. QEMU 2.5.0, QEMU x86 q35/ich9 mainboard --------------------------------------- SeaBIOS/Linux boots fine, but cbmem fails with "Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory". For some reason QEMU periodically generates NMIs: - In Linux this is printed every 30 seconds: [ 36.836053] Uhhuh. NMI received for unknown reason 30 on CPU 0. [ 36.836053] Do you have a strange power saving mode enabled? [ 36.836053] Dazed and confused, but trying to continue - SeaBIOS prints handle_02 - Coreinfo logs the NMI and dies. - If I first boot Linux and then reboot into coreinfo, the NMIs do not occur (maybe Linux disables them on reboot). QEMU riscv (v2.5.0-9-gb0cf38d + a few patches) ---------------------------------------------- In short: It doesn't work. I can get coreboot to boot in QEMU up to the "payload not loaded" message with a few patches: - I patched QEMU to not trap unaligned memory accesses - I patched coreboot to use the HTIF console instead of a 8250 UART memory-mapped at 0x3f8. - Both the write_msr(tohost, ...) interface and the memory-mapped HTIF at 0xFFFFFFFFF0000000 work. - I patched QEMU to dump characters written to the HTIF console, because I couldn't figure out how to use it properly. Coreboot fails to boot Linux (configured vmlinux as an ELF payload, because I couldn't find a compressed kernel): CBFS: Locating 'fallback/payload' CBFS: Found @ offset cbc0 size 136043 Loading segment from rom address 0x000000000002ccf8 code (compression=1) New segment dstaddr 0x0 memsize 0x35abe0 srcaddr 0x2cd30 filesize 0x13600b Loading segment from rom address 0x000000000002cd14 Entry Point 0xffffffff80000000 SELF Payload doesn't target RAM: Failed Segment: 0x0, 3517408 bytes 0. 0000000000200000-0000000001fdafff: RAM 1. 0000000001fdb000-0000000001ffefff: CONFIGURATION TABLES 2. 0000000001fff000-00000000021fffff: RAM Payload not loaded. Jonathan

2 1

Re: [coreboot] Using High Speed UART1 as Serial port on CoreBoot (MinnowBoard)
by Adrian Perez Resa April 20, 2016

April 20, 2016

Hi Ben, Many thanks for your reply, then I suppose the best option is the PCU UART I'll continue with that Thanks and best regards Adrián -----Mensaje original----- De: Ben Gardner [mailto:gardner.ben@gmail.com] Enviado el: 19 April 2016 17:26 Para: Adrian Perez Resa CC: coreboot(a)coreboot.org Asunto: Re: [coreboot] Using High Speed UART1 as Serial port on CoreBoot (MinnowBoard) Hi Adrian, You are better off hooking up to the "Serial Console" port and using that. http://wiki.minnowboard.org/MinnowBoard_MAX If you really want to use one of the HS UARTs, then you have a bit of work to do. See src/drivers/uart/uart8250mem.c and note the use of CONFIG_DRIVERS_UART_8250MEM_32. You'd need to implement something similar to src/soc/intel/skylake/romstage/uart.c, but for the E3800. Not worth it, in my opinion, as the PCU UART works just fine. Ben On Tue, Apr 19, 2016 at 9:27 AM, Adrian Perez Resa <aperezr(a)telnet-ri.es> wrote: > Hello everybody, > > > > I am newby with minnow board and CoreBoot. > > I am trying to use HIGH Speed UART1 as Serial port on CoreBoot > (SIO_UART 1 > pins) with no success. > > > > I have tried to configure CoreBoot with the following options: > > - Console > Index for UART port to use for console -> ‘0’ > > o Baud rate 115200 > > > > But I don’t know exactly what serial port I am using… > > > > High speed UART 1 (SIO UART 1) is connected to JP1 Header in minnow Board. > > However, Serial port seems to be always on the default debug UART > (connector > J4 on Minnow Board). > > This Debug UART is attached at ATOM GPIOS GPIO_S0_SC_57 and > GPIO_S0_SC_61 pins. > > > > Does anybody know what options are necessary to change for using a > different uart than the default one…? > > > > Thanks in advance! > > > > Best regards > > > > > > -- > Adrian Perez Resa > Dpto. Innovación y Desarrollo > Telnet Redes Inteligentes S.A. > http://www.telnet-ri.es > Tel: (+34)976 141 800 - Fax: (+34)976 141 810 > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] coreboot convention update
by ron minnich April 20, 2016

April 20, 2016

Yes, it does. On Tue, Apr 19, 2016, 11:59 AM Yang, York <york.yang(a)intel.com> wrote: > Just want to confirm, will whole event happen in Google SF office? > > > > Thanks, > > York > > > > *From:* coreboot [mailto:coreboot-bounces@coreboot.org] *On Behalf Of *ron > minnich > *Sent:* Tuesday, April 19, 2016 10:29 AM > *To:* coreboot <coreboot(a)coreboot.org> > *Subject:* [coreboot] coreboot convention update > > > > The coreboot convention is coming along very well. Just today we've been > able to schedule a talk which I think you are going to enjoy: Ms. Joanna > Rutkowska of the Invisible Things Lab, and one of the inventors of Qubes, > will be presenting her ideas on the Stateless Laptop on Monday, June 13. > Put simply, she is advocating for removable firmware modules to create a > truly stateless system. I am hoping we can also discuss using Qubes as a > coreboot payload. > > > > If you are coming, you should start looking at hotels. There are deals to > be found. I just booked a pretty nice hotel not far from Google SF for > about 225 a night. But, warning! Apple has just announced that their big > developer week is the same as our convention. So, if you're going to come > out, move fast before the hotels all evaporate! > > > > If you want to give a talk, please let us know soon. The talk slots are > getting filled quickly. If you have a short talk, of a practical nature, we > have 30 minute slots still open on the first two days, and will have room > for such talks on Wednesday and Thursday. > > > > If you want to see the Long Now, it's also a good idea to register soon; > that event is space-limited due to city regulations. > > > > Thanks,if you have questions please get in touch. > > > > Ron >

1 0

Re: [coreboot] coreboot convention update
by Yang, York April 19, 2016

April 19, 2016

Just want to confirm, will whole event happen in Google SF office? Thanks, York From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of ron minnich Sent: Tuesday, April 19, 2016 10:29 AM To: coreboot <coreboot(a)coreboot.org> Subject: [coreboot] coreboot convention update The coreboot convention is coming along very well. Just today we've been able to schedule a talk which I think you are going to enjoy: Ms. Joanna Rutkowska of the Invisible Things Lab, and one of the inventors of Qubes, will be presenting her ideas on the Stateless Laptop on Monday, June 13. Put simply, she is advocating for removable firmware modules to create a truly stateless system. I am hoping we can also discuss using Qubes as a coreboot payload. If you are coming, you should start looking at hotels. There are deals to be found. I just booked a pretty nice hotel not far from Google SF for about 225 a night. But, warning! Apple has just announced that their big developer week is the same as our convention. So, if you're going to come out, move fast before the hotels all evaporate! If you want to give a talk, please let us know soon. The talk slots are getting filled quickly. If you have a short talk, of a practical nature, we have 30 minute slots still open on the first two days, and will have room for such talks on Wednesday and Thursday. If you want to see the Long Now, it's also a good idea to register soon; that event is space-limited due to city regulations. Thanks,if you have questions please get in touch. Ron

1 0

coreboot convention update
by ron minnich April 19, 2016

April 19, 2016

The coreboot convention is coming along very well. Just today we've been able to schedule a talk which I think you are going to enjoy: Ms. Joanna Rutkowska of the Invisible Things Lab, and one of the inventors of Qubes, will be presenting her ideas on the Stateless Laptop on Monday, June 13. Put simply, she is advocating for removable firmware modules to create a truly stateless system. I am hoping we can also discuss using Qubes as a coreboot payload. If you are coming, you should start looking at hotels. There are deals to be found. I just booked a pretty nice hotel not far from Google SF for about 225 a night. But, warning! Apple has just announced that their big developer week is the same as our convention. So, if you're going to come out, move fast before the hotels all evaporate! If you want to give a talk, please let us know soon. The talk slots are getting filled quickly. If you have a short talk, of a practical nature, we have 30 minute slots still open on the first two days, and will have room for such talks on Wednesday and Thursday. If you want to see the Long Now, it's also a good idea to register soon; that event is space-limited due to city regulations. Thanks,if you have questions please get in touch. Ron

1 0

Using High Speed UART1 as Serial port on CoreBoot (MinnowBoard)
by Adrian Perez Resa April 19, 2016

April 19, 2016

Hello everybody, I am newby with minnow board and CoreBoot. I am trying to use HIGH Speed UART1 as Serial port on CoreBoot (SIO_UART 1 pins) with no success. I have tried to configure CoreBoot with the following options: - Console > Index for UART port to use for console -> '0' o Baud rate 115200 But I don't know exactly what serial port I am using... High speed UART 1 (SIO UART 1) is connected to JP1 Header in minnow Board. However, Serial port seems to be always on the default debug UART (connector J4 on Minnow Board). This Debug UART is attached at ATOM GPIOS GPIO_S0_SC_57 and GPIO_S0_SC_61 pins. Does anybody know what options are necessary to change for using a different uart than the default one...? Thanks in advance! Best regards -- Adrian Perez Resa Dpto. Innovación y Desarrollo Telnet Redes Inteligentes S.A. http://www.telnet-ri.es Tel: (+34)976 141 800 - Fax: (+34)976 141 810

2 1

Re: [coreboot] coreboot specific ACPI table
by Aaron Durbin April 19, 2016

April 19, 2016

On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org> wrote: > I think we should only export the coreboot table location and size > through ACPI and then read everything else from there. That way we can > share almost all of the kernel driver code with ARM and just need a > tiny platform-specific stub to look up the table location first. If we > add all the information into an actual ACPI table, we're building an > x86-only solution again. (A generic, platform-independent coreboot > driver could just as easily export the stuff we want into sysfs.) > That's fine. The only thing I was concerned about was implementing an ACPI table proper or try to do some ACPI device shenanigans like the ramoops device. coreboot doesn't currently have a ACPI ID assigned to it. If we go with a ACPI device coreboot should apply for an ACPI ID. I personally think the coreboot ACPI table seems more straight forward, but I was wondering if people knew of any downsides to going that route. > For comparison, the coreboot device tree interface on ARM > (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by > the maintainers but still used on Chromebooks today) only exports > start address and size of the coreboot table and the whole CBMEM area, > so maybe ACPI should just match that. (I guess if CBMEM is referenced > by the coreboot table like Aaron said, we could also drop that part.)

1 0

Re: [coreboot] Coreboot on ARM
by Zoran Stojsavljevic April 19, 2016

April 19, 2016

Hello Yessine, What I know about MLO is the following (worked on smart phones - TI OMAP4 (namely OMAP 4430) for a year in Y2010/Y2011). Here it is: http://processors.wiki.ti.com/index.php/Boot_Sequence http://stackoverflow.com/questions/27012822/how-mlo-minimal-bootloader-works My best understanding is that x-loader (MLO) is nothing more then minimalistic bootloader, derived from u-boot. In my time it was around 35KB of size, but I see that it grew with the time (over 64KB). It's main task is to specifically configure certain SoC I/O pins. AAs I remembered, at the time it needed to also configure SoC's DRAM (the last SoC's layer), since u-boot requires at least 256KB. Also, the security is added to MLO, so it must be signed (this came as a feature in Y2011). Zoran On Tue, Apr 19, 2016 at 2:07 AM, daoud yessine <yessine.daoud.92(a)gmail.com> wrote: > hi > > Is coreboot a replacement of x-oader (MLO) on arm systems ? > So coreboot will be placed in the boot partition on the SD/card (e.g ) and > it will be named MLO to be called by the rom code ?? > > ᐧ > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] coreboot specific ACPI table
by Julius Werner April 19, 2016

April 19, 2016

I think we should only export the coreboot table location and size through ACPI and then read everything else from there. That way we can share almost all of the kernel driver code with ARM and just need a tiny platform-specific stub to look up the table location first. If we add all the information into an actual ACPI table, we're building an x86-only solution again. (A generic, platform-independent coreboot driver could just as easily export the stuff we want into sysfs.) For comparison, the coreboot device tree interface on ARM (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by the maintainers but still used on Chromebooks today) only exports start address and size of the coreboot table and the whole CBMEM area, so maybe ACPI should just match that. (I guess if CBMEM is referenced by the coreboot table like Aaron said, we could also drop that part.)

1 0

Re: [coreboot] coreboot specific ACPI table
by ron minnich April 19, 2016

April 19, 2016

yeah, I know ... :-) I just wanted to get the full word in there .... ron On Mon, Apr 18, 2016 at 6:22 PM Aaron Durbin <adurbin(a)google.com> wrote: > On Mon, Apr 18, 2016 at 8:18 PM, ron minnich <rminnich(a)gmail.com> wrote: > > So we would submit new ACPI table types to the standards guys? Could we > get > > names like > > CORE > > BOOT > > CBFS > > We just need one table, and we can put whatever we want into it. It's > the equivalent of an HPET table, e.g. > > > > > ? > > > > ron > > > > On Mon, Apr 18, 2016 at 10:15 AM Patrick Georgi via coreboot > > <coreboot(a)coreboot.org> wrote: > >> > >> 2016-04-18 19:09 GMT+02:00 Vadim Bendebury <vbendeb(a)chromium.org>: > >> > It's been a while since I looked at it, but why not to pass all > >> > information through the coreboot table? (so that just one pointer > >> > needs to be shared through ACPI). > >> One reason for registering these things in ACPI is so that Linux > >> exports them properly via sysfs. /dev/mem is mostly non-functional in > >> newer kernel versions. > >> > >> > >> Patrick > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> https://www.coreboot.org/mailman/listinfo/coreboot >

1 0