I have 2 Intel SE440BX and one Intel SE440bx-3 (it's some kind of subversion to sebx-2) These were very popular Intel OEM boards and were used by Dell, compaq, fujitsu and the like. If someone wants info on what chips they have etc I'm willing to be of assistance and help with testing code one them to make them work. Since they all have Intels soldered on flash chips you can't make too many mistakes but I have no problem losing one in the process as I don't need all of them.
On Mon, Mar 26, 2007 at 01:09:57PM +0200, Oscar Molin wrote:
I have 2 Intel SE440BX and one Intel SE440bx-3 (it's some kind of subversion to sebx-2) These were very popular Intel OEM boards and were used by Dell, compaq, fujitsu and the like. If someone wants info on what chips they have etc I'm willing to be of assistance and help with testing code one them to make them work. Since they all have Intels soldered on flash chips you can't make too many mistakes but I have no problem losing one in the process as I don't need all of them.
I would wait with flashing until there was a practical way to unbrick the board. :) That said, 440BX is getting some work in v2, so more systems to test on would be great. If need be I could replace your flash with a socket. (I'm in Malmö)
//Peter
Hi Peter I said in an email to Corey about unbricking, that I think it might be possible to use the recovery part of the bios, appending that file from Intels own bios with a linuxbios. I'm not 100% sure that works but it might. I forgot to forward that message to the mailing list. Intels bios structure is divided in 64k parts and there are 3-4 (or more depending on size i guess) that is the bios. There are two that intels readme says is "recovery" bios (two identical files, two different places on the flash chip, I think) Then there is one which seems to have settings and "stuff". If I can include these recvery files, and place the linuxbios in the regular bios files (with intels header info to make their flash-program accept it), I don't see a reason why it shouldn't work. Intels flasher also has a function that checks validity of the files before flashing, so if there is a checksum or something in the header that has to match, I would be able to solve it or even bruteforce it to make it accept my files instead. The reason I'm looking at this way of handling things, and not just soldering a socket the first thing I do, is: 1) I'm lazy 2) This is the way it has to be done if there is ever going to be Intel OEM support, since their flasher is AFAIK the only one that can flash there chips. Regular users can't be expected to solder bios chips.
Thanks for the offer about the socket, but I'm too far away so I'll have to do it myself.
One last thing about 440bx. Since Rons assembly code from v1 works, why is it that it is so hard to port it to C? Is it a compiler bug/feature that makes it not work correctly or what is the exact problem? I've just started trying to understand this stuff and I read a post by Ron from 2004 where he had two boards working well apparently, he didn't mention any memory issues. If the working assembler code can be put in with the C code, and then change it line by line until it stops working, you should be able to pinpoint the problem right? Maybe my thinking is flawed, I'm not a good programmer.
2007/3/26, Peter Stuge stuge-linuxbios@cdy.org:
On Mon, Mar 26, 2007 at 01:09:57PM +0200, Oscar Molin wrote:
I have 2 Intel SE440BX and one Intel SE440bx-3 (it's some kind of subversion to sebx-2) These were very popular Intel OEM boards and were used by Dell, compaq, fujitsu and the like. If someone wants info on what chips they have etc I'm willing to be of assistance and help with testing code one them to make them work. Since they all have Intels soldered on flash chips you can't make too many mistakes but I have no problem losing one in the process as I don't need all of them.
I would wait with flashing until there was a practical way to unbrick the board. :) That said, 440BX is getting some work in v2, so more systems to test on would be great. If need be I could replace your flash with a socket. (I'm in Malmö)
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
that was a post by Richard Smith, not Ron. my bad
2007/3/29, Oscar Molin oscarmolin@gmail.com:
Hi Peter I said in an email to Corey about unbricking, that I think it might be possible to use the recovery part of the bios, appending that file from Intels own bios with a linuxbios. I'm not 100% sure that works but it might. I forgot to forward that message to the mailing list. Intels bios structure is divided in 64k parts and there are 3-4 (or more depending on size i guess) that is the bios. There are two that intels readme says is "recovery" bios (two identical files, two different places on the flash chip, I think) Then there is one which seems to have settings and "stuff". If I can include these recvery files, and place the linuxbios in the regular bios files (with intels header info to make their flash-program accept it), I don't see a reason why it shouldn't work. Intels flasher also has a function that checks validity of the files before flashing, so if there is a checksum or something in the header that has to match, I would be able to solve it or even bruteforce it to make it accept my files instead. The reason I'm looking at this way of handling things, and not just soldering a socket the first thing I do, is:
- I'm lazy
- This is the way it has to be done if there is ever going to be Intel
OEM support, since their flasher is AFAIK the only one that can flash there chips. Regular users can't be expected to solder bios chips.
Thanks for the offer about the socket, but I'm too far away so I'll have to do it myself.
One last thing about 440bx. Since Rons assembly code from v1 works, why is it that it is so hard to port it to C? Is it a compiler bug/feature that makes it not work correctly or what is the exact problem? I've just started trying to understand this stuff and I read a post by Ron from 2004 where he had two boards working well apparently, he didn't mention any memory issues. If the working assembler code can be put in with the C code, and then change it line by line until it stops working, you should be able to pinpoint the problem right? Maybe my thinking is flawed, I'm not a good programmer.
2007/3/26, Peter Stuge stuge-linuxbios@cdy.org:
On Mon, Mar 26, 2007 at 01:09:57PM +0200, Oscar Molin wrote:
I have 2 Intel SE440BX and one Intel SE440bx-3 (it's some kind of subversion to sebx-2) These were very popular Intel OEM boards and were used by Dell, compaq, fujitsu and the like. If someone wants info on what chips they have etc I'm willing to be of assistance and help with testing code one them to make them work. Since they all have Intels soldered on flash chips you can't make too many mistakes but I have no problem losing one in the process as I don't need all of them.
I would wait with flashing until there was a practical way to unbrick the board. :) That said, 440BX is getting some work in v2, so more systems to test on would be great. If need be I could replace your flash with a socket. (I'm in Malmö)
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Oscar Molin wrote:
that was a post by Richard Smith, not Ron. my bad
I've just started trying to understand this stuff and I read a post by Ron from 2004 where he had two boards working well apparently, he didn't mention any memory issues.
Yeah.. Thats the problem. V1 code worked great but something in the port to C in V2 is jacked up.
Richard Smith wrote:
Yeah.. Thats the problem. V1 code worked great but something in the port to C in V2 is jacked up.
Are you sure v1 works? Uwe seems to have suggested that it doesn't.
Thanks!
-- Al
On Fri, Mar 30, 2007 at 08:24:44AM +0300, Al Boldi wrote:
Richard Smith wrote:
Yeah.. Thats the problem. V1 code worked great but something in the port to C in V2 is jacked up.
Are you sure v1 works? Uwe seems to have suggested that it doesn't.
I'm not sure. I recently tested another 440BX board using the v1 code (Tyan S1846). It got to the point where it says "ELF loader by Eric Biederman" (or so). That looks like the RAM init passed just fine, right? Can somebody confirm that?
Uwe.
On 3/30/07, Uwe Hermann uwe@hermann-uwe.de wrote:
On Fri, Mar 30, 2007 at 08:24:44AM +0300, Al Boldi wrote:
Richard Smith wrote:
Yeah.. Thats the problem. V1 code worked great but something in the port to C in V2 is jacked up.
Are you sure v1 works? Uwe seems to have suggested that it doesn't.
I'm not sure. I recently tested another 440BX board using the v1 code (Tyan S1846). It got to the point where it says "ELF loader by Eric Biederman" (or so). That looks like the RAM init passed just fine, right? Can somebody confirm that?
that means stack works. If you get there you've gotten quite far.
ron
ron minnich wrote:
Yeah.. Thats the problem. V1 code worked great but something in the port to C in V2 is jacked up.
Are you sure v1 works? Uwe seems to have suggested that it doesn't.
I'm not sure. I recently tested another 440BX board using the v1 code (Tyan S1846). It got to the point where it says "ELF loader by Eric Biederman" (or so). That looks like the RAM init passed just fine, right? Can somebody confirm that?
I _know_ V1 used to work. I had a product at Bitworks based on it. At least it worked for the Bitworks IMS board. If you pull V1 to test then I recommend that you use older gcc's and tweak the makefile to use them. I think you may need to use gcc-2.95 or gcc 3.3
On Fri, Mar 30, 2007 at 08:03:00PM -0400, Richard Smith wrote:
I'm not sure. I recently tested another 440BX board using the v1 code (Tyan S1846). It got to the point where it says "ELF loader by Eric Biederman" (or so). That looks like the RAM init passed just fine, right? Can somebody confirm that?
I _know_ V1 used to work. I had a product at Bitworks based on it. At least it worked for the Bitworks IMS board. If you pull V1 to test then I recommend that you use older gcc's and tweak the makefile to use them. I think you may need to use gcc-2.95 or gcc 3.3
Do you think that makes a difference? I used gcc 4.1.2. I had to fix the code a bit to make it compile, but it _did_ compile. Apart from that, is there another reason to use an older compiler?
Uwe.
Uwe Hermann wrote:
least it worked for the Bitworks IMS board. If you pull V1 to test then I recommend that you use older gcc's and tweak the makefile to use them. I think you may need to use gcc-2.95 or gcc 3.3
Do you think that makes a difference? I used gcc 4.1.2. I had to fix the code a bit to make it compile, but it _did_ compile. Apart from that, is there another reason to use an older compiler?
Because those are the versions that I was using when I was building working roms.
gcc4 is a different beast than 2.95 or 3. If you used 4 and it worked then cool but if not then trying older versions seems in order. Droping back to earlier ld versions might also be a good thing to try.
* Uwe Hermann uwe@hermann-uwe.de [070331 04:04]:
I _know_ V1 used to work. I had a product at Bitworks based on it. At least it worked for the Bitworks IMS board. If you pull V1 to test then I recommend that you use older gcc's and tweak the makefile to use them. I think you may need to use gcc-2.95 or gcc 3.3
Do you think that makes a difference? I used gcc 4.1.2. I had to fix the code a bit to make it compile, but it _did_ compile. Apart from that, is there another reason to use an older compiler?
There's some tricky stuff. If you use asm() statements without cleanly specifying the clobbered registers, gcc 4 will be in real trouble. gcc 3 was not for some reason.
this made FILO compile fine, but fail on loading a kernel by printing a 0 and rebooting. This stuff is nasty to debug.
* Richard Smith smithbone@gmail.com [070331 02:03]:
I _know_ V1 used to work. I had a product at Bitworks based on it. At least it worked for the Bitworks IMS board. If you pull V1 to test then I recommend that you use older gcc's and tweak the makefile to use them. I think you may need to use gcc-2.95 or gcc 3.3
Or send fixes for newer gccs... ;-)
that's the weird part. 440bx worked in v1 for years, and worked well.
I don't know what the issue is on v2. I have no 440bx boards, have not had them for 4-5 years, so can't tell.
ron
On Thu, Mar 29, 2007 at 04:06:56PM +0200, Oscar Molin wrote:
Hi Peter I said in an email to Corey about unbricking, that I think it might be possible to use the recovery part of the bios, appending that file from Intels own bios with a linuxbios. I'm not 100% sure that works but it might. I forgot to forward that message to the mailing list.
I recognize it, I think I'm just replying a few days late.
Intels bios structure
[..]
If I can include these recvery files, and place the linuxbios in the regular bios files (with intels header info to make their flash-program accept it), I don't see a reason why it shouldn't work.
Could work, but reverse engineering the BIOS format may need quite an effort.
Intels flasher also has a function that checks validity of the files before flashing, so if there is a checksum or something in the header that has to match, I would be able to solve it or even bruteforce it to make it accept my files instead. The reason I'm looking at this way of handling things, and not just soldering a socket the first thing I do, is:
- I'm lazy
- This is the way it has to be done if there is ever going to be
Intel OEM support, since their flasher is AFAIK the only one that can flash there chips.
flashrom already supports two Intel chips and I don't see why more couldn't be added?
Regular users can't be expected to solder bios chips.
Certainly not.
Thanks for the offer about the socket, but I'm too far away so I'll have to do it myself.
All right.
If the working assembler code can be put in with the C code, and then change it line by line until it stops working, you should be able to pinpoint the problem right? Maybe my thinking is flawed, I'm not a good programmer.
Nope, it makes sense.
//Peter
Oscar Molin wrote:
I have 2 Intel SE440BX and one Intel SE440bx-3 (it's some kind of subversion to sebx-2) These were very popular Intel OEM boards and were used by Dell, compaq, fujitsu and the like. If someone wants info on what chips they have etc I'm willing to be of assistance and help with testing code one them to make them work. Since they all have Intels soldered on flash chips you can't make too many mistakes but I have no problem losing one in the process as I don't need all of them.
440BX is still very much a WIP. You'd end up losing all of them ;) BTW, Gateway also used those boards a lot, I've got a couple of them kicking around here. I've written some code to try and support the SuperI/O on that board, but I honestly can't remember where I put it right now, and I never did get to testing it.
At one point, I was looking at a TSOP (the type of chip that board has) programmer that sat on top of the flash chip and could program it without removing the chip. Aside from getting one of those (which I imagine are expensive), you'd have to somehow put a socket onto that board, which will involved an extremely steady hand with a sodiering iron.
-
Al Boldi -
Corey Osgood -
Oscar Molin -
Peter Stuge -
Richard Smith -
ron minnich -
Stefan Reinauer -
Uwe Hermann