Hi, The debate about e7501 (dropping or risking broken code in the tree) reminded me of an idea I had a while ago: Do we want to establish a list of boards and their latest successfully tested revision, and all maintainers/testers for each board that agree to test changes regularily or on demand (and have the hardware around, of course)? That way, we'd know who to ask if we make sweeping changes that affect the entire tree. The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards. This would help people keeping their local development up to date, and it helps with finding the cause of problems. Basically, everything that affects the whole tree should be documented with: - Rev in which this change appeared - Short explanation what happened (maybe just the URL to the mailing list archive) - Explanation what to change to keep up (incl. scripts, if used) - Developer responsible for it Both of these are only useful if they're generally maintained. Maybe that's too much effort for the gain, so what do you think? Regards, Patrick
On Tue, Feb 23, 2010 at 03:54:41PM +0100, Patrick Georgi wrote:
The debate about e7501 (dropping or risking broken code in the tree) reminded me of an idea I had a while ago:
Do we want to establish a list of boards and their latest successfully tested revision, and all maintainers/testers for each board that agree to test changes regularily or on demand (and have the hardware around, of course)?
That way, we'd know who to ask if we make sweeping changes that affect the entire tree.
In theory nice to have, but experience has shown that this list will be ignored and outdated very very soon: http://www.coreboot.org/Confirmed_working_svn_revisions I personally also don't think such a list is _that_ important to have. In theory _every_ revision should work and as soon as someone finds a bug / nonworking revision we quickly bisect and make trunk working again, so not much point in such a list IMHO.
The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards.
Yep, this idea I like very much!
This would help people keeping their local development up to date, and it helps with finding the cause of problems.
Basically, everything that affects the whole tree should be documented with: - Rev in which this change appeared
Yes.
- Short explanation what happened (maybe just the URL to the mailing list archive)
Yes.
- Explanation what to change to keep up (incl. scripts, if used)
This one is the most important. It should be a "migration guide"-like HOWTO a la "change variable name FOO to BAR", "remove all BAZ occurences in your code" etc. etc.
- Developer responsible for it
Not sure if this makes sense. And/or it's visible from the Signed-off-by anyway in most cases. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Am 23.02.2010 16:43, schrieb Uwe Hermann:
The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards.
Yep, this idea I like very much! I started an attempt here: http://www.coreboot.org/Flag_Days
The name is taken from OpenSolaris, where flag days are events that break compatibility in some way. See http://hub.opensolaris.org/bin/view/Community+Group+on/flag-days Both layout and name can be changed if something better comes across. Consider this a work in progress. Patrick
On Tue, 23 Feb 2010, Patrick Georgi wrote:
Am 23.02.2010 16:43, schrieb Uwe Hermann:
The other list I'd like to start is a document (on the wiki) that explains tree wide changes with the revision in which they happened, what happened, and how to replay those changes on a locally modified tree - esp. those with new boards.
Yep, this idea I like very much! I started an attempt here: http://www.coreboot.org/Flag_Days
I'd like this idea too, at least could make live everyone who rarely svn up his unfinished targets a lot easier. And this problem hit me few times already.
Patrick
Maciej -- Maciej Pijanka I don't fear computers, I fear lack of them -- Isaac Asimov
Hi, Could we have some tag to svn commit like: Signed-off-by... Acked-by: ... And then add: current->works Tag ;) and then make some script which will extract this and place it on wiki... Maybe we can have also current->works_tweaks That something is changed but otherwise it works pretty fine... Rudolf
Could we have some tag to svn commit like:
And then add:
current->works And also the "haha this is broken" tag and maybe the "will fry your mainboard" tag. :)
One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem. Thanks, Myles
On Tue, Feb 23, 2010 at 10:47:21AM -0700, Myles Watson wrote:
Could we have some tag to svn commit like:
And then add:
current->works And also the "haha this is broken" tag and maybe the "will fry your mainboard" tag. :)
One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem.
Boot testing would. The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: dedicating an artec dongle + plcc adapter runs about $350 per board... And then you still need a remote power toggle device (can be had for cheap-ish if you look around a bit) and some sort of serial capture device (or just another computer if it's one or a few boards). If I didn't have to sacrifice a dongle for each board, I'd set up a tyan S2881 and probably one or two alix boards for automated testing. Thanks, Ward.
Am 23.02.2010 20:07, schrieb Ward Vandewege:
If I didn't have to sacrifice a dongle for each board, I'd set up a tyan S2881 and probably one or two alix boards for automated testing. How about using serialice? It's not quite the real thing, but...
Patrick
Ward Vandewege wrote:
The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost:
You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing. These are the features I had in mind; . LPC/FWH/SPI bootable . Serial port for logging BUT (board under test) output . Ideally USB host for USB debug device console . LAN connection . A few GPO pins for power button/reset button/PWROK signalling An ALIX has most of this at a cost that can't be beat. Only booting is missing. Though an FPGA rocks I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port. Thoughts? Did I overlook a cricical feature? Preorders? //Peter
On 23.02.2010 21:14, Peter Stuge wrote:
Ward Vandewege wrote:
The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost:
You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing.
[...] I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port.
Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and of LPC/FWH chips in the near future. Parallel flash chips need some small additional circuitry because the FT2232H doesn't have enough pins for output and can only deliver 3.3V, but that's it. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth
On Wed, Feb 24, 2010 at 12:14:30AM +0100, Carl-Daniel Hailfinger wrote:
On 23.02.2010 21:14, Peter Stuge wrote:
Ward Vandewege wrote:
The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost:
You're not alone. I've wanted to create affordable tester hardware for quite some time now. I think it's the only way we'll get more boot testing.
[...] I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port.
Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and
Oh. That sounds like a much more affordable solution! What kind of hardware would one use to hook the spi chip to the mini module? Some sort of top hat?
of LPC/FWH chips in the near future.
I guess for lpc/fwh (plcc), one of the plcc adapters Peter and Stepan make would do. Thanks, Ward.
Ward Vandewege wrote:
I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port.
Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of)
In-system-programming is worth considering, but for boards with sockets it actually just creates extra work. In any case $30 for flash programming in the tester hardware is way unacceptable. I'm thinking that $10 is already nearly too high cost, but on the other hand it buys a very nice ARM7 with USB, which could be reused also independently of the tester.
What kind of hardware would one use to hook the spi chip to the mini module?
This is the question. Anything socketed is easy, but soldered down chips make it more difficult. For SO-8 I've only seen the IC-CLIP by Pomona, which doesn't attach with a very sturdy connection to chips. :\ //Peter
On 24.02.2010 01:22, Peter Stuge wrote:
Ward Vandewege wrote:
I think a small microcontroller and actual flash chips may be the simplest and cheapest way to do it. The microcontroller is for flashing from ALIX, maybe also GPO pins and serial port.
Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of)
In-system-programming is worth considering, but for boards with sockets it actually just creates extra work. In any case $30 for flash programming in the tester hardware is way unacceptable. I'm
I think Ward mentioned that the cost of a dongle was way higher, so I thought I'd mention something which works right now for SPI and is significantly cheaper than a dongle. Besides that, any testing rig has to be automated unless you're willing to invest boatloads of time per checkin. For that, you either need a dongle or in-system programming.
thinking that $10 is already nearly too high cost, but on the other hand it buys a very nice ARM7 with USB, which could be reused also independently of the tester.
For 6 EUR you can get a FT2232H (chip only), but you have to design a circuit for it. The advantage of the FT2232H is that it speaks SPI natively and reasonable speeds (a few MHz). I know that someone is selling an ATTiny based design to do in-system SPI programming, and it would be easy to code up flashrom support for it. I haven't been able to contact the vendor, though. If you plan to design that hardware yourself, let me list the requirements: For SPI, all you need is 4 GPIOs (CLK/MISO/MOSI/CS). For LPC/FWH, all you need is 6 GPIOs (AD[0-3]/CLK/FRAME). For Parallel, you need a boatload of GPIOs or some demultiplexer. More GPIOs (e.g. HOLD/WP for SPI and RST/ID/WP for LPC/FWH) are always useful, but not a hard requirement. They can be used to speed up programming or make it more reliable. Vcc and GND are not listed above because they are not GPIOs. Flashrom can deal with bitbanging SPI/LPC/FWH/Parallel (not all of them merged yet), or it can drive programmers which understand those protocols and just want higher-level commands (send command xy to flash). The bitbanging variant is obviously slower than a protocol-understanding external programmer. Why am I listing the requirements above? I just want to avoid that someone creates a nice piece of hardware, and afterwards notices that he/she needs to modify the design because some key requirement was overlooked. If you have a proposed design, send the details to flashrom@flashrom.org so that the flashrom developers can have a look and suggest changes (if needed).
What kind of hardware would one use to hook the spi chip to the mini module?
This is the question. Anything socketed is easy, but soldered down chips make it more difficult. For SO-8 I've only seen the IC-CLIP by Pomona, which doesn't attach with a very sturdy connection to chips. :\
There's always the option of soldering a few wires to the pins of the chip. Not exactly a clean solution, but it should work fine if you plan permanent dedication of the machine to the test rig. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth
Carl-Daniel Hailfinger wrote:
avoid that someone creates a nice piece of hardware, and afterwards notices that he/she needs to modify the design because some key requirement was overlooked.
I wouldn't worry. //Peter
Carl-Daniel Hailfinger wrote:
What kind of hardware would one use to hook the spi chip to the
For SO-8 I've only seen the IC-CLIP by Pomona, which doesn't attach with a very sturdy connection to chips. :\
There's always the option of soldering a few wires to the pins
A flex cable with a cutout. It requires a little bit of clearance around the flash chip though, which may not neccessarily be the case. To get an idea of what I mean see: http://www.foundmy.com/oscom/images/fm-d2ckey-flex-cable.jpg //Peter
On 24.02.2010 01:04, Ward Vandewege wrote:
On Wed, Feb 24, 2010 at 12:14:30AM +0100, Carl-Daniel Hailfinger wrote:
Speaking with y flashrom hat on, I'd like to point out that you can use the FT2232H Mini Module (~$30) to perform in-system-programming (well, as long as the machine is powered of) of SPI flash chips right now and
Oh. That sounds like a much more affordable solution! What kind of hardware would one use to hook the spi chip to the mini module? Some sort of top hat?
Basically yes. Or you solder a few wires on top of the chip pins.
of LPC/FWH chips in the near future.
I guess for lpc/fwh (plcc), one of the plcc adapters Peter and Stepan make would do.
Note that my suggestion does not perform flash emulation like the dongle, it only provides a way to write chips with an external programmer. Due to that, the PLCC adapters make it easier to connect to the pins of the chip socket (if there is a socket), but you'll have to stack a reverse adapter on top which has a flash chip inside. Or you use a top-hat style adapter and plug the PLCC adapter in it. The common requirement is to keep the flash chip attached to the board in a way that allows booting. Regards, Carl-Daniel -- "I do consider assignment statements and pointer variables to be among computer science's most valuable treasures." -- Donald E. Knuth
On Tue, Feb 23, 2010 at 12:07 PM, Ward Vandewege <ward@gnu.org> wrote:
On Tue, Feb 23, 2010 at 10:47:21AM -0700, Myles Watson wrote:
Could we have some tag to svn commit like:
And then add:
current->works And also the "haha this is broken" tag and maybe the "will fry your mainboard" tag. :)
One problem is that commits that are board-specific hopefully result in a working board. The problem is that they break other boards that weren't tested (or other payloads on the same board). I don't think there's a way around that basic problem.
Boot testing would.
The automatic testing framework Stepan built a few years ago - I'd love to get a few boards set up for that. I have some boards lying around that could be used for that. My main problem is cost: dedicating an artec dongle + plcc adapter runs about $350 per board... And then you still need a remote power toggle device (can be had for cheap-ish if you look around a bit) and some sort of serial capture device (or just another computer if it's one or a few boards).
Your S2881 could host a framework for qemu, AMD serengeti, and AMD serengeti_fam10. Having the three simulators working would be a start. I have no idea how hard it is to hook a simulator into the framework. Thanks, Myles
participants (8)
-
Carl-Daniel Hailfinger -
Maciej Pijanka -
Myles Watson -
Patrick Georgi -
Peter Stuge -
Rudolf Marek -
Uwe Hermann -
Ward Vandewege