I searched the linux kernel mail archive and found your
patch for x86 boot linuxbios support, but I didn't find the
linuxbios table parse code in linux-18.104.22.168, does linux kernel
still parse the linuxbios table now?
Apologies if this is a redundant contribution.
None of my pc motherboards have JTAG or HW debug capabilites.
And constantly (hot)flashing, changing ram init code, then (hot)flashing again
gets old really fast.
Looking around, I couldnt find any debug tools that would operate at
basically the reset vector level. I thought this was the goal of openbios,
but I got lost in all the jibberish about 4th and firmware standards.
So I set out to make a small interactive low level shell with the goal
of providing at least some tools to aid in board/memory bringup and debugging.
This was nontrivial given the system limitations, however I got a few
things to work.
Attached is llshell.inc (for linuxbios1, Ive not tried any of the new
stuff yet) and llshell_linux (for running/testing inside of linux).
It's written entirely in asm and can run in a memoryless early stage
(say at the beginning of ram_set_registers or points afterword).
List of commands:
beep -- pc speaker beep
rst (or RST) -- reset
out(b,w,l) <val> <port> -- raw out val at port
in(b,w,l) <port> -- show raw port value
jmp <address> -- jmp to address (llshell addr is in eax)
call <address> -- funcion call (assumes a working stack)
cli -- clear interrupts
sti -- enable interrupts
push <value> -- push value onto stack
pop -- pop from stack and display
wm(b,w,l) <addr> <val> -- write mem
dm <addr> <lines> -- dump mem
mcp <src> <dst> <size> -- mem copy
mpat <pat> <dst> <size> -- mem pattern
memt <begin> <end> -- memory test
pcir(b,w,l) <loc> -- pci read config
pciw(b,w,l) <loc> <val> -- pci write config
dl <addr> <size> -- memory download (display xor cheksum at completion)
cram <addr> <size> -- enable cache to be ram (experimental)
baud <val> -- change baudrate (not yet implemented)
exit -- exit shell
All values in hex (0x prefixing ok)
His MB has E7501 ....
So first step is make freebios2 work on that.
He may need to copy Tyan S2735 to make his MB copy at first. Then he .....
From: Ronald G. Minnich [mailto:firstname.lastname@example.org]
Sent: Wednesday, October 27, 2004 12:11 PM
To: Steve Kimball
Cc: Gin; linuxbios(a)clustermatic.org
Subject: Re: boot linux from an ide
On Wed, 27 Oct 2004, Steve Kimball wrote:
> To use FILO or Etherboot you change the payload.
> So you need to change the
> file to point to the FILO or Etherboot payload
> and make linuxbios.rom.
don't forget you can make your own!
and I do this:
File is this:
# Sample config file for the Arima HDAMA
buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
Linuxbios mailing list
> <Stephen.Kimball(a)bench.com> writes:
> > Rod,
> > I'm using Source Point 7.0.0. I can see the source files. I can
> > display source, disassembly or mixed. However, the disassembly
> > match up with the source code. There is a way to give Source Point
> > offset when the symbols are loaded, but I can't seem to get the
> > value. I know the address of _start and __protected_start but these
> > labels are not in linuxbios_c.o. I need to find the location of a
> >symbol in linuxbios_c.o to compute the offset.
> linuxbios_c is run at an absolute location in memory so the address
> of the symbols within it should be fine.
> Look at readelf -a linuxbios_c.
I have looked at the readelf output. Readelf says hardwaremain is at
000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8
(32-bit mode). But it's not there even after the copy into RAM.
> Now these are not addresses within the rom chip. The are the
> the code is copied to after memory initialization.
> Currently romcc which generates the code that executes immediately
> out of the rom chip does not give good debugging output. But
> you should still be able to see the assembly. crt0.s should
> match what you are looking at.
> You don't have the debugger in 16bit mode or something do you?
SourcePoint switches to 32-bit mode 16 instructions into crt0.s at the
Am I right that crt0.s loads LinuxBIOS into RAM then branches to
the "reference build" arima hdama seems to be too big when being
compiled with gcc 3.3.1 or 3.3.3..
See attached log file.
Please, if anyone has time and test capabilities, have an eye on the non
working ports and try to submit fixes.
Maybe this has been asked before, but i've been thinking about exporting
functions like serial console, debugger entry points, etc. the PC BIOS
uses the interrupt vectors as, well, vectors. I remember the C=64 had a
jump table at a fixed address. I was wondering how hard it would be to
use an ELF symbol table as a jump table, or at least as the source of
information to build one.
"Yinghai Lu" <yhlu(a)tyan.com> writes:
> 1. Using ROMCC to do propresser will help the size reduction?
Not directly. But it does cleanup the header files and increase
the exposure to romcc. There are a small handful of things
this make more maintainable.
> 2. what is usage for MOVNTI? It is for GDB....
Look at ramtest.c. movnti is a non-teporal move (bypasses the cache).
In some cases it can noticeably increase store performance. Last
I measured in the cases it mattered it increased store performance
> 3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
Correct. Either an exception must be taken or a call to gdb_stub_breakpoint()
needs to be made. At that point LinuxBIOS will stop and wait for
the debugger. Assuming CONFIG_GDB_STUB is compiled in. For details
on the gdb side, read up on the gdb remote serial protocol.
I'm not really a fan, I am still more productive with printf
debugging. But implement ion exception handling support is a general
win. And the support was easy to add.
> 4. You will use llshell for crt0.s or auto.c debug?
That is the idea. Again I added it because it is available. It would
not be hard to call out to it with an appropriate asm directive.
If people find llshell useful.
> 5. Current romcc only take constant parameters for non inline function? It
> that right?
There is something weird going on that affects the generated code, so
things don't work as smoothly as they should.
That said in theory function can be non-inline.
> 6. Anyone has tried to compile LinuxBIOS under Suse 9.1? what's the
> recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not
> compile Etherboot properly. I am always using RH9 to do the work. And just
> found I can not compile LB for S2885, (size>65536), but I can do it in Suse
> 9.1 pro.
The goal is to have LinuxBIOS compiling as many places as possible.
As for recommendations we can call out specific revisions of the
tool chain that are known good but I won't call out distros.
Size wise I know gcc-3.4 is about 2% better than gcc-3.3.
Interesting. On the purely size issue you can bump ROM_IMAGE_SIZE a
little and see if it the build works.
As for etherboot I don't know what your compile failure is. So I
don't know how to diagnose that.
I've just finished fixups to filo that make it quite a bit faster.
First, it used to scan the bus twice, the first time to do a count. That's
slow, although it was a nice algorithm. But it only needed to find at most
Now it scans until the device is found and returns it. Even in the worst
case, the new pci scan is always faster than the old.
There are new options in addition to PCI_BRUTE_SCAN.
scan everything ...
... but start at this bus (VERY good on k8, as the scan of 0:19.* takes
PCI_BRUTE_SCAN_LIMIT = 2
... and end here -1(useful when you know that the busses don't range to
And the 'instant gratification' option:
All three must be set or not set or you get a compile-time warning. IF all
three are set, FILO will probe the device and IF it is an ide controller
use that. If it's not an ide controller, filo will scan busses as usual.
This last option REALLY speeds things up
You can get filo only under Etherboot.
Also I added something into the filo in Etherboot.
From: Ronald G. Minnich [mailto:email@example.com]
Sent: Friday, October 29, 2004 3:39 PM
Cc: Li-Ta Lo; LinuxBIOS
Subject: RE: FILO fixups
On Fri, 29 Oct 2004, YhLu wrote:
> The filo is merged into Etherboot. And it will be released in 5.2.6
> I guess.
that's a plus and a minus for us. It's nice seeing FILO get pulled into
supported software like Etherboot. But we've had uneven luck building a
working etherboot here. And ETherboot still does far more than we want.
I would need to put the same kinds of mods into etherboot, and then build
etherboot in a way in which all the ethernet support is not compiled in.
In other words, I want to compile an etherboot down to FILO!
It is simpler to just use FILO directly.
> On Tue, 26 Oct 2004 Stephen.Kimball(a)bench.com wrote:
> > Can someone tell me what the starting sequence is with LinuxBIOS?
> > Reset jumps to crt0.s. crt0.s calls auto.E. auto.E is built using
> > romcc, so source-level debugging is not possible.
> ah well :-)
> > The statement
> > locations can be found using the Lxxxx labels in linuxbios.map.
> > hardwaremain is called. Hardwaremain is the first C function called.
> > Crt0 and auto run out of FLASH. Hardwaremain is the first function
> > called after LinuxBIOS is copied to RAM.
> sounds good so far.
It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000.
Then it branches to 0x4000 into _start, which sets up the stack and
calls hardwaremain. The address of hardwaremain from linuxbios_c.o is
wrong. The address is not the Flash address and it's not the RAM
address. Can someone explain how linuxbios_c.o is linked with RAM