Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "zbao" checked in revision 4385 to
the coreboot repository. This caused the following
Add AMD family 10 AM2r2 support.
Coreboot used to take SYSTEM_TYPE as a lable to tell what the socket is.
This patch replaces (some of, not all) CONFIG_SYSTEM_TYPE with CONFIG_SOCKET_TYPE.
It also fix some compiling error in src/northbridge/amd/amdmct/mct/mctardk4.c
Signed-off-by: Zheng Bao <zheng.bao(a)amd.com>
Acked-by: Marc Jones <marcj303(a)gmail.com>
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4385&device=sandpointx3_...
Compilation of via:epia-m700 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4385&device=epia-m700&ve...
If something broke during this checkin please be a pain
in zbao's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
coreboot automatic build system
AFAICS the time has come to give flashrom its own mailing list (maybe
flashrom(a)coreboot.org) and IRC channel (irc.freenode.net/#flashrom).
I do realize this has been brought up in the past, but while I was
sceptical back then, I realized that the times have changed in the last
The release of flashrom 0.9.0 has increased both visiblity and user
base, resulting in a sizable portion of list and chat traffic to be
related to flashrom.
Some of us are only interested in coreboot, while others are only
interested in flashrom. Since filtering mails according to subject can
introduce lots of errors, having two separate lists would make watching
one one of flashrom/coreboot easier.
List traffic over the last few years:
2007: 29 mails/day
2008: 41 mails/day
2009: 36 mails/day
Although the list traffic has not yet reached linux-kernel levels, it is
already too much to read in full. I hope splitting the lists will allow
people to concentrate on their personal area of interest and also
encourage more reviews. After all, if you have to read less mails, you
can respond to more of them.
One issue to solve is how we want to handle flashrom success/failure
reports sent to flashrom(a)coreboot.org. Right now they end up on an
unmoderated private list. After the change, they'd get a message that
the list is moderated. This might discourage users, so we have to think
of a nice moderation message, possibly mentioning that emergency help
for broken flash is available on IRC.
The suggested way forward is outlined below:
1. Register #flashrom on irc.freenode.net (done)
2. Invite parties interested in flashrom to join #flashrom besides
3. Pre-Announce the mailing list split with the following text:
"coreboot(a)coreboot.org will be split in two lists. flashrom(a)coreboot.org
is where flashrom development and usage will be discussed.
coreboot(a)coreboot.org will carry all traffic not related to flashrom.
coreboot(a)coreboot.org list members will be subscribed automatically to
flashrom(a)coreboot.org. If you are only interested in either coreboot or
flashrom, feel free to unsubscribe from either list once the split is done."
4. Wait a week for protests etc.
5. Create a new mailing list flashrom(a)coreboot.org with the same
subscribers as coreboot(a)coreboot.org.
6. Announce the mailing list split with the following text:
"coreboot(a)coreboot.org has been split in two lists.
flashrom(a)coreboot.org is where flashrom development and usage are
discussed from now own. coreboot(a)coreboot.org carries all traffic not
related to flashrom. coreboot(a)coreboot.org list members have been
subscribed automatically to flashrom(a)coreboot.org. If you are only
interested in either coreboot or flashrom, feel free to unsubscribe from
These are the changes I had to do the flashrom to get my in circuit
programer working. Not much as you can see.
Unfortunately it seems to have problems writing to the chip. The first
time I tried it it worked well. Writing random data to the chip. But
when I then tried to write the bios image. After several tries, adding
more capacitors, increasing the bus speed (yes increasing not
decreasing) and always erasing the chip before doing a write I got
good write. There where a couple of write runs that seems to be get
partial success, parts of the bios looked okay while parts where still
all FF. Increasing the bus speed seemed to make it write more data.
I have some pictures of the programer here:
Signed-off-by: Jakob Bornecrantz <wallbraker(a)gmail.com>