I've been playing about with trying to autobuild all the available
targets, to catch regressions, or more relevantly to convince myself
that when things are broken it's not just EPIA-M that's affected.
is what I've got so far.
1987/ is pre gcc4 fix, so 1989/ is more interesting.
All 12 Tyan boards built, leaving 18 that didn't.
amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
with elf payloads (the directories they look for the payload in aren't
convenient for an enclosed build - does anyone object if I clean this
embeddedplanet-ep405pc & motorola-sandpoint are both PPC so won't build
via-epia-m, Iwill-dk8s2, totalimpact-briq, technologic-ts5300 and
newisys-khepri all failed to have a config file that buildtarget was
via-epia, digitallogic-adl855pc, digitallogic-msm586seg, eaglelion-5bcm
& emulation-qemu-i386 all have problems with udelay.
amd-serenade has an error I don't quite understand.
island-aruma has a non-standard build dir so it doesn't get picked up.
Again this is something I'll fix up in the config file unless I hear
I've got my EPIA-M code to the point where it's hitting the udelay
problem various other ports have. I haven't quite tracked down what
other change has made this happen though. EPIA was certainly building a
month or so ago from the tree when I tried it.
Hell hath no fury like the lawyer of a woman scorned.
If you need an unified format, use this.
And, what this does is, basically, minimize erasing and writing.
I found that byte of W49 changes after verifing of the byte passed.
Probably, it is due to be affected by wrinting of another byte.
So, basic idea is like this.
1. write normally in the first run.
2. write only error bytes after second run without erasing.
As you know, bits of flash are 1 when erased and writing changes only 1 -> 0.
So, my way can be applied only if you need to change 1 -> 0.
But, all cases I have found are this case.
And, this is just a quick hack, not such a good solution.
I think this way can be applied to even the first run.
Why you do erasing -> writing sequence if all data in a sector is
just same as what you want to write?
--- Okajima, Jun.
An attached file is a quick hack to burn my RD1.
Use like this.
Assuming you put SST39SF020A or at least, not W49F002U on a socket.
The first burn:
flash_rom -t W49F002U -wv BIOS.IMG
If not verified:
flash_rom -t W49F002U -Fwv BIOS.IMG
(repeat this until verified.)
do # flash_rom -v BIOS.IMG again to make doubly sure.
-t option does not affect chip probing. Avoiding just in case that
you miss to set a select switch rightly.
If your swich is set to "ORG", and you put SST chip on a socket,
it fails when you add "-t W49F002U".
Hope an attached file can be sent on this ML.
--- Okajima, Jun. Tokyo, Japan.
I've run into an interesting problem doing some "bait and switch" with my
I have machine code for an x86 program that expects to run in protected
mode. It's not an ELF file, so I can't load it directly with elfboot().
What I'm doing for the time being is having elfboot load Etherboot, with
the emulator set to break at the Etherboot entry address. When the
breakpoint is hit I load the machine code into memory and change EIP to
its entry point. (Ultimately I'll probably create an ELF wrapper for this
code, but I don't have one yet).
My machine code gets a protection exception when it tries to set one of
the segment registers (to the value it already has, BTW). I traced this to
the fact that Etherboot was loaded on top of the GDT used by LinuxBIOS.
We can argue about what kind of assumptions payloads should make about
their runtime environment, but it seems to me that being in protected mode
without a GDT is a bomb waiting to go off. Some payloads are bound to do
things in a sequence that causes an explosion.
Can we move the GDT within the memory LB reports as unusable, say, before
I've found that since Debian upgraded the default GCC to 4 romcc doesn't
compile any more. The attached trivial patch fixes this. I don't see how
it could break anything, but let me know if you can see any issues with
If I want to hear the pitter patter of little feet, I'll put shoes on
Probably, most guys here use BIOS Saver.
And it works well?
In mine, RD1 for PLCC gets not being writable suddenly.
I mean, it seems writable but # flash_rom -v fails.
I solved this problem by a quick hack.
How about yours? You can write RD1 or W49F002U well?
Any problem happen?
BTW, a cable of your RD1 is not broken?
I needed soldering to fix it.
Just hold these dates: october 11-13, 2005
We've arranged for the lacsi symposium, in santa fe:
http://lacsi.rice.edu/symposium/ to set up 2.5 days for a linuxbios
summit. The info on the linuxbios track, hotels, etc. should be on that
web page later today or tomorrow. We hope to have vendor talks, and
discussions on where we as a community are going with linuxbios.
The time of year is nice in santa fe, new mexico is beautiful, the food is
great, the hotel is very pleasant: do consider coming! We'd like to see
all of you folks out here.
Vendors on this list, if you have something you'd like to talk about,
please get back to me.
I've started looking at moving my EPIA-M patches over to the new svn
trunk from my arch repo. However, rather than end up with one huge patch
at the end that needs committed I figure it'd be better to submit
patches as I go along; makes it easier for me to track mainline and also
for anyone else to pickup from where I've got to.
So, what's the best way for me to submit patches, or is there any way I
can get commit access to check in things myself?
Do you know any phreaks who carry around their own trunks.
Here's the information. This is a very nice hotel, in a nice town (Santa
Fe), so I think we'll have a great time. If you plan to bring hardware
or need anything special, let me know.
The LinuxBIOS Summit will be at the 2005 LACSI Symposium, October 11-13,
2005 in Santa Fe, New Mexico USA. See lacsi.rice.edu/symposium. We will
begin as a full-day workshop (among nine others) on the Symposium's
first day (October 11). Then we'll have another 1.5 days to meet in
parallel with the Symposium.
Register for the LACSI Symposium at
and select the LinuxBIOS Summit as your preferred workshop. You'll have
all the perquisites of a Symposium attendee (access to all workshops,
reception, research presentations, panels, proceedings) as well as to
the LinuxBIOS Summit meetings. Registration is $350 until September 5,
then $400 until October 5 or on-site. There are also student rates.
Rooms are reserved in the "LACSI" block at the Eldorado Hotel in
Santa Fe, NM USA. You may reserve a room at the Conference
Registration page (see "Hotel Reservation Form), or by calling
800.955.4455. Single rooms are $94, doubles are $114 (plus tax).