coreboot June 2013

coreboot@coreboot.org

45 participants
86 discussions

Invitation: coreboot GSoC 2013 blog post due @ Mon Jun 24, 2013 6pm (Marc Jones)
by Marc Jones 24 Jun '13

24 Jun '13

You have been invited to the following event. Title: coreboot GSoC 2013 blog post due Blog posts are due Tuesday 12am GMT. When: Mon Jun 24, 2013 6pm Mountain Time Calendar: Marc Jones Who: * Marc Jones - organizer * stefan.tauner(a)gmx.at * kyosti.malkki(a)gmail.com * Alex Gagniuc * alexander(a)sulfrian.net * Ayush Sagar * stefan.reinauer(a)coreboot.org * c-d.hailfinger.devel.2006(a)gmx.net * QingPei Wang * Patrick Georgi * ron minnich * Joshua Roys * r.marek(a)assembler.cz * Martin Roth * dave.frodin(a)se-eng.com * peter(a)stuge.se * coreboot(a)coreboot.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTM2YzRrYjM5NHI3aHUzZ… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account coreboot(a)coreboot.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

1 0

Re: [coreboot] Welcome GSoC Students! - week 1 completed
by Marc Jones 24 Jun '13

24 Jun '13

coreboot GSoC 2013 blog post due Blog posts are due Tuesday 12am GMT. *When* Mon, June 24, 6pm – 6pm GMT-06:00 *Who* • Marc Jones • stefan.tauner(a)gmx.at • Kyösti Mälkki • Alex Gagniuc • alexander(a)sulfrian.net • Ayush Sagar • Stefan Reinauer • Carl-Daniel Hailfinger • Jason Wang • Patrick Georgi • ron minnich • Joshua Roys • Rudolf Marek • Martin Roth • Dave Frodin • Peter Stuge • Coreboot On Mon, Jun 24, 2013 at 10:22 AM, Marc Jones <marcj303(a)gmail.com> wrote: > Hello Students, > > I hope that your first official week of GSoC 2013 has gone well. I > know that some of you are still working on exams, but it is important > to get off to a good start on GSoC. Please make a little time to > communicate with your mentors about your progress. You should be > having some contact every day or two. Even if it is to just check in. > Also, the weekly blog report is critical. It is the best way we can > judge your progress and give you passing grades at the midterm and > final. If you haven't already, please make a blog post for your first > weeks progress. You should discuss how you are progressing, what > happened last week and what will happen next week. You can link to > commits, add source code, drawings, pictures, or other items to your > blog post to educate the community about your project. Please get your > first week post done in the next day or two. Starting next week, blog > post are due Tuesday 12am GMT. I will send a calendar event so you > will get a reminder each week. > > > Mentors, > Please review and read blog posts each week. Feel free to comment and > give feedback for any GSoC project. Lets try to give each student as > much support as we can. > > > As always, if you have any questions or concerns, feel free to let me know. > > Regards, > Marc > > -- > http://se-eng.com > -- http://se-eng.com

1 0

Re: [coreboot] Welcome GSoC Students! - week 1 completed
by Marc Jones 24 Jun '13

24 Jun '13

Hello Students, I hope that your first official week of GSoC 2013 has gone well. I know that some of you are still working on exams, but it is important to get off to a good start on GSoC. Please make a little time to communicate with your mentors about your progress. You should be having some contact every day or two. Even if it is to just check in. Also, the weekly blog report is critical. It is the best way we can judge your progress and give you passing grades at the midterm and final. If you haven't already, please make a blog post for your first weeks progress. You should discuss how you are progressing, what happened last week and what will happen next week. You can link to commits, add source code, drawings, pictures, or other items to your blog post to educate the community about your project. Please get your first week post done in the next day or two. Starting next week, blog post are due Tuesday 12am GMT. I will send a calendar event so you will get a reminder each week. Mentors, Please review and read blog posts each week. Feel free to comment and give feedback for any GSoC project. Lets try to give each student as much support as we can. As always, if you have any questions or concerns, feel free to let me know. Regards, Marc -- http://se-eng.com

1 0

Re: [coreboot] coreboot on x60s
by Denis 'GNUtoo' Carikli 23 Jun '13

23 Jun '13

