Well, as there seems to be a lot of cleaning up going on lately, might as well add this to the docket. The attached patch removes the Bitworks IMS, as 1) there's no video support for it, 2) no one objected when this was discussed previously, and 3) no one seems to have one, and they aren't readily available. Any comments are welcome.
Signed-off-by: Corey Osgood corey_osgood@verizon.net
On Tue, May 22, 2007 at 11:20:15PM -0400, Corey Osgood wrote:
Well, as there seems to be a lot of cleaning up going on lately, might as well add this to the docket. The attached patch removes the Bitworks IMS, as 1) there's no video support for it, 2) no one objected when this was discussed previously, and 3) no one seems to have one, and they aren't readily available. Any comments are welcome.
Signed-off-by: Corey Osgood corey_osgood@verizon.net
I tend to agree, but I'd like to hear the opinion of Richard (CC'd).
Well, reason 1 and 3 are quite surely not enough to remove it, maybe not even reason 2. The reason why I agree that it can be removed is that it's almost completely copy+paste code from other targets with no real IMS-specific code which would be useful for anyone.
It may be easier to just start fresh if/when the IMS shall be ported to v2.
Richard, please let us know if we shall keep the code, otherwise I'll remove it in one or two days.
Cheers, Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070524 20:55]:
I tend to agree, but I'd like to hear the opinion of Richard (CC'd).
Well, reason 1 and 3 are quite surely not enough to remove it, maybe not even reason 2. The reason why I agree that it can be removed is that it's almost completely copy+paste code from other targets with no real IMS-specific code which would be useful for anyone.
It may be easier to just start fresh if/when the IMS shall be ported to v2.
Richard, please let us know if we shall keep the code, otherwise I'll remove it in one or two days.
my €0.02:
I think we should concentrate on fixing existing boards and adding new ones, not removing boards.
Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [070524 20:55]:
I tend to agree, but I'd like to hear the opinion of Richard (CC'd).
One drawback Ive discovered of gmail is that it will filter out duplicates so a cc: and a subscription to the list means that I only get one copy and it went into the linuxbios list filter which is massively lagged.
My apologies for not responding sooner.
Well, reason 1 and 3 are quite surely not enough to remove it, maybe not even reason 2. The reason why I agree that it can be removed is that it's almost completely copy+paste code from other targets with no real IMS-specific code which would be useful for anyone.
It may be easier to just start fresh if/when the IMS shall be ported to v2.
Richard, please let us know if we shall keep the code, otherwise I'll remove it in one or two days.
As Jordan acked you have my full permission to remove it from the tree if you so desire. As noted there is no IMS specific code in the tree because at the time RAM init for 440bx did not work. All my custom mods were in V1 in my private tree.
Reason #1 is the reason IMS was halted. I was using V1 code with the Linux command line VBIOS emulator and was never able to make the ATI M1 graphics chips work correctly. I could get HSYNC, and VSYNC correctly for 1024x768 but the screen was always black with a big block for the mouse cursor.
That said, I still have some boards and I would sure love to see proper video pop out sometime before I die. It is the only project of mine that outright failed because of technical problems I was not able to solve. The scars remain.
That was 6 months of some of the most intense debugging I've ever done. Eventually discovering the root cause would cleanse my debugging soul.
What 440bx based boards now work?
Maybe I'll take a Sunday afternoon and try to boot the code one of them on the IMS boards I have.
On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote:
What 440bx based boards now work?
tyan/s1846
//Peter
On Tue, Nov 27, 2007 at 03:39:54AM +0100, Peter Stuge wrote:
On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote:
What 440bx based boards now work?
tyan/s1846
Uh, that and
ASUS P2B ASUS P2B-F ASUS P3B-F A-Trend ATC-6220 AZZA PT-6IBD Biostar M6TBA Compaq Deskpro EN SFF P600 GIGABYTE GA-6BXC
Uwe.
On Mon, Nov 26, 2007 at 07:31:14PM -0500, Richard Smith wrote:
That said, I still have some boards and I would sure love to see proper video pop out sometime before I die. It is the only project of mine that outright failed because of technical problems I was not able to solve. The scars remain.
That was 6 months of some of the most intense debugging I've ever done. Eventually discovering the root cause would cleanse my debugging soul.
What 440bx based boards now work?
Each one which is in v2 svn (ca. 10 boards).
Maybe I'll take a Sunday afternoon and try to boot the code one of them on the IMS boards I have.
That would be great. If you stick one DIMM in slot 0 it should boot right away (yes, this will be fixed to support all combinations), just use either of the 440BX targets in svn. Except for 4-5 lines of code per target they're all the same.
Uwe.
Uwe Hermann wrote:
Maybe I'll take a Sunday afternoon and try to boot the code one of them on the IMS boards I have.
That would be great. If you stick one DIMM in slot 0 it should boot right away (yes, this will be fixed to support all combinations), just use either of the 440BX targets in svn. Except for 4-5 lines of code per target they're all the same.
I think I've got a p2b somewhere as well.
I was looking at the code last night. There does not seem to be any attempt to autodetect the settings from the spd. Its all marked TODO. Is there any code in anyone's private tree thats trying to do that?
I suspect that with a board that boots it should not be too much work to make the setup use the info from the SPD.
Uwe Hermann wrote:
That would be great. If you stick one DIMM in slot 0 it should boot right away (yes, this will be fixed to support all combinations), just use either of the 440BX targets in svn. Except for 4-5 lines of code per target they're all the same.
I may be able to help out here. I have a GigaByte i440bx board with a dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled.
Is it safe to flash it and still fallback to the original vendor bios?
Also, is there a tarball link to the sources?
Thanks!
-- Al
Al Boldi wrote:
I may be able to help out here. I have a GigaByte i440bx board with a dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled.
Oh. I don't care about bricking. My boards have sockets and unbricking things is my specialty. I got programmers, rework equipment, bla bla.
I just don't want to spend my time adding memory autodetection code if somebody already has it 90% there.
Also, is there a tarball link to the sources?
http://snapshots.linuxbios.org/
On Wed, Nov 28, 2007 at 08:04:59AM -0500, Richard Smith wrote:
I may be able to help out here. I have a GigaByte i440bx board with a dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled.
Oh. I don't care about bricking. My boards have sockets and unbricking things is my specialty. I got programmers, rework equipment, bla bla.
I just don't want to spend my time adding memory autodetection code if somebody already has it 90% there.
I have an almost-finished (and untested, yet) patch lingering on my drive for a few weeks now for the 440BX RAM init, which adds generic SPD functions in lib/spd.c and some 440BX-specific stuff in the resp. raminit.c. Will post soon.
Another patch I have here (just needs some small fixes, but an older version is still in the list archives, I posted it months ago) for the 82371EB southbridge which the 440BX boards use. I'll finish up that one first an post it after a few tests.
Uwe.
Uwe Hermann wrote:
functions in lib/spd.c and some 440BX-specific stuff in the resp. raminit.c. Will post soon.
82371EB southbridge which the 440BX boards use. I'll finish up that one first an post it after a few tests.
Great. I'll have reason to do some linuxbios hacking soon. I purchased some GIGABYTE GA-M57SLI-S4 setups to build a Multi-TB RAID server. Parts should arrive next week. One goes into service with stock BIOS to get going ASAP and the other gets LB.
Ultimate plan is a LB based NAS with the only rotating media being the SATA drives. Ward tells me there's still a bit 'o hacking to be done to all the get all the SATA slots up. If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
On Wed, Nov 28, 2007 at 07:14:08PM -0500, Richard Smith wrote:
Great. I'll have reason to do some linuxbios hacking soon. I purchased some GIGABYTE GA-M57SLI-S4 setups to build a Multi-TB RAID server. Parts should arrive next week. One goes into service with stock BIOS to get going ASAP and the other gets LB.
Ultimate plan is a LB based NAS with the only rotating media being the SATA drives. Ward tells me there's still a bit 'o hacking to be done to all the get all the SATA slots up.
Actually, no, all SATA slots are ok on this board (afaik); it's on the ck804 chipset that we have issues.
On this board we're still missing some interrupts on one of the PCI slots; there's no acpi, no fan control yet, some funkiness with i2c, etc.
If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
That should be interesting; count me in :) I have a couple spi boards of this type that need to be LB'ed.
Thanks, Ward.
On 29.11.2007 01:14, Richard Smith wrote:
Great. I'll have reason to do some linuxbios hacking soon. I purchased some GIGABYTE GA-M57SLI-S4 setups to build a Multi-TB RAID server. Parts should arrive next week. One goes into service with stock BIOS to get going ASAP and the other gets LB.
Ultimate plan is a LB based NAS with the only rotating media being the SATA drives. Ward tells me there's still a bit 'o hacking to be done to all the get all the SATA slots up. If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
For SPI flash size, the limitation is not how much the chipset can support, but how much the SPI translation feature in the IT8716F can support.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
For SPI flash size, the limitation is not how much the chipset can support, but how much the SPI translation feature in the IT8716F can support.
Are you talking about LCP reads -> SPI reads translation?
If so I only need that for the initial boot. After that I can issue SPI read commands directly to the device.
Is there some other limitation in the IT8716F you know of that won't let me read the full 24 bits of address? The datasheet is sparse but seems pretty straight forward. All the necessary registers and bits appear documented.
On 29.11.2007 19:34, Richard Smith wrote:
Carl-Daniel Hailfinger wrote:
For SPI flash size, the limitation is not how much the chipset can support, but how much the SPI translation feature in the IT8716F can support.
Are you talking about LCP reads -> SPI reads translation?
Yes.
If so I only need that for the initial boot. After that I can issue SPI read commands directly to the device.
Which is a little bit slow/inefficient. I suspect that using a USB storage device (together with early USB initialization) will give you better overall performance.
Is there some other limitation in the IT8716F you know of that won't let me read the full 24 bits of address? The datasheet is sparse but seems pretty straight forward. All the necessary registers and bits appear documented.
I am not aware of any other limitation.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
If so I only need that for the initial boot. After that I can issue SPI read commands directly to the device.
Which is a little bit slow/inefficient. I suspect that using a USB storage device (together with early USB initialization) will give you better overall performance.
Using multi-byte reads it should not be that much slower than the LPC->SPI read. Perhaps a bit more overhead but not much.
Assuming the max SPI clock of 33Mhz I see in the data sheet is correct then, yes, the data rate will be much slower than USB.
That said, here in the OLPC offices we have still have periodic pain involved with USB booting. A lot of usb sticks are just trash. The generic case requires up to several seconds of delay before you can access them.
In anycase, I'll have to start with USB and I have to get the compressed fs image to fit in 15 megs or less or it won't matter.
On Wed, Nov 28, 2007 at 07:14:08PM -0500, Richard Smith wrote:
If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
I'm waiting for sales information for 32Mbit flash, and will try to get the moq down a bit from 1k so I can order some.
Winbond list a 64Mbit product too, but it isn't available yet.
Does anyone know how big memory area is decoded to LPC by the mcp55?
//Peter
On Nov 30, 2007 4:42 AM, Peter Stuge peter@stuge.se wrote:
On Wed, Nov 28, 2007 at 07:14:08PM -0500, Richard Smith wrote:
If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
I'm waiting for sales information for 32Mbit flash, and will try to get the moq down a bit from 1k so I can order some.
Winbond list a 64Mbit product too, but it isn't available yet.
Does anyone know how big memory area is decoded to LPC by the mcp55?
it should be 16Mbyte.
you check that in mcp55_enable_rom.c
YH
On 30.11.2007 13:42, Peter Stuge wrote:
On Wed, Nov 28, 2007 at 07:14:08PM -0500, Richard Smith wrote:
If I can I'd also like to upgrade the SPI flash part to as big as the chipset will support and if thats still not big enough to hold my kernel+rootfs then change to a USB nand drive.
I'm waiting for sales information for 32Mbit flash, and will try to get the moq down a bit from 1k so I can order some.
The performance of SPI flash parts is usually dependent on three factors: * Clock frequency * Pinout (1-Read or 2-Read or 4-Read) * Bytes per Read command.
With the IT8716F SPI translation feature, the best possible result is: (freq/8/2) Byte/s That is roughly 2 MByte/s, way too slow to try to boot from it.
If you have a SPI controller which supports continuous 4-Read at 85 MHz, you can get up to 42 MByte/s in linear reads. Such a solution would be really nice.
Regards, Carl-Daniel
On Nov 30, 2007 3:44 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
With the IT8716F SPI translation feature, the best possible result is: (freq/8/2) Byte/s That is roughly 2 MByte/s, way too slow to try to boot from it.
it's actually pretty tolerable if you're just sucking in an initrd. I've done this sort of thing.
ron
Hello! Richard, would you be interested in a second opinion concerning a Bitworks IMS board? And would you mind letting me know off-list of course? Also can you advise me, in the same venue, what the motivation behind the boards was.
Let's just say I am curious about them.
-- Gregg C Levine hansolofalcon@worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi
-----Original Message----- From: linuxbios-bounces@linuxbios.org
[mailto:linuxbios-bounces@linuxbios.org] On
Behalf Of Richard Smith Sent: Wednesday, November 28, 2007 8:05 AM To: Al Boldi Cc: LinuxBIOS Mailing List Subject: Re: [LinuxBIOS] [PATCH] Remove Bitworks IMS
Al Boldi wrote:
I may be able to help out here. I have a GigaByte i440bx board with a dual-bios. There are two physical non-socketed chips, but the fallback
logic
is software conntrolled.
Oh. I don't care about bricking. My boards have sockets and unbricking things is my specialty. I got programmers, rework equipment, bla bla.
I just don't want to spend my time adding memory autodetection code if somebody already has it 90% there.
Also, is there a tarball link to the sources?
http://snapshots.linuxbios.org/
-- Richard A. Smith smithbone@gmail.com
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Wed, Nov 28, 2007 at 01:39:33PM +0300, Al Boldi wrote:
I may be able to help out here. I have a GigaByte i440bx board with a
Which board exactly? The GIGABYTE GA-6BXC is currently supported.
dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled.
Is it safe to flash it and still fallback to the original vendor bios?
Probably not, or it's risky at least. The chips being non-socketed is always a problem because you cannot revert back to the original BIOS (unless you have some soldering skills).
I'm relatively sure the dual-bios solution will not work in this case, as it's software-controlled (but other may have more information).
Uwe.
On Thu, Nov 29, 2007 at 02:34:18AM +0100, Uwe Hermann wrote:
I'm relatively sure the dual-bios solution will not work in this case, as it's software-controlled (but other may have more information).
Correct, any BIOS failsafe in software is out of play once LB is in the flash chip.
IIRC Gigabyte had some patents on a hardware failsafe as well, but it may not always be populated.
//Peter
Uwe Hermann wrote:
On Wed, Nov 28, 2007 at 01:39:33PM +0300, Al Boldi wrote:
I may be able to help out here. I have a GigaByte i440bx board with a
Which board exactly? The GIGABYTE GA-6BXC is currently supported.
GIGABYTE GA-BX2000. AwardBIOS 2A69KG0E.
dual-bios. There are two physical non-socketed chips, but the fallback logic is software conntrolled.
Is it safe to flash it and still fallback to the original vendor bios?
Probably not, or it's risky at least. The chips being non-socketed is always a problem because you cannot revert back to the original BIOS (unless you have some soldering skills).
I'm relatively sure the dual-bios solution will not work in this case, as it's software-controlled (but other may have more information).
That's what I thought. But, it's got two blind jumpers, J18 & J19, saying OPEN: Dual BIOS, CLOSED: Backup BIOS. I'll have to try to close those, to see if this is actually implemented.
Thanks!
-- Al
-
Al Boldi -
Carl-Daniel Hailfinger -
Corey Osgood -
Gregg C Levine -
Peter Stuge -
Richard Smith -
ron minnich -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege -
yhlu