coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

Re: [coreboot] latest greatest thinkpad with coreboot
by Trammell Hudson 02 Dec '16

02 Dec '16

On Thu, Dec 01, 2016 at 11:20:00PM +0000, ron minnich wrote: > If people are trying native graphics init I still think it's worth trying > the SPARK stuff from nico at least once. I'm intrigued by the use of Ada and excited about applying more formal methods as well as safer languages to the firmware space. It would also be interesting to consider using sel4 or CertiKOS as a payload. Do we require any sort of VGA init if the payload has the kernel framebuffer and mode support? I should do some tests with that on the x230. On Thu, Dec 1, 2016 at 2:54 PM Klemens Nanni <kl3(a)posteo.org> wrote: > >https://item.taobao.com/item.htm?id=43820633263&toSite=main > >http://forum.51nb.com/thread-1662397-1-1.html > > Interesting, I wonder how well these replacement screens would work with > coreboot? I assume the proprietary VGA Option ROM won't work with those > and native graphics initialisation still needs some work on the X230 > either ways. Based on the auto-translated Chinese forum post, I believe they have tapped into the docking station to get sufficient display lanes. I haven't tried using the docking station with coreboot, so I'm not certain how well it would work either. -- Trammell

2 1

Re: [coreboot] Anyone have a experence the u-boot on coreboot?(Rangeley platform)
by Yaroslav K. 01 Dec '16

01 Dec '16

Hello! I'm successfully using U-boot with Coreboot on the Rangeley platform with the attached dts file. I'm not sure if everything in it is needed and/or correct, but it works fine. serial1.dtsi was needed so that the second UART is used as stdout. Although, this question looks like more relevant to the U-boot mailing list than the Coreboot one. -- Yaroslav

1 0

Re: [coreboot] non-coreboot question on gnu ldscripts
by Zoran Stojsavljevic 01 Dec '16

01 Dec '16

> I can write an ldscript for riscv which will produce segments that have addresses aligned to 2M, but the alignment value is still 4K. Not expert (certainly) on ldscripts (far from that), but if you willing to write one script as per said/written above, and present it here, maybe we, non-experts, can learn, and help. :-) Zoran On Thu, Dec 1, 2016 at 6:03 PM, ron minnich <rminnich(a)gmail.com> wrote: > Apologies in advance: this is not a coreboot question but I'm counting on > coreboot expertise. > > I need to find a way to force the value of the segment alignment variable. > > The problem is that on the riscv gld, they want to align segments on 4k > boundaries. I need them aligned on 2M boundaries. Note this works fine > today on x86_64: ELF files have segments aligned on 2M boundaries and the > alignment value is 2M. > > I can write an ldscript for riscv which will produce segments that have > addresses aligned to 2M, but the alignment value is still 4K. > > Any suggestions from all you experts? > > thanks > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

[WIP] amdfam10: Major ".c" include cleanup
by Damien Zammit 01 Dec '16

01 Dec '16

Hi all, I am planning to do a cleanup of AMD Fam10-15 codebase, (i.e., not AGESA). I have currently completed a first attempt at removing most of the ".c" includes in romstage. It currently builds on one board only, KFSN4-DRE, and only works on DDR2, (DDR3 is WIP). I would really appreciate someone to take a look at the headers and comment so I can get a picture of how strict coreboot would like to be in terms of the header layout. As in, I don't want to touch 24 boards until I have an idea of how it should be laid out. Obviously this is going to be a massive cleanup and will need testing on hardware, I was hoping to use REACTS as a first step once I get things working. Any suggestions welcome before I begin to address Kyosti's comments in a new push. Damien

2 2

Re: [coreboot] [RFC] Explicitly use C11/GNU11
by Paul Menzel 01 Dec '16

01 Dec '16