On Sun, 23 Jun 2013 17:58:34 +1000 oneofthem <oneofthem(a)lavabit.com> wrote: > Hey do you how to flash coreboot onto the x60s? > I read the instructions here > https://www.coreboot.org/Lenovo_x60x > but I don't understand, mostly "you will need: the flash source, a > small patch for it, and the bucts utility) > What is the "small patch" meant to be? > > I really have no idea what I'm doing. > IT says: >You will need: the flashrom source, a small patch for it, and the >bucts utility. Flashrom is a program for flashing: http://www.flashrom.org/Flashrom If you're not confident with the instructions provided at https://www.coreboot.org/Lenovo_x60x you could try to find someone in your area that knows well coreboot and is able to do them for you, if there is no one in your area that knows corbeoot, you could still go on but you have the risk of bricking your laptop if theses instructions are not followed correctly(it happened to several people already, many also succedded though), if you brick the laptop any hope is not lost though: There is still a way to recover but it require to disassemble the laptop, buy a pomona clip and get an external programmer(you may already have one without knowing it), to connect them together, then to clip the pomona clip to the flash chip,to connect the external programmer to another computer that can run flashrom,to run flashrom and make it flash the new image trough the external programmer (for instance a normal coreboot image that is proven to work or the backup of the BIOS you have). Denis.

1 0

Beginner mobo..which of them?
by Marcello Stanisci 22 Jun '13

22 Jun '13

Hi, and thanks for welcoming me in this ml. I would like to buy a motherboard for build a new computer and at the same time for study how coreboot works. I'm looking for a fully (coreboot) supported mobo with a very simple architecture and well documented.. In a few words: suitable for a first approach. Can anyone help me? Which models are ok? marcello

3 3

Re: [coreboot] Bricked Lenovo T60
by Denis 'GNUtoo' Carikli 21 Jun '13

21 Jun '13

On Fri, 21 Jun 2013 09:26:11 -0700 ron minnich <rminnich(a)gmail.com> wrote: > But if you do it, of course, you want to always be sure the 'fallback > image' is a good one :-) In the case of SeaBIOS as a fallback payload, there is one more thing to take care of: The user must take care of making sure that what the fallback SeaBIOS loads automatically doesn't prevent it to boot: For instance if the user add some option rom in cbfs intended for the normal SeaBIOS and that it also prevent the fallback SeaBIOS from booting it would be a big problem... The workarround for that case is to configure (make menuconfig) the fallback SeaBIOS not to load option rom for instance. Of course that would need to be tested first...For instance by making the current payload load the modified SeaBIOS... Denis.

2 1

Re: [coreboot] Bricked Lenovo T60
by Gerd Hoffmann 21 Jun '13

21 Jun '13

On 06/21/13 18:26, ron minnich wrote: > the question about fallback is 'when do I tell the machine that the > normal boot succeeded'? At LANL, we learned the best place: as LATE in > the boot process as possible, long after LInux is up. You want to be > sure, if you set 'booted ok', that it is LINUX that booted ok, not > just coreboot. That's a key piece. I think at least on a developer machine you never ever want do that automatically ... After wading through the source code, looking especially at do_normal_boot() I think I figured how things are supposed to work. There are two bits and one counter in the cmos boot byte. One bit says "always boot normal mode". The other bit says "increase counter, when it is smaller than MAX_REBOOT_CNT boot normal, otherwise switch to fallback". So with this I should be able to make coreboot boot normal once, and on the next boot switch to fallback no matter what. So all I have to do in case normal doesn't boot up is to power-cycle the machine ... cheers, Gerd

1 0

Improving normal/fallback mecanism (Was: Bricked Lenovo T60)
by Denis 'GNUtoo' Carikli 21 Jun '13

21 Jun '13

