February 2016 - coreboot - mail.coreboot.org

New on blogs.coreboot.org: coreboot changelog Feb 10 - Feb 16
by WordPress Feb. 18, 2016

Feb. 18, 2016

1 0

[RFC] board-status.git growth
by Carl-Daniel Hailfinger Feb. 17, 2016

Feb. 17, 2016

Hi, since various automated systems started submitting board status files, the board-status repository has grown significantly to a point where submitting a new board from scratch requires a download which is bigger than the whole coreboot repository. Once I hook up four more systems in my lab, I expect this growth to accelerate quite a bit. It will get even more extreme once I start testing every commit instead of limiting the tests to one per hour. This poses three problems: 1. Download size for people wanting to submit new logs. Can be solved with shallow git clones of the board-status repository. 2. Download size for people wanting to find out where some breakage happened. Not really solvable unless we commit less reports, and that makes bisection harder. 3. Server load for anything working with the board-status repo. This means gitweb and the wiki, and that's not a problem (yet). Should we just ignore the size until it becomes too large, is size not a problem or should we immediately do something? Regards, Carl-Daniel

4 3

Re: [coreboot] Proposal - Fast Boot UEFI addendum to Coreboot
by Zoran Stojsavljevic Feb. 14, 2016

Feb. 14, 2016

Hello Patrick, > A 32bit coreboot doesn't preclude providing a 64bit uefi interface (as is needed for windows), and that's all that matters when people talk about "64bit UEFI". Agreed. In such a case I need just a super-tiny "Tiano_Core" payload which does the following: [1] Changes 32 bit protected mode to 64 bit mode; [2] To understand logical HDD/SSD disk partition, eg. to understand how to assist/make true FAT 32 /boot/EFI/ partition on the HDD/SSD/eMMC disk Do you have such one (you worked on something, I understood), but does it do what I spelled here? Thank you, Zoran _______ On Sun, Feb 14, 2016 at 2:44 PM, Patrick Georgi <pgeorgi(a)google.com> wrote: > A 32bit coreboot doesn't preclude providing a 64bit uefi interface (as is > needed for windows), and that's all that matters when people talk about > "64bit UEFI". > > Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> schrieb am So., 14. > Feb. 2016 um 13:40 Uhr: > >> Hello Patrick, >> >> You see, sometimes ago, when Coreboot came to existence, they used to >> call it Linux BIOS. I actually like this term. Linux BIOS! >> >> Now, my aim is the following: to make Coreboot alternative for/to UEFI >> compliant BIOS. For this to happen, I need there several things: >> [1] I'll see if FSP itself can be 64 bit (for now, it is 32 bit, and I >> need to do some work there to see how it looks/is integrated as part of the >> real 64 bit UEFI BIOS); >> [2] Coreboot to be 64 bit; >> [3] To understand logical HDD/SSD disk partition, eg. to understand how >> to assist/make true FAT 32 /boot/EFI/ partition on the HDD/SSD/eMMC disk >> (minimalistic 64 bit Tiano Core which will do just this - Coreboot payload). >> >> And, yes, if this can help, we can make it 32 bit UEFI compliant, for the >> beginning... Then, the following is required: >> [1] To understand logical HDD/SSD disk partition, eg. to understand how >> to assist/make true FAT 32 /boot/EFI/ partition on the HDD/SSD/eMMC disk >> (minimalistic 32 bit Tiano Core which will do just this - Coreboot payload). >> >> We do NOT want this MBR and who_knows_where parts of OS boot-loader on >> the actual HDD (MBR + adjacent 31KB of the disk), this crap hanging still >> out/around, do we?! >> >> Make sense? ;-) >> >> Thank you, >> Zoran >> _______ >> >> On Sun, Feb 14, 2016 at 12:35 PM, Patrick Georgi <pgeorgi(a)google.com> >> wrote: >> >>> 2016-02-14 8:32 GMT+01:00 Zoran Stojsavljevic < >>> zoran.stojsavljevic(a)gmail.com>: >>> > [1] FSP 32 bit as is; >>> That's probably best discussed with some Intel field rep for FSP. >>> >>> > [2] Coreboot to be 64 bit Coreboot, compiled for INTEL x86_64 >>> architecture; >>> The 64bit support was started, but I wouldn't expect it to work just >>> right yet. We don't even enable it by default anywhere, because it >>> isn't really needed. >>> Why do you want coreboot to be 64bit code? >>> >>> > [3] Have the minimum minimorum of Tiano Core (just UEFI HDD/SSD UEFI >>> boot >>> > partition maker, everything else scrapped)! >>> Tianocore is a bit of a sore spot. We have three different >>> implementations of a TianoCore payload, one by Scott Duplichan, >>> working on some AMD board, one by Intel, working on some Intel board >>> (and available in the TianoCore repository) and my copy that I >>> irregularly work on. >>> >>> I'd expect the bare minimum payload able to boot Windows still to take >>> 500-700kb compressed in flash. >>> >>> >>> Patrick >>> -- >>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: >>> Hamburg >>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >>> >> >>

