Hi, please, now that i get the patch ...can you tell me how to apply it. Tino.
The ability to apply patches is probably a reasonable prerequisite for any hacking with freebios :^). But the posting was answering Ron's request for the patch. The problem with my patch is it is like my own fork off of an older version of freebios than what is available now. My patch would be more for informational purposes, however it could be incorporated into the freebios source in part or whole. I cut a few corners with my approach: 1) Cut and pasted some other spd/smbus code just to be able to view the DDR spd contents. The actual ddr ram configuration is *not* done in this patch, I left the code segments in hoping to study them and figure out how to do it for the epia-m. Basically the code in the smbus.inc is a copy of code that I found elsewhere in freebios. Right now it is just useless bloat. 2) I walk all over the CMOS ram contents just because I wanted a way to carry over a version string from linuxbios to linux. Linuxbios compresses everything so I couldn't easily scan the rom for a version string. There is probably another way to address this problem. I just copied the version string into the upper 128 bytes of the epia-m's cmos memory. I also use byte $0e of cmos as a flag because I do a hard pci bus reset to get the system cleanly setup. I need to keep track of whether I've already reset once so it doesn't just endlessly reset. 3) The config file used to build the epia-m is built as part of an external Makefile--I take the one inside the epia-m's directory and tack on a few extra lines that say where the payload is. The payload is built in another directory, based on etherboot code. This approach is foreign to freebios but served our purposes. There is no toplevel Makefile in the normal freebios tree.
The really critical code to consider bringing into freebios/epia-m is A) VGA register init + setup B) VGA bios stuff C) VGA bios lockup fix, if an unacceptable INT is called, vga init is aborted. D) Actual pci reset on startup to reset the pci card to known state. This prevents lockups if the card is requesting an interrupt for example. E) Code to access the smbus/SPD which is a starting point to auto config of DDR F) VGA bios wants certain INT's implemented, these are implemented and seem to be ok. G) The pci firewire device comes up configured to respond to IO at 0 to 7f or so, which means the cmos ram can't be accessed. This part has to be moved out of the way. Normal pci configuration fixes this, but if you need to access some other device at those io ports early on you need to move the pci firewire device out of the way, this is a gotcha I had to get past. H) Audio + usb irq's were not initialized properly. I) The hardware status monitor was not initialized and activated. J) Shadow ram for copying the vga bios over wasn't initialized K) Shadow ram for vga bios wasn't write protected. Could be important.
That's about it. I don't know the status of epia-m freebios (not freebios2). I don't know if vga is supported in the current CVS version, or any other details.
-Dave
On Thu, Nov 06, 2003 at 07:52:50AM -0800, Dave Ashley wrote:
C) VGA bios lockup fix, if an unacceptable INT is called, vga init is aborted.
Similar functionality is already in the current CVS freebios tree.
D) Actual pci reset on startup to reset the pci card to known state. This prevents lockups if the card is requesting an interrupt for example.
I like this idea.
Also I noticed hardwaremain() has the code to call hard_reset() when the boot_complete parameter is set, but I haven't figured out how this parameter is set.