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)
"Bryan E. Chafy" bchafy@ccs.neu.edu writes:
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.
:)
romcc helps by reducing typos. But this addresses the problem of understanding what is wrong :)
The other trick that helps is to hard code the memory configuration and put that in the fallback image. And then use a second copy of linuxbios to develop new code. At least that way you don't need to swap the rom chip.
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.
I think the people who described it as such could not get that low level :) Forth certainly needs memory to work.
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.
It looks nice. And inspires some more ideas.
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).
Now if only we can figure out a way to successfully trap exceptions without memory working....
Eric
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
The other trick that helps is to hard code the memory configuration and put that in the fallback image. And then use a second copy of linuxbios to develop new code. At least that way you don't need to swap the rom chip.
some times that works, sometimes not. On the i855gm, hardcoding did not seem to work -- there's something dynamic you have to do, evidently, and just setting in the registers was not it.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
The other trick that helps is to hard code the memory configuration and put that in the fallback image. And then use a second copy of linuxbios to develop new code. At least that way you don't need to swap the rom chip.
some times that works, sometimes not. On the i855gm, hardcoding did not seem to work -- there's something dynamic you have to do, evidently, and just setting in the registers was not it.
I guess what I meant was that you can hard code the values that only change when you swap dimms. This means you don't initially need to look at SPD and all of that jazz when you first start bringing your memory up.
Eric
On Thu, 2004-10-28 at 08:22, Eric W. Biederman wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Wed, 27 Oct 2004, Eric W. Biederman wrote:
The other trick that helps is to hard code the memory configuration and put that in the fallback image. And then use a second copy of linuxbios to develop new code. At least that way you don't need to swap the rom chip.
some times that works, sometimes not. On the i855gm, hardcoding did not seem to work -- there's something dynamic you have to do, evidently, and just setting in the registers was not it.
I guess what I meant was that you can hard code the values that only change when you swap dimms. This means you don't initially need to look at SPD and all of that jazz when you first start bringing your memory up.
I guess this is the most diffcult part. Once you know how to issue the JEDEC command to the DRAM chip via the memory controller, you have no problem to program the size info in the controller.
Ollie
Eric _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I could build an image now. Thanks all. I am curious about how fallback image and normal image are used. It looks like in the normal image, it always jumps to the Protected_start. I don't think it should be the start when the system boots up since it will be in real-mode. So which image should I use?
Regards, Gin
-
On Fri, Oct 29, 2004 at 11:49:25AM +0800, Gin wrote:
I could build an image now. Thanks all. I am curious about how fallback image and normal image are used. It looks like in the normal image, it always jumps to the Protected_start. I don't think it should be the start when the system boots up since it will be in real-mode. So which image should I use?
Both. The fallback image tries to load the normal image but if that fails it'll take over and continue with the fallback image.
For only a single image, use fallback.
//Peter
The fallback image tries to load the normal image but if that fails it'll take over and continue with the fallback image.
So I am guessing the 2 images are the same. Then why 2 exact the same image? In case of damaged flash area?
I am asking this because I want to embed a linux kernel in the BIOS rom to run Flash_and_Burn util (For convenience when updating Bios). There probably won't be enough ROM space if I use both images.
gin
As I recall, the best way to do this is to disable the "normal" ROM by leaving it out of the Config.lb file in the targets directory all together and thus enable the fallback image only. We did this in order to fit a kernel image. There should be a couple targets that utilize this method in their configuration, for example freebios2/targets/arima/hdama/Config.kernelimage.lb .
On Fri, 7 Jan 2005 15:42:52 +0800 "Gin" ginlin@nexcom.com.tw wrote:
The fallback image tries to load the normal image but if that fails it'll take over and continue with the fallback image.
So I am guessing the 2 images are the same. Then why 2 exact the same image? In case of damaged flash area?
I am asking this because I want to embed a linux kernel in the BIOS
rom
to run Flash_and_Burn util (For convenience when updating Bios). There probably won't be enough ROM space if I use both images.
gin
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Fri, 7 Jan 2005, Gin wrote:
The fallback image tries to load the normal image but if that fails it'll take over and continue with the fallback image.
So I am guessing the 2 images are the same. Then why 2 exact the same image? In case of damaged flash area?
yes. Pretend you are reflashing 1024 machines, and the power drops. If you only were reflashing the 'normal' area, then the fallback area will still let you boot your machines.
I am asking this because I want to embed a linux kernel in the BIOS rom to run Flash_and_Burn util (For convenience when updating Bios). There probably won't be enough ROM space if I use both images.
yes, in some cases we only use one image.
ron
I think this is a good example of something that goes in the extensions directory, I'll try to figure this out. It looks like a really handy tool.
thanks
ron
-
Bryan E. Chafy -
David Hendricks -
ebiederman＠lnxi.com -
Gin -
Li-Ta Lo -
Peter Stuge -
Ronald G. Minnich