1 0

Re: [coreboot] Proposal - Fast Boot UEFI addendum to Coreboot
by Patrick Georgi Feb. 14, 2016

Feb. 14, 2016

2016-02-14 8:32 GMT+01:00 Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>: > [1] FSP 32 bit as is; That's probably best discussed with some Intel field rep for FSP. > [2] Coreboot to be 64 bit Coreboot, compiled for INTEL x86_64 architecture; The 64bit support was started, but I wouldn't expect it to work just right yet. We don't even enable it by default anywhere, because it isn't really needed. Why do you want coreboot to be 64bit code? > [3] Have the minimum minimorum of Tiano Core (just UEFI HDD/SSD UEFI boot > partition maker, everything else scrapped)! Tianocore is a bit of a sore spot. We have three different implementations of a TianoCore payload, one by Scott Duplichan, working on some AMD board, one by Intel, working on some Intel board (and available in the TianoCore repository) and my copy that I irregularly work on. I'd expect the bare minimum payload able to boot Windows still to take 500-700kb compressed in flash. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Proposal - Fast Boot UEFI addendum to Coreboot
by Zoran Stojsavljevic Feb. 13, 2016

Feb. 13, 2016

Hello Stefan, Patrick, and Coreboot folks, Long time no see, because (as I stated few times), my bosses want me in the another Galaxies to do another jobs. The new developments and the new requirements in the Embedded World once again pushed me back to Coreboot community. ;-) Over this two+ years, since I brought first IVB Cougar Canyon 2 with 32 bit Coreboot and SeaBIOS, with 120GB HDD WIN 8.0 boot loader and 32 bit WIN 8.0. I still have couple of these HDDs, sitting in my lab and collecting dust. I have spent lot of time dealing with 64 bit UEFI compliant BIOSes, and with WIN 10 and latest Linuxes, doing lot of testing and creating interesting use cases to better understand requirements for different projects. Few days ago, I tried to bring BYT-M (N2807) board, having there BYT-I MR4 FSP and Coreboot with SeaBIOS payload. One point in time, I decided to hook the 32 bit IVB WIN 8.0 32bit HDD (the same described above), and, on the first run, WIN 8.0 needed lot of time just to reinstall/reconfigure dynamically correct drivers for the platform used. Then I brought the whole thing again: [1] It came to boot loader (POST 01F8 code) within a second; [2] It came to WIN 8.0 32 bit (login) less then another second! :-) Now... This is with CSM ON (used payload SeaBIOS), and MBR boot (legacy support). _______ Now, I would like to have THE SAME, but having done the following: [1] FSP 32 bit as is; [2] Coreboot to be 64 bit Coreboot, compiled for INTEL x86_64 architecture; [3] Have the minimum minimorum of Tiano Core (just UEFI HDD/SSD UEFI boot partition maker, everything else scrapped)! So I can bring Embedded System 64 bit within 1 second to OS boot loader, UEFI style (so whole creation plays CSM OFF, and it is UEFI compliant/compatible)! Do you have solution for that? Thank you, Zoran Stojsavljevic

