How is LinuxTag 2008 going Peter, Paul, and Carl-Daniel? Are you getting alot of people excited about coreboot?
Dear list,
Am Donnerstag, den 29.05.2008, 13:39 -0400 schrieb Joseph Smith:
How is LinuxTag 2008 going Peter, Paul, and Carl-Daniel?
Pierre, who offered his help with the booth and is considered a spammer by trac, is also presenting coreboot.
Are you getting alot of people excited about coreboot?
So I will try to give a quick summary of the first two days. I was there about 70 % of it.
- Peter is talking a lot to people. As evidence he is gravelly. Especially after the workshop/talk he gave today.
- The booth is really small and located in the embedded area. Peter brought the GA-M57SLI-S4 SPI and alix1c and their output is displayed variantly on a monitor over Peter’s monitor switch. Most of the time bayou with coreinfo, tint and filo is shown on the alix1c.
I would guess that we talk to about 4–6 people in an hour. But since we are talking to them about 10 minutes the booth is busy most of the time and it would be rather crowded if more people are there. There knowledge on coreboot varies. Even more because of the name change early this year. So the strategy is like
1. Show them how fast it is on by resetting the GA-M57SLI-S4 SPI.
2. Tell them a little bit more about coreboot and some advantages from Carl-Daniel’s list (mainly speed, free software, C code, English error messages).
3. Often answer their question: „How risky is this.”
4. Tell them to look at the website to see if their motherboard is supported.
5. Tell them about flashrom.
6. Give them a flyer with information about coreboot, the website and the list.
Some people have already seen the project last year and have quiet some knowledge about the hardware. Then I need the help from Peter.
1. One guy said there is a well-known problem with the alix1c, that the temperature sensors are not calibrated correctly and asked if that is fixed when using coreboot.
2. Another guy was thinking about a NAS-Device with a Celeron processor. But he will come back some other time, because Peter or Carl-Daniel were busy with the workshop then.
- Although the booth is small and there is not enough room that more than four people have room around the booth, I believe that a lot of people are passing by, because their are just two bare boards sitting on the table and the monitor is displaying a ncurses-menu. The poster has also only coreboot on it. So we do not have a real eye-catcher. Maybe we should hack a screensaver payload which just displays „Want to boot faster?”, „Free your BIOS?” and so on in big ASCII on the monitor or write it on the poster.
When they see the demonstration, they are a little bit more excited. And some even want to take a deeper look at it.
There are also not so many business guys running around—especially no mainboard vendors. So I guess the main objective is, to make coreboot more known to the world and probably attract some potential developers.
If you have some more marketing ideas or objectives, please tell me/us.
- Each of Peter (English) and Carl-Daniel (German) gave a talk/workshop on flashrom today. I listened to the one of Carl-Daniel and there were about 15 people.
- Presenters are supplied with sandwiches (rolls) and some fruit for lunch. I liked, but I do not know, what it is compared to other fairs.
- Carl-Daniel arrived today. But it looks like he left his alix1c board in the cardboard in the workshop room and it was not there anymore when we came back. Hopefully we will find it or the one who took it brings it to the lost-and-found office, because that was the only presentation board, when Peter is leaving tomorrow. And Carl-Daniel is going to have a workshop with this board on Saturday.
Ok, that is it for now. I think I missed a lot and hopefully I did not write wrong stuff. I am enjoying it very much and I really like how nice you guys are also in “reality”, i. e. face to face. It is a real pleasure.
Greeting from Berlin,
Paul
On Thu, 29 May 2008 22:02:23 +0200, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear list,
Am Donnerstag, den 29.05.2008, 13:39 -0400 schrieb Joseph Smith:
How is LinuxTag 2008 going Peter, Paul, and Carl-Daniel?
Pierre, who offered his help with the booth and is considered a spammer by trac, is also presenting coreboot.
Are you getting alot of people excited about coreboot?
So I will try to give a quick summary of the first two days. I was there about 70 % of it.
- Peter is talking a lot to people. As evidence he is gravelly.
Especially after the workshop/talk he gave today.
- The booth is really small and located in the embedded area. Peter
brought the GA-M57SLI-S4 SPI and alix1c and their output is displayed variantly on a monitor over Peter’s monitor switch. Most of the time bayou with coreinfo, tint and filo is shown on the alix1c.
I would guess that we talk to about 4–6 people in an hour. But since we are talking to them about 10 minutes the booth is busy most of the time and it would be rather crowded if more people are there. There knowledge on coreboot varies. Even more because of the name change early this year. So the strategy is like
Show them how fast it is on by resetting the GA-M57SLI-S4 SPI.
Tell them a little bit more about coreboot and some advantages from
Carl-Daniel’s list (mainly speed, free software, C code, English error messages).
Often answer their question: „How risky is this.”
Tell them to look at the website to see if their motherboard is
supported.
Tell them about flashrom.
Give them a flyer with information about coreboot, the website and
the list.
Some people have already seen the project last year and have quiet some knowledge about the hardware. Then I need the help from Peter.
- One guy said there is a well-known problem with the alix1c, that the
temperature sensors are not calibrated correctly and asked if that is fixed when using coreboot.
- Another guy was thinking about a NAS-Device with a Celeron processor.
But he will come back some other time, because Peter or Carl-Daniel were busy with the workshop then.
- Although the booth is small and there is not enough room that more
than four people have room around the booth, I believe that a lot of people are passing by, because their are just two bare boards sitting on the table and the monitor is displaying a ncurses-menu. The poster has also only coreboot on it. So we do not have a real eye-catcher. Maybe we should hack a screensaver payload which just displays „Want to boot faster?”, „Free your BIOS?” and so on in big ASCII on the monitor
or
write it on the poster.
When they see the demonstration, they are a little bit more excited. And some even want to take a deeper look at it.
There are also not so many business guys running around—especially no mainboard vendors. So I guess the main objective is, to make coreboot more known to the world and probably attract some potential developers.
If you have some more marketing ideas or objectives, please tell me/us.
- Each of Peter (English) and Carl-Daniel (German) gave a talk/workshop
on flashrom today. I listened to the one of Carl-Daniel and there were about 15 people.
- Presenters are supplied with sandwiches (rolls) and some fruit for
lunch. I liked, but I do not know, what it is compared to other fairs.
- Carl-Daniel arrived today. But it looks like he left his alix1c board
in the cardboard in the workshop room and it was not there anymore when we came back. Hopefully we will find it or the one who took it brings it to the lost-and-found office, because that was the only presentation board, when Peter is leaving tomorrow. And Carl-Daniel is going to have a workshop with this board on Saturday.
Ok, that is it for now. I think I missed a lot and hopefully I did not write wrong stuff. I am enjoying it very much and I really like how nice you guys are also in “reality”, i. e. face to face. It is a real pleasure.
Greeting from Berlin,
Paul
Thanks for the update Paul:-)
Wow, wonderful job to all at LInuxTag! Thanks to you all!
I just ran the bayou demo and it is really impressive. I wonder if there is anything else like it? It's really neat.
thanks
ron
On 29/05/08 14:58 -0700, ron minnich wrote:
Wow, wonderful job to all at LInuxTag! Thanks to you all!
I just ran the bayou demo and it is really impressive. I wonder if there is anything else like it? It's really neat.
Thanks. There is still much to be done, but I think this is a pretty good start.. :) To that end, let me solicit the help of the community to think about the next step.
As a group we have identified two main behaviors for the chooser:
* An interactive menu * Chaining (running one payload after another in the fashion of a traditional BIOS)
But when you look closer, the number of possible modes explodes. As an example:
- You may want to add a timeout to the menu, so that if somebody doesn't press the hotkey, a default payload is chosen. - When chaining, some payloads will be opt in (press F1 for setup), some will be opt out (press F2 to skip), and others will always run - Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
So, this is a very long and complex way of saying that we need a simple yet clever way to configure bayou that takes into account all of the above. Any ideas?
Jordan
- You may want to add a timeout to the menu, so that if somebody doesn't
press the hotkey, a default payload is chosen.
I think a timeout with a specified default is a great idea:-)
- When chaining, some payloads will be opt in (press F1 for setup), some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Chaining is a great idea also. It could be specified with a 1,2,3,4,5 option line with 1 being first and 5 being last. My question about this is with chaining, how is bayou and or the payload going to know when to break and move on to the next payload?? Will we have to modify all of the payloads to break and return to bayou on a error or interactive message? Something like "This payload is not able to complete sucessfully. Would you like to return to bayou and run your next choosen payload[Y/n]?"
Just a thought.
On 30/05/08 18:06 -0400, Joseph Smith wrote:
Chaining is a great idea also. It could be specified with a 1,2,3,4,5 option line with 1 being first and 5 being last. My question about this is with chaining, how is bayou and or the payload going to know when to break and move on to the next payload?? Will we have to modify all of the payloads to break and return to bayou on a error or interactive message? Something like "This payload is not able to complete successfully. Would you like to return to bayou and run your next choosen payload[Y/n]?"
Clearly if you want a chain of N payloads, then you are going to need to have N-1 payloads that cleanly return. Thats just going to have to be one of those assumptions that we can't change.
I would prefer to keep each payload as standalone as possible - they shouldn't have to know they are being managed by the chooser. So, yes, if the payload errors out and you want bayou to know about it, then you'll have to make sure it returns an error code of some sort. Again, this is reasonable, and easily managed with libpayload.
Jordan
But when you look closer, the number of possible modes explodes. As an example:
- You may want to add a timeout to the menu, so that if somebody doesn't
press the hotkey, a default payload is chosen.
- When chaining, some payloads will be opt in (press F1 for setup), some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
How about the name of the lar entry for the payload (since we can store the user-friendly name in the notes.) The default payload is the one named "payload" or "normal" or "default". Then any number of payloads with their attributes can be added, but the default still works.
Thanks, Myles
On 30/05/08 16:59 -0600, Myles Watson wrote:
But when you look closer, the number of possible modes explodes. As an example:
- You may want to add a timeout to the menu, so that if somebody doesn't
press the hotkey, a default payload is chosen.
- When chaining, some payloads will be opt in (press F1 for setup), some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
How about the name of the lar entry for the payload (since we can store the user-friendly name in the notes.) The default payload is the one named "payload" or "normal" or "default". Then any number of payloads with their attributes can be added, but the default still works.
I like this, but allow me to play devil's advocate for a second. There might be a few flies in the ointment. The dynamic nature of LAR forces us to consider complex scenarios that otherwise wouldn't be a factor. What if you want to change the default payload? If the name isn't shorter then payloads/default, then there will be much shifting of bytes, which is dangerous on the ROM (or rather, no less dangerous then writing a new ROM).
The other thing that concerns me is that the person building the LAR needs to make the conscious decision to name one of the payloads payload/default. Sure we could make the LAR binary handle the magic, but that would be just another flag in a cast of thousands. We already experience a bit of this pain already. In lieu of a magic number in the LAR header or in the SELF header, bayou currently checks for the name prefix 'payload/' and assumes that is a payload. I have already forgotten to append 'payload/' several times (until I got the Makefile to do it for me). I believe that this will cause problems down the road - not everybody will be using buildrom.
All that said, I think that this is the best suggestion so far - it is easy to implement, and at least gets us further down the path.
Jordan
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Monday, June 02, 2008 5:48 PM To: Myles Watson Cc: 'ron minnich'; coreboot@coreboot.org Subject: Re: LinuxTag 2008 Status
On 30/05/08 16:59 -0600, Myles Watson wrote:
But when you look closer, the number of possible modes explodes. As
an
example:
- You may want to add a timeout to the menu, so that if somebody
doesn't
press the hotkey, a default payload is chosen.
- When chaining, some payloads will be opt in (press F1 for setup),
some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
How about the name of the lar entry for the payload (since we can store
the
user-friendly name in the notes.) The default payload is the one named "payload" or "normal" or "default". Then any number of payloads with
their
attributes can be added, but the default still works.
I like this, but allow me to play devil's advocate for a second. There might be a few flies in the ointment. The dynamic nature of LAR forces us to consider complex scenarios that otherwise wouldn't be a factor. What if you want to change the default payload? If the name isn't shorter then payloads/default, then there will be much shifting of bytes, which is dangerous on the ROM (or rather, no less dangerous then writing a new ROM).
Right now we don't do partial writes, do we? If we did, this isn't dangerous as long as we rewrite the entire lar entry, is it?
The other thing that concerns me is that the person building the LAR needs to make the conscious decision to name one of the payloads payload/default.
No matter what we choose to do, the user will have to make a conscious decision about which payload is default. If there isn't a default it will still work, and they'll be more careful next time they build the ROM. :)
Sure we could make the LAR binary handle the magic, but that would be just another flag in a cast of thousands. We already experience a bit of this pain already. In lieu of a magic number in the LAR header or in the SELF header, bayou currently checks for the name prefix 'payload/' and assumes that is a payload. I have already forgotten to append 'payload/' several times (until I got the Makefile to do it for me). I believe that this will cause problems down the road - not everybody will be using buildrom.
You're right, we still have considerable evangelism to do.
All that said, I think that this is the best suggestion so far - it is easy to implement, and at least gets us further down the path.
I'm looking forward to seeing the next incarnation.
Thanks, Myles
On 03/06/08 13:03 -0600, Myles Watson wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Monday, June 02, 2008 5:48 PM To: Myles Watson Cc: 'ron minnich'; coreboot@coreboot.org Subject: Re: LinuxTag 2008 Status
On 30/05/08 16:59 -0600, Myles Watson wrote:
But when you look closer, the number of possible modes explodes. As
an
example:
- You may want to add a timeout to the menu, so that if somebody
doesn't
press the hotkey, a default payload is chosen.
- When chaining, some payloads will be opt in (press F1 for setup),
some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
How about the name of the lar entry for the payload (since we can store
the
user-friendly name in the notes.) The default payload is the one named "payload" or "normal" or "default". Then any number of payloads with
their
attributes can be added, but the default still works.
I like this, but allow me to play devil's advocate for a second. There might be a few flies in the ointment. The dynamic nature of LAR forces us to consider complex scenarios that otherwise wouldn't be a factor. What if you want to change the default payload? If the name isn't shorter then payloads/default, then there will be much shifting of bytes, which is dangerous on the ROM (or rather, no less dangerous then writing a new ROM).
Right now we don't do partial writes, do we? If we did, this isn't dangerous as long as we rewrite the entire lar entry, is it?
You are right, we don't do partial writes right now, but it is the 800 pound gorilla in the room. Everything about the design of LAR is based around the concept of partial writes, so we really can't ignore it.
One of our problems is that we have made partial writes a high priority, but we haven't clearly defined how they are going to work. Adding new code to an existing ROM isn't a difficult concept, but when it comes to changing or replacing blobs, it gets very vague, and IMHO very scary. None of our current v3 platforms support fallback, so just one blown sector is death, even if LAR can detect it and print a "gee, we're sorry but the ROM is corrupted message". I am having trouble being convinced that this is any safer then writing a full ROM, but thats off-topic for this message.
The point is that we have to always be aware that the LAR could change from boot to boot. If we need to support a dynamic LAR, then we need to keep the bayou related complexity to a minimum, or at least as low as the circumstances will allow.
The other thing that concerns me is that the person building the LAR needs to make the conscious decision to name one of the payloads payload/default.
No matter what we choose to do, the user will have to make a conscious decision about which payload is default. If there isn't a default it will still work, and they'll be more careful next time they build the ROM. :)
Indeed. But I think my main concern is that on one hand we treat payloads like any other LAR blob, but on the other hand we put restrictions on the name and make it the developers burden to get it right.
Sure we could make the LAR binary handle the magic, but that would be just another flag in a cast of thousands. We already experience a bit of this pain already. In lieu of a magic number in the LAR header or in the SELF header, bayou currently checks for the name prefix 'payload/' and assumes that is a payload. I have already forgotten to append 'payload/' several times (until I got the Makefile to do it for me). I believe that this will cause problems down the road - not everybody will be using buildrom.
You're right, we still have considerable evangelism to do.
I like your moxie! :)
Jordan
Right now we don't do partial writes, do we? If we did, this isn't dangerous as long as we rewrite the entire lar entry, is it?
You are right, we don't do partial writes right now, but it is the 800 pound gorilla in the room. Everything about the design of LAR is based around the concept of partial writes, so we really can't ignore it.
One of our problems is that we have made partial writes a high priority, but we haven't clearly defined how they are going to work. Adding new code to an existing ROM isn't a difficult concept, but when it comes to changing or replacing blobs, it gets very vague, and IMHO very scary. None of our current v3 platforms support fallback, so just one blown sector is death, even if LAR can detect it and print a "gee, we're sorry but the ROM is corrupted message". I am having trouble being convinced that this is any safer then writing a full ROM, but thats off-topic for this message.
The point is that we have to always be aware that the LAR could change from boot to boot. If we need to support a dynamic LAR, then we need to keep the bayou related complexity to a minimum, or at least as low as the circumstances will allow.
It seems like supporting partial writes means knowing the details that right now only flashrom knows. Maybe we should bite off a smaller chunk and make flashrom support partial writes. In other words we create a valid LAR updated however the user wanted, make sure they know if they're changing the bootblock or something else that's critical, and then let flashrom only write the portions that have changed. That way we keep the details where they belong.
Thanks, Myles
On 30.05.2008 22:44, Jordan Crouse wrote:
On 29/05/08 14:58 -0700, ron minnich wrote:
Wow, wonderful job to all at LInuxTag! Thanks to you all!
I just ran the bayou demo and it is really impressive. I wonder if there is anything else like it? It's really neat.
Thanks. There is still much to be done, but I think this is a pretty good start.. :) To that end, let me solicit the help of the community to think about the next step.
As a group we have identified two main behaviors for the chooser:
- An interactive menu
- Chaining (running one payload after another in the fashion of a
traditional BIOS)
Absolutely.
But when you look closer, the number of possible modes explodes. As an example:
- You may want to add a timeout to the menu, so that if somebody doesn't
press the hotkey, a default payload is chosen.
Reasonable.
- When chaining, some payloads will be opt in (press F1 for setup), some
will be opt out (press F2 to skip), and others will always run
Reasonable as well.
- Uwe expressed a desire to select a chain from the menu
No offense, but IMHO that is a bit overboard.
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
Maybe just store a default configuration at compile time and retrieve settings from NVRAM or from a continuously-changing zone in flash?
So, this is a very long and complex way of saying that we need a simple yet clever way to configure bayou that takes into account all of the above. Any ideas?
See above.
Regards, Carl-Daniel
On 01/06/08 17:48 +0200, Carl-Daniel Hailfinger wrote:
- Uwe expressed a desire to select a chain from the menu
No offense, but IMHO that is a bit overboard.
Not as overboard as it might sound though - say for example that we make a payload specifically to populate the legacy tables. A boot menu could offer the choice between Windows and Linux, and if you chose the Windows path it would run the legacy table payload followed by the windows loader, while the Linux path would just run grub2 (or FILO). Its not a crazy idea, and its the sort of thing we need to be prepared for.
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
Maybe just store a default configuration at compile time and retrieve settings from NVRAM or from a continuously-changing zone in flash?
Sure, but lets get more technical - how is this going to work? Who is going to write the configuration? How would one change the configuration (probably at the same time they are adding something to the LAR?). Should we have a simple text file on the ROM? XML? Something else? Many questions, few answers.
Jordan
- Uwe expressed a desire to select a chain from the menu
No offense, but IMHO that is a bit overboard.
Not as overboard as it might sound though - say for example that we make a payload specifically to populate the legacy tables. A boot menu could offer the choice between Windows and Linux, and if you chose the Windows path it would run the legacy table payload followed by the windows loader, while the Linux path would just run grub2 (or FILO). Its not a crazy idea, and its the sort of thing we need to be prepared for.
I really like this idea :-)
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Hi all,
On 29.05.2008 22:02, Paul Menzel wrote:
Am Donnerstag, den 29.05.2008, 13:39 -0400 schrieb Joseph Smith:
How is LinuxTag 2008 going Peter, Paul, and Carl-Daniel?
Pierre, who offered his help with the booth and is considered a spammer by trac, is also presenting coreboot.
We were a team of four for most of the time. Thanks again to Paul and Pierre for helping us out, they were a pleasure to work with! There was some sort of "collateral damage", though: I believe Paul and Pierre now know a lot more about coreboot. ;-)
Are you getting alot of people excited about coreboot?
So I will try to give a quick summary of the first two days. I was there about 70 % of it.
- Peter is talking a lot to people. As evidence he is gravelly.
Especially after the workshop/talk he gave today.
His voice recovered. Sort of.
I would guess that we talk to about 4–6 people in an hour. But since we are talking to them about 10 minutes the booth is busy most of the time and it would be rather crowded if more people are there.
To be honest, we could have talked to more people if we had been given more than 2 m^2 booth space with the space available for presentation in front being 1 m wide.
There knowledge on coreboot varies. Even more because of the name change early this year.
I had multiple companies/public sector institutions tell me to not bother telling them about coreboot because "we are already investigating LinuxBIOS". When I pointed out the recent name change, they invariably asked why we didn't advertise the old name on our flyers/posters as well. I then pointed out the difficulties we had with "Linux" and "BIOS" in the name and they understood that. Still, I'd like to keep the old name around for some time to come, at least on posters (smaller font etc.).
Some people have already seen the project last year and have quiet some knowledge about the hardware. Then I need the help from Peter.
To be honest, Paul is a very fast learner and answered even difficult questions about hardware support and architecture and he covered the booth alone for extended periods of time.
- Another guy was thinking about a NAS-Device with a Celeron processor.
But he will come back some other time, because Peter or Carl-Daniel were busy with the workshop then.
That actually sort of worked out. This person will join the list and inquire further.
- Although the booth is small and there is not enough room that more
than four people have room around the booth, I believe that a lot of people are passing by, because their are just two bare boards sitting on the table and the monitor is displaying a ncurses-menu. The poster has also only coreboot on it. So we do not have a real eye-catcher. Maybe we should hack a screensaver payload which just displays „Want to boot faster?”, „Free your BIOS?” and so on in big ASCII on the monitor or write it on the poster.
We need to capitalize further on our instant boot ability. It was the feature that impressed people the most. It was also a much-praised feature in the radio interview I did on Friday. The interviewer said that living directly below the roof in summer was only bearable if one could turn the computers off to reduce heating and get instant boot on demand.
When they see the demonstration, they are a little bit more excited. And some even want to take a deeper look at it.
Indeed.
There are also not so many business guys running around—especially no mainboard vendors. So I guess the main objective is, to make coreboot more known to the world and probably attract some potential developers.
To be honest, a quite sizable percentage of people stopping by our booth were developers exhibiting with other projects, so I'd say we got some opinion leaders interested.
If you have some more marketing ideas or objectives, please tell me/us.
- Each of Peter (English) and Carl-Daniel (German) gave a talk/workshop
on flashrom today. I listened to the one of Carl-Daniel and there were about 15 people.
Yes, the turnout was way lower than expected, probably due to the fact that even we as speakers were having difficulties finding the room. The only advertisements for the workshops I could find were directly in front of the rooms where the workshops happened, and these rooms were on floors where nothing else happened.
Advice for anybody considering a speaking/tutorial engagement at next year's LinuxTag: Submit a talk+paper and don't bother with workshops.
- Carl-Daniel arrived today. But it looks like he left his alix1c board
in the cardboard in the workshop room and it was not there anymore when we came back. Hopefully we will find it or the one who took it brings it to the lost-and-found office, because that was the only presentation board, when Peter is leaving tomorrow. And Carl-Daniel is going to have a workshop with this board on Saturday.
The board was recovered on Saturday evening. Someone had picked it up and threw it over the walls of the locked back room of our booth. Thanks to that anonymous kind finder.
And Peter's flight was overbooked, so he had to stay in Berlin. That way we could handle the coreboot workshop together. Thanks, Peter! By the way, the coreboot workshop had even less attendance (~8 persons) than the flashrom workshop, but at least one person brought a board, although that board was unsupported (alix.2c2). The great thing is that we got coreboot to run mostly fine, just some interrupts seemed to be screwed. Still, that person is going to join the list and probably work on finishing the port.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Joseph Smith -
Myles Watson -
Paul Menzel -
ron minnich