On Fri, 21 Jun 2013 09:26:11 -0700 ron minnich <rminnich(a)gmail.com> wrote: > the question about fallback is 'when do I tell the machine that the > normal boot succeeded'? At LANL, we learned the best place: as LATE in > the boot process as possible, long after LInux is up. You want to be > sure, if you set 'booted ok', that it is LINUX that booted ok, not > just coreboot. That's a key piece. > > Because if coreboot sets 'booted ok', and then the node doesn't boot, > that's not doing you much good, is it? We learned that the hard way. > > So: only linux boot scripts get to set 'normal booted ok', and that > should be the last thing you do > and > many things get to clear 'normal booted ok', including linux, the > payload, and coreboot itself. The issue is that the coreboot implementation doesn't currently work like that. An implementation of what you described would work like that: At very early boot, coreboot would record the value of a booted_ok nvram setting in a variable, and then reset that the booted_ok nvram parameter to false. It would then boot on the boot_option nvram setting(like Normal for instance) if the recorded value is true; Then the OS would boot and the last boot scipt to run would do something like nvramtool -w booted_ok=true In the case of when something goes wrong, coreboot would record the value of booted_ok and find that it booted ok, then it would set that value to false, since something goes wrong it wouldn't complete the boot... Then the user would shut down the computer and power it on again, coreboot would then look at the booted_ok value and finds that there was a problem last time the user booted the computer, and because of that would run the images that have the fallback prefix in cbfs. Here would be the advantages and disadvantages of that approach: ---------------------------------------------------------------- -> It would require cooperation from the OS/Distribution, so for instance the user would be expected to put a systemd unit in /etc/systemd/system, we would probalby also have to create a sysvinit script for that. We could probably add support for clearing the booted_ok flag in SeaBIOS for the cases where adding an init script is not an option, and make a Kconfig option in coreboot to select that SeaBIOS option. I guess that adding an nvram option for telling seabios to clear that value is probably a bad idea because the change would affect too many boards(see below). -> The good thing is that it's way more reliable than the current approach that seem to tell that it booted fine in ramstage, from IRC: <kmalkki> if I remember correctly normal boot is marked good before entering payload The current approach doesn't guarantee that the user could boot into a working system, the payload could fail or the OS could not boot because of a wrong memory layout for instance. -> The user would be able to test new changes really easily: * For instance if it's a laptop he wouldn't even need to disassemble the laptop if the reflashing goes wrong. * Even for the people used to reflash their laptop it would be a huge benefit: * Assuming that there is a working coreboot image already for the laptop, they wouldn't need to use an external reflashing tool, that means faster testing. * That also means that they could develop for that laptop in more situations(For instance in a train, in a plane etc... where it would be complicated to reflash the laptop externally), If someone ports CONFIG_ELOG and/or CONFIG_CHROMEOS_RAMOOPS to all laptops, the developer would also get the logs in the case where the system didn't boot. Implementation: --------------- So what would be the best approach for adding support for that? -> Many boards have the possibility to use the nvram and some use it by default... Should a new cmos layout option be added? Or should we re-use the last_boot option? would the rename of options or values be a problem if the layout doesn't change? What about value types changes (Fallback/Normal -> false/true) ? Basically what happen if you have a board that has a CMOS layout and that you flash an image with a new and different CMOS layout and reboot? There are 2 cases: if the board has a cmos.default(very few boards have that) or if the board lack that(it's the case for the majority of the boards). -> Should a new Kconfig option and fallback/normal mecanism be added, since we have 2 implementations already that could be a good idea and it would be safer that way. Denis.

1 0

Re: [coreboot] Native init for AMD cards
by ron minnich 21 Jun '13

21 Jun '13

This is the sort of thing I started with. It looks easier at first, but as you hit kernel churn, white space issues, the need to delete struct members or even rewrite structs and the code that uses them, and a lot of other trivial things, I expect you to quickly find you need a semantic patch. But the proof is in the pudding -- just give it a try and see how it goes. Note that on i915tool, I got about 50% of the way there with coccinnelle, and even had things working in user mode, but my new approach is to build up code from the traced IO stream. And, at the end, there's no way to avoid a lot of hand work, it seems. But maybe the intel stuff is particularly hard, that seems to be the rule. ron

1 0

Bricked Lenovo T60
by Damien Zammit 21 Jun '13

21 Jun '13

Hi folks, Thanks #coreboot for all your help with my laptop, I learnt a lot today from you all. Unfortunately my first attempt at installing coreboot has resulted in a bricked laptop. I tried to cheat by making an educated guess of the SPI chip model without pulling my laptop to bits to verify. However, it seemed right according to the responses i was getting from flashrom -V for the failed chips, since the manufacturer id and model id I was getting from flashrom matched the datasheet specs for a particular chip. I downloaded and compiled the crossgcc toolchain. I created a patch for flashrom and proceeded to read my flash. I got a successful read from flashrom and dumped my vgabios. I compiled coreboot for T60 and followed the wiki grabbing the 3 patches for Lenovo stuff and inserting my custom SMBIOS details in the config. Once i felt happy with my coreboot.rom I followed exactly the procedure on the coreboot Lenovo wiki to flash my laptop internally. I have attached here the coreboot config i used, the clues I used to write the flashrom patch, the flashrom patch i wrote, and the flashing log. My current T60 status is "Bricked, in Bucts 1 configuration" I guess my next step is to pull my laptop to bits without removing the CMOS battery and see if the flash chip is indeed the one that I estimated, and perhaps reflash it with coreboot? I'm not too sure what to do next but GNUtoo from #coreboot recommends a poloma clip. Coreboot team were very very helpful in trying everything to help me and warned me right at the start I needed a way to recover. They were right! Damien

6 5

← 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 June 2013