Dear Julius, Am Mittwoch, den 30.11.2016, 20:10 -0800 schrieb Julius Werner: > > Thank you for the elaborate explanation. I never intended to take on > > that task, but if I had, you would have convinced me. > > > > I hope using GNU11 suits everyone. > > Yes, just to be clear (this has split into so many different threads > that I'm no longer sure what the latest decision is?), I only > (prematurely) objected to forbidding GNU extensions. Otherwise, I'm > totally in favor of switching to C11 and not aware of any difference > between the versions that would cause a problem for us. As written, my current understanding is, that when switching the coreboot toolchain from 4.9(?) to 5.3(?), the coreboot project switched from GNU89 to GNU11. My current proposal [1] is to explicitly set that, so that people can still use GCC 4.9 – Debian 8.5 (Jessie/stable) ships GCC 4.9.2. Reviews are welcome. Thanks, Paul [1] https://review.coreboot.org/17636

1 0

Re: [coreboot] your preferred method for supplying power to chip for RPi spi flashing?
by Peter Stuge 01 Dec '16

01 Dec '16

Zoran Stojsavljevic wrote: > I programmed most of INTEL platforms using dediprog SF100: ATOM: > from D4xx/D5xx (Pine Creek) series, TNC, BYT-M/I, BSW and CORE > (IVB, HSW, BDX-DE, BDW-H, SKL-Y/U), whereas for some HSW-U series it was > necessary to put platform in S5 state by shutting down them to S5. AC in > most cases removed, I did not have battery since I played with test > platforms. And there were 4x2 pins connectors for most of platforms, Reference boards (test platforms) tend to have the SPI bus mux built-in. //Peter

1 0

your preferred method for supplying power to chip for RPi spi flashing?
by Michael Carbone 01 Dec '16

01 Dec '16

Hi coreboot list, I have been attempting to use a raspberry pi for spi flashing and when I use the 3.3v pin the raspberry pi doesn't power up as the chip draws too much power through the 3.3v pin for the raspberry pi to also run. I am powering the RPi through micro-USB, either connected to wall outlet or another computer. What is your recommended method for powering the chip and RPi? Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy because I don't know if coreboot has WoL functionality for the x230 should I want to reflash the chip [2]. Advice/thoughts appreciated, and let me know if there's a better place to ask this question. FYI this is the chip I am trying to program: [3] Thanks, Michael [1] https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whiteli… [2] https://www.coreboot.org/Board:lenovo/x230 [3] http://www.zlgmcu.com/mxic/pdf/NOR_Flash_c/MX25L3206E_DS_EN.pdf -- Michael Carbone Qubes OS | https://www.qubes-os.org @QubesOS <https://www.twitter.com/QubesOS> PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4

4 3

latest greatest thinkpad with coreboot
by ron minnich 01 Dec '16

01 Dec '16

what's the latest best one? What's the battery life like (can't be worse than this mac pro that's always hot and now seems to have a life of 90 minutes, always). How much dram/ssd can I jam in it? thanks

1 0

non-coreboot question on gnu ldscripts
by ron minnich 01 Dec '16

01 Dec '16

Apologies in advance: this is not a coreboot question but I'm counting on coreboot expertise. I need to find a way to force the value of the segment alignment variable. The problem is that on the riscv gld, they want to align segments on 4k boundaries. I need them aligned on 2M boundaries. Note this works fine today on x86_64: ELF files have segments aligned on 2M boundaries and the alignment value is 2M. I can write an ldscript for riscv which will produce segments that have addresses aligned to 2M, but the alignment value is still 4K. Any suggestions from all you experts? thanks

1 0

Re: [coreboot] Rettungsboot
by Zoran Stojsavljevic 30 Nov '16

30 Nov '16

amusement value: How long was the minimum time to cross USA from East Coast (NYC) to West Coast (SF) back then in 1880s (Vayat Erp and Dock Holiday time: by horse or carriage)? And how long for the same distance Today/Present time (by plane or shuttle)? Ron, technology advances... Doesn't it??? ;-) Zoran On Wed, Nov 30, 2016 at 10:18 PM, ron minnich <rminnich(a)gmail.com> wrote: > amusement value: > > The 512 bytes used for MBR is about .04% of the 8" floppy disk that > shipped with the original IBM PC. For 128 MB to be that fraction of a new > disk, the disk would have to be 256 GiB. That's about $40 worth of disk. > > Geez. > > > On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> > Or do you want to do the full EFI "let's waste 128MB of *every** disk* >> on >> > a special FAT32 partition" madness (which still requires bootloaders to >> > include one specific FS driver they might otherwise not want)? >> >> YES, you do. Accent on: "every disk" . >> >> Zoran >> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner(a)chromium.org> >> wrote: >> >> > To sum it up, I want something that is lean and clean enough so it could >> be added to any bootloader. Even if that boot loader is not of the >> let's build a tiny OS type. >> >> I don't really see how you could reach this goal with anything that >> requires reading a file from the boot media? There are billions of >> different file systems out there... do you want to require your >> "minimal" bootloader to include drivers for all of them? (There are >> bootloaders that don't contain any file system drivers at all, like >> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of >> every disk on a special FAT32 partition" madness (which still requires >> bootloaders to include one specific FS driver they might otherwise not >> want)? >> >> I think if you want to do anything truly minimal and compatible with >> everything, you can't rely on files (and you should try to rely on >> partitions as little as possible, e.g. no full GPT parsing). Which >> probably means putting it in the first sector. And once you have that, >> you can create some fancy text-based format (or Go source file / >> node.js script / whatever the cool kids use these days) to describe >> the target sector, load address etc. of the fallback kernel... but >> you're really just exemplifying the XKCD Igor mentioned because you've >> just reinvented the MBR. (And let's face it... no coreboot bootloader >> has the pull to sufficiently promote adoption of some completely new >> fallback boot descriptor format right now, even if it doesn't require >> a Go compiler in your bootloader.) >> >> So, really, I think what you want is just the MBR. It is the deadest >> simple design possible (just load a sector and jump), it is as >> infinitely flexible as code itself, and it coexists perfectly with all >> partitioning schemes relevant today (MBR and GPT). Yes, it requires a >> software interrupt BIOS interface, but if the recovery kernel code is >> cleverly written you really only need the disk access part (and you >> know your bootloader already has that driver because that's how it >> loaded the MBR in the first place). And yes, on x86 it requires real >> mode (for non-x86 I'd just make up an as equivalent as possible system >> with your software interrupt solution of choice), but that's a small >> price you pay with a few files worth of shim code in exchange for >> automatic compatibility with 35 years worth of existing BIOSes. I'd >> say that's a better deal than any new dead-on-arrival scheme you could >> make up out of thin air. >> >> (If you really can't stand the idea of BIOS interrupts and real mode, >> I think your next best option would be to try to cram an >> as-small-as-possible binary recovery descriptor and the real mode code >> to parse/load/execute it together into the 446 bytes of MBR space you >> have. This way, your new payloads can just find and parse/load/execute >> the descriptor itself without having to provide any BIOS interface, >> but the thing is still compatible with existing legacy BIOSes as >> well.) >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2016