Broadcom Blast works...I'm the maintainer of it.
YH
-----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Uwe Hermann Sent: Wednesday, October 25, 2006 10:51 AM To: linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] Improvements to "Supported Motherboards" wiki page.
Hi all,
there are a few boards left which don't yet have a status entryhere: http://www.linuxbios.org/Supported_Motherboards
Advantech SOM GX DB533-C Agami Aruma AMD Quartet AMD Rumba AMD Serenade Broadcom Blast Broadcom BCM5780 Dell S1850 DigitalLogic smartModule855 DigitalLogic msm586seg DigitalLogic msm800sev EagleLion 5BCM Intel Jarrell Intel XE7501devkit IWILL DK8S2 IWILL DK8X Lippert Cool Frontrunner Supermicro X6DAi-G Supermicro X6DHE-G Supermicro X6DHE-G2 Supermicro X6DHR-iG Supermicro X6DHR-iG2 Technologic TS5300 Totalimpact Briq VIA EPIA VIA EPIA-M VIA EPIA-MII
What's the status of those? Do they all work?
Thanks, Uwe.
* Lu, Yinghai yinghai.lu@amd.com [061025 20:03]:
Broadcom Blast works...I'm the maintainer of it.
YH
Epia-MII works as well, with the Epia-M target.
Hi,
On Thu, Oct 26, 2006 at 01:18:42AM +0200, Stefan Reinauer wrote:
- Lu, Yinghai yinghai.lu@amd.com [061025 20:03]:
Broadcom Blast works...I'm the maintainer of it.
YH
Epia-MII works as well, with the Epia-M target.
MII is now yellow (should it be green?). What's with the Epia-M itself, and with the Epia? Any known problems or should everything work?
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [061026 13:17]:
Hi,
On Thu, Oct 26, 2006 at 01:18:42AM +0200, Stefan Reinauer wrote:
- Lu, Yinghai yinghai.lu@amd.com [061025 20:03]:
Broadcom Blast works...I'm the maintainer of it.
YH
Epia-MII works as well, with the Epia-M target.
MII is now yellow (should it be green?). What's with the Epia-M itself, and with the Epia? Any known problems or should everything work?
IMHO Epia-MII should be green and Epia-M should be yellow. Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
Hi,
On Thu, Oct 26, 2006 at 03:45:22PM +0200, Stefan Reinauer wrote:
IMHO Epia-MII should be green and Epia-M should be yellow. Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
Yes, I think so. Every motherboard should have its own subdirectory. But we should try to find a way to prevent at least some of the duplicated code which is the result of that. Suggestions?
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [061026 19:28]:
On Thu, Oct 26, 2006 at 03:45:22PM +0200, Stefan Reinauer wrote:
IMHO Epia-MII should be green and Epia-M should be yellow. Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
Yes, I think so. Every motherboard should have its own subdirectory. But we should try to find a way to prevent at least some of the duplicated code which is the result of that. Suggestions?
Yes, we should get rid of 90% of the motherboard specific code and instead pack things into config files ;-) modularize as much as possible and autogenerate the rest.
in v3 we should get the failsafe and auto.c moved to generic code completely...
Yes, we should get rid of 90% of the motherboard specific code and instead pack things into config files ;-) modularize as much as possible and autogenerate the rest.
Amen.
in v3 we should get the failsafe and auto.c moved to generic code completely...
Unfortunately, in the failsafe part in the ROM, some things _have_ to be hardcoded, even if you _could_ auto-detect them, simply because auto detect is not "fail-safe" enough.
It should only be the bare minimum required to a) get console output; and b) reflash the board; of course.
Segher
* Segher Boessenkool segher@kernel.crashing.org [061026 22:22]:
Yes, we should get rid of 90% of the motherboard specific code and instead pack things into config files ;-) modularize as much as possible and autogenerate the rest.
Unfortunately, in the failsafe part in the ROM, some things _have_ to be hardcoded, even if you _could_ auto-detect them, simply because auto detect is not "fail-safe" enough.
It should only be the bare minimum required to a) get console output; and b) reflash the board; of course.
Perfectly right. I did not talk about autodetection at runtime. Being able to _configure_ the hardware of a mainboard in a _configuration file_ would be the way to go though.
What makes the boards in linuxbios so ugly at the moment is that 90% of the code in auto.c/cache_as_ram_auto.c is identical for all opteron boards. The 10% difference is the GPIOs for memreset and the I2C configuration for SPD ROM. Plus some hand crafted code to call the correct superio initialisation.
Notice something? This could easily be backed into 5 lines of configuration file, but its several hundreds of lines of code.
By automating this we drop some flexibility that we never used, and add a lot of flexibility because it is so easy to handle and extend.
Stefan
On Thu, Oct 26, 2006 at 03:45:22PM +0200, Stefan Reinauer wrote:
MII is now yellow (should it be green?). What's with the Epia-M itself, and with the Epia? Any known problems or should everything work?
IMHO Epia-MII should be green and Epia-M should be yellow.
MII needs to be yellow: The PCI slot is not initialized correctly (at least my PCI wifi card didn't show up in lspci) and the CF slot is still a problem. I have not tested 1394. (I put my MII board up in the ceiling, driving a projector at a stage event I was working on last week btw. Remote access via ssh over wifi. PAL output on VGA port with Dave's viafb. Sorry, no pictures.)
Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
It should have been done already, IMHO.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061027 01:38]:
Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
It should have been done already, IMHO.
I agree. I'll create a copy when Uwe checked in his CHIPNAME patch
On Fri, Oct 27, 2006 at 12:09:31PM +0200, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [061027 01:38]:
Maybe we should duplicate the epia-m target and have a seperate one for epia-mii so next time someone is fixing things for epia-m it wont break the mii.
It should have been done already, IMHO.
I agree. I'll create a copy when Uwe checked in his CHIPNAME patch
Done.
Uwe.
Uwe Hermann wrote:
and with the Epia? Any known problems or should everything work?
plain Epia is broken, though Ron supposedly has a working BIOS image (as far as I understand, no specific source code used to build it though...which reminds me, can you send me that image, Ron?)
-Alex Mauer "hawke"
Alex Mauer wrote:
Uwe Hermann wrote:
and with the Epia? Any known problems or should everything work?
I noticed on that page that the bottom section, "Motherboards supported in LinuxBIOSv1" lists the EPIA as "LBv2: Yes". If that is meant to indicate that it works in LBv2 it should probably be changed; if it is meant to indicate only that it exists in LBv2, then never mind.
-Alex Mauer "hawke"
Hi,
On Tue, Oct 31, 2006 at 09:01:18PM -0600, Alex Mauer wrote:
I noticed on that page that the bottom section, "Motherboards supported in LinuxBIOSv1" lists the EPIA as "LBv2: Yes". If that is meant to indicate that it works in LBv2 it should probably be changed; if it is meant to indicate only that it exists in LBv2, then never mind.
It's meant to indicate whether the board was ported to LinuxBIOSv2 at all. I clarified that a bit in the wiki.
Uwe.
-
Alex Mauer -
Lu, Yinghai -
Peter Stuge -
Segher Boessenkool -
Stefan Reinauer -
Uwe Hermann