Can I flash my BIOS? I was looking for a BIOS replacment since my default BIOS plain sux, compare to some other bioses, anywho, so i stumbled across the beowulf project got me interested since I do alot of 3d rendering and heard of clustering before. Then I stumbled across of LinuxBios and my 'childhood dream' was true, booting directly not having a shitty old ancient 8bit looky BIOS. Erm, so ya I read a little bit here and there. And it would seem on the status page that my motherboard is NOT supported :/ I have currently a Linux/windows dual, not sure how that would all work i have yet to read lots but is my motherboard the Asus P4-TE supported? ----------------------------------- Angelo "Gigatron" Arifi
send an lspci and we will be able to tell.
Thanks
ron
My pcchips m787cl+ with the sis630e chipset started reporting a 00:00..00 mac address. It was working at first, but somewhere in the process of debugging I started getting all zeros.
I looked thorough the linuxbios and the sis900.c driver, and I think everything is being setup correctly. I even wrote a small program to read the eeprom directly (rather than the APC cmos), following the code in the sis driver, and I always read zeroes. I cannot ever seem to get a 1 on DO (b1 of IO reg 0x2008).
I put the orig bios back in and booted Linux and same result, so I am pretty sure the eeprom got erased (or is dead).
Anybody (ollie?) know if there is a way to re-write the eeprom? The ifconfig command will set the mac to any value but it doesn't last through reboots, and I did not see any code in the driver that appears to write to the eeprom.
The bios that came with the board does not seem to have a way to set it either.
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.
-Steve
Greetings,
AFAIK, on the 630e, the MAC address is actually stored in CMOS at index 9-14. I'm not sure how that came to be zeroed, but if you put it back there, all will be well. The regular BIOS sets that during POST.
G'day, sjames
On Sat, 21 Sep 2002, Steve M. Gehlbach wrote:
My pcchips m787cl+ with the sis630e chipset started reporting a 00:00..00 mac address. It was working at first, but somewhere in the process of debugging I started getting all zeros.
I looked thorough the linuxbios and the sis900.c driver, and I think everything is being setup correctly. I even wrote a small program to read the eeprom directly (rather than the APC cmos), following the code in the sis driver, and I always read zeroes. I cannot ever seem to get a 1 on DO (b1 of IO reg 0x2008).
I put the orig bios back in and booted Linux and same result, so I am pretty sure the eeprom got erased (or is dead).
Anybody (ollie?) know if there is a way to re-write the eeprom? The ifconfig command will set the mac to any value but it doesn't last through reboots, and I did not see any code in the driver that appears to write to the eeprom.
The bios that came with the board does not seem to have a way to set it either.
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.
-Steve
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
AFAIK, on the 630e, the MAC address is actually stored in CMOS at index 9-14. I'm not sure how that came to be zeroed, but if you put it back there, all will be well. The regular BIOS sets that during POST.
G'day, sjames
Thanks, you are correct, except the BIOS stubbornly refuses to reset it now. I have zeroed the cmos (using the jumper) several times, and pressed F2(? I think) to set default values, but still a zero. It's interesting the the M787cl+, after a zero cmos, doesn't boot on the first poweron, have to then poweroff and try again. Oh well, budget board, budget bios I guess. Another argument for Linuxbios.
-Steve
On Sun, 22 Sep 2002, Steve M. Gehlbach wrote:
Thanks, you are correct, except the BIOS stubbornly refuses to reset it now. I have zeroed the cmos (using the jumper) several times, and pressed F2(? I think) to set default values, but still a zero. It's interesting the the M787cl+, after a zero cmos, doesn't boot on the first poweron, have to then poweroff and try again. Oh well, budget board, budget bios I guess. Another argument for Linuxbios.
This is probably because the MAC address in flash is 0 too. Consider a flash update. You have to: - write the new flash - write "permanent" parameters from CMOS to flash
then, next time CMOS gets wiped, you copy the MAC etc. from FLASH to CMOS.
If you load linuxbios and then zero flash, boom! -- no record of the MAC address of the board. If you then load the original flash, it will copy the all-zero mac address to flash.
we're going to need a way to record this kind of nonsense in FLASH images of linuxbios.
ron
This is probably because the MAC address in flash is 0 too. Consider a flash update. You have to:
- write the new flash
- write "permanent" parameters from CMOS to flash
then, next time CMOS gets wiped, you copy the MAC etc. from FLASH to CMOS.
If you load linuxbios and then zero flash, boom! -- no record of the MAC address of the board. If you then load the original flash, it will copy the all-zero mac address to flash.
we're going to need a way to record this kind of nonsense in FLASH images of linuxbios.
Hmm... well I never touched the original flash BIOS. I use an EMP-30 and program different chips to test and run linuxbios. I guess I thought the mac would be in the original bios flash, and I guess I don't understand how it got changed. The board came with the cmos jumper in the "clear" position, which threw me since it wouldn't come up at first until I spotted this.
Anyway, the user space program to set a new MAC address in cmos is attached to this email; it is pretty simple, but has to run as root of course. Maybe we should put this in linuxbios, as an option or something. I wonder how you pick a MAC address? At one time they were assigned in blocks by manufacturer, I thought. I realize they only have to be unique on the subnet, but if you start assigning them randomly and shipping them to customers, what are the odds? Mathematically 1 in 2^48 but by Murphy probably 1 in 2 of a collision :-/ .
-Steve
On Monday 23 September 2002 6:08 am, Steve M. Gehlbach wrote:
The board came with the cmos jumper in the "clear" position, which threw me since it wouldn't come up at first until I spotted this.
Yeah - I hate it when manufacturers do that too.
Anyway, the user space program to set a new MAC address in cmos is attached to this email; it is pretty simple, but has to run as root of course. Maybe we should put this in linuxbios, as an option or something. I wonder how you pick a MAC address? At one time they were assigned in blocks by manufacturer, I thought. I realize they only have to be unique on the subnet, but if you start assigning them randomly and shipping them to customers, what are the odds? Mathematically 1 in 2^48 but by Murphy probably 1 in 2 of a collision :-/ .
Surely they printed the MAC address on a sticky label on one or more of: a) the motherboard b) the ethernet controller / socket c) the manual d) the box the motherboard came in e) a little piece of paper included in the packaging ?
I'm generally used to seeing two labels - one on the motherboard itself, and one on a separate piece of paper that a system assembler can stick on the outside of the final assembled case, in case the end-user ever needs to know the MAC address without booting the machine.
Antony.
Surely they printed the MAC address on a sticky label on one or more of: a) the motherboard b) the ethernet controller / socket c) the manual d) the box the motherboard came in e) a little piece of paper included in the packaging ?
I'm generally used to seeing two labels - one on the motherboard itself, and one on a separate piece of paper that a system assembler can stick on the outside of the final assembled case, in case the end-user ever needs to know the MAC address without booting the machine.
Yup, there it is in all the places your say. EA=00079...; thought it was a serial number. I guess I should have been able to figure this on out myself, thanks.
-Steve
Greetings,
I don't know about other vendors, but Matsonic boards have the MAC on a sticker just in case.
G'day, sjames
On Sun, 22 Sep 2002, Steve M. Gehlbach wrote:
This is probably because the MAC address in flash is 0 too. Consider a flash update. You have to:
- write the new flash
- write "permanent" parameters from CMOS to flash
then, next time CMOS gets wiped, you copy the MAC etc. from FLASH to CMOS.
If you load linuxbios and then zero flash, boom! -- no record of the MAC address of the board. If you then load the original flash, it will copy the all-zero mac address to flash.
we're going to need a way to record this kind of nonsense in FLASH images of linuxbios.
Hmm... well I never touched the original flash BIOS. I use an EMP-30 and program different chips to test and run linuxbios. I guess I thought the mac would be in the original bios flash, and I guess I don't understand how it got changed. The board came with the cmos jumper in the "clear" position, which threw me since it wouldn't come up at first until I spotted this.
Anyway, the user space program to set a new MAC address in cmos is attached to this email; it is pretty simple, but has to run as root of course. Maybe we should put this in linuxbios, as an option or something. I wonder how you pick a MAC address? At one time they were assigned in blocks by manufacturer, I thought. I realize they only have to be unique on the subnet, but if you start assigning them randomly and shipping them to customers, what are the odds? Mathematically 1 in 2^48 but by Murphy probably 1 in 2 of a collision :-/ .
-Steve
On Sat, 21 Sep 2002, Steve M. Gehlbach wrote:
My pcchips m787cl+ with the sis630e chipset started reporting a 00:00..00 mac address. It was working at first, but somewhere in the process of debugging I started getting all zeros.
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.
The bios that came with the board does not seem to have a way to set it either.
That makes sense. Part of the flash upgrade (from what I have seen) is to load the MAC from CMOS to BIOS ... no MAC in CMOS, no MAC address in Flash.
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
Ronald G Minnich rminnich@lanl.gov writes:
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.
Well that and you can kill your system 10 other ways as well. Killing a BIOS update is fragile. Though with a little care it can be made fairly robust.
It is becoming clear that we need a cmos.c for each mainboard, which does the mainboard-specific cmos functions. too bad.
A lot of this can be fairly motherboard independent with just the list of where it lives changing from board to board.
Something that came up while I was trying to figure out how to support multiple baud rates with the same binary build of LinuxBIOS, is the idea to have an area set aside in the rom image that is the size of the cmos, and has the default CMOS settings. And then anytime a checksum would fail or if we decide not to look at the CMOS at all, we consult this area. And it can use a common generic code base.
The we just need to set up the flash uptility to copy this into the image before it is flashed into the ROM. The nice thing is that we can uses this for things like motherboard serial numbers or the ipv6 DHCP DUID that they want for DHCP.
Eric
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
On Sun, 22 Sep 2002, Steve M. Gehlbach wrote:
Well, you and Steven are correct. Not sure why the mfr bios refuses to reset it.
There's no record of the value of the MAC address anywhere, so it can't reset it.
Not so. Clearly the cmos only approach is much less robust.
CMOS-only is a terrible idea, but it's what they do to save the cost of the part + installing it on the mainboard + flashing that part with a mac address.
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.
can you send those along so I can take a look?
ron
Steve M. Gehlbach wrote:
My pcchips m787cl+ with the sis630e chipset started reporting a 00:00..00 mac address. It was working at first, but somewhere in the process of debugging I started getting all zeros.
I looked thorough the linuxbios and the sis900.c driver, and I think everything is being setup correctly. I even wrote a small program to
read
the eeprom directly (rather than the APC cmos), following the code in the sis driver, and I always read zeroes. I cannot ever seem to get a 1
on DO
(b1 of IO reg 0x2008).
I put the orig bios back in and booted Linux and same result, so I am
pretty
sure the eeprom got erased (or is dead).
Anybody (ollie?) know if there is a way to re-write the eeprom? The ifconfig command will set the mac to any value but it doesn't last
through
reboots, and I did not see any code in the driver that appears to
write to
the eeprom.
The utils and instructions for programing the eeprom with the SiS 900 can be found at:
ftp://sis55X:sis55x@ftp3.sis.com.tw/SiS900/utility/
Bari
The utils and instructions for programing the eeprom with the SiS 900 can be found at:
ftp://sis55X:sis55x@ftp3.sis.com.tw/SiS900/utility/
Bari
Thanks for the link; very useful info.
-Steve
On Sun, 2002-09-22 at 14:35, Steve M. Gehlbach wrote:
My pcchips m787cl+ with the sis630e chipset started reporting a 00:00..00 mac address. It was working at first, but somewhere in the process of debugging I started getting all zeros.
I looked thorough the linuxbios and the sis900.c driver, and I think everything is being setup correctly. I even wrote a small program to read the eeprom directly (rather than the APC cmos), following the code in the sis driver, and I always read zeroes. I cannot ever seem to get a 1 on DO (b1 of IO reg 0x2008).
I put the orig bios back in and booted Linux and same result, so I am pretty sure the eeprom got erased (or is dead).
Anybody (ollie?) know if there is a way to re-write the eeprom? The ifconfig command will set the mac to any value but it doesn't last through reboots, and I did not see any code in the driver that appears to write to the eeprom.
The storage for MAC address changed again and again over time. If you do really have a 630E mb. You can use the attached file.
Ollie
The storage for MAC address changed again and again over time. If you do really have a 630E mb. You can use the attached file.
Ollie
Thanks Ollie. This is a much better program than my quick hack. I had pretty much figured it out from your linux driver by this time, but this is good, since I needed the education to anticipate problems in the field, etc.
-Steve
-
Angelo Arifi -
Antony Stone -
Bari Ari -
ebiederman＠lnxi.com -
ollie lho -
Ronald G Minnich -
Steve M. Gehlbach -
steven james