1 0

Re: [coreboot] Removed boards list.
by Denis 'GNUtoo' Carikli Feb. 12, 2016

Feb. 12, 2016

On Tue, 9 Feb 2016 09:47:08 +0100 Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: > > Would it be possible to get such page updated (for instance by the > > commit author) when the commit has been pushed to master? > Maybe the board-status to wiki tool should check multiple versions of > the coreboot tree (eg. master plus all tags) and work from that, > presenting the information on the "supported motherboards" page ("last > version supporting the board: (master, 4.1, ...)"). Thanks,That is a better idea since it's automatic. Denis.

1 0

Aspirant for GSOC 2016 with coreboot for ARM64 qemu port
by Saket Sinha Feb. 11, 2016

Feb. 11, 2016

Hi, I think this is early for this but I am looking forward to participate in GSOC 2016 with coreboot for ARM64 qemu port. This is to discuss the idea further. I guess the project was a part of last year GSOC as well so we already have some base-work to start with. I request you to guide me as where to start with to prepare for this project. Regards, Saket Sinha

1 0

New on blogs.coreboot.org: coreboot changelog Feb 3 - Feb 9
by WordPress Feb. 11, 2016

Feb. 11, 2016

1 0

Re: [coreboot] Can not have IRQ from ethernet device connected to the PCIe #4 in legacy mode
by benoit Feb. 11, 2016

Feb. 11, 2016

Hi Ben, I haven't got this recent workaround. I will make a try by back porting this code that seems to be the problem. I will inform you about my results. Many thanks Benoit On 11/02/2016 00:42, Ben Gardner wrote: > Hi Benoit, > > There was a bit of a discussion about interrupt routing a while back > (Dec 2015) on FSP Baytrail. > Apparently the IRQs were not swizzled correctly. > > https://review.coreboot.org/#/c/12684/ > > If you are not using a recent version of coreboot, you may need to > back-port that change. > > Ben > > On Wed, Feb 10, 2016 at 3:00 PM, benoit <benoit.sansoni(a)gmail.com> wrote: >> Hi all, >> >> I am facing a legacy IRQ under OS. >> I am currently using Coreboot + FSP on baytrail. >> My OS is running with IRQ in legacy using PIRQ described in >> coreboot/src/mainboard/intel/bayleybay_fsp/irqroute.h . >> Under the OS USB, SATA, SMBus are working well using legacy interrupt. >> Nevertheless I have an ethernet device connected on the PCIe root #4 and >> no IRQs are received. >> >> I tried to change the IRQ in the interrupt line register without success. >> >> I can compare also with a Phoenix BIOS, and with the same OS binary the >> ethernet is working. >> >> I check out also the ilb registers + 0x4d0 and 0x4d1 registers (ECL). >> Everything is correctly initalized. >> >> Do I need to activate/deactivate something in the PCIe root #4 to >> forward legacy interrupt to the 8259 PIC ? >> >> Many thanks in advance >> Benoit >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Removed boards list.
by Denis 'GNUtoo' Carikli Feb. 10, 2016

Feb. 10, 2016

On Tue, 9 Feb 2016 09:47:08 +0100 Patrick Georgi <pgeorgi(a)google.com> wrote: [...] > > Would it be possible to get such page updated (for instance by the > > commit author) when the commit has been pushed to master? > Maybe the board-status to wiki tool should check multiple versions of > the coreboot tree (eg. master plus all tags) and work from that, > presenting the information on the "supported motherboards" page ("last > version supporting the board: (master, 4.1, ...)"). Thanks, that is a better idea since it's automatic. Denis.

1 0