October 2004 - coreboot - mail.coreboot.org

Does linux kernel parse linuxbios table?
by Liu Tao Jan. 14, 2005

Jan. 14, 2005

Hello Eric, 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-2.6.8.1, does linux kernel still parse the linuxbios table now? Regards, Liu Tao

3 2

low level shell
by Bryan E. Chafy Jan. 7, 2005

Jan. 7, 2005

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)

7 10

RE: boot linux from an ide
by YhLu Dec. 28, 2004

Dec. 28, 2004

Just remind: 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 ..... Regards YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] 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 > freebios2/targets/<vendor>/<board>/Config.lb > file to point to the FILO or Etherboot payload > and make linuxbios.rom. don't forget you can make your own! I have targets/arima/hdama/Config.filo.lb and I do this: ./buildtarget arima/hdama/Config.filo.lb File is this: # Sample config file for the Arima HDAMA target hdama.filo mainboard arima/hdama romimage "normal" option USE_FALLBACK_IMAGE=0 option ROM_IMAGE_SIZE=0x10000 option LINUXBIOS_EXTRA_VERSION=".0Normal" payload /opt/filo/normal/filo.elf end romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x10000 option LINUXBIOS_EXTRA_VERSION=".0Fallback" payload /opt/filo/fallback/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

6 9

RE: Makefile changes for symbols
by Stephen.Kimball＠bench.com Nov. 3, 2004

Nov. 3, 2004

> <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 doesn't > > match up with the source code. There is a way to give Source Point an > > offset when the symbols are loaded, but I can't seem to get the right > > 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 addresses > 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 JMP instruction. Am I right that crt0.s loads LinuxBIOS into RAM then branches to hardwaremain? Steve

6 15

status information
by Stefan Reinauer Nov. 2, 2004

Nov. 2, 2004

Hi, 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. Stefan

7 37

linuxbios external api
by Jeremy Jackson Nov. 2, 2004

Nov. 2, 2004

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. -- Jeremy Jackson Coplanar Networks (519)897-1516 http://www.coplanar.net

6 5

Re: Merge/Cleanup status
by ebiederman＠lnxi.com Nov. 1, 2004

Nov. 1, 2004

"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 by 3X. > 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. Eric

2 3

FILO fixups
by Ronald G. Minnich Nov. 1, 2004

Nov. 1, 2004

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 2 devices. 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. PCI_BRUTE_SCAN means: scan everything ... PCI_BRUTE_SCAN_START ... but start at this bus (VERY good on k8, as the scan of 0:19.* takes FOREVER). PCI_BRUTE_SCAN_LIMIT = 2 ... and end here -1(useful when you know that the busses don't range to 256) And the 'instant gratification' option: IDE_HINT_BUS IDE_HINT_DEV IDE_HINT_FUNC 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 ron

4 8

RE: FILO fixups
by YhLu Nov. 1, 2004

Nov. 1, 2004

You can get filo only under Etherboot. make bin/filo.zelf or make bin/tg3--filo.zelf Also I added something into the filo in Etherboot. Regards YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 29, 2004 3:39 PM To: YhLu 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 formally > 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. ron

3 2

RE: LinuxBIOS debugging with an emulator
by Stephen.Kimball＠bench.com Nov. 1, 2004

Nov. 1, 2004

> 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. Then > > hardwaremain is called. Hardwaremain is the first C function called. > > yep. > > > Crt0 and auto run out of FLASH. Hardwaremain is the first function > > called after LinuxBIOS is copied to RAM. > > sounds good so far. > > ron 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 addresses? Steve

3 2