> I am pretty sure you won't find an eeprom. PC chips has a habit of storing > MAC address in CMOS to save the eeprom cost on the motherboard. Matsonic > ms7308e does this too. At some point your cmos probably got zerod. Bad > thing the vendors do is store MAC address in cmos. Zero cmos, zero mac > address. > > They copy the MAC address from flash to cmos if cmos is 0. The idea is, if > cmos is 0, the BIOS copies the MAC address from CMOS to flash. If the cmos > is 0 not, the BIOS doesn't do anything. Thus, MAC address is stored in > BOTH flash and CMOS. > > That's why they tell you to NEVER interrupt a BIOS update ... you can lose > the MAC address. This amazingly fragile scheme is becoming more and more > common. > > It is becoming clear that we need a cmos.c for each mainboard, which does > the mainboard-specific cmos functions. too bad.
Well, you and Steven are correct. Not sure why the mfr bios refuses to reset it. Apparently the sis630 has the capability to support an eeprom, but it is not installed on this mobo. I saw a small soic part 21C8L2K from TI and assumed this was an eeprom. Apparently not, it appears to connect to the cpu and neither TI nor the entire web have ever heard of this part. The 630e has a feature to "autoload" the eeprom to the cmos, and this function is being triggered in the linuxbios code that ollie wrote, so I assumed the part was on the board. Not so. Clearly the cmos only approach is much less robust. So I wrote a small user space program to reset the cmos and that works. Thanks to ollie and the folks at sis for the sis900.c driver in the linux code for an example. The mac addr registers are otherwise somewhat undocumented, but appear to be in what sis calls the "APC registers". As Steven points out, they are at cmos 0x70,0x71; index 9-14. But you have to expose them to the cmos by writing a 1 to b6 of reg 0x48 of the ISA bridge (LPC interface) (-d 1039:0008) first. Otherwise you are reading or clobbering rtc and status bytes of std cmos I think. > > BTW, I have the text mode vga going on this mobo if anyone is > interested in > > the code. I was able to use my stpc vga code with only a few changes. > > Very interesting, how does it fit in to linuxbios? Is it > mainboard-independent or ... > > ron Three files, replacing video_subr.c, and adding ./include/pc80/vga.h and ./pc80/vga_load_regs.c. These are pc generic, and a then a chip specific file ./northsouthbridge/sis/630/sis630_vga.c. Then some code is added to southbridge.c to call the vga init function. Originally I had called the init function in display_init(), but it turns out for the sis630 this is too early in the process. The pci-pci brige that exposes the legacy vga regs is not ready until the pci init process is complete. So the vga init has to be done later than I would like in final southbridge fixup, but it comes up so fast that the monitor is not ready yet anyway. Oh, and there is there is setting b3 of reg 0x3e of bus 0, device 2 (-d 1039:0001, AGP) or the vga legacy registers won't show up either. Thanks to a kind anonymous soul who set me the 630 data sheet or I would have been dead in the water on this one. Ollie is really helpful but sis as a company hasn't responded to my requests for an nda/datasheet, and posts on the web indicate this is the norm. Actually almost all of the code is generic, I think, but when I first wrote it I wasn't sure how to break it up. Until I see a few vga parts I won't be confident of where the generic/chip specific dividing line should be. -Steve _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
