Hi,
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
I'll start testing my 440BX code soon, so I'd like to know what I have to expect...
Uwe.
Uwe Hermann wrote:
Hi,
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
I'll start testing my 440BX code soon, so I'd like to know what I have to expect...
Uwe.
Well, from what I can tell, this chipset is fairly idiot-proof, as long as you don't go messing around with anything not in the docs. The only real show stoppers would be setting the timings too tight, or setting the ram type to the wrong type, but I don't even know if that would burn hardware. BTW, if you want a hand with testing anything, send me an email, I'm curious to see how you've gotten it to work, and I've got a test rig installing gentoo right now. I've spent a few hours pouring over the docs, but haven't gotten the time to make anything from it.
Corey Osgood
Hi,
On Sat, Nov 11, 2006 at 08:12:17AM -0500, Corey Osgood wrote:
BTW, if you want a hand with testing anything, send me an email, I'm curious to see how you've gotten it to work,
I don't have working code, yet. I'll post a patch as soon as I have (might take a few more days)...
I'm currently building the code infrastructure, comparing the v1 code to the datasheet and the E7501 code which I (partially) reuse...
Uwe.
On 11/11/06, Uwe Hermann uwe@hermann-uwe.de wrote:
Hi,
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
I'll start testing my 440BX code soon, so I'd like to know what I have to expect...
I don't think you can. I have over the years tried a lot of wrong ram settings, and only ever seen temporary failures. We have in 7 1/2 years never seen anything that looked like damage due to bad ram programming.
thanks
ron
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
I'll start testing my 440BX code soon, so I'd like to know what I have to expect...
I don't think you can. I have over the years tried a lot of wrong ram settings, and only ever seen temporary failures. We have in 7 1/2 years never seen anything that looked like damage due to bad ram programming.
Have you ever seen any damage from programming something else incorrectly though? It's a typical programming mistake to write to the wrong register ;-)
That said, on modern hardware, it's almost impossible to damage the hardware by software alone (for example, if you accidentally turn off the fans (or don't turn them on), most chips will automatically shut off).
Segher
p.s. Be careful with high-power voltage regulators though ;-)
Uwe Hermann wrote:
Hi,
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
I'll start testing my 440BX code soon, so I'd like to know what I have to expect...
Uwe.
Don't mean to bug you or anything, but I've got a couple more questions, if you have the time: did you have to do anything with the southbridge code, or is that all set? And did you start from scratch, or modify the code that was already there?
And a final question for anyone, if I were to do a flash and it not go well, do failsafes like key combonations to pull a bios off a floppy still work, or are those stored in the BIOS?
Corey Osgood
On 11/11/06, Corey Osgood corey_osgood@verizon.net wrote:
And a final question for anyone, if I were to do a flash and it not go well, do failsafes like key combonations to pull a bios off a floppy still work, or are those stored in the BIOS?
Those are part of the BIOS.
Your only safe way to do this is to have duplicate flash parts.
I do this: 1. clone the fuctory bios. 2. make sure the CLONE boots. 3. put the ORIGINAL flash part in a bag, on a shelf, where I can not touch it. 4. use hot swap to program linuxbios. Always work with the CLONE part for fuctory.
Why always work with the CLONE? because if you use the clone, that ensures that your flash programming is working.
This way, WHEN, not IF, but WHEN I make a mistake and put linuxbios in over the fuctory bios, I have a fallback position: that part on the shelf. And, WHEN I make this mistake, FIRST thing I do is make another fuctory BIOS copy.
This procedure developed after some really serious, stupid mistakes wiping out BIOSes.
thanks
ron
On Sat, Nov 11, 2006 at 10:54:49AM -0500, Corey Osgood wrote:
Don't mean to bug you or anything, but I've got a couple more questions, if you have the time: did you have to do anything with the southbridge code, or is that all set?
I haven't touched the southbridge code yet, but it seems to be supported already.
And please note, I'm merely writing code currently, I haven't yet actually _tested_ anything...
And did you start from scratch, or modify the code that was already there?
Both, partly. I don't want to do further cut'n'paste programming, there's enough of that in the tree already. I started mostly from scratch and tried to properly document the code. Some parts I'll reuse from the E7501 I guess, and the real know-how is in the V1 440BX code (which is working fine for me on my hardware, btw).
And a final question for anyone, if I were to do a flash and it not go well, do failsafes like key combonations to pull a bios off a floppy still work, or are those stored in the BIOS?
Won't work, see Ron's post. I have a local svn repository where I checkin all my proprietary BIOS images, so I won't lose them no matter how much I mess up. And I put one or more backups of them on real physical chips, of course.
Uwe.
Uwe Hermann wrote:
I haven't touched the southbridge code yet, but it seems to be supported already.
And please note, I'm merely writing code currently, I haven't yet actually _tested_ anything...
Sorry, guess I got a little over-excited. I had the same thought on the southbridge code, although I didn't see any other models using it, but at the very least it looks clean.
Won't work, see Ron's post. I have a local svn repository where I checkin all my proprietary BIOS images, so I won't lose them no matter how much I mess up. And I put one or more backups of them on real physical chips, of course.
Uwe.
Alright, I thought as much, but it was worth a shot. It doesn't really matter anyways, both of the boards I have here now were rescued from the dumpster, so they're no real loss if I kill them, and I should have an asus board on the way monday, along with a bios savior.
Corey
Uwe Hermann wrote:
Both, partly. I don't want to do further cut'n'paste programming, there's enough of that in the tree already. I started mostly from scratch and tried to properly document the code. Some parts I'll reuse from the E7501
Rock on. \m/ You the man. Go Uwe Go!
I guess, and the real know-how is in the V1 440BX code (which is working fine for me on my hardware, btw).
It worked for you out-of-the-box? Wow. I always had to hardcode one of the settings to the ram that V1 never quite got right on my Asus P2B but worked fine for the Bitworks/IMS. The boards I have are slightly different revs. ZX vs BX I think.
Uwe Hermann wrote:
Hi,
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
There is nothing you can do from software to physically harm SDR, DDR, or DDR2 devices.
Tom Sylla wrote:
I'm just a bit curious - are there settings/registers in northbridges which can seriously brick a mainboard and/or RAM (physically) if abused properly?
There is nothing you can do from software to physically harm SDR, DDR, or DDR2 devices.
100% agree with Tom. I suppose if you somehow tickle some crazy bug to make the controller output the wrong voltage you could do something bad to the rams but the chances of that are so low they aren't even worth considering. Remember thats a really mature chipset.
I've put all manner of wrong settings in those chips and during the development of the Bitworks/IMS board we did all sorts of "Bad" things to the ram and it kept on plugging.
So I think you are safe.
Thinking about this brings back a few memories.
1) I found in my testing that you can do things to the north bridge that will crash it in such a way that a reset does not fully fix. It's very sneaky, things just start behaving really weird and your code just seems to start failing for no good reason. But not so bad as to suspect that its hardware. Especially if you are doinking with the register settings at the time.
The only fix is to _remove_ power from the board. And on the ASUS I seem to remember having to remove the CMOS battery as well. (Bitworks/IMS had no battery) So I recommend you remove the battery and power cycle frequently.
2) The 66Mhz/100Mhz operation of the front side bus is controlled via a jumper. The Bitworks board however was never qualified to run at 100Mhz. So all the settings are for 66Mhz. If you run with the 66Mhz drive settings yet have the jumper set to 100Mhz you are in for a lot of frustration. Just depends on the quality of your ram and the board layout. I recommend that you do all you development with 66Mhz and then work out the 100Mhz settings after you have the code working. I can't help much with the 100Mhz settings. You will need to dump a Factory BIOS set to 100Mhz and compare how they setup the drive settings.
- I found in my testing that you can do things to the north bridge
that will crash it in such a way that a reset does not fully fix. It's very sneaky, things just start behaving really weird and your code just seems to start failing for no good reason. But not so bad as to suspect that its hardware. Especially if you are doinking with the register settings at the time.
The only fix is to _remove_ power from the board.
Many chips have debug registers (often not documented in public literature) that seriously change the behaviour of the chip; and such debug registers are often not reset by a simple chip reset (which is a good thing really). Most shipping hardware (esp. "B" or later revs) doesn't need programming any of those registers for proper operation.
Segher
-
Corey Osgood -
Richard Smith -
ron minnich -
Segher Boessenkool -
Tom Sylla -
Uwe Hermann