From ts1 at tsn.or.jp Mon Dec 1 02:52:00 2003 From: ts1 at tsn.or.jp (Takeshi Sone) Date: Mon Dec 1 02:52:00 2003 Subject: Level 2 cache activation code? In-Reply-To: <1070234054.19232.32.camel@em2.my.own.domain> References: <1069797381.15097.72.camel@em2.my.own.domain> <1070234054.19232.32.camel@em2.my.own.domain> Message-ID: <20031201075151.GA32063@tsn.or.jp> On Mon, Dec 01, 2003 at 12:14:14AM +0100, Svante Signell wrote: > No speed-up seen. Extremely slow as before. Any hints? mtrr is OK, I > believe. Is it the microcode?? You could try the microcode driver of Linux or code from LinuxBIOS. > 3. How to create a kernel module consisting of more than one object > file. Now I include the needed source files into the main one. ld -o module.o -r obj1.o obj2.o -- Takeshi From niki.waibel at newlogic.com Mon Dec 1 05:45:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Dec 1 05:45:00 2003 Subject: v1: epia-m: irq_tables.c, mainboard.c Message-ID: <200312011044.hB1AiH84011967@enterprise2.newlogic.at> i think we need a new thread for the ``intel dual netwokcard problem on epia-m'' topic. facts (correct me if i am wrong!): * intel dual eth nic is not working with linuxbios (2003-10-24). * it can be plugged into the pci slot (00:14.0) of the epia-m. * the dual nic has a pci-to-pci bridge on the card. * that bridge assignes pci bus 2 (0=internal, 1=vga/agp?) * the 2 nics on the card assign: 02:04.0 and 02:05.0 * linuxbios detects the bus/bridge and also sees the 2 nic. !!* linuxbios does not assign irqs to the nics. * default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c: === /* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*5, /* there can be total 5 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0, /* Where the interrupt router lies (dev) */ 0x1c20, /* IRQs devoted exclusively to PCI usage */ 0, /* Vendor */ 0, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ #if 0 0x58, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st ructu re (including checksum) */ { {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, {0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2, 0}, {0,0x50, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0}, {0,0x68, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x4, 0}, {0,0x8, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0, 0}, {0x50,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0} } #else 0xac, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st ructu re (including checksum) */ { /* ethernet */ {0,0x90, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, /* usb */ {0,0x80, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x2, 0}, /* pci */ {0,0xa0, {{0x1, 0xdeb8}, {0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}}, 0x3, 0}, /* audio */ {0,0x8d, {{0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x0, 0}, /* 1394 */ {0,0x68, {{0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x3, 0} } #endif }; === * if i run util/getpir/getpir (with the dual eth nic board) i get: === /* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*5, /* there can be total 5 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0, /* Where the interrupt router lies (dev) */ 0x1c00, /* IRQs devoted exclusively to PCI usage */ 0, /* Vendor */ 0, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0x78, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st ructu re (including checksum) */ { {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, {0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2, 0}, {0,0x50, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0}, {0,0x68, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x4, 0}, {0,0x8, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0, 0}, } }; === * it does not help using the new irq_tables.c. * i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running. --> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq); pci_assign_irqs(2, 0x5, dualenetbIrq);'' in addition i had to play with the irq lists. questions: * what do the strange numbers in my new irq_table.c mean? * if everything is hardcoded in mainboard.c -- what is irq_table.c for? * is it possible that all this is hardcoded in mainboard.c for epia/epia-m only, but not for other boards? other boards use irq_table.c to assign interrupts? * if you plug a card to the pci slot linuxbios seems to detect everything (devices/bridges/devices behind bridges). why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs to all devices which were detected in the previous stage. this must be the way the regular bios does it... * when booting the epia-m with the std (award) bios and using the getpir prg -> the resulting irq_table.c does not work either. is it just ignored by the epia-m setup, or what is it actually for? niki From ijpriya at hotmail.com Mon Dec 1 07:52:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Mon Dec 1 07:52:00 2003 Subject: Linuxbios with Diskonchip? Message-ID: Hi, I have Diskonchip millennium MD2800 (8 MB capacity) and Microns SDRAM capacity (256 Mbits). Then the flash is to be mapped into the physical address 0xFFFFFFFF-0xFF800000. SDRAM is to mapped into the physical address 0x00000000-0xFE000000. Is this mapping correct? >From: ron minnich >To: Devi Priya >CC: gizara at cox.net, >Subject: Re: Linuxbios with Diskonchip? >Date: Sat, 29 Nov 2003 18:35:20 -0700 (MST) > >On Fri, 28 Nov 2003, Devi Priya wrote: > > > Hi, > > > > I am using Diskonchip millennium with boot capability. I just want >to > > know if diskonchip is mapped to the high order physical address (at >reset) > > and is any remapping is done later? > >usually mapped at flash address, right? 0xf0000 and 0xfff00000 > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ From rsmith at bitworks.com Mon Dec 1 11:58:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon Dec 1 11:58:01 2003 Subject: v1: epia-m: irq_tables.c, mainboard.c In-Reply-To: <200312011044.hB1AiH84011967@enterprise2.newlogic.at> References: <200312011044.hB1AiH84011967@enterprise2.newlogic.at> Message-ID: <3FCB72E7.6060109@bitworks.com> Niki Waibel wrote: > === > /* This file was generated by getpir.c, do not modify! > (but if you do, please run checkpir on it to verify) > Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up > > Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM Just FYI this link is going stale... MS currently redirects you to its new location but who knows how long that will last. Perhaps someone should save the whitepaper and put it at a location more under our control. It is useful info. Unless the ms copywrite forbids this, of course. :) -- Richard A. Smith rsmith at bitworks.com From ebiederman at lnxi.com Mon Dec 1 14:54:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 1 14:54:01 2003 Subject: automatic power on possible? In-Reply-To: <200311272142.21841.thomas@wehrspann.de> References: <200311272142.21841.thomas@wehrspann.de> Message-ID: writes: > Most modern motherboards supports the timer based automatic power on > via BIOS settings. With linuxbios this is not(?) possible. There is a program > for linux, called nvram-wakeup, to set the wakeup time in nvram or rtc. But > especially for the K7SEM or EPIA boards a reboot is needed after it, so the > wakeup settings can take effect. > Does anyone know what the BIOS is doing what linuxbios does not? > Perhaps it can be done in a program? I believe it is just a matter of programming some real-time clock registers so an alarm will go off at a specified time, and setting up the appropriate southbridge or superio bits so that the board will wake up when the alarm is triggered. I doubt it even requires BIOS support at all. Though that can't hurt. Eric From rminnich at lanl.gov Mon Dec 1 18:29:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 1 18:29:00 2003 Subject: v1: epia-m: irq_tables.c, mainboard.c In-Reply-To: <200312011044.hB1AiH84011967@enterprise2.newlogic.at> Message-ID: On Mon, 1 Dec 2003, Niki Waibel wrote: > i think we need a new thread for the ``intel dual netwokcard problem on > epia-m'' topic. > OK, I'm now looking at this for real :) > facts (correct me if i am wrong!): > * intel dual eth nic is not working with linuxbios (2003-10-24). > * it can be plugged into the pci slot (00:14.0) of the epia-m. > * the dual nic has a pci-to-pci bridge on the card. > * that bridge assignes pci bus 2 (0=internal, 1=vga/agp?) > * the 2 nics on the card assign: 02:04.0 and 02:05.0 > * linuxbios detects the bus/bridge and also sees the 2 nic. > !!* linuxbios does not assign irqs to the nics. > * default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c: ok so far. > {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, That's 0:14.0, or Bus 0, devfn 0xa0. > {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, Note that linuxbios and the standard bios agree. > > * it does not help using the new irq_tables.c. which makes sense as the one in there is already correct. My mistake. The issue is that the card you're using has a bridge on it. I've never dealt with this before. > * i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running. > --> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq); > pci_assign_irqs(2, 0x5, dualenetbIrq);'' > in addition i had to play with the irq lists. eek. You know that this is exactly the wrong way to do this and why, I assume. But it works, so keep it for now. But this will never go into the CVS. > > questions: > * what do the strange numbers in my new irq_table.c mean? doesn't matter, the old one was probably ok. > * if everything is hardcoded in mainboard.c -- what is irq_table.c for? irq_table.c is for linux, it tells linux how the irqs are wired up. In an ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd and those OSes would do everything correctly. In our world, each of these OSes get it wrong often enough that we have to now assign it directly. I had hoped to avoid IRQ assignment in linuxbios but it seems that we have no choice -- too many busted hardware/OS bits out there. > * is it possible that all this is hardcoded in mainboard.c for > epia/epia-m only, > but not for other boards? yes. > other boards use irq_table.c to assign interrupts? yes. And, *most of the time*, it works fine. > * if you plug a card to the pci slot linuxbios seems to detect everything > (devices/bridges/devices behind bridges). > why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs > to all devices which were detected in the previous stage. > this must be the way the regular bios does it... Yes. We need more complex irq management in linuxbios. Obviously linux doesn't know what to do here either. > * when booting the epia-m with the std (award) bios and using the getpir > prg -> the resulting irq_table.c does not work either. is it > just ignored > by the epia-m setup, or what is it actually for? I don't know what the award bios is doing. It's clear that linux is not able to handle the interrupt assignmnet in this case, so linuxbios will have to do more. Oh well. Another thing to add. ron From linladn at yahoo.co.in Mon Dec 1 18:36:01 2003 From: linladn at yahoo.co.in (=?iso-8859-1?q?mount=20me?=) Date: Mon Dec 1 18:36:01 2003 Subject: sst28SF040 sst28SF020 flash memories In-Reply-To: <20030821123454.S72144-100000@www.missl.cs.umd.edu> Message-ID: <20031201160747.33422.qmail@web8206.mail.in.yahoo.com> advantech/pcm-5823 ---> does this use sst28sf040 for having linux in it ? Or it is going to be the Etherboot/DOC for booting of the linux ? Could i get one advantech/pcm-5823 in india ? Any indians with linuxbios in their board ? firstboot, karthik bala guru ________________________________________________________________________ Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com From YhLu at tyan.com Mon Dec 1 19:59:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Dec 1 19:59:01 2003 Subject: Tyan S4880 Message-ID: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> Ron, Please check in the Tyan s2850/2880/2881/2882/4880 updates into the CVS Tree. 1. northbridge/amd/amdk8/raminit.h: change uint8_t to uint16_t 2. southbridge/amd/amd8111/amd8111_early_smbus.c: update smbus_write_byte 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to enable PCI-X MASTER Mode. 4. other in /src/mainboard/tyan/ and /targets/tyan Stefan, With update 1 and 2, you can get ride of FAKE_SPD_ROM. You need to change some lines in auto.c for quartet. 1. I2C HUB address: 0x30 --> 0x18, 2. RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8. Regards YH. -------------- next part -------------- A non-text attachment was scrubbed... Name: tyan_1201.change.diff.gz Type: application/octet-stream Size: 47193 bytes Desc: not available URL: From rminnich at lanl.gov Mon Dec 1 20:44:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 1 20:44:01 2003 Subject: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> Message-ID: stefan and eric, we will look at these changes tomorrow. If you get a chance can you scan them too to make sure no obvious problems exist? thanks ron p.s. Ollie, Greg, and I will be combing linuxbios source this week, looking at issues and working on integrating the newest LNXI code in as well as this code. From rminnich at lanl.gov Mon Dec 1 23:11:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 1 23:11:01 2003 Subject: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> Message-ID: I committed all this except for one thing: diff -uNr ./freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c ../freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c --- ./freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c 2003-10-13 06:01:13.000000000 -0400 +++ ../freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c 2003-12-01 16:14:18.000000000 -0500 @@ -120,24 +120,19 @@ return; } - /* setup transaction */ - /* disable interrupts */ - outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)), - SMBUS_IO_BASE + SMBGCTL); +//By LYH Begin + outb(0x37,SMBUS_IO_BASE + SMBGSTATUS); /* set the device I'm talking too */ - outw(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBHSTADDR); - outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); - /* set up for a byte data write */ /* FIXME */ - outw((inw(SMBUS_IO_BASE + SMBGCTL) & ~7) | (0x1), SMBUS_IO_BASE + SMBGCTL); - /* clear any lingering errors, so the transaction will run */ - /* Do I need to write the bits to a 1 to clear an error? */ - outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS); + outw(((device & 0x7f) << 1) | 0, SMBUS_IO_BASE + SMBHSTADDR); + + /* data to send */ + outb(val, SMBUS_IO_BASE + SMBHSTDAT); - /* clear the data word...*/ - outw(val, SMBUS_IO_BASE + SMBHSTDAT); + outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); /* start the command */ - outw((inw(SMBUS_IO_BASE + SMBGCTL) | (1 << 3)), SMBUS_IO_BASE + SMBGCTL); + outb(0xa, SMBUS_IO_BASE + SMBGCTL); +//By LYH END /* poll for transaction completion */ smbus_wait_until_done(); I'm a little worried about removing some of those lines, such as: /* disable interrupts */ outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)), SMBUS_IO_BASE + SMBGCTL); does it hurt to leave this in? OR: - /* clear any lingering errors, so the transaction will run */ - /* Do I need to write the bits to a 1 to clear an error? */ - outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS); why remove this? comments? ron From ebiederman at lnxi.com Tue Dec 2 01:09:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 2 01:09:00 2003 Subject: Tyan S4880 In-Reply-To: References: Message-ID: ron minnich writes: > I committed all this except for one thing: This feels like something brought on by excess register pressure. Ron one thing you did note was the changing of word accesses to byte accesses. With romcc that does not help in the case of register pressure. Usually doing the wrong size register accesses is a bad thing. Eric From ebiederman at lnxi.com Tue Dec 2 01:19:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 2 01:19:01 2003 Subject: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> References: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> Message-ID: YhLu writes: > Ron, > > Please check in the Tyan s2850/2880/2881/2882/4880 updates into the CVS > Tree. > > 1. northbridge/amd/amdk8/raminit.h: change uint8_t to uint16_t This is quite reasonable. > 2. southbridge/amd/amd8111/amd8111_early_smbus.c: update smbus_write_byte > 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to enable > PCI-X MASTER Mode. Why is this necessary? Previously it has been the policy to not set the master enables any more than is necessary for proper operation of the devices. Unless I am mistaken not setting the master enables is very much in spec for pci devices. > 4. other in /src/mainboard/tyan/ and /targets/tyan > > Stefan, > With update 1 and 2, you can get ride of FAKE_SPD_ROM. You need to change > some lines in auto.c for quartet. 1. I2C HUB address: 0x30 --> 0x18, 2. > RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8. Looking at the diffstat output you also touched the quartet/Config.lb and removed the FAKE_SPD define. Has this been tested? There is a context diff included in tyan/s2881/lyh.txt that does not look like it needs to be there. And of course there were all kinds of binary roms that the diff did not include. Eric From ebiederman at lnxi.com Tue Dec 2 01:49:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 2 01:49:01 2003 Subject: Tyan S4880 In-Reply-To: References: Message-ID: ron minnich writes: > stefan and eric, we will look at these changes tomorrow. If you get a > chance can you scan them too to make sure no obvious problems exist? > > thanks > > ron > p.s. Ollie, Greg, and I will be combing linuxbios source this week, > looking at issues and working on integrating the newest LNXI code in as > well as this code. I currently have a very odd issue. I am getting hang ups with B3 stepping cpus with the latest version of the LinuxBIOS tree that I have. I'm not certain what the problem is, but this will have create a delay in getting the last of my bug fixes out.. Eric From stepan at suse.de Tue Dec 2 09:16:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Dec 2 09:16:00 2003 Subject: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> References: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB> Message-ID: <20031202141555.GA19194@suse.de> * YhLu [031202 02:05]: > With update 1 and 2, you can get ride of FAKE_SPD_ROM. > You need to change some lines in auto.c for quartet. > 1. I2C HUB address: 0x30 --> 0x18, > 2. RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8. Tried this, doesn't work. I end up with 0KB memory detected on each CPU. Is it only my Quartets that behave like this? Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From miernik at ctnet.pl Tue Dec 2 09:38:00 2003 From: miernik at ctnet.pl (Miernik) Date: Tue Dec 2 09:38:00 2003 Subject: LinuxBIOS on laptop - someone can create a custom mainboard! Message-ID: <20031202143806.GA5688@tarnica.ctnet.pl> I think you will be interested in this project: http://www.technoir.nu/libretto/list/2003/msg01557.html Here he writes "Price really depends on what ICs and bios used": http://www.technoir.nu/libretto/list/2003/msg01564.html This would be a really exiting to have a complete custome made mainboard for a Toshiba Libretto laptop with LinuxBIOS. -- Miernik ________________________ jabber:miernik at amessage.info ___________________/__ tel: +48608233394 __/ mailto:miernik at ctnet.pl Sing a declaration against US invasion in Iraq: http://www.moveon.org/declaration/ From rminnich at lanl.gov Tue Dec 2 11:14:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Dec 2 11:14:01 2003 Subject: Tyan S4880 In-Reply-To: Message-ID: On 1 Dec 2003, Eric W. Biederman wrote: > Ron one thing you did note was the changing of word accesses to byte > accesses. With romcc that does not help in the case of register pressure. I would think it would hurt since x86 lets you use those little sub-registers (puddle arithmetic), so using bigger registers reduces the number of registers available. ron From stepan at suse.de Tue Dec 2 11:21:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Dec 2 11:21:00 2003 Subject: Tyan S4880 In-Reply-To: References: Message-ID: <20031202162031.GA23768@suse.de> * ron minnich [031202 17:13]: > On 1 Dec 2003, Eric W. Biederman wrote: > > > Ron one thing you did note was the changing of word accesses to byte > > accesses. With romcc that does not help in the case of register pressure. > > I would think it would hurt since x86 lets you use those little > sub-registers (puddle arithmetic), so using bigger registers reduces the > number of registers available. Yes, being able to use this from romcc would severely lower register pressure I assume. Neither romcc nor the code compiled with it takes care of this at the moment though. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From YhLu at tyan.com Tue Dec 2 12:25:00 2003 From: YhLu at tyan.com (YhLu) Date: Tue Dec 2 12:25:00 2003 Subject: =?GB2312?B?tPC4tDogVHlhbiBTNDg4MA==?= Message-ID: <3174569B9743D511922F00A0C943142303990830@TYANWEB> It should work for quertet. I compare the schematic of S4880 and quartet, and the SPD_ROM access part is the same. You need to update raminit.h and amd8111_early_sumbus.c too. YH. -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?12?2? 6:16 ???: YhLu ??: ron minnich; ebiederman at lnxi.com; linuxbios at clustermatic.org ??: Re: Tyan S4880 * YhLu [031202 02:05]: > With update 1 and 2, you can get ride of FAKE_SPD_ROM. > You need to change some lines in auto.c for quartet. > 1. I2C HUB address: 0x30 --> 0x18, > 2. RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8. Tried this, doesn't work. I end up with 0KB memory detected on each CPU. Is it only my Quartets that behave like this? Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From YhLu at tyan.com Tue Dec 2 12:29:01 2003 From: YhLu at tyan.com (YhLu) Date: Tue Dec 2 12:29:01 2003 Subject: =?GB2312?B?tPC4tDogVHlhbiBTNDg4MA==?= Message-ID: <3174569B9743D511922F00A0C943142303990833@TYANWEB> >> 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to enable >> PCI-X MASTER Mode. >Why is this necessary? Previously it has been the policy to not set >the master enables any more than is necessary for proper operation >of the devices. Unless I am mistaken not setting the master enables is >very much in spec for pci devices. Eric, Otherwise I can not use LAN and SCSI devices in PCI-X in Linux. For Broadcom NIC, I can not ifconfig and ping. For SCSI, I just can not get through the SCSI initialize in Linux kernel. YH. From stepan at suse.de Tue Dec 2 13:01:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Dec 2 13:01:01 2003 Subject: ????: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C943142303990830@TYANWEB> References: <3174569B9743D511922F00A0C943142303990830@TYANWEB> Message-ID: <20031202180030.GA24716@suse.de> * YhLu [031202 18:32]: > It should work for quertet. > > I compare the schematic of S4880 and quartet, and the SPD_ROM access part is > the same. > > You need to update raminit.h and amd8111_early_sumbus.c too. Aaah. I found the culprit. All SMBus addresses have to be shifted right by one compared to what the data sheet says. I forgot to do this for the DIMM modules. I checked your changes to amd8111_early_smbus.c into the freebios2 tree. I still can't see the onboard network adapter, even with only 3G in the machine. So I'll try the PCI-X master changes here as well. Thanks a lot, Yinghai! Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From ebiederman at lnxi.com Tue Dec 2 14:20:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 2 14:20:01 2003 Subject: =?gb2312?b?tPC4tA==?=: Tyan S4880 In-Reply-To: <3174569B9743D511922F00A0C943142303990833@TYANWEB> References: <3174569B9743D511922F00A0C943142303990833@TYANWEB> Message-ID: YhLu writes: > >> 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to > enable > >> PCI-X MASTER Mode. > > >Why is this necessary? Previously it has been the policy to not set > >the master enables any more than is necessary for proper operation > >of the devices. Unless I am mistaken not setting the master enables is > >very much in spec for pci devices. > > Eric, > > Otherwise I can not use LAN and SCSI devices in PCI-X in Linux. > For Broadcom NIC, I can not ifconfig and ping. > For SCSI, I just can not get through the SCSI initialize in Linux kernel. Hmm. Very odd. This has not been my experience so I want to confirm we are communicating clearly. We are talking about pci configuration space byte register 4, bit 2 which has a value of 0x4. bit 1 memory space enable of that byte our generic code should already be setting if the device has any memory resources. Linux drivers are expected to call pci_set_master() which sets this bit before performing DMA transactions. Any driver that does not is buggy. I believe we are talking about the general case of setting these bits, not the specific instance of the 8131 ioapic. And unless I am highly mistaken this all applies to pci devices in general not just pci-X devices.' So I can check out the possibility of buggy kernel drivers YH which kernel and which drivers are you using. tg3 or bcm??? for the broadcom nic. In the general case if we are going to do this we should set this bit in the pci layer so it always gets set and not set it for the individual devices. ....... Looking at the specific case of the amd8131, the documentation says unless master enable is set it will not generate interrupts. I would not see this problem on the HDAMA because it's interrupts are poorly wired and do not actually use the ioapic on the 8131, instead they all goto the 8111. IOAPICs are a case of architectural hardware. Architectural hardware is generally driven by generic drivers so it need to be configured to act exactly as specified in the architecture. To do that in this specific case we do need set the master enable, or we will not generate interrupts. Eric From YhLu at tyan.com Tue Dec 2 14:31:01 2003 From: YhLu at tyan.com (YhLu) Date: Tue Dec 2 14:31:01 2003 Subject: Tyan S4880 Message-ID: <3174569B9743D511922F00A0C943142303990875@TYANWEB> Eric, The Kernel is used 2.4.22 and I compiled it in ADM64 mode. The LAN device is Broadcom 5704 and driver should be tg3. The SCSI device (LSI SCSI 53c1030 -- onboard and Adaptec 29320 addon card) all can not be initialized in Linux Kernal. Regards YH. From ebiederman at lnxi.com Tue Dec 2 16:23:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 2 16:23:00 2003 Subject: config -> default In-Reply-To: References: Message-ID: ron minnich writes: > this fixup is at the top of next week's list now that sc '03 is over. > > sc '03 is a major event that pretty much eats up nov. for us, so sorry for > the inconvenience. Any head way on this. Especially the formulas which look like they will need a second pass to get right? And of course we still have some dependency problems with the makefiles. I'm not quite there but this is quickly becoming and itch I want to scratch, unless someone is working on this. Eric From gwatson at lanl.gov Tue Dec 2 16:38:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Tue Dec 2 16:38:00 2003 Subject: config -> default In-Reply-To: References: Message-ID: I'm looking at it. Greg At 2:27 PM -0700 12/2/03, Eric W. Biederman wrote: >ron minnich writes: > >> this fixup is at the top of next week's list now that sc '03 is over. >> >> sc '03 is a major event that pretty much eats up nov. for us, so sorry for >> the inconvenience. > >Any head way on this. Especially the formulas which look >like they will need a second pass to get right? > >And of course we still have some dependency problems with >the makefiles. > >I'm not quite there but this is quickly becoming and itch I want >to scratch, unless someone is working on this. > >Eric >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From mirenna at mi.ingv.it Wed Dec 3 04:34:00 2003 From: mirenna at mi.ingv.it (Santi Mirenna) Date: Wed Dec 3 04:34:00 2003 Subject: Help on epia-m 10000 linuxbios VGA Message-ID: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8> Hi to all, today i make EPIA-M 10000 rom image. i compile to have VGA and Filo, after apply patch of Dave Ashley and info from Takeshi about RAM ammount VGA now is found by the system but .... In attach you have the output log .... Can someone tell me where i wrong? Dave Ashley reply: You haven't applied all the patch, specifically the handler for the unsupported bios interrupts. This is the bug where it just gets into an endless loop of bios interrupts, so the program needs to exit the bios somehow. -Dave Hi , can some one tell me where to look .... i made the patch ....where to look Dave to know if the patch is ok ? Thanks. Santi Mirenna -------------- next part -------------- LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 starting... RB?0 LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 starting... 80 08 07 0d 0a 01 40 00 04 60 70 00 82 08 00 01 0e 04 0c 01 02 20 00 75 70 00 00 48 30 48 2a 40 75 75 45 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1106/3123] PCI: 00:01.0 [1106/b091] PCI: 00:0d.0 [1106/3044] PCI: 00:10.0 [1106/3038] PCI: 00:10.1 [1106/3038] PCI: 00:10.2 [1106/3038] PCI: 00:10.3 [1106/3104] PCI: 00:11.0 [1106/3177] PCI: 00:11.1 [1106/0571] PCI: 00:11.5 [1106/3059] PCI: 00:12.0 [1106/3065] PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1106/3122] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done Allocating PCI resources... PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it ASSIGN RESOURCES, bus 0 PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io PCI: 00:01.0 24 <- [0xf8000000 - 0xfbffffff] bus 1 prefmem PCI: 00:01.0 20 <- [0xfc000000 - 0xfcffffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf8000000 - 0xfbffffff] prefmem PCI: 01:00.0 14 <- [0xfc000000 - 0xfcffffff] mem ASSIGNED RESOURCES, bus 1 PCI: 00:0d.0 10 <- [0xfd000000 - 0xfd0007ff] mem PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io PCI: 00:10.0 20 <- [0x00001880 - 0x0000189f] io PCI: 00:10.1 20 <- [0x000018a0 - 0x000018bf] io PCI: 00:10.2 20 <- [0x000018c0 - 0x000018df] io PCI: 00:10.3 10 <- [0xfd001000 - 0xfd0010ff] mem PCI: 00:11.1 20 <- [0x000018e0 - 0x000018ef] io PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io PCI: 00:12.0 14 <- [0xfd002000 - 0xfd0020ff] mem ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 PCI: 00:01.0 cmd <- 07 PCI: 00:0d.0 cmd <- 07 PCI: 00:10.0 cmd <- 07 PCI: 00:10.1 cmd <- 07 PCI: 00:10.2 cmd <- 07 PCI: 00:10.3 cmd <- 07 PCI: 00:11.0 cmd <- 07 PCI: 00:11.1 cmd <- 07 PCI: 00:11.5 cmd <- 01 PCI: 00:12.0 cmd <- 07 PCI: 01:00.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized totalram: 224M Initializing CPU #0 Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 128MB, type WB Setting variable MTRR 1, base: 128MB, range: 64MB, type WB Setting variable MTRR 2, base: 192MB, range: 32MB, type WB DONE variable MTRRs Clear out the extra MTRR's call intel_enable_fixed_mtrr() call intel_enable_var_mtrr() Leave setup_mtrrs done. Max cpuid index : 1 Vendor ID : CentaurHauls Processor Type : 0x00 Processor Family : 0x06 Processor Model : 0x09 Processor Mask : 0x00 Processor Stepping : 0x01 Feature flags : 0x0380b135 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Disabling local apic...done. CPU #0 Initialized Mainboard fixup Final mainboard fixup Southbridge fixup setting firewire Assigning IRQ 10 to 0:d.0 Readback = 10 setting usb Assigning IRQ 11 to 0:10.0 Readback = 11 Assigning IRQ 10 to 0:10.1 Readback = 10 Assigning IRQ 12 to 0:10.2 Readback = 12 Assigning IRQ 5 to 0:10.3 Readback = 5 setting vt8235 Assigning IRQ 5 to 0:11.1 Readback = 255 Assigning IRQ 12 to 0:11.5 Readback = 12 setting ethernet Assigning IRQ 11 to 0:12.0 Readback = 11 setting vga Assigning IRQ 11 to 1:0.0 Readback = 11 setting pci slot 4d0: 0x20 4d1: 0x1c 4d0: 0x20 4d1: 0x1c INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3122 write_protect_vgabios 0x55 0xaa 0x7f 0xe9 0x12 0x5c 0xb1 0x1d 0xa6 0xfc 0xde 0x60 0x0 0x0 0x0 0x0 biosint: # 0x1a, eax 0xb108 ebx 0x0 ecx 0xffff0000 edx 0x3d5 biosint: ebp 0x11804 esp 0xfcc edi 0xf6 esi 0xf58d8 biosint: ip 0x40a3 cs 0x58d8 flags 0x46 0xb108: bus 0 devfn 0x0 reg 0xf6 val 0x3 biosint: # 0x15, eax 0x5f19 ebx 0x834 ecx 0xff20 edx 0x3d4 biosint: ebp 0x11804 esp 0xfca edi 0x44 esi 0xfb167 biosint: ip 0x4ef9 cs 0x44 flags 0x86 biosint: # 0x15, eax 0x5f19 ebx 0x404 ecx 0x0 edx 0x3d4 biosint: ebp 0x11804 esp 0xfb2 edi 0x44 esi 0xfb167 biosint: ip 0x51df cs 0x909 flags 0x2 biosint: # 0x15, eax 0x5f19 ebx 0xf004 ecx 0x0 edx 0x3c4 biosint: ebp 0x11804 esp 0xfca edi 0xb1a9 esi 0xfbcc5 biosint: ip 0x4fcb cs 0x44 flags 0x6 biosint: # 0x15, eax 0x5f19 ebx 0xf004 ecx 0x0 edx 0x3d4 biosint: ebp 0x11804 esp 0xfca edi 0xb1a9 esi 0xfbcc5 biosint: ip 0x5020 cs 0x44 flags 0x2 biosint: # 0x15, eax 0x5f0f ebx 0xb734 ecx 0xff20 edx 0x3d5 biosint: ebp 0x11804 esp 0xff0 edi 0x44 esi 0xf5c81 biosint: ip 0x5c98 cs 0x0 flags 0x2 biosint: # 0x15, eax 0x5f02 ebx 0x0 ecx 0x0 edx 0xd4 biosint: ebp 0x11804 esp 0xfde edi 0x44 esi 0xf5c81 biosint: ip 0x4008 cs 0x5c81 flags 0x46 biosint: # 0x15, eax 0x5f02 ebx 0x300 ecx 0x5 edx 0xd4 biosint: ebp 0x11804 esp 0xfcc edi 0x44 esi 0xf5c81 biosint: ip 0x4045 cs 0x5c81 flags 0x46 biosint: # 0x15, eax 0x5f19 ebx 0x1900 ecx 0x1 edx 0xd4 biosint: ebp 0x11804 esp 0xfde edi 0x44 esi 0xf5c81 biosint: ip 0x515d cs 0x5c81 flags 0x2 biosint: # 0x15, eax 0x5f19 ebx 0x1904 ecx 0x1 edx 0xd4 biosint: ebp 0x11804 esp 0xfda edi 0x44 esi 0xf5c81 biosint: ip 0x51df cs 0x909 flags 0x46 biosint: # 0x15, eax 0x5f02 ebx 0x0 ecx 0x0 edx 0xd4 biosint: ebp 0x11804 esp 0xff0 edi 0x44 esi 0xf5c81 biosint: ip 0x5ce8 cs 0x0 flags 0x46 biosint: # 0xf8, eax 0xc01b ebx 0x1000 ecx 0x100 edx 0x3ce biosint: ebp 0x10fca esp 0xfc0 edi 0x9c8a esi 0xf77e0 biosint: ip 0x2bf cs 0x7 flags 0x246 biosint: Unsupport int #0xf8 <----- biosint: # 0xc8, eax 0xc01b ebx 0x1000 ecx 0x100 edx 0x3ce biosint: ebp 0x10fca esp 0xfc0 edi 0x9c8a esi 0xf77e0 biosint: ip 0x2bf cs 0x7 flags 0x246 biosint: Unsupport int #0xc8 biosint: # 0xcd, eax 0xc01b ebx 0x1000 ecx 0x100 edx 0x3ce biosint: ebp 0x10fca esp 0xfc0 edi 0x9c8a esi 0xf77e0 biosint: ip 0x2bf cs 0x7 flags 0x246 biosint: Unsupport int #0xcd From ijpriya at hotmail.com Wed Dec 3 04:53:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 3 04:53:00 2003 Subject: Diskonchip ipl code for sc1200? Message-ID: Hi, I could not find any ipl code for sc1200 (nano mainboard). Which should I mention in the config file for docipl? Please give me suggestion. Thanks in advance. _________________________________________________________________ Contact brides & grooms FREE! Only on www.shaadi.com. http://www.shaadi.com/ptnr.php?ptnr=hmltag Register now! From stepan at suse.de Wed Dec 3 05:37:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Dec 3 05:37:00 2003 Subject: Diskonchip ipl code for sc1200? In-Reply-To: References: Message-ID: <20031203103637.GA28257@suse.de> * Devi Priya [031203 10:53]: > Hi, > > I could not find any ipl code for sc1200 (nano mainboard). Which should I > mention in the config file for docipl? Please give me suggestion. Have you looked at freebios/src/mainboard/nano/nano ? It contains sample configuration files.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From ian at abelon.com Wed Dec 3 06:00:01 2003 From: ian at abelon.com (Ian Smith) Date: Wed Dec 3 06:00:01 2003 Subject: Help on epia-m 10000 linuxbios VGA In-Reply-To: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8> References: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8> Message-ID: <6.0.1.1.2.20031203104904.02b71900@mail.abelon.com> An HTML attachment was scrubbed... URL: From mirenna at mi.ingv.it Wed Dec 3 09:15:01 2003 From: mirenna at mi.ingv.it (Santi Mirenna) Date: Wed Dec 3 09:15:01 2003 Subject: Help on epia-m 10000 linuxbios VGA Message-ID: <5.1.1.6.2.20031203151229.06182e18@10.1.1.8> At 11.59 03/12/2003, you wrote: >Hi Santi, > >At a minimum you need to check that your arch/i386/lib/idt.c file has the >Int 21 and Unsupported Interrupt handler calling code installed: > >@@ -175,9 +175,18 @@ > eax = 64 * 1024; > ret = 0; > break; >+#ifdef CONFIG_INT21HANDLER >+ case 0x15: >+ ret=handleint21( &edi, &esi, &ebp, &esp, >+ &ebx, &edx, &ecx, &eax, &flags); >+ break; >+#endif > default: > printk_info(__FUNCTION__ ": Unsupport int #0x%x\n", > intnumber); >+#ifdef CONFIG_UNSUPPORTINT_RECOVER >+ unsupportint_recover(); >+#endif > break; > > >and that arch/i386/lib/vgabios.c and mainboard/via/epia-m/mainboard.c >respectively have the actual handler routines: > >@@ -145,6 +145,13 @@ > __asm__ (".text\n""real_mode_switch_end:\n"); > extern char real_mode_switch_end[]; > >+#ifdef CONFIG_UNSUPPORTINT_RECOVER >+void unsupportint_recover(void) >+{ >+ __asm__ __volatile__ ( " jmp vgarestart \n" ); >+} >+#endif >+ > >and > >@@ -92,3 +176,33 @@ > final_southbridge_fixup(); > } > >+int handleint21( unsigned long *edi, unsigned long *esi, unsigned long *ebp, >+ unsigned long *esp, unsigned long *ebx, unsigned >long *edx, >+ unsigned long *ecx, unsigned long *eax, unsigned >long *flags) >+{ >+int res=-1; >+ switch(*eax&0xffff) >+ { >+ case 0x5f19: >+ break; >+ case 0x5f18: >+ *eax=0x5f; >+ *ebx=0x15; // MCLK = 133, 32M frame buffer >+ res=0; >+ break; >+ case 0x5f02: >+ *eax=0x5f; >+ *ebx=0 | (3<<8); >+ *ecx=5 | (0<<8) | (0<<16); >+ res=0; >+ break; >+ case 0x5f0f: >+ *eax=0x5f; >+ *ebx=0; >+ *ecx=0; >+ *edx=0; >+ res=0; >+ break; >+ } >+ return res; >+} > > >NOTE: It's possible that you may have patch these in by hand as the >original diffs were from an older version of the codebase and things may >have changed since then. All the patch is ok and I get the CVS of 05 2003-July >A quick check is to make sure there are no *.rej files present which might >indicate a patch operation has failed. all files are patched >The diffs aren't large, so it's probably worthing checking them by hand to >make sure the patches have been properly applied. > >Cheers > >Ian > >At 09:31 03/12/2003, Santi Mirenna wrote: >>Hi to all, today i make EPIA-M 10000 rom image. i compile to have VGA and >>Filo, >>after apply patch of Dave Ashley and info from Takeshi about RAM ammount >>VGA now is found by the system but .... >>In attach you have the output log .... >>Can someone tell me where i wrong? >> >>Dave Ashley reply: >> >>You haven't applied all the patch, specifically the handler >>for the unsupported bios interrupts. >>This is the bug where it just gets into an endless loop >>of bios interrupts, so the program needs to exit the >>bios somehow. -Dave >> >>Hi , can some one tell me where to look .... >>i made the patch ....where to look Dave to know if the patch is ok ? >> >>Thanks. >> >>Santi Mirenna From rminnich at lanl.gov Wed Dec 3 09:34:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 09:34:01 2003 Subject: Help on epia-m 10000 linuxbios VGA In-Reply-To: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8> Message-ID: can somebody write a HOWTO for this? people are really getting lost. ron From rminnich at lanl.gov Wed Dec 3 09:34:30 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 09:34:30 2003 Subject: Diskonchip ipl code for sc1200? In-Reply-To: Message-ID: On Wed, 3 Dec 2003, Devi Priya wrote: > I could not find any ipl code for sc1200 (nano mainboard). Which should I > mention in the config file for docipl? Please give me suggestion. you'll have to write it. ron From rminnich at lanl.gov Wed Dec 3 11:43:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 11:43:00 2003 Subject: arima hdama success Message-ID: as of this morning, with Yh Lu's changes, arima hdama builds work fine. ron From rminnich at lanl.gov Wed Dec 3 12:16:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 12:16:01 2003 Subject: config -> default In-Reply-To: Message-ID: On 2 Dec 2003, Eric W. Biederman wrote: > Any head way on this. Especially the formulas which look > like they will need a second pass to get right? it's moving. > I'm not quite there but this is quickly becoming and itch I want > to scratch, unless someone is working on this. I would rather not see the old stuff re-appear that put perl eval commands into the makefile. I had linuxbios builds down to 10 seconds at one point, but it is creeping up again as people put stuff like this in: export LINUXBIOS_BUILD:=$(shell date) export LINUXBIOS_COMPILE_TIME:=$(shell date +%T) export LINUXBIOS_COMPILE_BY:=$(shell whoami) export LINUXBIOS_COMPILE_HOST:=$(shell hostname) export LINUXBIOS_COMPILE_DOMAIN:=$(shell dnsdomainname) export LINUXBIOS_COMPILER:=$(shell $(CC) $(CFLAGS) -v 2>&1 | tail -n 1) export LINUXBIOS_LINKER:=$(shell $(CC) -Wl,-v 2>&1 | grep version | tail -n 1) export LINUXBIOS_ASSEMBLER:=$(shell touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>& 1; rm -f dummy.s dummy.o ) I find the LINUXBIOS_ASSEMBLER one fairly distressing. Also, the 'dnsdomainname' has caused trouble in the past on machines which are not using dns (these do exist). ron From stepan at suse.de Wed Dec 3 16:48:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Dec 3 16:48:01 2003 Subject: irq tables generation Message-ID: <20031203214831.GB2254@suse.de> Hi, * ron minnich [031202 00:28]: > > {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0}, > > > pci_assign_irqs(2, 0x5, dualenetbIrq);'' > > in addition i had to play with the irq lists. > > eek. You know that this is exactly the wrong way to do this and why, I > assume. But it works, so keep it for now. But this will never go into the > CVS. Do we agree that interrupts should be _unassigned_ during firmware execution and set by the OS only? Another way of handling this might be to set some default values and allow the OS to reconfigure those. A PIRQ-Table has to contain * one entry for each PCI device that needs an interrupt * one entry for each peer bus to be visible. It seems we know these parameters in-system already and can generate a valid table assuming some fixed parameters (cycling interrupts a la {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}} and a fixed mask of 0xdeb8. > irq_table.c is for linux, it tells linux how the irqs are wired up. In an > ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd > and those OSes would do everything correctly. In our world, each of these > OSes get it wrong often enough that we have to now assign it directly. I > had hoped to avoid IRQ assignment in linuxbios but it seems that we have > no choice -- too many busted hardware/OS bits out there. Not to forget the mptable - that contains additional information on which busses are available - information that Linux obviously don't like to read from there but from the irq table. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Wed Dec 3 17:05:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 17:05:01 2003 Subject: irq tables generation In-Reply-To: <20031203214831.GB2254@suse.de> Message-ID: On Wed, 3 Dec 2003, Stefan Reinauer wrote: > Do we agree that interrupts should be _unassigned_ during firmware > execution and set by the OS only? Another way of handling this might be > to set some default values and allow the OS to reconfigure those. I am finding that OSes are really dumb, in general. Much to my regret, we are going to have to assign these in linuxbios. It won't be 100% reliable otherwise. > Not to forget the mptable - that contains additional information on > which busses are available - information that Linux obviously don't like > to read from there but from the irq table. in SMP mode, the mptable is used. In UP mode with IO-APIC support, the mptable is used, But in Old Fashioned 1981 PC mode, the IRQ table is used and the MPTABLE ignored. what a mess. ron From stepan at suse.de Wed Dec 3 17:50:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Dec 3 17:50:00 2003 Subject: irq tables generation In-Reply-To: References: <20031203214831.GB2254@suse.de> Message-ID: <20031203225021.GA2359@suse.de> * ron minnich [031203 23:05]: > I am finding that OSes are really dumb, in general. Much to my regret, we > are going to have to assign these in linuxbios. It won't be 100% reliable > otherwise. It seems this does not add a lot of complexity, especially compared to providing all these tables to different OSes, but I might be wrong. > in SMP mode, the mptable is used. In UP mode with IO-APIC support, the > mptable is used, But in Old Fashioned 1981 PC mode, the IRQ table is used > and the MPTABLE ignored. > > what a mess. It's even better. Linux kernels compiled for x86_64 always use the IO-APIC. Still we need to add the peer bus 1 to the irq table so see the bus in Linux which could use the mptable to detect busses as well. Why I don't know. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From YhLu at tyan.com Wed Dec 3 21:26:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Dec 3 21:26:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB> Eric, I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c You put /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } Why you need to clear that? After you clear that, I can not see the 8151 and AGP in s2885. PS: I have reversed the scan sequence to make sure HT scan 8111 at first and then 8151. Regards Yinghai Lu From YhLu at tyan.com Wed Dec 3 21:29:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Dec 3 21:29:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C9431423039909D5@TYANWEB> Output -----????----- ???: YhLu ????: 2003?12?3? 18:34 ???: YhLu; ebiederman at lnxi.com ??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org ??: Tyan S2885 Eric, I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c You put /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } Why you need to clear that? After you clear that, I can not see the 8151 and AGP in s2885. PS: I have reversed the scan sequence to make sure HT scan 8111 at first and then 8151. Regards Yinghai Lu -------------- next part -------------- A non-text attachment was scrubbed... Name: s2885_out_put.zip Type: application/octet-stream Size: 22825 bytes Desc: not available URL: From ijpriya at hotmail.com Wed Dec 3 21:43:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 3 21:43:00 2003 Subject: Filesystem for doc? Message-ID: Hi, Which filesystem should I use for diskonchip? Should I use ths True FFS or can I use the NFTL? _________________________________________________________________ Love shopping online? Get this e credit card. http://server1.msn.co.in/features/amex/ Save cost, add value! From ijpriya at hotmail.com Wed Dec 3 22:39:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 3 22:39:01 2003 Subject: Diskonchip ipl code for sc1200? Message-ID: Hi, Thanks for ur suggestion. Should I write both ipl code for the chipset and the DOCM? Should I also write the SPL code for chipset and DOCM? Can I use the ipl and spl code given with the xpressloader BootLoader Development Kit? >From: ron minnich >To: Devi Priya >CC: linuxbios at clustermatic.org >Subject: Re: Diskonchip ipl code for sc1200? >Date: Wed, 3 Dec 2003 07:34:03 -0700 (MST) > >On Wed, 3 Dec 2003, Devi Priya wrote: > > > I could not find any ipl code for sc1200 (nano mainboard). Which >should I > > mention in the config file for docipl? Please give me suggestion. > >you'll have to write it. > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ It is Ms World time! Send in your wishes to Ami Vashi. http://server1.msn.co.in/sp03/Missworld2003/ Help her bring home the crown! From rminnich at lanl.gov Wed Dec 3 23:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 3 23:07:00 2003 Subject: Diskonchip ipl code for sc1200? In-Reply-To: Message-ID: On Thu, 4 Dec 2003, Devi Priya wrote: > Thanks for ur suggestion. Should I write both ipl code for the chipset > and the DOCM? Should I also write the SPL code for chipset and DOCM? Can I > use the ipl and spl code given with the xpressloader BootLoader Development > Kit? when I did this for VIA 8601 I adapted the code for ipl.S from sis 630. I think you should try that. ron From ijpriya at hotmail.com Thu Dec 4 08:44:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Thu Dec 4 08:44:00 2003 Subject: Doubt with Diskonchip millennium? Message-ID: Hi, In the application note (AP044) from Msystems diskonchip it is given as: "The DiskOnChip Millennium is mapped into an 8KB memory window in the host platform?s memory map. This 8KB window consists of four 2KB windows." Why is this mapping done? Is this done for all the DiskOnChip Millennium? The steps for BIOS is summarised as 1. After DiskOnChip Millennium BUSY# signal is negated, the CPU fetches the Reset Vector from the Boot-Block area, fetches the Boot Code stored there, and starts to execute the code. 2. Boot Code runs the first part of BIOS, initializing the basic hardware functionality. 3. Boot Codes loads the rest of the BIOS from the flash memory to the DRAM, and transfer control (jumps) there. 4. Chip Select of DiskOnChip Millennium is remapped from Reset Vector to BIOS expansion area. 5. CPU executes the rest of the BIOS code, including ROM expansion devices (among them, the DiskOnChip Millennium itself). 6. CPU calls OS bootstrap loader (INT19). 7. OS is loaded, and recognizes the DiskOnChip Millennium as the boot device. 8. OS loads the application code from the DiskOnChip Millennium and executes it. 9. Application software uses DiskOnChip Millennium exactly as if it were using a regular hard disk. In step 4 why is this remapping done _________________________________________________________________ Shop online for kids? toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com From svante.signell at telia.com Thu Dec 4 10:37:00 2003 From: svante.signell at telia.com (Svante Signell) Date: Thu Dec 4 10:37:00 2003 Subject: Level 2 cache activation code? In-Reply-To: <00de01c3b79c$5afc6f20$0701000a@techmanager> References: <1069797381.15097.72.camel@em2.my.own.domain> <1070234054.19232.32.camel@em2.my.own.domain> <00de01c3b79c$5afc6f20$0701000a@techmanager> Message-ID: <1070552214.1433.36.camel@em2.my.own.domain> On Mon, 2003-12-01 at 00:47, Denis Dowling wrote: > Hi Svante, > > ----- Original Message ----- > From: "Svante Signell" > To: "ron minnich" > Cc: "Takeshi Sone" ; > Sent: Monday, December 01, 2003 10:14 AM > Subject: Re: Level 2 cache activation code? > > > > The processor is an 1.3GHz Celeron Tualatin, with CPUID: 6b0. According > > to the code in l2_cache.c newer CPUs than Coppermine (680) does not need > > the L2 setup code. Is this the case? > > This was based on the assumption that all CPU from the coppermine forward > had the cache integrated onto the CPU die. Is this the case with your CPU. > Is it just a single large CPU on the slot1 pcb or does there look to be > cache chips mounted on the board as well? The CPU is placed on a socket 370 to slot 1 adapter (SLOT-T) from Upgradeware. No, there are no external cache chips on the MOBO. BTW, the MOBO is a dual CPU 82443BX board (MSI-6120). It runs perfectly well with dual Celerons (Mendocino). Also, the CPU placed on the SLOT-T adapter works perfectly well with other (single CPU) boards. > > if (signature < 0x630 || signature >= 0x680) { > > printk_debug("CPU signature of %x so no L2 cache configuration\n", > > signature); > > goto done; > > You could always just drop this test and see what happens later. If the CPU > does have external cache chips then this code might just work in > initiallising the cache. I have disabled the test and it seems the cache activation seem to work, see below. The slowness remains however :-( Dec 4 14:39:56 cl-dual kernel: Configuring L2 cache...Disable Cache Dec 4 14:39:56 cl-dual kernel: rdmsr(0x17) = 0, 84320000 Dec 4 14:39:56 cl-dual kernel: L2 Cache latency is 1 Dec 4 14:39:56 cl-dual kernel: Sending 0 to set_l2_register4 Dec 4 14:39:56 cl-dual kernel: L2 ECC Checking is enabled Dec 4 14:39:56 cl-dual kernel: L2 Physical Address Range is 512M Dec 4 14:39:56 cl-dual kernel: Maximum cache mask is 2000 Dec 4 14:39:56 cl-dual kernel: L2 Cache Mask is 0 Dec 4 14:39:56 cl-dual kernel: read_l2(2) = 0 Dec 4 14:39:56 cl-dual kernel: write_l2(2) = 0 Dec 4 14:39:56 cl-dual kernel: Enable Cache Dec 4 14:39:56 cl-dual kernel: L2 Cache size is 256K Dec 4 14:39:56 cl-dual kernel: L2 Cache lines initialized Dec 4 14:39:56 cl-dual kernel: Disable Cache Dec 4 14:39:56 cl-dual kernel: Enable Cache Dec 4 14:39:56 cl-dual kernel: done. Dec 4 14:39:56 cl-dual kernel: cache_on installed > Looks fine. Turn on as much debugging in the l2_cache code as possible and > post to me and I will decode. Need to be able to see all of the printk_debug > messages. > > Regards, > Denis What is wrong here: Not caches Not mtrr microcode?? anything else?? HW fault, i.e. the VRM does not work as expected, even though lm-sensors are reporting correct voltages. The BIOS is not supporting Coppermine and later CPUs. AMI BIOS V2.0 from (MSI) Soon giving up... From ebiederman at lnxi.com Fri Dec 5 00:31:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 5 00:31:01 2003 Subject: Tyan S2885 In-Reply-To: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB> References: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB> Message-ID: YhLu writes: > Eric, > > I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c > You put > /* Unmap all of the other pci busses */ > for(reg = 0xe0; reg <= 0xec; reg += 4) { > f1_write_config32(reg, 0); > } > > Why you need to clear that? After you clear that, I can not see the 8151 and > AGP in s2885. Hmm. This looks like a thinko. So right now the code says: unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } return max; } And I think what I meant was: unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); return max; } I don't have a clue why it works at all with clearing those registers after the pci bus scan. I wonder if that is the reason scan order matters because I don't clear those registers out first and things are dual mapped. Anyway my intention was to be very careful and to clear the HT chain mapping registers before we scanned them so we didn't have any old configurations getting in the way. Eric From ebiederman at lnxi.com Fri Dec 5 01:17:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 5 01:17:00 2003 Subject: Romcc Ramblings... In-Reply-To: <20031202162031.GA23768@suse.de> References: <20031202162031.GA23768@suse.de> Message-ID: Stefan Reinauer writes: > * ron minnich [031202 17:13]: > > On 1 Dec 2003, Eric W. Biederman wrote: > > > > > Ron one thing you did note was the changing of word accesses to byte > > > accesses. With romcc that does not help in the case of register pressure. > > > > I would think it would hurt since x86 lets you use those little > > sub-registers (puddle arithmetic), so using bigger registers reduces the > > number of registers available. > > Yes, being able to use this from romcc would severely lower register > pressure I assume. Neither romcc nor the code compiled with it takes > care of this at the moment though. I tried this at one point. And the problem is that there is not a instruction sequence to move to/from the byte registers from a normal 32bit register. Which negates most of the benefit of the extra registers. 64bit mode on the Opteron gets byte register correct but it no longer has more than one byte register per general purpose register. Getting in support for mmx and sse registers was much more beneficial. 16 more instead of just 4. A more general purpose technique is to use bit-fields. I am close to having bit-fields implemented in my backburner version of romcc. I have some really odd ball ideas about bitfields in 128 bit sse registers :) But who knows when I will get that done. Bit-fields still share with the x86 byte registers the property of increasing the register pressure when you modify their values or read/write them. (Because the field needs a register of it's own to be modified). But when they are just passed around they can nicely reduce the register pressure. And in addition they are under programmer control so you know it is a trade off between register pressure when using the value and register pressure when passing the values. You can roll bit-fields by hand at the moment if you want though. What I find most disturbing is last I looked is that size crt0.o list it at about 33K (After lowering spurious debugging messages from debug to spew). And linuxbios_payload.nrvb at about 24K. crt0.o from the p4dpr is at about 10K. So romcc is giving me a 3X code bloat... I am pretty certain it is code bloat caused by inlining everything. Ron you complained earlier about compile speed and I think romcc is the big culprit there. It's register allocator is currently using a O(N^2) data structure, so the more code it compiles the slower it gets... I think I saw another version of basically the same algorithm that uses a different data structure, which would make it much faster. Right now the speed is tolerable when I remember to set #define DEBUG_CONSISTENCY 1 instead of 2 which I committed accidently the other day. DEBUG_CONSISTENCY 2 is only really useful when debugging the register allocator. With a perfect compiler DEBUG_CONSISTENCY is not needed at all but romcc is still teething so if there is not a performance hit it is useful. Eric From cforney at opus.com Fri Dec 5 05:54:01 2003 From: cforney at opus.com (Craig C Forney) Date: Fri Dec 5 05:54:01 2003 Subject: arima hdama success Message-ID: <000901c3bb1d$77dd8dc0$0100a8c0@opusone> On Wed, 3 Dec 2003, Ron Minnich wrote > as of this morning, with Yh Lu's changes, arima hdama builds work fine. > >ron I'm not having the same success. I got the latest snapshot this evening, built for the arima hdama, and it fails the same way it has failed (hangs after printing out stuff below) for the last couple of months. Have Yh Lu's changes that fix the arima hdama been committed? If not, could someone point me to the changes that fix whatever this problem is? Thanks, Craig Forney Opus Innovations LLC LinuxBIOS-1.1.5.0Fallback Thu Dec 4 23:13:33 PST 2003 starting... setting up resource map.... AMD8111 southbridge is connected to HT link 00000000 setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling SMP settings setup_remote_node setup_remote_done Renaming current temp node to 00000001 done. Enabling routing table for node 00000001 done. 00000002 nodes initialized. detect_mp_capabilities: 00000002 coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram1.01 setting up CPU01 northbridge registers done. Ram2.00 166Mhz Interleaved RAM: 0x00100000 KB Ram2.01 Enabling dual channel memory disabling dimm00 disabling dimm01 disabling dimm00 disabling dimm01 200Mhz disabling dimm00 disabling dimm01 RAM: 0x00100000 KB Ram3 ECC enabled ECC enabled Initializing memory: done Clearing memory: addr 00000000-0000003f ----------------done Initializing memory: done Clearing memory: addr 00000040-0000003f done Ram4 PCI: 00:01.00 00: 22 10 50 74 00 00 30 02 12 00 04 06 00 00 81 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 f1 01 20 02 20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00 30: ff ff 00 00 a0 00 00 00 00 00 00 00 ff 00 00 00 40: 07 00 1f 00 00 00 00 00 02 0c 00 00 00 2c 00 00 50: 00 00 02 00 00 00 04 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 07 b8 03 00 08 00 03 00 0e 00 ff ff 02 00 ff ff b0: 00 00 00 00 00 00 00 00 08 c0 00 80 00 00 00 00 c0: 08 00 41 00 20 00 11 00 20 00 00 00 22 00 35 00 d0: 02 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 08 08 0c 00 08 08 0d 00 0f 0f 13 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:01.01 00: 22 10 51 74 00 00 00 02 01 10 00 08 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 ... PCI info deleted for brevity ... 80: 33 00 00 00 00 00 00 00 35 33 72 13 20 0a 10 00 90: 00 80 0a 08 08 0b 5b 0e 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: a3 88 1e 5a 02 00 00 00 8c 5b b7 d6 72 9f e7 ef c0: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 04 67 05 44 e4 ae 6b 16 9e 4f 10 40 c5 1b cc 44 e0: d9 c6 0a 24 48 04 5c 10 38 6c 03 48 86 74 2e 26 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCI: 00:18.03 00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 40 00 be fc 07 77 73 80 7b 46 50: 08 a5 f7 0b 88 00 00 00 16 16 16 00 00 04 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 11 01 02 51 11 80 00 50 00 38 00 08 1b 22 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 02 00 00 00 70 0f 00 00 00 83 06 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 01 00 00 e0 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 20 10 00 00 1b 01 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.5.0Fallback Thu Dec 4 23:13:33 PST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD 8111 Enumerating: NSC 87360 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [ffff/ffff] enabled PCI: 00:19.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 00:19.1 No device operations From rminnich at lanl.gov Fri Dec 5 10:48:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 5 10:48:01 2003 Subject: Romcc Ramblings... In-Reply-To: Message-ID: On 4 Dec 2003, Eric W. Biederman wrote: > > Ron you complained earlier about compile speed and I think romcc is the > big culprit there. It's register allocator is currently using a O(N^2) > data structure, so the more code it compiles the slower it gets... I > think I saw another version of basically the same algorithm that uses a > different data structure, which would make it much faster. I don't mind the romcc compile speed at all, I just don't want to see us return to the days of tons of perl code in the Makefiles. We made deliberate changes to the new config tool to eliminate the need for that stuff. When I first cut over to the new config tool I was quite surprised at the difference in build time for linuxbios -- all those Perl invocations are expensive. Romcc is fine by me, I don't care how fast it goes, it saves our necks. ron From YhLu at tyan.com Fri Dec 5 12:28:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Dec 5 12:28:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C943142303990AA3@TYANWEB> I will try the code and use normal scan. YH. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?12?4? 21:36 ???: YhLu ??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org ??: Re: Tyan S2885 YhLu writes: > Eric, > > I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c > You put > /* Unmap all of the other pci busses */ > for(reg = 0xe0; reg <= 0xec; reg += 4) { > f1_write_config32(reg, 0); > } > > Why you need to clear that? After you clear that, I can not see the 8151 and > AGP in s2885. Hmm. This looks like a thinko. So right now the code says: unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } return max; } And I think what I meant was: unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; /* Unmap all of the other pci busses */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); return max; } I don't have a clue why it works at all with clearing those registers after the pci bus scan. I wonder if that is the reason scan order matters because I don't clear those registers out first and things are dual mapped. Anyway my intention was to be very careful and to clear the HT chain mapping registers before we scanned them so we didn't have any old configurations getting in the way. Eric From steve at nexpath.com Fri Dec 5 13:11:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Fri Dec 5 13:11:01 2003 Subject: Romcc Ramblings... In-Reply-To: References: Message-ID: <3FD0CC7E.4080707@nexpath.com> ron minnich wrote: > I just don't want to see us > return to the days of tons of perl code in the Makefiles. We made > deliberate changes to the new config tool to eliminate the need for that > stuff. When I first cut over to the new config tool I was quite surprised > at the difference in build time for linuxbios -- all those Perl > invocations are expensive. You realize you are talking about God's Language :-)). Anyway, I think as many sins could just as easily be committed in bash, I wouldn't necessarily hang it all on Perl. IMHO. -Steve From rminnich at lanl.gov Fri Dec 5 13:15:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 5 13:15:00 2003 Subject: Romcc Ramblings... In-Reply-To: <3FD0CC7E.4080707@nexpath.com> Message-ID: On Fri, 5 Dec 2003, Steve Gehlbach wrote: > ron minnich wrote: > > I just don't want to see us > > return to the days of tons of perl code in the Makefiles. We made > > deliberate changes to the new config tool to eliminate the need for that > > stuff. When I first cut over to the new config tool I was quite surprised > > at the difference in build time for linuxbios -- all those Perl > > invocations are expensive. > > You realize you are talking about God's Language :-)). Anyway, I think > as many sins could just as easily be committed in bash, I wouldn't > necessarily hang it all on Perl. IMHO. yes, we want to keep the bash invocations to a minimum too. ron From stuge-linuxbios at cdy.org Fri Dec 5 13:48:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri Dec 5 13:48:01 2003 Subject: Romcc Ramblings... In-Reply-To: References: <20031202162031.GA23768@suse.de> Message-ID: <20031205184004.GE24918@foo.birdnet.se> On Thu, Dec 04, 2003 at 11:22:08PM -0700, Eric W. Biederman wrote: > > > > > > I would think it would hurt since x86 lets you use those little > > > sub-registers (puddle arithmetic), so using bigger registers reduces > > > the number of registers available. > > > > Yes, being able to use this from romcc would severely lower register > > pressure I assume. Neither romcc nor the code compiled with it takes > > care of this at the moment though. > > I tried this at one point. And the problem is that there > is not a instruction sequence to move to/from the byte registers > from a normal 32bit register. Hmm, there's movzx and movsx for moving to 32 bit, but from 32 to 8 is worse for esi, edi and ebp. 32->16 works fine of course. I could be missing something though. :) //Peter From jarcher at pobox.com Fri Dec 5 13:57:00 2003 From: jarcher at pobox.com (Jordan Archer) Date: Fri Dec 5 13:57:00 2003 Subject: Update to pirq_routing Message-ID: <5.2.1.1.2.20031205105558.00bb6b88@cybermorph.com> The following is the diff for a change I made. I think the HAVE_PIRQ_TABLE is always defined and this allowed me to turn off the existence of a routing table. Jordan RCS file: /cvsroot/freebios/freebios2/src/arch/i386/include/arch/pirq_routing.h,v retrieving revision 1.1 diff -r1.1 pirq_routing.h 42c42,43 < #if defined(DEBUG) && defined(HAVE_PIRQ_TABLE) --- > //#if defined(DEBUG) && defined(HAVE_PIRQ_TABLE) > #if defined(DEBUG) && HAVE_PIRQ_TABLE // JORDAN: This needs to be dependent on value, not existence. 48c49,50 < #if defined(HAVE_PIRQ_TABLE) --- > //#if defined(HAVE_PIRQ_TABLE) > #if HAVE_PIRQ_TABLE // JORDAN: This needs to be dependent on value, not Index: romcc_io.h =================================================================== From YhLu at tyan.com Fri Dec 5 18:03:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Dec 5 18:03:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C943142303990AFE@TYANWEB> Eric, I change amdk8_scan_root_bus to: unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; uint32_t value; /* Unmap all of the other pci busses */ printk_debug("\nbefore pci_scan_bus\n"); for(reg = 0xe0; reg <= 0xec; reg += 4) { value = f1_read_config32(reg); printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", reg,value,max); if((value>>24)>max) f1_write_config32(reg, 0); } for(reg = 0xe0; reg <= 0xec; reg += 4) { value = f1_read_config32(reg); printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", reg,value,max); } max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); printk_debug("after pci_scan_bus\n"); for(reg = 0xe0; reg <= 0xec; reg += 4) { value = f1_read_config32(reg); printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", reg,value,max); } return max; } I think as least you only need to clear the regs that contain bigger bus number than the next bus for scanning. The result will be in the end. The problems: 1. It can not access 8151 on CPU link0 and so can not scan it 2. The HT scan seems can not figure out and set the link and read/write enable bit in e0. It set the e0 to 0x05050000 Regards Yinghai Lu Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.52.0_Fallback Fri Dec 5 14:29:03 EST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD 8111 Enumerating buses... before pci_scan_bus amdk8_scan_root_bus e0 = 4000203 max = 0 amdk8_scan_root_bus e4 = 6050003 max = 0 amdk8_scan_root_bus e8 = 0 max = 0 amdk8_scan_root_bus ec = 0 max = 0 amdk8_scan_root_bus e0 = 0 max = 0 amdk8_scan_root_bus e4 = 0 max = 0 amdk8_scan_root_bus e8 = 0 max = 0 amdk8_scan_root_bus ec = 0 max = 0 PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 [1022/746d] enabled amd8111_enable dev: PCI: 01:04.6 lpc_dev: PCI: 01:04.0 index: 6 reg: ffff -> ffbf done PCI: 01:04.6 [ffff/ffff] disabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled amd8111_enable dev: PCI: 04:01.0 lpc_dev: PCI: 01:04.0 index: 9 reg: ffbf -> fdbf done PCI: 04:01.0 [ffff/ffff] disabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 4 Hypertransport scan link done Hyper transport scan link: 0 max: 5 Missing static device: PCI: 05:00.0 HyperT reset not needed PCI: pci_scan_bus for bus 5 PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:00.0 No device operations PCI: 05:01.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:01.0 No device operations PCI: pci_scan_bus returning with max=05 Hyper transport scan link: 0 new max: 5 Hypertransport scan link done amdk8_scan_chains max: 5 done amdk8_scan_chains max: 5 starting... amdk8_scan_chains max: 5 done PCI: pci_scan_bus returning with max=05 after pci_scan_bus amdk8_scan_root_bus e0 = 5050000 max = 5 amdk8_scan_root_bus e4 = 0 max = 5 amdk8_scan_root_bus e8 = 0 max = 5 amdk8_scan_root_bus ec = 0 max = 5 done Allocating resources... PCI: 05:00.0 missing read_resources PCI: 05:01.0 missing read_resources PCI: 05:00.0 missing read_resources PCI: 05:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 01:04.6 missing read_resources PCI: 01:04.6 missing read_resources ASSIGN RESOURCES, bus 0 PCI: 05:00.0 missing read_resources PCI: 05:01.0 missing read_resources PCI: 00:18.0 c8 <- [0x00003000 - 0x00002fff] node 0 link 0 io PCI: 05:00.0 missing read_resources PCI: 05:01.0 missing read_resources PCI: 00:18.0 80 <- [0xfec00000 - 0xfebfffff] node 0 link 0 mem PCI: 01:04.6 missing read_resources PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 2 io PCI: 01:04.6 missing read_resources PCI: 00:18.0 b8 <- [0xfe900000 - 0xfebfffff] node 0 link 2 mem ASSIGN RESOURCES, bus 5 PCI: 05:00.0 missing set_resources PCI: 05:01.0 missing set_resources ASSIGNED RESOURCES, bus 5 ASSIGN RESOURCES, bus 1 PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io PCI: 01:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 2 prefmem PCI: 01:01.0 20 <- [0xfe900000 - 0xfe9fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:09.0 10 <- [0xfe900000 - 0xfe90ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:01.1 10 <- [0xfeb00000 - 0xfeb00fff] mem PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xfeb00000 - 0xfeafffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xfeb00000 - 0xfeafffff] bus 3 mem PCI: 01:02.1 10 <- [0xfeb01000 - 0xfeb01fff] mem PCI: 04:01.0 missing read_resources PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io PCI: 04:01.0 missing read_resources PCI: 01:03.0 24 <- [0xfeb00000 - 0xfeafffff] bus 4 prefmem PCI: 04:01.0 missing read_resources PCI: 01:03.0 20 <- [0xfea00000 - 0xfeafffff] bus 4 mem ASSIGN RESOURCES, bus 4 PCI: 04:00.0 10 <- [0xfea04000 - 0xfea04fff] mem PCI: 04:00.1 10 <- [0xfea05000 - 0xfea05fff] mem PCI: 04:00.2 10 <- [0xfea08000 - 0xfea080ff] mem PCI: 04:00.2 14 <- [0xfea09000 - 0xfea0901f] mem PCI: 04:01.0 missing set_resources PCI: 04:0b.0 10 <- [0x00001010 - 0x00001017] io PCI: 04:0b.0 14 <- [0x00001030 - 0x00001033] io PCI: 04:0b.0 18 <- [0x00001020 - 0x00001027] io PCI: 04:0b.0 1c <- [0x00001040 - 0x00001043] io PCI: 04:0b.0 20 <- [0x00001000 - 0x0000100f] io PCI: 04:0b.0 24 <- [0xfea07000 - 0xfea073ff] mem PCI: 04:0c.0 10 <- [0xfea06000 - 0xfea067ff] mem PCI: 04:0c.0 14 <- [0xfea00000 - 0xfea03fff] mem ASSIGNED RESOURCES, bus 4 PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem PCI: 01:04.1 20 <- [0x00002460 - 0x0000246f] io PCI: 01:04.2 10 <- [0x00002440 - 0x0000245f] io PCI: 01:04.5 10 <- [0x00002000 - 0x000020ff] io PCI: 01:04.5 14 <- [0x00002400 - 0x0000243f] io PCI: 01:04.6 missing set_resources ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 done. Enabling resourcess... PCI: 00:18.0 cmd <- 00 PCI: 05:00.0 missing enable_resources PCI: 05:01.0 missing enable_resources PCI: 01:01.0 bridge ctrl <- 0000 PCI: 01:01.0 cmd <- 07 PCI: 02:09.0 cmd <- 02 PCI: 01:01.1 cmd <- 06 PCI: 01:02.0 bridge ctrl <- 0000 PCI: 01:02.0 cmd <- 07 PCI: 01:02.1 cmd <- 06 PCI: 01:03.0 bridge ctrl <- 0000 PCI: 01:03.0 cmd <- 07 PCI: 04:00.0 cmd <- 02 PCI: 04:00.1 cmd <- 02 PCI: 04:00.2 cmd <- 02 PCI: 04:01.0 missing enable_resources PCI: 04:0b.0 cmd <- 03 PCI: 04:0c.0 cmd <- 02 PCI: 01:04.0 cmd <- 0f PCI: 01:04.1 cmd <- 01 PCI: 01:04.2 cmd <- 01 PCI: 01:04.3 cmd <- 00 PCI: 01:04.5 cmd <- 01 PCI: 01:04.6 missing enable_resources PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 cmd <- 00 PCI: 00:19.0 cmd <- 00 PCI: 00:19.1 cmd <- 00 PCI: 00:19.2 cmd <- 00 PCI: 00:19.3 cmd <- 00 done. Initializing devices... PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.3 init NB: Function 3 Misc Control.. resetting cpu From YhLu at tyan.com Fri Dec 5 18:20:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Dec 5 18:20:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C943142303990B09@TYANWEB> Eric, If don't clear the regs, the result will be: Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.52.0_Fallback Fri Dec 5 15:05:21 EST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating: AMD 8111 Enumerating buses... before pci_scan_bus amdk8_scan_root_bus e0 = 4000203 max = 0 amdk8_scan_root_bus e4 = 6050003 max = 0 amdk8_scan_root_bus e8 = 0 max = 0 amdk8_scan_root_bus ec = 0 max = 0 PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 [1022/746d] enabled amd8111_enable dev: PCI: 01:04.6 lpc_dev: PCI: 01:04.0 index: 6 reg: ffff -> ffbf done PCI: 01:04.6 [ffff/ffff] disabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled amd8111_enable dev: PCI: 04:01.0 lpc_dev: PCI: 01:04.0 index: 9 reg: ffbf -> fdbf done PCI: 04:01.0 [ffff/ffff] disabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 4 Hypertransport scan link done Hyper transport scan link: 0 max: 5 PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004 HyperT reset needed PCI: pci_scan_bus for bus 5 PCI: 05:01.0 [1022/7454] ops PCI: 05:01.0 [1022/7454] enabled PCI: 05:02.0 [1022/7455] bus ops PCI: 05:02.0 [1022/7455] enabled PCI: pci_scan_bus for bus 6 PCI: 06:00.0 [10de/0322] enabled PCI: pci_scan_bus returning with max=06 PCI: pci_scan_bus returning with max=06 Hyper transport scan link: 0 new max: 6 Hypertransport scan link done amdk8_scan_chains max: 6 done amdk8_scan_chains max: 6 starting... amdk8_scan_chains max: 6 done PCI: pci_scan_bus returning with max=06 after pci_scan_bus amdk8_scan_root_bus e0 = 4010203 max = 6 amdk8_scan_root_bus e4 = 6050003 max = 6 amdk8_scan_root_bus e8 = 0 max = 6 amdk8_scan_root_bus ec = 0 max = 6 done Allocating resources... PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 04:01.0 missing read_resources PCI: 01:04.6 missing read_resources PCI: 01:04.6 missing read_resources ASSIGN RESOURCES, bus 0 PCI: 00:18.0 c8 <- [0x00003000 - 0x00002fff] node 0 link 0 io PCI: 00:18.0 80 <- [0xe0000000 - 0xf8ffffff] node 0 link 0 mem PCI: 01:04.6 missing read_resources PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 2 io PCI: 01:04.6 missing read_resources PCI: 00:18.0 b8 <- [0xf9000000 - 0xf92fffff] node 0 link 2 mem ASSIGN RESOURCES, bus 5 PCI: 05:01.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 05:02.0 1c <- [0x00003000 - 0x00002fff] bus 6 io PCI: 05:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 6 prefmem PCI: 05:02.0 20 <- [0xf8000000 - 0xf8ffffff] bus 6 mem ASSIGN RESOURCES, bus 6 PCI: 06:00.0 10 <- [0xf8000000 - 0xf8ffffff] mem PCI: 06:00.0 14 <- [0xf0000000 - 0xf7ffffff] prefmem ASSIGNED RESOURCES, bus 6 ASSIGNED RESOURCES, bus 5 ASSIGN RESOURCES, bus 1 PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io PCI: 01:01.0 24 <- [0xf9200000 - 0xf91fffff] bus 2 prefmem PCI: 01:01.0 20 <- [0xf9000000 - 0xf90fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:09.0 10 <- [0xf9000000 - 0xf900ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:01.1 10 <- [0xf9200000 - 0xf9200fff] mem PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:02.0 24 <- [0xf9200000 - 0xf91fffff] bus 3 prefmem PCI: 01:02.0 20 <- [0xf9200000 - 0xf91fffff] bus 3 mem PCI: 01:02.1 10 <- [0xf9201000 - 0xf9201fff] mem PCI: 04:01.0 missing read_resources PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io PCI: 04:01.0 missing read_resources PCI: 01:03.0 24 <- [0xf9200000 - 0xf91fffff] bus 4 prefmem PCI: 04:01.0 missing read_resources PCI: 01:03.0 20 <- [0xf9100000 - 0xf91fffff] bus 4 mem ASSIGN RESOURCES, bus 4 PCI: 04:00.0 10 <- [0xf9104000 - 0xf9104fff] mem PCI: 04:00.1 10 <- [0xf9105000 - 0xf9105fff] mem PCI: 04:00.2 10 <- [0xf9108000 - 0xf91080ff] mem PCI: 04:00.2 14 <- [0xf9109000 - 0xf910901f] mem PCI: 04:01.0 missing set_resources PCI: 04:0b.0 10 <- [0x00001010 - 0x00001017] io PCI: 04:0b.0 14 <- [0x00001030 - 0x00001033] io PCI: 04:0b.0 18 <- [0x00001020 - 0x00001027] io PCI: 04:0b.0 1c <- [0x00001040 - 0x00001043] io PCI: 04:0b.0 20 <- [0x00001000 - 0x0000100f] io PCI: 04:0b.0 24 <- [0xf9107000 - 0xf91073ff] mem PCI: 04:0c.0 10 <- [0xf9106000 - 0xf91067ff] mem PCI: 04:0c.0 14 <- [0xf9100000 - 0xf9103fff] mem ASSIGNED RESOURCES, bus 4 PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem PCI: 01:04.1 20 <- [0x00002460 - 0x0000246f] io PCI: 01:04.2 10 <- [0x00002440 - 0x0000245f] io PCI: 01:04.5 10 <- [0x00002000 - 0x000020ff] io PCI: 01:04.5 14 <- [0x00002400 - 0x0000243f] io PCI: 01:04.6 missing set_resources ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. Enabling resourcess... PCI: 00:18.0 cmd <- 00 PCI: 05:01.0 cmd <- 06 PCI: 05:02.0 bridge ctrl <- 003e PCI: 05:02.0 cmd <- 07 PCI: 06:00.0 cmd <- 03 PCI: 01:01.0 bridge ctrl <- 0000 PCI: 01:01.0 cmd <- 07 PCI: 02:09.0 cmd <- 02 PCI: 01:01.1 cmd <- 06 PCI: 01:02.0 bridge ctrl <- 0000 PCI: 01:02.0 cmd <- 07 PCI: 01:02.1 cmd <- 06 PCI: 01:03.0 bridge ctrl <- 0000 PCI: 01:03.0 cmd <- 07 PCI: 04:00.0 cmd <- 02 PCI: 04:00.1 cmd <- 02 PCI: 04:00.2 cmd <- 02 PCI: 04:01.0 missing enable_resources PCI: 04:0b.0 cmd <- 03 PCI: 04:0c.0 cmd <- 02 PCI: 01:04.0 cmd <- 0f PCI: 01:04.1 cmd <- 01 PCI: 01:04.2 cmd <- 01 PCI: 01:04.3 cmd <- 00 PCI: 01:04.5 cmd <- 01 PCI: 01:04.6 missing enable_resources PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 cmd <- 00 PCI: 00:19.0 cmd <- 00 PCI: 00:19.1 cmd <- 00 PCI: 00:19.2 cmd <- 00 PCI: 00:19.3 cmd <- 00 done. Initializing devices... PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.3 init NB: Function 3 Misc Control.. resetting cpu From ebiederman at lnxi.com Fri Dec 5 18:21:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 5 18:21:01 2003 Subject: Tyan S2885 In-Reply-To: <3174569B9743D511922F00A0C943142303990AFE@TYANWEB> References: <3174569B9743D511922F00A0C943142303990AFE@TYANWEB> Message-ID: YhLu writes: > Eric, > > I change amdk8_scan_root_bus to: > > unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) > { > unsigned reg; > uint32_t value; > /* Unmap all of the other pci busses */ > printk_debug("\nbefore pci_scan_bus\n"); > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > if((value>>24)>max) > f1_write_config32(reg, 0); > } > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > } > > max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); > > printk_debug("after pci_scan_bus\n"); > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > } > > return max; > } > > I think as least you only need to clear the regs that contain bigger bus > number than the next bus for scanning. > > The result will be in the end. > > The problems: > 1. It can not access 8151 on CPU link0 and so can not scan it > 2. The HT scan seems can not figure out and set the link and read/write > enable bit in e0. It set the e0 to 0x05050000 Doh. The Opteron is too forgiving when you only have one link. It makes this kind of debugging a pain. What I am doing should not work but it does in that case... My apologies, for missing this. In amdk8_scan_chains() there is the snippet: config_busses &= 0x0000ffff; config_busses |= ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); Which is the offending piece of code. It neither sets the link that we are supposed to go out, nor does it set the r/w enable bits. Ouch. It only works if those registers are pre programmed. So I think this should be: config_busses &= 0x000fc88; config_busses |= (3 << 0) | /* rw enable, no device compare */ (( nodeid & 7) << 4) | (( link & 3 ) << 8) | ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); Eric From YhLu at tyan.com Fri Dec 5 18:58:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Dec 5 18:58:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB> Eric, Great, it works. Even normal scan it can find out 8151. But the bus number is funny, I may need to update bus number mptable.c and irq_table.c and reset.c I wonder if 8151 on CPU 1 and 8131/8111 on CPU0. is the amdk8_scan_root_bus called two times? If so, you may keep the > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > if((value>>24)>max) > f1_write_config32(reg, 0); > } Regards YH. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?12?5? 15:26 ???: YhLu ??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org ??: Re: Tyan S2885 YhLu writes: > Eric, > > I change amdk8_scan_root_bus to: > > unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) > { > unsigned reg; > uint32_t value; > /* Unmap all of the other pci busses */ > printk_debug("\nbefore pci_scan_bus\n"); > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > if((value>>24)>max) > f1_write_config32(reg, 0); > } > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > } > > max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); > > printk_debug("after pci_scan_bus\n"); > for(reg = 0xe0; reg <= 0xec; reg += 4) { > value = f1_read_config32(reg); > printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n", > reg,value,max); > } > > return max; > } > > I think as least you only need to clear the regs that contain bigger bus > number than the next bus for scanning. > > The result will be in the end. > > The problems: > 1. It can not access 8151 on CPU link0 and so can not scan it > 2. The HT scan seems can not figure out and set the link and read/write > enable bit in e0. It set the e0 to 0x05050000 Doh. The Opteron is too forgiving when you only have one link. It makes this kind of debugging a pain. What I am doing should not work but it does in that case... My apologies, for missing this. In amdk8_scan_chains() there is the snippet: config_busses &= 0x0000ffff; config_busses |= ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); Which is the offending piece of code. It neither sets the link that we are supposed to go out, nor does it set the r/w enable bits. Ouch. It only works if those registers are pre programmed. So I think this should be: config_busses &= 0x000fc88; config_busses |= (3 << 0) | /* rw enable, no device compare */ (( nodeid & 7) << 4) | (( link & 3 ) << 8) | ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); Eric -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: S2885_1.1.5_reverse_scan_reg_clear_e0_before_scan.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: S2885_1.1.5_normal_scan_clear_e0_before_scan.txt URL: From ebiederman at lnxi.com Fri Dec 5 19:16:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 5 19:16:01 2003 Subject: Tyan S2885 In-Reply-To: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB> References: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB> Message-ID: YhLu writes: > Eric, > > Great, it works. Even normal scan it can find out 8151. > > But the bus number is funny, I may need to update bus number mptable.c and > irq_table.c and reset.c > > I wonder if 8151 on CPU 1 and 8131/8111 on CPU0. is the amdk8_scan_root_bus > called two times? If so, you may keep the amdk8_scan_root_bus is always only called once. It just finds the cpus. It recurses into amdk8_scan_chains which actually finds all of the busses. So it is ok to zap everything in amdk8_scan_root_bus. But it may be a little more elegant to zap just what we need in amdk8_scan_root_bus. Eric From YhLu at tyan.com Fri Dec 5 19:51:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Dec 5 19:51:01 2003 Subject: Tyan S2885 Message-ID: <3174569B9743D511922F00A0C943142303990B2F@TYANWEB> S2885 updated to 1.1.5 Only reset once. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: S2885_1.1.5_normal_scan_clear_e0_before_scan_hard_reset_OK.txt URL: From Phreak_Show at gmx.de Sat Dec 6 10:57:01 2003 From: Phreak_Show at gmx.de (Stefan) Date: Sat Dec 6 10:57:01 2003 Subject: Will this work ?? Message-ID: <3FD1FC88.3050404@gmx.de> Hi there, I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size of 512 KB. Will I be able to get a open source "bios" work on that mainboard ? thx for your helping!! From Antony at Soft-Solutions.co.uk Sat Dec 6 11:20:00 2003 From: Antony at Soft-Solutions.co.uk (Antony Stone) Date: Sat Dec 6 11:20:00 2003 Subject: Will this work ?? In-Reply-To: <3FD1FC88.3050404@gmx.de> References: <3FD1FC88.3050404@gmx.de> Message-ID: <200312061620.20115.Antony@Soft-Solutions.co.uk> On Saturday 06 December 2003 3:58 pm, Stefan wrote: > Hi there, > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size > of 512 KB. > Will I be able to get a open source "bios" work on that mainboard ? Boot Linux on that board by whatever means you can and post the results of "lspci" and "lspci -v" so we can see what chipsets etc are really there. Antony. -- This is not a rehearsal. This is Real Life. Please reply to the list; please don't CC me. From rminnich at lanl.gov Sat Dec 6 11:46:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Dec 6 11:46:01 2003 Subject: Will this work ?? In-Reply-To: <3FD1FC88.3050404@gmx.de> Message-ID: On Sat, 6 Dec 2003, Stefan wrote: > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size > of 512 KB. nvidia chipset, right? no chance. nvidia has no wish to help. ron From a.nielsen at optushome.com.au Sat Dec 6 23:15:01 2003 From: a.nielsen at optushome.com.au (Adam Nielsen) Date: Sat Dec 6 23:15:01 2003 Subject: Will this work ?? In-Reply-To: References: Message-ID: <200312071409.54893@korath> > > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size > > of 512 KB. > nvidia chipset, right? no chance. nvidia has no wish to help. That's a shame - I was thinking of getting a Gigabyte/nVidia board because Gigabyte now appear to have true dual BIOS chips on their boards. If it fails to boot from one chip it automatically switches to the other, you can reflash one chip from the other or from a floppy in the default BIOS setup, etc. it looks like it'd be a very handy board to use for testing - put LinuxBIOS in the main chip and have the default BIOS as backup. Then you can boot off the backup in case of a failed flash attempt and reflash LinuxBIOS into the main chip. Looks like Gigabyte are introducing it on all their boards though, which is a good sign. Cheers, Adam. From sc at flagen.com Sun Dec 7 06:59:00 2003 From: sc at flagen.com (David Hendricks) Date: Sun Dec 7 06:59:00 2003 Subject: Will this work ?? In-Reply-To: <200312071409.54893@korath> References: <200312071409.54893@korath> Message-ID: <20031207050022.5a6281ca.sc@flagen.com> LinuxBIOS can boot off a fallback image on the ROM in case the primary image fails. On Sun, 7 Dec 2003 14:09:54 +1000 Adam Nielsen wrote: > > > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a > > > size of 512 KB. > > > nvidia chipset, right? no chance. nvidia has no wish to help. > > That's a shame - I was thinking of getting a Gigabyte/nVidia board > because Gigabyte now appear to have true dual BIOS chips on their > boards. If it fails to boot from one chip it automatically switches > to the other, you can reflash one chip from the other or from a floppy > in the default BIOS setup, etc. it looks like it'd be a very handy > board to use for testing - put LinuxBIOS in the main chip and have the > default BIOS as backup. Then you can boot off the backup in case of a > failed flash attempt and reflash LinuxBIOS into the main chip. > > Looks like Gigabyte are introducing it on all their boards though, > which is a good sign. > > Cheers, > Adam. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From ijpriya at hotmail.com Mon Dec 8 04:42:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Mon Dec 8 04:42:00 2003 Subject: Hardware Help with diskonchip? Message-ID: Hi, In the application note (AP044) from Msystems it is given as: "The DiskOnChip Millennium is mapped into an 8KB memory window in the host platform?s memory map. This 8KB window consists of four 2KB windows." Why is this mapping done? Is this mapping done in hardware? I use diskonchip millennium (8MByte MD2800). Then shouldn't the entire 8MB shall be mapped in hardware to the physical address space? The steps for BIOS is summarised as 1. After DiskOnChip Millennium BUSY# signal is negated, the CPU fetches the Reset Vector from the Boot-Block area, fetches the Boot Code stored there, and starts to execute the code. 2. Boot Code runs the first part of BIOS, initializing the basic hardware functionality. 3. Boot Codes loads the rest of the BIOS from the flash memory to the DRAM, and transfer control (jumps) there. 4. Chip Select of DiskOnChip Millennium is remapped from Reset Vector to BIOS expansion area. 5. CPU executes the rest of the BIOS code, including ROM expansion devices (among them, the DiskOnChip Millennium itself). 6. CPU calls OS bootstrap loader (INT19). 7. OS is loaded, and recognizes the DiskOnChip Millennium as the boot device. 8. OS loads the application code from the DiskOnChip Millennium and executes it. 9. Application software uses DiskOnChip Millennium exactly as if it were using a regular hard disk. In step 4 why is this remapping done? Is this mapping done in hardware? In my setup, the diskonchip is mapped in hardware to the higher order address (0xFFFFFFFF-0xFF800000). SDRAM mapped to lower address (0x00000000-0x1FFFFFF). What else modification do i require in HARDWARE to use diskonchip millennium? _________________________________________________________________ Add zing to Hotmail. Get FREE newsletters. http://server1.msn.co.in/features/general/Newsletters/index.asp Subscribe now! From nemesis-lists at icequake.net Mon Dec 8 07:48:01 2003 From: nemesis-lists at icequake.net (Ryan Underwood) Date: Mon Dec 8 07:48:01 2003 Subject: legacy BIOS usage Message-ID: <20031208124939.GC17909@dbz.icequake.net> Hi, I had the idea of using LinuxBIOS but also maintaining a legacy BIOS for debugging and dual boot scenarios. It would be linked into the LinuxBIOS image and jumped to alternatively depending on the user input. However, thinking about this gave me 2 questions: 1. Are there any forms of user input possible into LinuxBIOS loader? Is the system initialized enough to accept a keyboard input, or ACPI system button, or even something sillier like checking if a PS/2 mouse is plugged in (the user can unplug the mouse to signal LinuxBIOS to jump to the legacy BIOS instead). 2. Is it possible to get the machine into a state where it can check whatever form of user input is possible, but still be able to then put the machine back into a state where the legacy BIOS won't be confused. Or could something like this be done via the reboot vector instead? Power on clean gets you LinuxBIOS, but reboot goes to legacy BIOS... I guess the problem there again would be putting the hardware back into a state that the legacy BIOS can use. any ideas on that topic? It would be nice to use FreeDOS occasionally for testing some external hardware control programs, but FreeDOS requires a PC BIOS, of which there are no open source implementations that I know of. :( Maybe that can be a project for the future, but somehow I see a lack of interest in putting any new effort into a dead platform, so using the legacy proprietary BIOS might be the only real world choice. p.s. there is a broken Microsoft link in the FAQ, it is here now: http://www.microsoft.com/whdc/hwdev/archive/BUSBIOS/pciirq.mspx -- Ryan Underwood, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From adam at cfar.umd.edu Mon Dec 8 09:05:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Mon Dec 8 09:05:00 2003 Subject: legacy BIOS usage In-Reply-To: <20031208124939.GC17909@dbz.icequake.net> Message-ID: <20031208090518.Q392-100000@www.missl.cs.umd.edu> On Mon, 8 Dec 2003, Ryan Underwood wrote: > any ideas on that topic? It would be nice to use FreeDOS occasionally > for testing some external hardware control programs, but FreeDOS > requires a PC BIOS, of which there are no open source implementations > that I know of. :( Maybe that can be a project for the future, but > somehow I see a lack of interest in putting any new effort into a dead > platform, so using the legacy proprietary BIOS might be the only real > world choice. oh sure there is. see "SEBOS" project in linuxbios v1 cvs tree. It boots windows, and windows 98 wasn't that far off. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From nemesis-lists at icequake.net Mon Dec 8 09:35:00 2003 From: nemesis-lists at icequake.net (Ryan Underwood) Date: Mon Dec 8 09:35:00 2003 Subject: legacy BIOS usage In-Reply-To: <20031208090518.Q392-100000@www.missl.cs.umd.edu> References: <20031208124939.GC17909@dbz.icequake.net> <20031208090518.Q392-100000@www.missl.cs.umd.edu> Message-ID: <20031208143618.GA27814@dbz.icequake.net> hi, On Mon, Dec 08, 2003 at 09:06:33AM -0500, Adam Sulmicki wrote: > On Mon, 8 Dec 2003, Ryan Underwood wrote: > > > any ideas on that topic? It would be nice to use FreeDOS occasionally > > for testing some external hardware control programs, but FreeDOS > > requires a PC BIOS, of which there are no open source implementations > > that I know of. :( Maybe that can be a project for the future, but > > somehow I see a lack of interest in putting any new effort into a dead > > platform, so using the legacy proprietary BIOS might be the only real > > world choice. > > oh sure there is. see "SEBOS" project in linuxbios v1 cvs tree. It boots > windows, and windows 98 wasn't that far off. Very nice! That slipped in under my radar. I guess I'll be heading in that direction then instead of bothering with the old proprietary junk. thanks -- Ryan Underwood, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From rminnich at lanl.gov Mon Dec 8 12:29:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 8 12:29:00 2003 Subject: for all k8 builders Message-ID: your builds are broken today due to the missing amdk8.h file in src/northbridge/amd/amdk8. Do an update; I just added it. ron From ebiederman at lnxi.com Mon Dec 8 14:56:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 8 14:56:01 2003 Subject: for all k8 builders In-Reply-To: References: Message-ID: ron minnich writes: > your builds are broken today due to the missing amdk8.h file in > src/northbridge/amd/amdk8. > > Do an update; I just added it. Grumble. You are pushing out my changes before we have finished testing them. I don't mind to much but I do know some of that code was not fully generalized, so there could be problems if you have not looked through it carefully. Eric From rminnich at lanl.gov Mon Dec 8 15:11:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 8 15:11:01 2003 Subject: for all k8 builders In-Reply-To: Message-ID: On 8 Dec 2003, Eric W. Biederman wrote: > Grumble. You are pushing out my changes before we have finished > testing them. I don't mind to much but I do know some of that code > was not fully generalized, so there could be problems if you have > not looked through it carefully. The problem was that builds that worked friday stopped working this morning, due apparently to this: Revision 1.9 - (download), view (text) (markup) (annotate) - [select for diffs] Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm CVS Tags: HEAD Changes since 1.8: +21 -8 lines Diff to previous 1.8 - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains can be scanned in any order === it was your push, not mine. It broke all the K8 builds. I would normally not have pushed your stuff out but this was kind of an emergency. Trust me, I'm not going to push your changes out before we test 'em, but I can't stop you from doing it :-) thanks ron From ebiederman at lnxi.com Mon Dec 8 15:30:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 8 15:30:01 2003 Subject: for all k8 builders In-Reply-To: References: Message-ID: ron minnich writes: > On 8 Dec 2003, Eric W. Biederman wrote: > > > Grumble. You are pushing out my changes before we have finished > > testing them. I don't mind to much but I do know some of that code > > was not fully generalized, so there could be problems if you have > > not looked through it carefully. > > The problem was that builds that worked friday stopped working this > morning, due apparently to this: > > Revision 1.9 - (download), view (text) (markup) (annotate) - [select for > diffs] > Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm > CVS Tags: HEAD > Changes since 1.8: +21 -8 lines > Diff to previous 1.8 > > - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains > can be scanned in any order > > === > > it was your push, not mine. It broke all the K8 builds. I would normally > not have pushed your stuff out but this was kind of an emergency. > > Trust me, I'm not going to push your changes out before we test 'em, but I > can't stop you from doing it :-) Ok. My apologies I jumped the gun on that one. I guess one of my clean ups slipped out unintentionally. I checked in the changes I had talked about with Yhlu to get the bus scanning right and it appears some of my cleanups slipped out unintentionally. I'm going to many directions at once it appears. Eric From YhLu at tyan.com Mon Dec 8 15:35:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Dec 8 15:35:01 2003 Subject: for all k8 builders Message-ID: <3174569B9743D511922F00A0C943142303990BA6@TYANWEB> If only - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains can be scanned in any order it will not break the code. There must some other file changes cause that. YH. -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?12?8? 12:12 ???: Eric W. Biederman ??: linuxbios at clustermatic.org ??: Re: for all k8 builders On 8 Dec 2003, Eric W. Biederman wrote: > Grumble. You are pushing out my changes before we have finished > testing them. I don't mind to much but I do know some of that code > was not fully generalized, so there could be problems if you have > not looked through it carefully. The problem was that builds that worked friday stopped working this morning, due apparently to this: Revision 1.9 - (download), view (text) (markup) (annotate) - [select for diffs] Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm CVS Tags: HEAD Changes since 1.8: +21 -8 lines Diff to previous 1.8 - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains can be scanned in any order === it was your push, not mine. It broke all the K8 builds. I would normally not have pushed your stuff out but this was kind of an emergency. Trust me, I'm not going to push your changes out before we test 'em, but I can't stop you from doing it :-) thanks ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon Dec 8 15:38:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 8 15:38:01 2003 Subject: for all k8 builders In-Reply-To: <3174569B9743D511922F00A0C943142303990BA6@TYANWEB> Message-ID: On Mon, 8 Dec 2003, YhLu wrote: > If only > - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains > can be scanned in any order > it will not break the code. > > There must some other file changes cause that. I'm sorry, I don't understand. ron From YhLu at tyan.com Mon Dec 8 15:44:00 2003 From: YhLu at tyan.com (YhLu) Date: Mon Dec 8 15:44:00 2003 Subject: for all k8 builders Message-ID: <3174569B9743D511922F00A0C943142303990BAA@TYANWEB> I will check the code. From ebiederman at lnxi.com Mon Dec 8 15:48:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 8 15:48:01 2003 Subject: for all k8 builders In-Reply-To: References: Message-ID: ron minnich writes: > On Mon, 8 Dec 2003, YhLu wrote: > > > If only > > - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains > > can be scanned in any order > > it will not break the code. > > > > There must some other file changes cause that. > > I'm sorry, I don't understand. > > ron So to be clear the complete change was below. The include of amdk8.h, the extra memory hole bit, and the deletion of the link defines, and the deletion of other_reg slipped out by accident. But I don't see those extra changes causing problems... Eric Index: northbridge.c =================================================================== RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/northbridge.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- northbridge.c 14 Oct 2003 02:36:51 -0000 1.8 +++ northbridge.c 6 Dec 2003 00:11:56 -0000 1.9 @@ -12,6 +12,7 @@ #include #include "chip.h" #include "northbridge.h" +#include "amdk8.h" struct mem_range *sizeram(void) { @@ -60,6 +61,16 @@ mem[idx].sizek = sizek; idx++; } + + /* see if we need a hole from 0xa0000 to 0xbffff */ + if((mem[idx-1].basek < ((8*64)+(8*16))) && + (mem[idx-1].sizek > ((8*64)+(16*16)))) { + mem[idx].basek = (8*64)+(16*16); + mem[idx].sizek = mem[idx-1].sizek - ((8*64)+(16*16)); + mem[idx-1].sizek = ((8*64)+(8*16)) - mem[idx-1].basek; + idx++; + } + /* See if I need to split the region to accomodate pci memory space */ if ((mem[idx - 1].basek <= mmio_basek) && ((mem[idx - 1].basek + mem[idx - 1].sizek) > mmio_basek)) { @@ -151,10 +162,6 @@ } -#define LinkConnected (1 << 0) -#define InitComplete (1 << 1) -#define NonCoherent (1 << 2) -#define ConnectionPending (1 << 4) static unsigned int amdk8_scan_chains(device_t dev, unsigned int max) { unsigned nodeid; @@ -166,7 +173,7 @@ for(link = 0; link < dev->links; link++) { uint32_t link_type; uint32_t busses, config_busses; - unsigned free_reg, config_reg, other_reg; + unsigned free_reg, config_reg; dev->link[link].cap = 0x80 + (link *0x20); do { link_type = pci_read_config32(dev, dev->link[link].cap + 0x18); @@ -249,7 +256,13 @@ ((unsigned int) (dev->link[link].subordinate) << 16); pci_write_config32(dev, dev->link[link].cap + 0x14, busses); - config_busses = (config_busses & 0x00ffffff) | (dev->link[link].subordinate << 24); + config_busses &= 0x000fc88; + config_busses |= + (3 << 0) | /* rw enable, no device compare */ + (( nodeid & 7) << 4) | + (( link & 3 ) << 8) | + ((dev->link[link].secondary) << 16) | + ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); #if 1 printk_debug("Hypertransport scan link done\n"); @@ -456,11 +469,11 @@ unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; - max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); - /* Unmap all of the other pci busses */ + /* Unmap all of HT chains */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } + max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max); return max; } From rminnich at lanl.gov Mon Dec 8 15:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Dec 8 15:50:01 2003 Subject: for all k8 builders In-Reply-To: Message-ID: On 8 Dec 2003, Eric W. Biederman wrote: > The include of amdk8.h, the extra memory hole bit, and the deletion of > the link defines, and the deletion of other_reg slipped out by > accident. But I don't see those extra changes causing problems... agree. ron From YhLu at tyan.com Mon Dec 8 16:05:00 2003 From: YhLu at tyan.com (YhLu) Date: Mon Dec 8 16:05:00 2003 Subject: for all k8 builders Message-ID: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB> Eric, Please check the northbridge.c attached. It seems you should modify the e0 before you do the hypertransport_scan_chain. Otherwise you can not access the buses. YH. config_busses &= 0x000fc88; config_busses |= (3 << 0) | /* rw enable, no device compare */ (( nodeid & 7) << 4) | (( link & 3 ) << 8) | ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); #if 1 printk_debug("Hyper transport scan link: %d max: %d\n", link, max); #endif /* Now we can scan all of the subordinate busses i.e. the chain on the hypertranport link */ max = hypertransport_scan_chain(&dev->link[link], max); -------------- next part -------------- A non-text attachment was scrubbed... Name: northbridge.c Type: application/octet-stream Size: 13690 bytes Desc: not available URL: From ebiederman at lnxi.com Mon Dec 8 16:34:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 8 16:34:00 2003 Subject: for all k8 builders In-Reply-To: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB> References: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB> Message-ID: YhLu writes: > Eric, > > Please check the northbridge.c attached. > > It seems you should modify the e0 before you do the > hypertransport_scan_chain. Otherwise you can not access the buses. Unless I am mistaken that is what f1_write_config32 is doing... config_reg is one of 0xe0, 0xe4, 0xe8, or 0xec I think the only differences I am seeing are in, amdk8_scan_root_bus and I just unconditionally zero 0xe0 - 0xec where you handle it conditionally Eric > > YH. > > config_busses &= 0x000fc88; > config_busses |= > (3 << 0) | /* rw enable, no device compare */ > (( nodeid & 7) << 4) | > (( link & 3 ) << 8) | > ((dev->link[link].secondary) << 16) | > ((dev->link[link].subordinate) << 24); > f1_write_config32(config_reg, config_busses); > > #if 1 > printk_debug("Hyper transport scan link: %d max: %d\n", > link, max); > #endif > /* Now we can scan all of the subordinate busses i.e. the > chain on the hypertranport link */ > max = hypertransport_scan_chain(&dev->link[link], max); From YhLu at tyan.com Mon Dec 8 16:39:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Dec 8 16:39:01 2003 Subject: =?GB2312?B?tPC4tDogZm9yIGFsbCBrOCBidWlsZGVycw==?= Message-ID: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB> Eric, I mean in the amdk8_scan_chains, you need to put > config_busses &= 0x000fc88; > config_busses |= > (3 << 0) | /* rw enable, no device compare */ > (( nodeid & 7) << 4) | > (( link & 3 ) << 8) | > ((dev->link[link].secondary) << 16) | > ((dev->link[link].subordinate) << 24); > f1_write_config32(config_reg, config_busses); before /* Now we can scan all of the subordinate busses i.e. the > chain on the hypertranport link */ > max = hypertransport_scan_chain(&dev->link[link], max); YH. From ebiederman at lnxi.com Mon Dec 8 16:51:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 8 16:51:01 2003 Subject: =?gb2312?b?tPC4tA==?=: for all k8 builders In-Reply-To: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB> References: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB> Message-ID: YhLu writes: > Eric, > > I mean in the amdk8_scan_chains, you need to put > > > > config_busses &= 0x000fc88; > > config_busses |= > > (3 << 0) | /* rw enable, no device compare */ > > (( nodeid & 7) << 4) | > > (( link & 3 ) << 8) | > > ((dev->link[link].secondary) << 16) | > > ((dev->link[link].subordinate) << 24); > > f1_write_config32(config_reg, config_busses); > > before > > /* Now we can scan all of the subordinate busses i.e. the > > chain on the hypertranport link */ > > max = hypertransport_scan_chain(&dev->link[link], max); > Right. Sorry. That is what I thought I had done (and actually did in my internal tree). Somehow I modified the wrong line... I have fixed that and committed it. This is the diff. Let's see what idiot mistake I will make this time... Index: northbridge.c =================================================================== RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/northbridge.c,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- northbridge.c 6 Dec 2003 00:11:56 -0000 1.9 +++ northbridge.c 8 Dec 2003 21:48:01 -0000 1.10 @@ -5,6 +5,7 @@ #include #include #include +#include #include #include #include @@ -233,8 +234,12 @@ ((unsigned int)(dev->link[link].subordinate) << 16)); pci_write_config32(dev, dev->link[link].cap + 0x14, busses); - config_busses &= 0x0000ffff; - config_busses |= ((dev->link[link].secondary) << 16) | + config_busses &= 0x000fc88; + config_busses |= + (3 << 0) | /* rw enable, no device compare */ + (( nodeid & 7) << 4) | + (( link & 3 ) << 8) | + ((dev->link[link].secondary) << 16) | ((dev->link[link].subordinate) << 24); f1_write_config32(config_reg, config_busses); @@ -256,13 +261,7 @@ ((unsigned int) (dev->link[link].subordinate) << 16); pci_write_config32(dev, dev->link[link].cap + 0x14, busses); - config_busses &= 0x000fc88; - config_busses |= - (3 << 0) | /* rw enable, no device compare */ - (( nodeid & 7) << 4) | - (( link & 3 ) << 8) | - ((dev->link[link].secondary) << 16) | - ((dev->link[link].subordinate) << 24); + config_busses = (config_busses & 0x00ffffff) | (dev->link[link].subordinate << 24); f1_write_config32(config_reg, config_busses); #if 1 printk_debug("Hypertransport scan link done\n"); @@ -469,7 +468,7 @@ unsigned int amdk8_scan_root_bus(device_t root, unsigned int max) { unsigned reg; - /* Unmap all of HT chains */ + /* Unmap all of the HT chains */ for(reg = 0xe0; reg <= 0xec; reg += 4) { f1_write_config32(reg, 0); } From prl at peterlister.co.uk Mon Dec 8 18:29:01 2003 From: prl at peterlister.co.uk (Peter Lister) Date: Mon Dec 8 18:29:01 2003 Subject: legacy BIOS usage In-Reply-To: <20031208143618.GA27814@dbz.icequake.net> References: <20031208124939.GC17909@dbz.icequake.net> <20031208090518.Q392-100000@www.missl.cs.umd.edu> <20031208143618.GA27814@dbz.icequake.net> Message-ID: <1070926244.4868.4585.camel@eddie> On Mon, 2003-12-08 at 14:36, Ryan Underwood wrote: > Very nice! That slipped in under my radar. I guess I'll be heading in > that direction then instead of bothering with the old proprietary junk. You should also note Peter Anvin's MEMDISK which emulates a virtual HDD from a memory image. The code lives with syslinux, but not tied to any specific bootloader. http://syslinux.zytor.com/memdisk.php It's possible that there may soon also be PXE for Etherboot as well; there is a reasonable amount of code in existance and I'm trying to resurrect it and get enough working that a couple of NBPs will run. I personally think that a completely open legacy BIOS implementation based on these + ADLO + bochs BIOS with hardware handled by LinuxBIOS will have a very significant impact on a certain family of proprietary operating systems. From JJia at Fortinet.com Tue Dec 9 13:06:01 2003 From: JJia at Fortinet.com (Jia Jianwei) Date: Tue Dec 9 13:06:01 2003 Subject: Promise PDC20275 IDE controller Message-ID: <003a01c3be7e$5fcccd40$3a4610ac@JiaJianwei> I'm working on a BIOS with Promise PDC20275 IDE controller, But the Ultra DMA mode can't work anyway. I can't get the datasheet of the controller.Anybody knows how to initialize the controller? or give me some advices, Thanks very much! Regards, Jia Jianwei -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxbios at xdr.com Tue Dec 9 13:09:00 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Tue Dec 9 13:09:00 2003 Subject: EPIA-M + second serial port enabler Message-ID: <200312091808.hB9I8phP028465@xdr.com> In a previous email message http://www.clustermatic.org/pipermail/linuxbios/2003-November/005891.html I wrote In V1 the file to modify is src/superio/via/vt1211/setup_serial.inc That code sets up ttyS0 which is the VT1211's logical device 2. You want to add some similiar code for logical device 3 to get ttyS1 working. Assuming you want it to be at 2f8 you'd merge in these lines: OUTPNPADDR($7) OUTPNPDATA($3) /* set the enable in reg. 0x30 */ OUTPNPADDR($0x30) OUTPNPDATA($0x1) /* Serial Port 2 Base Address (BEh) */ OUTPNPADDR($0x60) OUTPNPDATA($0xbe) /* Serial Port 2 IRQ (03h) */ OUTPNPADDR($0x70) OUTPNPDATA($0x3) /* Serial Port 2 Control */ OUTPNPADDR($0xf0) OUTPNPDATA($0x2) ...then do the turn off pnp /* turn off PnP */ OUTPNPADDR($0xaa) ...then duplicate the serial setup except the address goes from 3f8 -> 2f8 There is a piece missing. I had to enable the second serial port on the VT1211 and although linux recognized it, there was no serial activity on the lines. These lines need to be added during the vt1211 configuration: /* Allow serial port 2 (ldn 3) pins to come out */ OUTPNPADDR($0x27) OUTPNPDATA($00) This has to be before the $0xaa write to turn off configuration mode. The default value on powerup for this register on the vt1211 is 0xff. There are multi purpose pins on the chip and this connects them to the second serial port. -Dave From ijpriya at hotmail.com Wed Dec 10 00:21:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 10 00:21:01 2003 Subject: DOCM mapping address? Message-ID: Hi, I like to have my linuxbios, linux OS, filesystem in the same diskonchip millennium. If I have to use diskonchip millennium with linuxbios, to which physical address should the DOCM should be mapped in hardware ? Is any driver should be loaded before the OS gets loaded? I have mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any remapping is to be done in hardware afer this? Which file system should I use? Regards, Priya. _________________________________________________________________ Discover India. Celebrate her diversity. http://server1.msn.co.in/features/tourism/ Come, fall in love! From ravivsn at roc.co.in Wed Dec 10 08:10:01 2003 From: ravivsn at roc.co.in (Ravi) Date: Wed Dec 10 08:10:01 2003 Subject: Is net4501 of soekris engineering supported? Message-ID: <3FD7205F.1070901@roc.co.in> Hi, This is my first posting to this list. Before posting this mail I searched for any support of net 4501 soekris box. Is net 4501 soekris box is supported by linuxbios? Thanks in advance, Best Regards, Ravi From rminnich at lanl.gov Wed Dec 10 10:33:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 10 10:33:00 2003 Subject: Is net4501 of soekris engineering supported? In-Reply-To: <3FD7205F.1070901@roc.co.in> Message-ID: On Wed, 10 Dec 2003, Ravi wrote: > Is net 4501 soekris box is supported by linuxbios? without an lspci we can't tell you. ron From YhLu at tyan.com Wed Dec 10 15:53:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Dec 10 15:53:01 2003 Subject: IDE on s2885 and LinuxBIOS -- FILO Message-ID: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> Ron, I have checked pci.c in fifo. It need to be changes as follow. It seems otherwise it can not scan the peer root bus. Maybe someone need to make it can handle peer root bus refer to the code in Linux kernel or Etherboot. Regards YH. void pci_init(void) { /* Count devices */ dev_list = 0; debug("Scanning PCI: "); pci_scan_bus(0); pci_scan_bus(1); // For Tyan s2880,s2881,s2882,s2885,s4880 // pci_scan_bus(3); //For Tyan s2885 debug("found %d devices\n", n_devs); /* Make the list */ dev_list = malloc(n_devs * sizeof(struct pci_dev)); n_devs = 0; pci_scan_bus(0); pci_scan_bus(1); // For Tyan s2880,s2881,s2882,s2885,s4880 // pci_scan_bus(3); //For Tyan s2885 #if DEBUG { int i; for (i = 0; i < n_devs; i++) { debug("%02x:%02x.%x %04x:%04x %04x %02x\n", PCI_BUS(dev_list[i].addr), PCI_DEV(dev_list[i].addr), PCI_FN(dev_list[i].addr), dev_list[i].vendor, dev_list[i].device, dev_list[i].devclass, dev_list[i].prog_if); } } #endif } -----????----- ???: YhLu ????: 2003?12?10? 9:27 ???: 'ron minnich' ??: Hendricks David W. ??: Re: IDE on s2885 and LinuxBIOS Is it working with On current tree or using old source tree to make sure all 8111/8131 on bus 0? Yinghai Lu -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?12?10? 7:25 ???: YhLu ??: Hendricks David W. ??: Re: IDE on s2885 and LinuxBIOS I wonder what differes from HDAMA to s2885? filo works fine on HDAMA ron -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: S4880_REG_with_MB_HT_FIFO.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: S4880_REG_with_MB_HT_FIFO_patch.txt URL: From stepan at suse.de Wed Dec 10 16:34:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Dec 10 16:34:00 2003 Subject: IDE on s2885 and LinuxBIOS -- FILO In-Reply-To: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> Message-ID: <20031210213555.GB9144@suse.de> * YhLu [031210 22:02]: > I have checked pci.c in fifo. It need to be changes as follow. > > It seems otherwise it can not scan the peer root bus. How is this done on the HDAMA and other boards? > Maybe someone need to make it can handle peer root bus refer to the code in > Linux kernel or Etherboot. Can we have an array of peer busses in the config file? ie. register SCAN_BUSSES={ 0, 1, 3 } Or is there any real way to _detect_ peer busses? Or at least conclude their existance by the available southbridges - There is obviously no peer bus without a (transparent) bridge Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From YhLu at tyan.com Wed Dec 10 16:37:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Dec 10 16:37:01 2003 Subject: IDE on s2885 and LinuxBIOS -- FILO Message-ID: <3174569B9743D511922F00A0C943142303990D30@TYANWEB> > How is this done on the HDAMA and other boards? The 8111/8131 in bus 0 or bus1 if it works with filo? From ebiederman at lnxi.com Wed Dec 10 16:43:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Dec 10 16:43:01 2003 Subject: IDE on s2885 and LinuxBIOS -- FILO In-Reply-To: <20031210213555.GB9144@suse.de> References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> Message-ID: Stefan Reinauer writes: > * YhLu [031210 22:02]: > > I have checked pci.c in fifo. It need to be changes as follow. > > > > It seems otherwise it can not scan the peer root bus. > > How is this done on the HDAMA and other boards? Currently I have not been testing the Filo on the HDAMA. Last time this was brought up I someone was going to modify FILO to scan through all possible busses like etherboot does. > > Maybe someone need to make it can handle peer root bus refer to the code in > > Linux kernel or Etherboot. > > Can we have an array of peer busses in the config file? > ie. register SCAN_BUSSES={ 0, 1, 3 } In LinuxBIOS we are fine. It is just in FILO where there is an issue. > Or is there any real way to _detect_ peer busses? Or at least conclude > their existance by the available southbridges - There is obviously no > peer bus without a (transparent) bridge Linux uses the pirq table to infer their presence. We really should export the device tree in the LinuxBIOS table. Then FILO can read that to find busses and other devices. Eric From ijpriya at hotmail.com Wed Dec 10 22:09:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 10 22:09:01 2003 Subject: Please help Message-ID: Hi, I like to have my linuxbios, linux OS, filesystem in the same diskonchip millennium. If I have to use diskonchip millennium with linuxbios, to which physical address should the DOCM should be mapped in hardware ? Is any driver should be loaded before the OS gets loaded? I have mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any remapping is to be done in hardware afer this? Which file system should I use? _________________________________________________________________ Download cool KHNH ringtones. Add style to your mobile. http://server1.msn.co.in/sp03/gprs/howcani_ring.asp Simply click here. From rminnich at lanl.gov Wed Dec 10 22:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 10 22:39:00 2003 Subject: Please help In-Reply-To: Message-ID: On Thu, 11 Dec 2003, Devi Priya wrote: > diskonchip millennium. If I have to use diskonchip millennium with > linuxbios, to which physical address should the DOCM should be mapped in > hardware ? Is any driver should be loaded before the OS gets loaded? I have > mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any > remapping is to be done in hardware afer this? > Which file system should I use? I would like to help but your questions indicate you are somewhat unfamiliar with many things. Are you using some standard motherboard or designing one? If you are not designing one, consider buying an existing DOC-based mobo from cwlinux.com and learning from that. ron From ijpriya at hotmail.com Wed Dec 10 23:56:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 10 23:56:01 2003 Subject: Please help Message-ID: I am using SC1200. >From: ron minnich >To: Devi Priya >CC: linuxbios at clustermatic.org >Subject: Re: Please help >Date: Wed, 10 Dec 2003 20:40:51 -0700 (MST) > >On Thu, 11 Dec 2003, Devi Priya wrote: > > > diskonchip millennium. If I have to use diskonchip millennium with > > linuxbios, to which physical address should the DOCM should be mapped in > > hardware ? Is any driver should be loaded before the OS gets loaded? I >have > > mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any > > remapping is to be done in hardware afer this? > > Which file system should I use? > >I would like to help but your questions indicate you are somewhat >unfamiliar with many things. Are you using some standard motherboard or >designing one? > >If you are not designing one, consider buying an existing DOC-based mobo >from cwlinux.com and learning from that. > >ron > _________________________________________________________________ Contact brides & grooms FREE! Only on www.shaadi.com. http://www.shaadi.com/ptnr.php?ptnr=hmltag Register now! From ts1 at tsn.or.jp Thu Dec 11 03:30:01 2003 From: ts1 at tsn.or.jp (Takeshi Sone) Date: Thu Dec 11 03:30:01 2003 Subject: IDE on s2885 and LinuxBIOS -- FILO In-Reply-To: References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de> Message-ID: <20031211083112.GA3485@tsn.or.jp> On Wed, Dec 10, 2003 at 02:49:29PM -0700, Eric W. Biederman wrote: > Stefan Reinauer writes: > > > * YhLu [031210 22:02]: > > > I have checked pci.c in fifo. It need to be changes as follow. > > > > > > It seems otherwise it can not scan the peer root bus. > > > > How is this done on the HDAMA and other boards? > > Currently I have not been testing the Filo on the HDAMA. Last > time this was brought up I someone was going to modify FILO to scan > through all possible busses like etherboot does. That patch is here: http://www.clustermatic.org/pipermail/linuxbios/2003-October/005753.html > > > Maybe someone need to make it can handle peer root bus refer to the code in > > > Linux kernel or Etherboot. > > > > Can we have an array of peer busses in the config file? > > ie. register SCAN_BUSSES={ 0, 1, 3 } I like this idea implemented in FILO, rather than having 2 options (recurse from bus 0, and scan 0-255). What do you think? > > Or is there any real way to _detect_ peer busses? Or at least conclude > > their existance by the available southbridges - There is obviously no > > peer bus without a (transparent) bridge > > Linux uses the pirq table to infer their presence. We really > should export the device tree in the LinuxBIOS table. Then FILO can > read that to find busses and other devices. That would be the right solution eventually. -- Takeshi From parit_top at yahoo.com Sat Dec 13 23:37:00 2003 From: parit_top at yahoo.com (Parit Wattanasin) Date: Sat Dec 13 23:37:00 2003 Subject: serial programming Message-ID: <20031214043944.21965.qmail@web10801.mail.yahoo.com> hi, I'm new for LinuxBIOS. I have problem about my mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I want to customized it to chang payload from etherboot with my program about serial port(now this mainboard use serial console) how can I'change it(my program use assembly). Thank you for answer __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From stuge-linuxbios at cdy.org Sun Dec 14 00:22:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun Dec 14 00:22:01 2003 Subject: serial programming In-Reply-To: <20031214043944.21965.qmail@web10801.mail.yahoo.com> References: <20031214043944.21965.qmail@web10801.mail.yahoo.com> Message-ID: <20031214051445.GA17520@foo.birdnet.se> On Sat, Dec 13, 2003 at 08:39:44PM -0800, Parit Wattanasin wrote: > hi, I'm new for LinuxBIOS. I have problem about my > mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I want > to customized it to chang payload from etherboot with > my program about serial port(now this mainboard use > serial console) how can I'change it(my program use > assembly). Thank you for answer The payload can be exchanged from Etherboot to another self-contained ELF file simply by recompiling LinuxBIOS. I'm not quite sure about the status of the EPIA port in the version 2 CVS tree, but it's there and there's been work put into it so it should probably compile and work just fine. The best bet is to check the mailing list archives for information, and then grab the CVS code, or a snapshot, and make your own build. While making your own build you can also take out all serial port activity not needed for your application, of course. //Peter From rminnich at lanl.gov Sun Dec 14 00:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Dec 14 00:50:01 2003 Subject: serial programming In-Reply-To: <20031214051445.GA17520@foo.birdnet.se> Message-ID: On Sun, 14 Dec 2003, Peter Stuge wrote: > I'm not quite sure about the status of the EPIA port in the version 2 CVS > tree, but it's there and there's been work put into it so it should probably > compile and work just fine. EPIA is fine in V2, not perfect but FAR better than EPIA in v1. We want to clean up EPIA completely, then fix up EPIA-M, but there have been some distractions (SC '03). ron From stuge-linuxbios at cdy.org Sun Dec 14 02:45:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun Dec 14 02:45:01 2003 Subject: serial programming In-Reply-To: References: <20031214051445.GA17520@foo.birdnet.se> Message-ID: <20031214073708.GC17520@foo.birdnet.se> On Sat, Dec 13, 2003 at 10:52:20PM -0700, ron minnich wrote: > On Sun, 14 Dec 2003, Peter Stuge wrote: > > > I'm not quite sure about the status of the EPIA port in the version 2 CVS > > tree, but it's there and there's been work put into it so it should probably > > compile and work just fine. > > EPIA is fine in V2, not perfect but FAR better than EPIA in v1. > > We want to clean up EPIA completely, then fix up EPIA-M, but there have > been some distractions (SC '03). Ah, yes, that's right. I can't wait until I actually have the time to sit down and do something with LinuxBIOS, last time was over two years ago, there's been an amazing evolution of the code. I can easily imagine running LinuxBIOS 3 or 4 on _MANY_ systems in another year or two. It seems vendors (like Tyan) are picking up too, which is great. Just don't take over all of their competent people over at LANL, at least not until there's support for all of their boards in the tree.. >:) Just a short note to celebrate your success. :) //Peter From parit_top at yahoo.com Sun Dec 14 13:38:01 2003 From: parit_top at yahoo.com (Parit Wattanasin) Date: Sun Dec 14 13:38:01 2003 Subject: serial programming In-Reply-To: <20031214170000.26080.21738.Mailman@nwn.definitive.org> Message-ID: <20031214184048.54508.qmail@web10805.mail.yahoo.com> --- linuxbios-request at clustermatic.org wrote: > Send Linuxbios mailing list submissions to > linuxbios at clustermatic.org > > To subscribe or unsubscribe via the World Wide Web, > visit > > http://www.clustermatic.org/mailman/listinfo/linuxbios > or, via email, send a message with subject or body > 'help' to > linuxbios-request at clustermatic.org > > You can reach the person managing the list at > linuxbios-admin at clustermatic.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Linuxbios digest..." > > > Today's Topics: > > 1. serial programming (Parit Wattanasin) > 2. Re: serial programming (Peter Stuge) > 3. Re: serial programming (ron minnich) > 4. Re: serial programming (Peter Stuge) > > --__--__-- > > Message: 1 > Date: Sat, 13 Dec 2003 20:39:44 -0800 (PST) > From: Parit Wattanasin > Subject: serial programming > To: linuxbios at clustermatic.org > > hi, I'm new for LinuxBIOS. I have problem about my > mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I > want > to customized it to chang payload from etherboot > with > my program about serial port(now this mainboard use > serial console) how can I'change it(my program use > assembly). Thank you for answer > > __________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing. > http://photos.yahoo.com/ > > --__--__-- > > Message: 2 > Date: Sun, 14 Dec 2003 06:14:45 +0100 > From: Peter Stuge > To: linuxbios at clustermatic.org > Subject: Re: serial programming > > On Sat, Dec 13, 2003 at 08:39:44PM -0800, Parit > Wattanasin wrote: > > hi, I'm new for LinuxBIOS. I have problem about my > > mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I > want > > to customized it to chang payload from etherboot > with > > my program about serial port(now this mainboard > use > > serial console) how can I'change it(my program use > > assembly). Thank you for answer > > The payload can be exchanged from Etherboot to > another self-contained ELF > file simply by recompiling LinuxBIOS. > > I'm not quite sure about the status of the EPIA port > in the version 2 CVS > tree, but it's there and there's been work put into > it so it should probably > compile and work just fine. > > The best bet is to check the mailing list archives > for information, and then > grab the CVS code, or a snapshot, and make your own > build. > > While making your own build you can also take out > all serial port activity > not needed for your application, of course. > > > //Peter > > --__--__-- > > Message: 3 > Date: Sat, 13 Dec 2003 22:52:20 -0700 (MST) > From: ron minnich > To: Peter Stuge > cc: linuxbios at clustermatic.org > Subject: Re: serial programming > > On Sun, 14 Dec 2003, Peter Stuge wrote: > > > I'm not quite sure about the status of the EPIA > port in the version 2 CVS > > tree, but it's there and there's been work put > into it so it should probably > > compile and work just fine. > > EPIA is fine in V2, not perfect but FAR better than > EPIA in v1. > > We want to clean up EPIA completely, then fix up > EPIA-M, but there have > been some distractions (SC '03). > > ron > > > --__--__-- > > Message: 4 > Date: Sun, 14 Dec 2003 08:37:08 +0100 > From: Peter Stuge > To: linuxbios at clustermatic.org > Subject: Re: serial programming > > On Sat, Dec 13, 2003 at 10:52:20PM -0700, ron > minnich wrote: > > On Sun, 14 Dec 2003, Peter Stuge wrote: > > > > > I'm not quite sure about the status of the EPIA > port in the version 2 CVS > > > tree, but it's there and there's been work put > into it so it should probably > > > compile and work just fine. > > > > EPIA is fine in V2, not perfect but FAR better > than EPIA in v1. > > > > We want to clean up EPIA completely, then fix up > EPIA-M, but there have > > been some distractions (SC '03). > > Ah, yes, that's right. > > I can't wait until I actually have the time to sit > down and do something > with LinuxBIOS, last time was over two years ago, > there's been an amazing > evolution of the code. I can easily imagine running > LinuxBIOS 3 or 4 on > _MANY_ systems in another year or two. It seems > vendors (like Tyan) are > picking up too, which is great. Just don't take over > all of their competent > people over at LANL, at least not until there's > support for all of their > boards in the tree.. >:) > > Just a short note to celebrate your success. :) > > > //Peter > > > --__--__-- > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > End of Linuxbios Digest I'm assemble my serial program to elf-format and exchange for etherboot.It has error =LinuxBIOS-1.0.0 Wed Dec 3 11:26:55 ICT 2003 starting.. =Enabled first bank of RAM: 0x08000000 bytes =Copying LinuxBIOS to ram. =Jumping to LinuxBIOS. =POST: 0x39 =LinuxBIOS-1.0.0 Wed Dec 3 11:26:55 ICT 2003 booting... =POST: 0x40 =... =... =... =Copying IRQ routing tables to 0xf0000...done. =Verifing priq routing tables copy at 0xf0000...succeed =POST: 0x96 =Wrote linuxbios table at: 00000500 - 000006b0 =checksum 8255 = =Welcome to elfboot, the open sourced starter. =January 2002, Eric Biederman. =Version 1.2 = =POST: 0xf8 37:init_bytes() - zkernel_start:0xfff00000 =zkernel_mask:0x0000ffff =Found ELF candiate at offset 0 =New segment addr 0x8048000 size 0xa6 offset 0x0 =filesize 0xa6 =(cleaned up) New segment addr 0x8048000 size 0xa6 =offset 0x0 filesize 0xa6 =Cannot Load ELF Image =POST: 0xff= __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From dwh at lanl.gov Mon Dec 15 00:12:00 2003 From: dwh at lanl.gov (Hendricks David W.) Date: Mon Dec 15 00:12:00 2003 Subject: VIA EPIA mini-ITX mainboards In-Reply-To: <000001c3bfd1$881ce150$9512cecb@etechtxp1> Message-ID: Yeah, Slasdot obviously is not intended to be used as a message forum for lingering discussion. Ron has a working image that was used for what I gather is a similar mainboard. Output from lspci would also be helpful so that we can make sure the hardware on your board is the same as the hardware on ours (Whatever came in the ITuner Minibox M-100's). P.S. I cc'd this e-mail to the mailing list ( http://www.clustermatic.org/pipermail/linuxbios/2003-December/ ) since the EPIA is a rather popular platform and others might be able to offer help in this matter. Etherboot can boot a kernel over a LAN, and IDE disk, floppy, and probably some others too. Are you using an ethernet bridge like a Linksys WET11 or an add-in PCI or USB wireless device? On Thu, 11 Dec 2003, Sonam Chauhan wrote: > [ Re: http://bsd.slashdot.org/comments.pl?sid=87041&cid=7567224 ] > > Hi - Thanks for offering to help with your experience flashing VIA EPIA > mini-ITX mainboards. Sorry, I didn't see your reply until recently. :) > > You wrote: > > If you're using the 500MHz/800MHz normal SDRAM version, I'll send > > you a ROM I used with the old freebios tree and an Etherboot > > payload. > That'd be great! Yes, I have the 533 MHz fanless EPIA ESP 5000 board > with PC 133 SDRAM. > > By etherboot, do you mean that the board can boot remotely from LAN, > using the onboard ethernet port? If so, that's excellent! Out of > curiosity, do you see any problem with the Mini-ITX board etherbooting > via a 802.11 wireless access point it is connected to with it's ethernet > interface? > > With best regards, > Sonam Chauhan > From niki.waibel at newlogic.com Mon Dec 15 04:53:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Dec 15 04:53:01 2003 Subject: EPIA-M + second serial port enabler In-Reply-To: <200312091808.hB9I8phP028465@xdr.com> Message-ID: <200312150955.hBF9tf84006867@enterprise2.newlogic.at> i'd just like to confirm that the 2nd serial port on the epia-m works if you do the modifications dave describes. niki On 09-Dec-2003 Dave Ashley wrote: > In a previous email message > http://www.clustermatic.org/pipermail/linuxbios/2003-November/005891.html > > I wrote > In V1 the file to modify is src/superio/via/vt1211/setup_serial.inc > That code sets up ttyS0 which is the VT1211's logical device 2. You > want to add some similiar code for logical device 3 to get ttyS1 working. > > Assuming you want it to be at 2f8 you'd merge in these lines: > OUTPNPADDR($7) > OUTPNPDATA($3) > /* set the enable in reg. 0x30 */ > OUTPNPADDR($0x30) > OUTPNPDATA($0x1) > > /* Serial Port 2 Base Address (BEh) */ > OUTPNPADDR($0x60) > OUTPNPDATA($0xbe) > /* Serial Port 2 IRQ (03h) */ > OUTPNPADDR($0x70) > OUTPNPDATA($0x3) > /* Serial Port 2 Control */ > OUTPNPADDR($0xf0) > OUTPNPDATA($0x2) > > ...then do the turn off pnp > /* turn off PnP */ > OUTPNPADDR($0xaa) > > ...then duplicate the serial setup except the address goes from 3f8 -> 2f8 > > > There is a piece missing. I had to enable the second serial port on the VT1211 > and although linux recognized it, there was no serial activity on the lines. > > These lines need to be added during the vt1211 configuration: > > /* Allow serial port 2 (ldn 3) pins to come out */ > OUTPNPADDR($0x27) > OUTPNPDATA($00) > > This has to be before the $0xaa write to turn off configuration mode. > > The default value on powerup for this register on the vt1211 is 0xff. > There are multi purpose pins on the chip and this connects them to the second > serial port. > > -Dave From linuxbios at xdr.com Wed Dec 17 14:10:01 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Wed Dec 17 14:10:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity Message-ID: <200312171913.hBHJD25G000391@xdr.com> I am at my wits end regarding how to get the serial ports on the epia-m to run at full 115,200 baud rate. Here is a summary of what is known: 1) The serial ports are driven by the VT1211 superio chip. 2) Under AWARD bios the serial ports are capable of 115,200 operation. 3) Under linuxbios they can only run at 57,600 max. 4) Booting up with AWARD then soft reset (or hit reset button on motherboard) into linuxbios still maintains 115,200 baud 5) Hard reset (power off then on) into linuxbios reduces maximum baud rate to 57,600. 6) All registers of the VT1211 are identical after linuxbios bootup, whether from award -> softreset -> linuxbios bootup or hardreset -> linuxbios bootup. I am speaking of all registers of all logical devices of the VT1211, including all the global registers. I wrote a program to dump everything then diff'd the two outputs, they're identical. I have repeatedly tried asking VIA for help, in various different ways. The VT1211 datasheet and the VT1211 bios porting guide have not resolved the issue. VIA has proven incapable of addressing the problem. I have one last idea. There is an emulator to test VGA bios's, I was messing with it a few months back. Is there an emulator for the full BIOS? I'd like to be able to watch all io port accesses of the award bios, maybe I can trap when it goes to write to the 0x2e + 0x2f io ports to configure the vt1211 serial ports, then look for something near there that might be related. The idea would be to figure out what magical thing the AWARD bios is doing to initialize the serial port. Failing that is there any way to disassemble a BIOS image? Any ideas welcome. BTW if anyone has figured out how to fix the problem, please just f*cking out with it, I think I've been very generous in the past with enhancements and turnabout is fair play. Thanks-- Dave From rminnich at lanl.gov Wed Dec 17 16:25:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 17 16:25:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity [PMX:#] In-Reply-To: <200312171913.hBHJD25G000391@xdr.com> Message-ID: I don't know what the problem is, I don't have an EPIA-M yet. One thing you could do with a PCI analyzer is watch the ins and outs and look for a magic setting. Are your sure the clock source for the superio or uart is the same for linuxbios and award? disassembly is a bad idea. The "emulator for VGA bios" will actually run anything that looks like a bios. I've run T23 bios on a T23 (and crashed the T23 that way). So that works. ron From linuxbios at xdr.com Wed Dec 17 17:47:00 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Wed Dec 17 17:47:00 2003 Subject: EPIA-M serial port 1/2 baud rate insanity Message-ID: <200312172250.hBHMoLUL001502@xdr.com> >I don't know what the problem is, I don't have an EPIA-M yet. >... >Are your sure the clock source for the superio or uart is the same for >linuxbios and award? >The "emulator for VGA bios" will actually run anything... If sending you an epia-m would mean you'd begin looking at it I'll get you one. Let me know. I'm not sure of the clock source, VIA hasn't provided a schematic for the board. The datasheet indicates 2 clock sources, one is for the LPC interface and the other is for the main clock. LPC is the 33 mhz pci clock. The other clock is 48 mhz. I had a scope on the chip and as near as I can tell the 48 mhz clock was in fact 48 mhz. I didn't look at the 33 mhz clock at all. -Dave From ijpriya at hotmail.com Wed Dec 17 21:45:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Wed Dec 17 21:45:01 2003 Subject: sc1200? Message-ID: Hi, After power-on, the x86 processor is placed in real mode. That means the CPU looks for the instruction at the address 0xffff0. Is it correct? In SC1200 datasheet, it is given that, "Approximately 150 to 250 external clock cycles after RESET is deasserted, the processor begins executing instructions at the top of physical memory (address location FFFFFFF0h). The actual number of clock cycles depends on the clock scaling in use. Also, before execution begins, an additional 220 clock cycles are needed when self-test is requested. Typically, an intersegment jump is placed at FFFFFFF0h. This instruction will force the processor to begin execution in the lowest 1 MB of address space." In real mode, the CPU can address only 1 MB. Then how this address could be addressed by the CPU? To which address does my Flash memory gets mapped to at power-on? _________________________________________________________________ Don?t miss out on jobs that are not advertised. http://go.msnserver.com/IN/38902.asp Post your CV on naukri.com today. From aip at cwlinux.com Wed Dec 17 22:24:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Dec 17 22:24:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity In-Reply-To: <200312171913.hBHJD25G000391@xdr.com>; from Dave Ashley on Wed, Dec 17, 2003 at 11:13:02AM -0800 References: <200312171913.hBHJD25G000391@xdr.com> Message-ID: <20031218112744.A21757@mail.cwlinux.com> Hi Dave, Have you checked out the clock connected to LPC? On W311, FS2 can be set to 24 or 48 MHz. It could be the problem, since I have similar problem with USB on a custom cle266 board. FYI, it can be programmed thru smb. Here is from we have done to program the USB clock. #define SMB_BASE_ADDRESS 0x5000 #define SMB_STATUS (SMB_BASE_ADDRESS + 0) #define SMB_CONTROL (SMB_BASE_ADDRESS + 2) #define SMB_COMMAND (SMB_BASE_ADDRESS + 3) #define SMB_ADDRESS (SMB_BASE_ADDRESS + 4) #define SMB_DATA (SMB_BASE_ADDRESS + 5) #define I2C_TRANS_CMD 0x40 #define CLOCK_SLAVE_ADDRESS 0x69 static void ext_clock_fixup(void) { int dt; struct pci_dev *dev; dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x3177, 0); if (dev != NULL) { printk_info("ext clock setting\n"); // SMB IO address 5000h pci_write_config_byte(dev, 0xD1, (SMB_BASE_ADDRESS>>8)&0xff ); pci_write_config_byte(dev, 0xD0, SMB_BASE_ADDRESS&0xff ); // enable SMB pci_write_config_byte(dev, 0xD2, 0x01); // clear status outb( 0xff, SMB_STATUS ); // USB out 48MHz outb( 0x7f, SMB_DATA ); outb( 0x83, SMB_COMMAND ); outb( (CLOCK_SLAVE_ADDRESS<<1), SMB_ADDRESS ); outb( 0x8|I2C_TRANS_CMD, SMB_CONTROL ); while( inb(SMB_STATUS) & 0x01 ); } } You may want to put similar code in serial init. Hope this help. -Andrew On Wed, Dec 17, 2003 at 11:13:02AM -0800, Dave Ashley wrote: > I am at my wits end regarding how to get the serial ports on the epia-m to > run at full 115,200 baud rate. Here is a summary of what is known: > > 1) The serial ports are driven by the VT1211 superio chip. > 2) Under AWARD bios the serial ports are capable of 115,200 operation. > 3) Under linuxbios they can only run at 57,600 max. > 4) Booting up with AWARD then soft reset (or hit reset button on motherboard) > into linuxbios still maintains 115,200 baud > 5) Hard reset (power off then on) into linuxbios reduces maximum baud rate to > 57,600. > 6) All registers of the VT1211 are identical after linuxbios bootup, whether > from award -> softreset -> linuxbios bootup or hardreset -> linuxbios bootup. > I am speaking of all registers of all logical devices of the VT1211, including > all the global registers. I wrote a program to dump everything then diff'd the > two outputs, they're identical. > > I have repeatedly tried asking VIA for help, in various different ways. The > VT1211 datasheet and the VT1211 bios porting guide have not resolved the > issue. VIA has proven incapable of addressing the problem. > > I have one last idea. There is an emulator to test VGA bios's, I was messing > with it a few months back. Is there an emulator for the full BIOS? I'd like > to be able to watch all io port accesses of the award bios, maybe I can > trap when it goes to write to the 0x2e + 0x2f io ports to configure the > vt1211 serial ports, then look for something near there that might be related. > The idea would be to figure out what magical thing the AWARD bios is doing > to initialize the serial port. > > Failing that is there any way to disassemble a BIOS image? > > Any ideas welcome. > > BTW if anyone has figured out how to fix the problem, please just f*cking > out with it, I think I've been very generous in the past with enhancements > and turnabout is fair play. > > Thanks-- > Dave > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Thu Dec 18 00:04:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Dec 18 00:04:01 2003 Subject: sc1200? In-Reply-To: Message-ID: at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH 0xffffff0 and 0xffff0. ron From ijpriya at hotmail.com Thu Dec 18 01:18:01 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Thu Dec 18 01:18:01 2003 Subject: sc1200? Message-ID: Thanks for ur suggestion. My flash is 4 MB. My processor can address up to 4 GB physical address space. That means after power-on, in shematic should I map the flash memory like 0xFFC00000-0xFFFFFFFF and 0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the 256KB region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower address to 0x00000000-0x003FFFFF >From: ron minnich >To: Devi Priya >CC: linuxbios at clustermatic.org >Subject: Re: sc1200? >Date: Wed, 17 Dec 2003 22:07:00 -0700 (MST) > >at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH >0xffffff0 and 0xffff0. > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ Don?t miss out on jobs that are not advertised. http://go.msnserver.com/IN/38902.asp Post your CV on naukri.com today. From ollie at lanl.gov Thu Dec 18 11:12:00 2003 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu Dec 18 11:12:00 2003 Subject: sc1200? In-Reply-To: References: Message-ID: <1071764089.4956.136.camel@exponential.lanl.gov> On Wed, 2003-12-17 at 23:21, Devi Priya wrote: > Thanks for ur suggestion. > My flash is 4 MB. My processor can address up to 4 GB physical address > space. That means after power-on, in shematic should I map the flash memory > like 0xFFC00000-0xFFFFFFFF and > 0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the 256KB > region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower address to > 0x00000000-0x003FFFFF > Are you building your own mainboard ? Usually this mapping stuff is done by the southbridge or superio chip, you don't and can't do anything about. BTW, are you sure your flash is 4MByte instead of 4Mbits ? Ollie From rminnich at lanl.gov Thu Dec 18 12:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Dec 18 12:39:00 2003 Subject: sc1200? In-Reply-To: Message-ID: You're building hardware? ron From rminnich at lanl.gov Thu Dec 18 12:40:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Dec 18 12:40:01 2003 Subject: sc1200? In-Reply-To: Message-ID: On Thu, 18 Dec 2003, Devi Priya wrote: > > Thanks for ur suggestion. > My flash is 4 MB. My processor can address up to 4 GB physical address > space. That means after power-on, in shematic should I map the flash memory > like 0xFFC00000-0xFFFFFFFF and ffe00000-ffffffff and e0000-fffff From bari at onelabs.com Thu Dec 18 12:40:04 2003 From: bari at onelabs.com (Bari Ari) Date: Thu Dec 18 12:40:04 2003 Subject: sc1200? In-Reply-To: References: Message-ID: <3FE1E769.6040007@onelabs.com> Devi Priya wrote: > > Thanks for ur suggestion. > My flash is 4 MB. My processor can address up to 4 GB physical address > space. That means after power-on, in shematic should I map the flash > memory like 0xFFC00000-0xFFFFFFFF and > 0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the > 256KB region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower > address to 0x00000000-0x003FFFFF > >> From: ron minnich >> To: Devi Priya >> CC: linuxbios at clustermatic.org >> Subject: Re: sc1200? >> Date: Wed, 17 Dec 2003 22:07:00 -0700 (MST) >> >> at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH >> 0xffffff0 and 0xffff0. >> From the AMD data sheet: The Core Logic module positively decodes memory addresses 000F0000h-000FFFFFh (64 KB) and FFFC0000h-FFFFFFFFh (256 KB) at reset. These memory cycles cause the Core Logic module to claim the cycle, and generate an ISA bus memory cycle with ROMCS# asserted. The Core Logic module can also be configured to respond to memory addresses FF000000h-FFFFFFFFh (16 MB) and 000E0000h-000FFFFFh (128 KB). 8- or 16-bit wide ROM is supported. BOOT16 strap determines the width after reset. MCR[14,3] (Offset 34h) in the General Configuration Block allows program control of the width. Flash ROM is supported in the Core Logic module by enabling the ROMCS# signal on write accesses to the ROM region. Normally only read cycles are passed to the ISA bus, and the ROMCS# signal is suppressed for write cycles. When the ROM Write Enable bit (F0 Index 52h[1]) is set, a write access to the ROM address region causes a write cycle to occur with MEMW#,WR# and ROMCS# asserted. The Boot Flash supported by the SC1200/SC1201 can be up to 16 MB. It is supported with the ROMCS# signal. DOCCS# ? Asserted on memory read/write transactions from/to a programmable window. ? ROMCS# ? Asserted on memory read/write to upper 16 MB of address space. Configurable via the ROM Mask register (F0 Index 6Eh). ? DOCR# ? DOCR# is asserted on memory read transactions from DOCCS# window (i.e., when both DOCCS# and MEMR# are active, DOCR# is active; otherwise, it is inactive). ? DOCW ? DOCW# is asserted on memory write transactions to DOCCS# window (i.e., when both DOCCS# and MEMW# are active, DOCW# is active; otherwise, it is inactive). ? RD#, WR# ? The signals IOR#, IOW#, MEMR#, and MEMW# are combined into two signals: RD# is asserted on I/O read or memory read; WR# is asserted on I/O write or memory write. Memory devices that use ROMCS# or DOCCS# as their chip select signal can be configured to support an 8-bit or 16-bit data bus via bits 3 and 6 of the MCR register. Such devices can also be configured as zero wait states devices (regardless of the data bus width) via bits 9 and 10 of the MCR register. The DiskOnChip chip select signal (DOCCS#) is asserted on any memory read or memory write transaction from/to a programmable address range. The address range is pro-grammable via the DOCCS#Base Address and Control registers (F0 Index 78h and 7Ch). The base address must be on an address boundary, the size of the range. Signal DOCCS# can also be used to interface to NAND Flash devices together with signals DOCW# and DOCR#. See application note AMD Geode? SC1200/SC2200/ SC3200 Processors: External NAND Flash Memory Circuit for details. This you'll have to get from AMD. It goes into using the DOC for boot ROM and also as a general storage device. It also contains IPL and SPL code along with the boot procedure, memory map, etc. -Bari From linuxbios at xdr.com Thu Dec 18 12:42:01 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Thu Dec 18 12:42:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity Message-ID: <200312181745.hBIHjEnL006550@xdr.com> Andrew Ip wrote: >Have you checked out the clock connected to LPC? On W311, FS2 can be >set to 24 or 48 MHz. It could be the problem, since I have similar problem >with USB on a custom cle266 board. FYI, it can be programmed thru smb. >Here is from we have done to program the USB clock. >... >You may want to put similar code in serial init. Hope this help. I tried this and...it worked! My simple test program is below. Linuxbios puts the smb stuff at 0xf00 and it is already enabled (at least in my patch). So all I had to do was do the outb's to get it to work. Thanks *very* much. Note to Ron: Let me know if you want the epia-m, I'll still send one off if you want it. I've got a spare 10000 (1 gig) that you can have. Note I don't read email sent to the address I'm posting from...best send to dash at xdr.com to get to me. #include #include #include #include #include #define SMB_STATUS (base + 0) #define SMB_CONTROL (base + 2) #define SMB_COMMAND (base + 3) #define SMB_ADDRESS (base + 4) #define SMB_DATA (base + 5) #define I2C_TRANS_CMD 0x40 #define CLOCK_SLAVE_ADDRESS 0x69 int main(int argc, char **argv) { int res; int base=0xf00; res=iopl(3); if(res) { perror("iopl"); exit(-1); } outb( 0xff, SMB_STATUS ); // USB out 48MHz outb( 0x7f, SMB_DATA ); outb( 0x83, SMB_COMMAND ); outb( (CLOCK_SLAVE_ADDRESS<<1), SMB_ADDRESS ); outb( 0x8|I2C_TRANS_CMD, SMB_CONTROL ); while( inb(SMB_STATUS) & 0x01 ); } -Dave From linuxbios at xdr.com Thu Dec 18 13:31:01 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Thu Dec 18 13:31:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity Message-ID: <200312181834.hBIIY5LP006669@xdr.com> Here is what I did to integrate this into linuxbios. I created the following file src/mainboard/via/epia-m/smbusenable.inc /* Useful macros PCIBUS, and SMBUS functions for getting DRAM going. */ /* courtesy Eric Biederman of linuxnetworx.com */ #define CS_WRITE_BYTE(addr, byte) \ movl $addr, %eax ; \ movl $byte, %edx ; \ PCI_WRITE_CONFIG_BYTE #define CS_WRITE_WORD(addr, word) \ movl $addr, %eax ; \ movl $word, %ecx ; \ PCI_WRITE_CONFIG_WORD #define CS_WRITE_LONG(addr, dword) \ movl $addr, %eax ; \ movl $dword, %ecx ; \ PCI_WRITE_CONFIG_DWORD #define DEVFN(device, function) (((device) << 3) + (function)) #ifndef CONFIG_ADDR #define CONFIG_ADDR(bus,devfn,where) (((bus) << 16) | ((devfn) << 8) | (where)) #endif /* generic SMB routines that work for many systems. The only one that might * not work is the enable_smbus. * you have to define PM_FUNCTION for this to work. */#define SMBUS_IO_BASE 0xf00 #define SMBHSTSTAT 0 #define SMBHSTCTL 2 #define SMBHSTCMD 3 #define SMBHSTADD 4 #define SMBHSTDAT0 5 #define SMBHSTDAT1 6 #define SMBBLKDAT 7 /* (DA) Lines added to get this to compile */ #define PM_DEVFN CONFIG_ADDR(0,0x11*8,0) #define DRAM_CONFIG_PORT 0x5a #define SMBUS_MEM_DEVICE_0 0x50 #define LAST_SMBUS_MEM_DEVICE SMBUS_MEM_DEVICE_0 #define REGISTERED_DRAM_REGISTER $0x69 #define REGISTERED_DRAM $0x2d #define NONREGISTERED_DRAM $0 /* put the SMBUS at port 0xf00 + enable*/ CS_WRITE_WORD(PM_DEVFN+ 0xd0, SMBUS_IO_BASE|1) /* iobase addr */ CS_WRITE_BYTE(PM_DEVFN + 0xd2, (0x4 << 1) | 1) /* smbus enable */ CS_WRITE_WORD(PM_DEVFN + 0x4, 1) /* iospace enable */ /* The VT1211 serial port needs 48 mhz clock, on power up it is getting only 24 mhz, there is some mysterious device on the smbus that can fix this...this code below does it. */ #define MYOUTB(val, port) movb val, %al; movw port, %dx ; outb %al, %dx #define I2C_TRANS_CMD 0x40 #define CLOCK_SLAVE_ADDRESS 0x69 MYOUTB( $0xff, $(SMBUS_IO_BASE+SMBHSTSTAT)) MYOUTB( $0x7f, $(SMBUS_IO_BASE+SMBHSTDAT0)) MYOUTB( $0x83, $(SMBUS_IO_BASE+SMBHSTCMD)) MYOUTB( $(CLOCK_SLAVE_ADDRESS<<1), $(SMBUS_IO_BASE+SMBHSTADD)) MYOUTB( $(8 | I2C_TRANS_CMD), $(SMBUS_IO_BASE+SMBHSTCTL)) movw $(SMBUS_IO_BASE+SMBHSTSTAT), %dx smbwait1: inb %dx, %al and $1, %al jnz smbwait1 ----- Now in src/mainboard/via/epia-m/Config we need to include the above file, so it ends up looking like this: mainboardinit mainboard/via/epia-m/smbusenable.inc mainboardinit superio/via/vt1211/setup_serial.inc mainboardinit pc80/serial.inc -Dave From brian.thomason at lindows.com Thu Dec 18 16:21:01 2003 From: brian.thomason at lindows.com (Brian Thomason) Date: Thu Dec 18 16:21:01 2003 Subject: Intel 82845G/GL Message-ID: <3FE21B1F.6070706@lindows.com> I scanned the entire mailing and website for LinuxBIOS and didn't see a single reference to the Intel 82845G/GL. Is this configuration supported? If not, would it be "easy" to add support for it? I'm very new to LinuxBIOS (just discovered the website a month or so ago and still don't fully grok it) but have two machines with this chipset I'd like to get setup as sample boxes to show my boss the increase in boot time. (From what I hear, it speeds up boot time CONSIDERABLY) Thanks in advance for your time, Brian Thomason Lindows.com Developer Relations From rminnich at lanl.gov Thu Dec 18 16:29:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Dec 18 16:29:00 2003 Subject: Intel 82845G/GL In-Reply-To: <3FE21B1F.6070706@lindows.com> Message-ID: On Thu, 18 Dec 2003, Brian Thomason wrote: > I scanned the entire mailing and website for LinuxBIOS and didn't see a > single reference to the Intel 82845G/GL. Is this configuration > supported? If not, would it be "easy" to add support for it? not done yet. started, but not done. > > I'm very new to LinuxBIOS (just discovered the website a month or so ago > and still don't fully grok it) but have two machines with this chipset > I'd like to get setup as sample boxes to show my boss the increase in > boot time. (From what I hear, it speeds up boot time CONSIDERABLY) have you done this type of hacking before? if so, you can probably get there. ron From brian.thomason at lindows.com Thu Dec 18 16:33:01 2003 From: brian.thomason at lindows.com (Brian Thomason) Date: Thu Dec 18 16:33:01 2003 Subject: Intel 82845G/GL In-Reply-To: References: Message-ID: <3FE21DD6.5040409@lindows.com> Unfortunately, no. I'm a lowly web programmer at this point. (Python/PHP/Perl) I learn quite quickly though - Who's currently working on this chipset? -Brian ron minnich wrote: >On Thu, 18 Dec 2003, Brian Thomason wrote: > > > >>I scanned the entire mailing and website for LinuxBIOS and didn't see a >>single reference to the Intel 82845G/GL. Is this configuration >>supported? If not, would it be "easy" to add support for it? >> >> > >not done yet. started, but not done. > > >>I'm very new to LinuxBIOS (just discovered the website a month or so ago >>and still don't fully grok it) but have two machines with this chipset >>I'd like to get setup as sample boxes to show my boss the increase in >>boot time. (From what I hear, it speeds up boot time CONSIDERABLY) >> >> > >have you done this type of hacking before? if so, you can probably get >there. > >ron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwh at lanl.gov Thu Dec 18 17:32:00 2003 From: dwh at lanl.gov (Hendricks David W.) Date: Thu Dec 18 17:32:00 2003 Subject: Intel 82845G/GL In-Reply-To: <3FE21B1F.6070706@lindows.com> Message-ID: That's a graphics chip, correct? Unfortunately, we're still working on initializing VGA BIOSes (Particularly on GeForce cards). However, there are some boards which have VGA working in LinuxBIOS, like the VIA EPIA mini-itx board with an integrated graphics controller. I haven't tried booting KDE with it yet, but I imagine the BIOS and kernel could load at least as fast as KDE itself. As for your Intel 82845G/GL, could you please post lspci output? As I recall, the 82845 is on the i845 chipset, uses the 82801DB PCI controller and the e7501 (ICH4) memory controller hub. Eric Beiderman got that chipset, or at least a very similar one, working with the Supermicro X5DPR in the freebios1 tree (I don't think it's in freebios2 yet). I can't say you'll get VGA output without some serious hacking around, but you should at least be able to boot it, get some serial output, and SSH in if all goes well and your kernel boots. By the way, and I hate to get off-topic, how is Micheal doing in Europe? I've read about the lawsuits on The Register, but they don't seem to have a very positive outlook :( On Thu, 18 Dec 2003, Brian Thomason wrote: > I scanned the entire mailing and website for LinuxBIOS and didn't see a > single reference to the Intel 82845G/GL. Is this configuration > supported? If not, would it be "easy" to add support for it? > > I'm very new to LinuxBIOS (just discovered the website a month or so ago > and still don't fully grok it) but have two machines with this chipset > I'd like to get setup as sample boxes to show my boss the increase in > boot time. (From what I hear, it speeds up boot time CONSIDERABLY) > > Thanks in advance for your time, > > Brian Thomason > Lindows.com Developer Relations > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From brian.thomason at lindows.com Thu Dec 18 17:50:01 2003 From: brian.thomason at lindows.com (Brian Thomason) Date: Thu Dec 18 17:50:01 2003 Subject: Intel 82845G/GL In-Reply-To: References: Message-ID: <3FE22FFB.20002@lindows.com> Hendricks David W. wrote: >That's a graphics chip, correct? Unfortunately, we're still working on >initializing VGA BIOSes (Particularly on GeForce cards). > Come to find out, it is a graphics chip (I don't know hardware very well, so please bear with me :-) ) I also know very little in the way of LinuxBIOS and how it works. It is disheartening to hear GeForce cards aren't supported as of yet. >However, there are some boards which have VGA working in LinuxBIOS, like >the VIA EPIA mini-itx board with an integrated graphics controller. > I believe our resellers sell some PC's with this installed, so that is good to hear. >I haven't tried booting KDE with it yet, but I imagine the BIOS and kernel >could load at least as fast as KDE itself. > >As for your Intel 82845G/GL, could you please post lspci output? > 00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge (rev 03) 00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82) 00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02) 00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) > As I recall, the 82845 is on the i845 chipset, > How would I verify this? >uses the 82801DB PCI controller and the e7501 (ICH4) memory controller hub. > You know your hardware don't you? :-) >Eric Beiderman got that chipset, or at least a very similar one, working with the Supermicro >X5DPR in the freebios1 tree (I don't think it's in freebios2 yet). I can't >say you'll get VGA output without some serious hacking around, but you >should at least be able to boot it, get some serial output, and SSH in if >all goes well and your kernel boots. > :-( Looks like I'll just have to track down a box with the VIA EPIA mini-itx board you referred to. >By the way, and I hate to get off-topic, how is Micheal doing in >Europe? I've read about the lawsuits on The Register, but they don't seem >to have a very positive outlook :( > Unfortunately, I'm not permitted to discuss that, but you can read about them as they happen on ChoicePC.com. Many thanks for the prompt and helpful reply. -Brian From ebiederman at lnxi.com Thu Dec 18 19:27:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Dec 18 19:27:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... Message-ID: Brainstorming earlier today I think I have found a way to use an linux kernel for the boot loader and to implement pcbios compatibility without too much cost. The idea is to use a uclinux kernel. And implement a ``user space'' aplication that is a user space shim that makes kernel calls. There are a few nasty details to work out like how to handle services that are expected to work in vm86 mode. But I'm not certain I care. Other thoughts? After I come back from my christmas vacation I am going to have to try it and see how will it will actually work. Eric From aip at cwlinux.com Thu Dec 18 19:30:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu Dec 18 19:30:01 2003 Subject: EPIA-M serial port 1/2 baud rate insanity In-Reply-To: <200312181745.hBIHjEnL006550@xdr.com>; from Dave Ashley on Thu, Dec 18, 2003 at 09:45:14AM -0800 References: <200312181745.hBIHjEnL006550@xdr.com> Message-ID: <20031219083330.A5137@mail.cwlinux.com> Hi Dave, > I tried this and...it worked! My simple test program is below. Linuxbios > puts the smb stuff at 0xf00 and it is already enabled (at least in my patch). > So all I had to do was do the outb's to get it to work. Thanks *very* much. Execellent. I will integrate it to the v1 tree. Thank you very much for the patch. :) -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From joshua at joshuawise.com Thu Dec 18 20:27:00 2003 From: joshua at joshuawise.com (Joshua Wise) Date: Thu Dec 18 20:27:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <200312182031.04720.joshua@joshuawise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 18 December 2003 7:36 pm, Eric W. Biederman wrote: > Brainstorming earlier today I think I have found a way to use > an linux kernel for the boot loader and to implement pcbios > compatibility without too much cost. The idea is to use > a uclinux kernel. And implement a ``user space'' aplication > that is a user space shim that makes kernel calls. The way I implement my bootloader on ARM is like this: 1) First stage assembly loader sets up serial and DRAM. 2) First stage loader probes RAM, and sets up tagged list. 3) First stage jumps into zImage of special LAB (Linux As Bootldr) kernel. (currently just a 2.6.0 kernel from handhelds.org that has CONFIG_LAB defined.) 4) LAB kernel boots up until it gets ready to jump into init. 5) #ifdef'ed code takes over and calls a LAB main function which does all sorts of cool stuff including giving the user a CLI if requested (usually by holding the iPAQ's joypad down), or autobooting (running a predefined mkdir/mount/armboot sequence.) Conceivably you could write a subapp for the CLI that does what you want, and put it in the autoboot script. LAB for ARM's zImage is currently ~509kbytes for those who care. (We must keep it below 512KB.) > There are a few nasty details to work out like how to handle > services that are expected to work in vm86 mode. But I'm > not certain I care. I've tinkered with writing an OS, but I still don't know too much about the x86 architecture, so I couldn't help there. Sorry. > Other thoughts? Check out my LAB code, see what you think. It's in handhelds.org anoncvs, module linux/kernel26. Relevant crap is in bootldr/, drivers/bootldr/, and arch/arm/boot/. > After I come back from my christmas vacation I am going to have to try > it and see how will it will actually work. Take care, have a nice vacation. > Eric /joshua - -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | I akilled *@* by mistake In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/4lTWPn9tWOqA4LMRAnd3AKCRojCaS1dGk7BHmp9RTxkCNjo/7QCfVAel 7kuNSdKY2Y5lg9QAdwGP5BQ= =qD9C -----END PGP SIGNATURE----- From ebiederman at lnxi.com Fri Dec 19 00:17:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 00:17:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <200312182031.04720.joshua@joshuawise.com> References: <200312182031.04720.joshua@joshuawise.com> Message-ID: Joshua Wise writes: > On Thursday 18 December 2003 7:36 pm, Eric W. Biederman wrote: > > Brainstorming earlier today I think I have found a way to use > > an linux kernel for the boot loader and to implement pcbios > > compatibility without too much cost. The idea is to use > > a uclinux kernel. And implement a ``user space'' aplication > > that is a user space shim that makes kernel calls. > > The way I implement my bootloader on ARM is like this: > > 1) First stage assembly loader sets up serial and DRAM. > 2) First stage loader probes RAM, and sets up tagged list. Roughly what LinuxBIOS does. > 3) First stage jumps into zImage of special LAB (Linux As Bootldr) kernel. > (currently just a 2.6.0 kernel from handhelds.org that has CONFIG_LAB > defined.) > 4) LAB kernel boots up until it gets ready to jump into init. > 5) #ifdef'ed code takes over and calls a LAB main function which does all > sorts of cool stuff including giving the user a CLI if requested (usually by > holding the iPAQ's joypad down), or autobooting (running a predefined > mkdir/mount/armboot sequence.) > > Conceivably you could write a subapp for the CLI that does what you want, and > put it in the autoboot script. Somehow I could write a subapp that would make linux look like a normal pcbios, but I can be surprised. > LAB for ARM's zImage is currently ~509kbytes for those who care. (We must keep > it below 512KB.) Ouch! My x86 images are below that, at least before decompression. > > There are a few nasty details to work out like how to handle > > services that are expected to work in vm86 mode. But I'm > > not certain I care. > I've tinkered with writing an OS, but I still don't know too much about the > x86 architecture, so I couldn't help there. Sorry. > > > Other thoughts? > Check out my LAB code, see what you think. It's in handhelds.org anoncvs, > module linux/kernel26. Relevant crap is in bootldr/, drivers/bootldr/, and > arch/arm/boot/. I probably will. Doing that stuff inside the kernel does not really feel proper to me. I already have an x86 kernel that can load another kernel from user space. I'm just trying to find a good long term architecture for using the kernel as a bootloader. > > After I come back from my christmas vacation I am going to have to try > > it and see how will it will actually work. > Take care, have a nice vacation. Thanks. Eric From rminnich at lanl.gov Fri Dec 19 00:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 00:29:01 2003 Subject: Intel 82845G/GL In-Reply-To: <3FE22FFB.20002@lindows.com> Message-ID: On Thu, 18 Dec 2003, Brian Thomason wrote: > Hendricks David W. wrote: > > >That's a graphics chip, correct? Unfortunately, we're still working on > >initializing VGA BIOSes (Particularly on GeForce cards). > > > Come to find out, it is a graphics chip (I don't know hardware very > well, so please bear with me :-) ) the 82845 is a north bridge. > You know your hardware don't you? :-) david really knows hardware quite well. ron From rminnich at lanl.gov Fri Dec 19 00:34:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 00:34:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: well I sure like the idea of using linux for the bios, as always ... ron From rminnich at lanl.gov Fri Dec 19 00:34:05 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 00:34:05 2003 Subject: EPIA-M serial port 1/2 baud rate insanity In-Reply-To: <20031219083330.A5137@mail.cwlinux.com> Message-ID: let's talk about that patch one more time before we commit. ron From ebiederman at lnxi.com Fri Dec 19 00:47:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 00:47:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: ron minnich writes: > well I sure like the idea of using linux for the bios, as always ... Regardless of the actual details what I like is the added requirement that we attempt to support the legacy pcbios interface. It's ugly it's nasty but if we can do that with a Linux kernel driving the hardware we have a single solution which can work for everyone. Some people can strip it down and not include all of the features but... Eric From adam at cfar.umd.edu Fri Dec 19 00:51:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri Dec 19 00:51:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: <20031219005706.H66505-100000@www.missl.cs.umd.edu> you mean just like dosemu runs under linux ??? On 18 Dec 2003, Eric W. Biederman wrote: > > Brainstorming earlier today I think I have found a way to use > an linux kernel for the boot loader and to implement pcbios > compatibility without too much cost. The idea is to use > a uclinux kernel. And implement a ``user space'' aplication > that is a user space shim that makes kernel calls. > > There are a few nasty details to work out like how to handle > services that are expected to work in vm86 mode. But I'm > not certain I care. > > Other thoughts? > > After I come back from my christmas vacation I am going to have to try > it and see how will it will actually work. > > Eric > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Fri Dec 19 02:40:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 02:40:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <20031219005706.H66505-100000@www.missl.cs.umd.edu> References: <20031219005706.H66505-100000@www.missl.cs.umd.edu> Message-ID: Adam Sulmicki writes: > you mean just like dosemu runs under linux ??? Right but for BSD and early versions of windows the dependencies were worse. I don't know which services matter though. Eric From ts1 at tsn.or.jp Fri Dec 19 04:18:00 2003 From: ts1 at tsn.or.jp (Takeshi Sone) Date: Fri Dec 19 04:18:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <20031219005706.H66505-100000@www.missl.cs.umd.edu> Message-ID: <20031219092135.GA27866@tsn.or.jp> On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote: > Adam Sulmicki writes: > > > you mean just like dosemu runs under linux ??? > > Right but for BSD and early versions of windows the dependencies > were worse. I don't know which services matter though. Last time I saw the source code of FreeBSD, its _bootloader_ has its own vm86 monitor (in assembly), works in protected mode, and calls all the BIOS calls (video, keyboard, disk,...) in vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86. Also I saw a recent version of Windows calls BIOS services in vm86. Maybe we can modify FreeBSD, and have work-around for Windows, but at least I don't think it's the way to go. My conclusion then was that PCBIOS had to work in real mode. Maybe we can code it with GCC and .code16gcc hack. If 64KB is not enough, maybe 0xE000 segment can be used so that we have 64KB code and 64KB data segments. And all the "POST" code can be outside the real mode space. So it's not impossible or hard at all. -- Takeshi From ebiederman at lnxi.com Fri Dec 19 06:49:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 06:49:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <20031219092135.GA27866@tsn.or.jp> References: <20031219005706.H66505-100000@www.missl.cs.umd.edu> <20031219092135.GA27866@tsn.or.jp> Message-ID: Takeshi Sone writes: > On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote: > > Adam Sulmicki writes: > > > > > you mean just like dosemu runs under linux ??? > > > > Right but for BSD and early versions of windows the dependencies > > were worse. I don't know which services matter though. > > Last time I saw the source code of FreeBSD, its _bootloader_ has its > own vm86 monitor (in assembly), works in protected mode, > and calls all the BIOS calls (video, keyboard, disk,...) in > vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86. > Also I saw a recent version of Windows calls BIOS services in vm86. > > Maybe we can modify FreeBSD, and have work-around for Windows, > but at least I don't think it's the way to go. Thanks. I knew this was the biggest danger, and from the description it looks like no half measures will do. > My conclusion then was that PCBIOS had to work in real mode. If that is the case the PCBIOS has hit an evolutionary dead, as the code size cannot increase, there is very little room for change remaining. This explains ACPI. And it makes EFI look much more attractive. I think I see one way out of this pickle, implement the firmware in System Management mode. System calls will be slow and we will need an interrupt reflector but this does allow us to escape the bounds of vm86 mode, and the legacy limitations. And our OS will even have some protection from ``user mode''. System Management mode is essentially big real mode. So code would need to be compiled with .code16gcc, but there is a full 4G available. I know with amd's processors I can switch to 32bit or 64bit protected mode inside of smm mode, Intel's documentation is not clear on that point, so I don't know what we can do there. Depending on what works it may make sense simply to build an smm mode trampoline to get out of vm86 mode. > Maybe we can code it with GCC and .code16gcc hack. > If 64KB is not enough, maybe 0xE000 segment can be used > so that we have 64KB code and 64KB data segments. > And all the "POST" code can be outside the real mode space. > So it's not impossible or hard at all. For just PCBIOS compatibility I agree. Primarily I want that layer to exist as an add-on and an after thought. Something that gives backwards compatibility but allows us to do something better. With only 256KB of room, there simply is not enough room to implement drivers of interesting hardware. Nor is there enough room to implement interesting protocol stacks. And it limits what we can do in the future. Eric From stepan at suse.de Fri Dec 19 08:53:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Dec 19 08:53:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <20031219135615.GA14339@suse.de> * Eric W. Biederman [031219 01:36]: > > Brainstorming earlier today I think I have found a way to use > an linux kernel for the boot loader and to implement pcbios > compatibility without too much cost. The idea is to use > a uclinux kernel. And implement a ``user space'' aplication > that is a user space shim that makes kernel calls. What functionality is it exactly that we need the uclinux kernel for? We won't do any scheduling, and we won't need source code drivers if we implement a pcbios "emulation" What I liked most about the LinuxBIOS2 approach is that code was only introduced in the tree when it was specifically needed. Since I had my hands at the Alpha bootloader Milo, everything that uses a Linux kernel for it's operations kind of scares me... Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From rminnich at lanl.gov Fri Dec 19 11:48:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 11:48:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <20031219135615.GA14339@suse.de> Message-ID: On Fri, 19 Dec 2003, Stefan Reinauer wrote: > * Eric W. Biederman [031219 01:36]: > > > > Brainstorming earlier today I think I have found a way to use > > an linux kernel for the boot loader and to implement pcbios > > compatibility without too much cost. The idea is to use > > a uclinux kernel. And implement a ``user space'' aplication > > that is a user space shim that makes kernel calls. > > What functionality is it exactly that we need the uclinux > kernel for? We won't do any scheduling, and we won't need source code > drivers if we implement a pcbios "emulation" > What I liked most about the LinuxBIOS2 approach is that > code was only introduced in the tree when it was specifically needed. I've been assuming that the uclinux approach is for a payload for those who want it. I did not expect to see this in the tree. ron From ebiederman at lnxi.com Fri Dec 19 13:11:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 13:11:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <20031219135615.GA14339@suse.de> References: <20031219135615.GA14339@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [031219 01:36]: > > > > Brainstorming earlier today I think I have found a way to use > > an linux kernel for the boot loader and to implement pcbios > > compatibility without too much cost. The idea is to use > > a uclinux kernel. And implement a ``user space'' aplication > > that is a user space shim that makes kernel calls. > > What functionality is it exactly that we need the uclinux > kernel for? We won't do any scheduling, and we won't need source code > drivers if we implement a pcbios "emulation" > What I liked most about the LinuxBIOS2 approach is that > code was only introduced in the tree when it was specifically needed. > > Since I had my hands at the Alpha bootloader Milo, everything that uses > a Linux kernel for it's operations kind of scares me... So this is for the bootloader, the payload and it will be optional. This will not go into the linuxBIOS tree, this is an alternative to etherboot. I might do a kernel port to a weird hardware configuration but I will not hack up the kernel in the way Milo does. I have worked on it and I have the scars as well. Anything that borrows the kernel drivers is asking for trouble. But look at etherboot. It also has a dependency on linux drivers. But because etherboot actually ports the drivers, and then ports the bug fixes it works there is not a nightmare of a maintenance issue there. So I think using the kernel whole will be ok. The observation has been that any sufficiently general firmware bootloader tends to become an OS, so why not use a real OS. So the things I actually care about are: booting over myrinet, booting over inifinband, booting over quadrics, booting over a pair of bonded nics. Having a good tg3 driver. Getting Lustre as my root filesystem. Unless size issues kill it again I am going to use the linux kernel as my bootloader to do this. So except for the case where someone plugs in a card with an option rom all the pcbios emulation would do would be to make system calls to the linux kernel. The biggest modification I would have to make would be to change the load address of the kernel, and not the let the kernel use all of RAM, but instead live in a small fixed area. I guess the other problem I see with doing a pcbios emulation layer is I don't know if there it is there is an API to get the kernel drivers to stop. If I can't have my cake and eat it too, I won't have pcbios compatibility. Oh, well. Eric From rminnich at lanl.gov Fri Dec 19 14:33:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 14:33:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On 19 Dec 2003, Eric W. Biederman wrote: > The observation has been that any sufficiently general firmware > bootloader tends to become an OS, so why not use a real OS. ah ha! we've come full circle :-) good to hear. > > So the things I actually care about are: booting over myrinet, > booting over inifinband, booting over quadrics, booting over a pair of > bonded nics. Having a good tg3 driver. Getting Lustre as my root > filesystem. Unless size issues kill it again I am going to use the > linux kernel as my bootloader to do this. yah, this is why we still put linux in flash here at LANL. ron From gwatson at lanl.gov Fri Dec 19 14:39:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Fri Dec 19 14:39:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <20031219135615.GA14339@suse.de> Message-ID: At 11:20 AM -0700 12/19/03, Eric W. Biederman wrote: >Stefan Reinauer writes: > >> * Eric W. Biederman [031219 01:36]: >> > >> > Brainstorming earlier today I think I have found a way to use >> > an linux kernel for the boot loader and to implement pcbios >> > compatibility without too much cost. The idea is to use >> > a uclinux kernel. And implement a ``user space'' aplication >> > that is a user space shim that makes kernel calls. >> >> What functionality is it exactly that we need the uclinux >> kernel for? We won't do any scheduling, and we won't need source code >> drivers if we implement a pcbios "emulation" >> What I liked most about the LinuxBIOS2 approach is that >> code was only introduced in the tree when it was specifically needed. >> >> Since I had my hands at the Alpha bootloader Milo, everything that uses >> a Linux kernel for it's operations kind of scares me... > >So this is for the bootloader, the payload and it will be optional. >This will not go into the linuxBIOS tree, this is an alternative to >etherboot. > I would like to see this from the PPC perspective. Since neither filo nor etherboot work on PPC, this might be a good way of booting from, say, a disk. Which would be nice. Greg From ebiederman at lnxi.com Fri Dec 19 15:53:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 15:53:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <20031219135615.GA14339@suse.de> Message-ID: Greg Watson writes: > I would like to see this from the PPC perspective. Since neither filo nor > etherboot work on PPC, this might be a good way of booting from, say, a > disk. Which would be nice. I won't argue with that but this will take some time to come to fruition. etherboot should be fairly straight forward to port to the PPC. Currently etherboot supports 3 architectures 4 if you count x86_64. The PPC would not even be the first big endian port. So for a low end solution that works I still recommend etherboot. But if we can avoid the bloat issues the Linux kernel is a good thing to have. Any interest in porting kexec to the ppc? It is not strictly required if you can get your kernel to avoid the memory problem but it is quite useful. Eric From ebiederman at lnxi.com Fri Dec 19 15:55:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 15:55:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: ron minnich writes: > On 19 Dec 2003, Eric W. Biederman wrote: > > > The observation has been that any sufficiently general firmware > > bootloader tends to become an OS, so why not use a real OS. > > ah ha! we've come full circle :-) > > good to hear. I have never disagreed. Now that we have something that works for the low end limited ROM solutions I can revisit some of the more interesting ideas. > > So the things I actually care about are: booting over myrinet, > > booting over inifinband, booting over quadrics, booting over a pair of > > bonded nics. Having a good tg3 driver. Getting Lustre as my root > > filesystem. Unless size issues kill it again I am going to use the > > linux kernel as my bootloader to do this. > > yah, this is why we still put linux in flash here at LANL. Now if you had more than a proof of concept implementation of most of the pieces I would not be happier, but anyway... Eric From rminnich at lanl.gov Fri Dec 19 16:20:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 16:20:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On Fri, 19 Dec 2003, Greg Watson wrote: > I would like to see this from the PPC perspective. Since neither filo > nor etherboot work on PPC, this might be a good way of booting from, > say, a disk. Which would be nice. a linux kernel, with a small initrd with modules and kexec, is just about the ideal boot loader setup. cwlinux.com has been selling this configuration for some time. Setting up the same thing on PPC should be easy. We have all the bits we need for a very capable bootloader, and have for 3 years. The only thing missing has been a big enough FLASH part. If the FLASH gets big enough soon enough, our problems will be solved for us. ron From rminnich at lanl.gov Fri Dec 19 16:23:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 16:23:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On 19 Dec 2003, Eric W. Biederman wrote: > Now if you had more than a proof of concept implementation of most > of the pieces I would not be happier, but anyway... I kind of miss the point. Pink's been booting with linux in ide-flash for a year, and if the flash on pink were large enough, we would have been using that instead. ron From ebiederman at lnxi.com Fri Dec 19 16:38:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 16:38:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: ron minnich writes: > On 19 Dec 2003, Eric W. Biederman wrote: > > > Now if you had more than a proof of concept implementation of most > > of the pieces I would not be happier, but anyway... > > I kind of miss the point. Pink's been booting with linux in ide-flash for > a year, and if the flash on pink were large enough, we would have been > using that instead. Possibly proof of concept is the wrong term. What Pink does works. I can't throw J. Random kernel at beoboot and have that work. I can't throw memtest86 at it and have that work. I can't use an SMP aware kernel with beoboot. And last I looked beoboot had a bulky user space that makes it hard to squeeze into flash as well. So beoboot with 2 kernel monte works for a certain interesting subset of cases but it does not handle the general case. Except possibly for the exotic driver case 512KB is a large enough FLASH chip to put in both LinuxBIOS and a kernel. You have to work at it with a 512KB flash chip but it is doable today. Eric From rminnich at lanl.gov Fri Dec 19 16:49:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Dec 19 16:49:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On 19 Dec 2003, Eric W. Biederman wrote: > What Pink does works. I can't throw J. Random kernel at beoboot and have > that work. I can't throw memtest86 at it and have that work. I can't use an > SMP aware kernel with beoboot. And last I looked beoboot had a bulky user > space that makes it hard to squeeze into flash as well. So beoboot > with 2 kernel monte works for a certain interesting subset of cases > but it does not handle the general case. ok, gotcha. I don't think I would use beoboot for the general flash case, I think what Andrew Ip set up with kernel+kexec+initrd with some utils is the right model. > Except possibly for the exotic driver case 512KB is a large enough > FLASH chip to put in both LinuxBIOS and a kernel. You have to work at > it with a 512KB flash chip but it is doable today. gotcha. thanks ron From joshua at joshuawise.com Fri Dec 19 16:58:01 2003 From: joshua at joshuawise.com (Joshua Wise) Date: Fri Dec 19 16:58:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <200312191701.57968.joshua@joshuawise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 19 December 2003 4:04 pm, Eric W. Biederman wrote: > ron minnich writes: > > On 19 Dec 2003, Eric W. Biederman wrote: > > > The observation has been that any sufficiently general firmware > > > bootloader tends to become an OS, so why not use a real OS. > > > > ah ha! we've come full circle :-) > > > > good to hear. > > I have never disagreed. Now that we have something that works for > the low end limited ROM solutions I can revisit some of the more > interesting ideas. *jumps up and down like a hyperactive two-year-old* LAB can do that stuff! I would definately like to see LAB used on more than just ARM. > > > So the things I actually care about are: booting over myrinet, > > > booting over inifinband, booting over quadrics, booting over a pair of > > > bonded nics. Having a good tg3 driver. Getting Lustre as my root > > > filesystem. Unless size issues kill it again I am going to use the > > > linux kernel as my bootloader to do this. If you can have it in the kernel you can have it in LAB. LAB's command line API is really easy - I've ported userland apps (mtderase) to LAB in sub-10 minutes. As to size issues, we're at a 512k zImage. We do not have bzImages on ARM, so I could not tell you the size with it. 512k is with a few ARM-specific drivers, and jffs2. It does not have networking. This is with kernel 2.6. > > yah, this is why we still put linux in flash here at LANL. Oh and did I say LAB had MTD support? :) > Now if you had more than a proof of concept implementation of most > of the pieces I would not be happier, but anyway... *jumps up and down* I do I do!! > Eric /joshua - -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | I akilled *@* by mistake In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/43VVPn9tWOqA4LMRAtiDAJ9sxXhTis+n1hpCvmX4gDc32ycTCwCdGwCB 2BMzNV/IHpx46g6tRljOdkk= =u9wv -----END PGP SIGNATURE----- From joshua at joshuawise.com Fri Dec 19 17:04:01 2003 From: joshua at joshuawise.com (Joshua Wise) Date: Fri Dec 19 17:04:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <200312182031.04720.joshua@joshuawise.com> Message-ID: <200312191708.27438.joshua@joshuawise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > 1) First stage assembly loader sets up serial and DRAM. > > 2) First stage loader probes RAM, and sets up tagged list. > Roughly what LinuxBIOS does. Right, ok. You can find my code in arch/arm/boot/bootldr-xscale.S. > Somehow I could write a subapp that would make linux look like a normal > pcbios, but I can be surprised. The subapp does run in kernelland, so you can do pretty much anything you want. (That's how we can boot another kernel from within LAB land.) > > LAB for ARM's zImage is currently ~509kbytes for those who care. (We must > > keep it below 512KB.) > Ouch! My x86 images are below that, at least before decompression. Whine whine whine. :) This is including lots of cruft. > I probably will. Doing that stuff inside the kernel does not really feel > proper to me. I already have an x86 kernel that can load another kernel > from user space. I'm just trying to find a good long term architecture > for using the kernel as a bootloader. The design decision was made to do this all from kernelland when LAB started off in 2.4. 2.4 did not have initramfs, so that was not even an option. The decision stuck as I upported to 2.6. Yes, you have TKM for x86, but that's not very portable or readable. armboot is very readable (and portable) code, despite its name. Regarding longevity, LAB will be supported for the next forever by handhelds.org. > Eric /joshua - -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | I akilled *@* by mistake In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/43baPn9tWOqA4LMRAowFAJ4/vmIz6ytttytLbLKZZZrxMvPWjgCfczMY 8PPMCwdkppZl1tlr19lw3ek= =Rq/f -----END PGP SIGNATURE----- From ebiederman at lnxi.com Fri Dec 19 19:06:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Dec 19 19:06:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <200312191701.57968.joshua@joshuawise.com> References: <200312191701.57968.joshua@joshuawise.com> Message-ID: Joshua Wise writes: > On Friday 19 December 2003 4:04 pm, Eric W. Biederman wrote: > > ron minnich writes: > > > On 19 Dec 2003, Eric W. Biederman wrote: > > > > The observation has been that any sufficiently general firmware > > > > bootloader tends to become an OS, so why not use a real OS. > > > > > > ah ha! we've come full circle :-) > > > > > > good to hear. > > > > I have never disagreed. Now that we have something that works for > > the low end limited ROM solutions I can revisit some of the more > > interesting ideas. > > *jumps up and down like a hyperactive two-year-old* LAB can do that stuff! > > I would definately like to see LAB used on more than just ARM. Yes we are reaching the point where we can converge on some of these things. LAB might be the right framework. And if it is something good it will save me the trouble of starting my own project. But it takes more than a hyper active 2 year old to convince me. It might take a hyperactive 2 year old to remind me about interesting ideas though. > > > > So the things I actually care about are: booting over myrinet, > > > > booting over inifinband, booting over quadrics, booting over a pair of > > > > bonded nics. Having a good tg3 driver. Getting Lustre as my root > > > > filesystem. Unless size issues kill it again I am going to use the > > > > linux kernel as my bootloader to do this. > If you can have it in the kernel you can have it in LAB. LAB's command line > API is really easy - I've ported userland apps (mtderase) to LAB in sub-10 > minutes. By and large I don't want a command line interface. I don't want a hardware monitor. I want a configurable but non-interactive boot. > As to size issues, we're at a 512k zImage. We do not have bzImages on ARM, so > I could not tell you the size with it. Compression wise there is not a difference between bzImage and zImage. zImage on x86 has a 640K limit because it loads below 1MB. bzImage breaks that ancient barrier. > 512k is with a few ARM-specific drivers, and jffs2. It does not have > networking. This is with kernel 2.6. Hmm. I am pretty certain I have gotten 2.6 down some smaller. Our practical limit with LinuxBIOS etc is in the neighborhood of 384KB. > > > yah, this is why we still put linux in flash here at LANL. > > Oh and did I say LAB had MTD support? :) Well I think I have run finally convinced to use the MTD drivers... Mostly I prefer to flash from a production kernel rather than a bootloader, there are more recover options but anyway. > > Now if you had more than a proof of concept implementation of most > > of the pieces I would not be happier, but anyway... > *jumps up and down* I do I do!! I will see. Does LAB restrict it's kernel to a very small subset of memory? Or do you use something like kexec? Eric From joshua at joshuawise.com Fri Dec 19 22:47:01 2003 From: joshua at joshuawise.com (Joshua Wise) Date: Fri Dec 19 22:47:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <200312191701.57968.joshua@joshuawise.com> Message-ID: <200312192251.44827.joshua@joshuawise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 19 December 2003 7:15 pm, Eric W. Biederman wrote: > Yes we are reaching the point where we can converge on some of these > things. LAB might be the right framework. And if it is something good it > will save me the trouble of starting my own project. But it takes more > than a hyper active 2 year old to convince me. It might take a hyperactive > 2 year old to remind me about interesting ideas though. Right, well then you should see it in action. If you're in the Boston area sometime soon I can give you a demo on an iPAQ, perhaps. > > If you can have it in the kernel you can have it in LAB. LAB's command > > line API is really easy - I've ported userland apps (mtderase) to LAB in > > sub-10 minutes. > By and large I don't want a command line interface. I don't want a > hardware monitor. I want a configurable but non-interactive boot. Right, that's where our autoboot stuff comes in. You can have it mount a partition by default, do whatever you want by default if no key has been struck on the serial line within 3 seconds. > Compression wise there is not a difference between bzImage and zImage. > zImage on x86 has a 640K limit because it loads below 1MB. bzImage breaks > that ancient barrier. Right, I just read about that. Mea culpa. > > 512k is with a few ARM-specific drivers, and jffs2. It does not have > > networking. This is with kernel 2.6. > Hmm. I am pretty certain I have gotten 2.6 down some smaller. Our > practical limit with LinuxBIOS etc is in the neighborhood of 384KB. I've done 2.4 in 256k, but it's rather useless like that. If you do not plan to load modules at runtime, you can shave a good bit more off of it. If you write bzip2 compression support (or upport the stuff from kernel 2.4), you can shave even more off of it. I've pulled off 50k with bzip2 (not actually written the code, just did a bzip2 -9 < piggy > piggy.bz2). If you don't plan to have a framebuffer, you can shave some off of it. If you don't plan to have jffs2 you can shave a lot more off. Little tidbits here and there make the world go 'round. > Well I think I have run finally convinced to use the MTD drivers... > Mostly I prefer to flash from a production kernel rather than a > bootloader, there are more recover options but anyway. Ah yes, the ancient problem. Instead of read/modify/erase/write, it often turns into read/modify/erase/poweroff. That's Bad. > I will see. Does LAB restrict it's kernel to a very small subset of > memory? Or do you use something like kexec? To boot a secondary kernel I use some code I wrote called armboot, although it's not very arm specific. It does something like this: 1) Load the new kernel into a contiguous vmalloced block. 2) We allocate 64k for a list of things that need to be relocated. We call this a pointer of type "struct physlist", which is 32 bytes. It has four ints: the new address, the old address, the block size, and whether this is the last block. 2) In blocks of the maximum kmalloc size (these blocks have to be contiguous), we kmalloc space for the kernel, and memcpy the kernel into those blocks. We then fill in a struct physlist, and move on to the next struct physlist. We can do this because kmalloc is always contiguous, and we can always map it with virt_to_phys(). 3) We set up another kmalloced block for the tagged list of boot parameters that you need on ARM. 4) We set up one more kmalloced block and copy an assembler function into it, to make sure we don't wipe ourself out while relocating. 5) We flush our data caches. 6) We call the relocated assembler function, which turns off the MMU, jumps into the relocated assembler function's physical address, and does actual relocating. Then we jump into our newly moved zImage. Confused yet? 7) If at any point we failed, the system could be in an inconsistent state. You will want to panic() if you fail, because you're leaking memory like a sieve, and if you failed there's probably something bigger wrong. This looks more difficult than it actually is. The C segment is only about 170 lines, and the assembler bit is 90 lines. The reason that this works is that kmalloc should allocate from the top of memory down. You need a fair bit of ram - say, 8MB - to prevent the tail from running over other important structures, such as the list of addresses to relocate. But it seems to work well enough, and it looks like it should be fairly portable. The important code is in handhelds.org cvs, module linux/kernel26, files drivers/bootldr/armboot.c and drivers/bootldr/armboot-asm.S. > Eric /joshua - -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | I akilled *@* by mistake In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/48dQPn9tWOqA4LMRAqg8AJ4tEJmyHQ5gb9c/Mj401uhRQxSvSwCeL/mD 0uiImbJ4XRrQ4avT9bVyhRE= =krn6 -----END PGP SIGNATURE----- From ebiederman at lnxi.com Sat Dec 20 03:01:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat Dec 20 03:01:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <200312192251.44827.joshua@joshuawise.com> References: <200312191701.57968.joshua@joshuawise.com> <200312192251.44827.joshua@joshuawise.com> Message-ID: Joshua Wise writes: > On Friday 19 December 2003 7:15 pm, Eric W. Biederman wrote: > > Yes we are reaching the point where we can converge on some of these > > things. LAB might be the right framework. And if it is something good it > > will save me the trouble of starting my own project. But it takes more > > than a hyper active 2 year old to convince me. It might take a hyperactive > > 2 year old to remind me about interesting ideas though. > Right, well then you should see it in action. If you're in the Boston area > sometime soon I can give you a demo on an iPAQ, perhaps. Salt Lake City, and Illinois with my family for Christmas. Though a serial console logfile might be interesting. > > > 512k is with a few ARM-specific drivers, and jffs2. It does not have > > > networking. This is with kernel 2.6. > > Hmm. I am pretty certain I have gotten 2.6 down some smaller. Our > > practical limit with LinuxBIOS etc is in the neighborhood of 384KB. > I've done 2.4 in 256k, but it's rather useless like that. If you do not plan > to load modules at runtime, you can shave a good bit more off of it. If you > write bzip2 compression support (or upport the stuff from kernel 2.4), you > can shave even more off of it. I've pulled off 50k with bzip2 (not actually > written the code, just did a bzip2 -9 < piggy > piggy.bz2). The problem is that the bzip2 decompresser is huge, usually bzip2 is a net loss because of the decompresser. But it may be possible to write a tuned version. The cases I have typically worried about are much smaller and I have made huge gains by switching to nrv2b from upx because the decompresser is something like 100 bytes, and the compression is roughly as good as gzip. > If you don't plan to have a framebuffer, you can shave some off of > it. If you don't plan to have jffs2 you can shave a lot more > off. Little tidbits here and there make the world go 'round. Quite true. > > Well I think I have run finally convinced to use the MTD drivers... > > Mostly I prefer to flash from a production kernel rather than a > > bootloader, there are more recover options but anyway. > Ah yes, the ancient problem. Instead of read/modify/erase/write, it often > turns into read/modify/erase/poweroff. That's Bad. :) > > I will see. Does LAB restrict it's kernel to a very small subset of > > memory? Or do you use something like kexec? > To boot a secondary kernel I use some code I wrote called armboot, although > it's not very arm specific. It does something like this: > > 1) Load the new kernel into a contiguous vmalloced block. > 2) We allocate 64k for a list of things that need to be relocated. We call > this a pointer of type "struct physlist", which is 32 bytes. It has four > ints: the new address, the old address, the block size, and whether this is > the last block. > 2) In blocks of the maximum kmalloc size (these blocks have to be contiguous), > we kmalloc space for the kernel, and memcpy the kernel into those blocks. We > then fill in a struct physlist, and move on to the next struct physlist. We > can do this because kmalloc is always contiguous, and we can always map it > with virt_to_phys(). > 3) We set up another kmalloced block for the tagged list of boot parameters > that you need on ARM. > 4) We set up one more kmalloced block and copy an assembler function into it, > to make sure we don't wipe ourself out while relocating. > 5) We flush our data caches. > 6) We call the relocated assembler function, which turns off the MMU, jumps > into the relocated assembler function's physical address, and does actual > relocating. Then we jump into our newly moved zImage. Confused yet? Nope. Having implemented something similar it sounds sane. > 7) If at any point we failed, the system could be in an inconsistent state. > You will want to panic() if you fail, because you're leaking memory like a > sieve, and if you failed there's probably something bigger wrong. Ouch. > This looks more difficult than it actually is. The C segment is only about 170 > lines, and the assembler bit is 90 lines. > > The reason that this works is that kmalloc should allocate from the top of > memory down. You need a fair bit of ram - say, 8MB - to prevent the tail from > running over other important structures, such as the list of addresses to > relocate. But it seems to work well enough, and it looks like it should be > fairly portable. The important code is in handhelds.org cvs, module > linux/kernel26, files drivers/bootldr/armboot.c and > drivers/bootldr/armboot-asm.S. Ok. I need to get into that kernel tree and take a look. But it sounds similar to my kexec stuff. Which I discuss at least part of the time on fastboot at osdl.org. It sounds compatible enough that we could productively merge implementations, that plus my kexec stuff is still on Andrew Morton todo list ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt means it has a fair shot of getting into the stock kernel. On a practical side I think I can boost it's priority high enough after I get back to actually do something. A recent version of kexec patch is at: http://developer.osdl.org/rddunlap/kexec/ Kexec as it is currently structured is actually two system calls callable from user space. sys_kexec_load() load the kernel into a linked list of pages, making certain that when those pages are copied to their final destination nothing will be stomped. And it allocates a chunk of memory with kmalloc for the bit of code that copies the kernel to it's final resting place. This can fail at any time and the system is in a consistent state. sys_reboot(LINUX_REBOOT_CMD_KEXEC) initiates the transfer to the new kernel. The new kernel is started in physical mode. sys_kexec_load() is passed an entry point to jump to, and an array of physical destination address, virtual process space address, and virtual length regions to load. Which allows us to load arbitrary things. The only requirement is that you have enough memory for both kernels simultaneously. For truly high end machines there are some other restrictions because physical mode does not allow access to all of their memory but anyway... From ebiederman at lnxi.com Sat Dec 20 13:11:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat Dec 20 13:11:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <20031219092135.GA27866@tsn.or.jp> References: <20031219005706.H66505-100000@www.missl.cs.umd.edu> <20031219092135.GA27866@tsn.or.jp> Message-ID: Takeshi Sone writes: > On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote: > > Adam Sulmicki writes: > > > > > you mean just like dosemu runs under linux ??? > > > > Right but for BSD and early versions of windows the dependencies > > were worse. I don't know which services matter though. > > Last time I saw the source code of FreeBSD, its _bootloader_ has its > own vm86 monitor (in assembly), works in protected mode, > and calls all the BIOS calls (video, keyboard, disk,...) in > vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86. > Also I saw a recent version of Windows calls BIOS services in vm86. > > Maybe we can modify FreeBSD, and have work-around for Windows, > but at least I don't think it's the way to go. > > My conclusion then was that PCBIOS had to work in real mode. > > Maybe we can code it with GCC and .code16gcc hack. > If 64KB is not enough, maybe 0xE000 segment can be used > so that we have 64KB code and 64KB data segments. > And all the "POST" code can be outside the real mode space. > So it's not impossible or hard at all. Ok Then I am up to idea #2. For cooperation, just before I go catch my flight. Implement a minimal but real PCBIOS. Have a linux kernel. Use the PCBIOS to initialize the option roms. Jump to the linux base boot loader. When I have loaded something I go to real mode with kexec and had off control to the loaded kernel. Which can make BIOS calls. I have traditionally avoided that because the PCBIOS tends to get wedged when I start linux but with the source that should not be a problem. Eric From rminnich at lanl.gov Sat Dec 20 13:18:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Dec 20 13:18:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On 20 Dec 2003, Eric W. Biederman wrote: > Ok Then I am up to idea #2. For cooperation, just before I go > catch my flight. here's what I would like: - we support all things bootable that don't need a pcbios linux, plan9, memtest, etc. - we encourage other projects to move away from needing a bios this is mainly xyzbsd - we use emulation for the option roms so that PPC and other non-x86 will work (this is almost done) - we provide (for those who want it) PCBIOS support as an option Making it optional allows vendors to build Windows-proof PCs, and I have had some interest expressed in that concept: if you are Windows-proof, you are audit-proof. A desriable property. we should really make PCBIOS an option of last resort. We should not plan for it as anything but a hack for OSes that are doing the wrong thing -- using a PCBIOS. ron From rminnich at lanl.gov Sat Dec 20 14:33:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Dec 20 14:33:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: Message-ID: On Sat, 20 Dec 2003, ron minnich wrote: > here's what I would like: > - we support all things bootable that don't need a pcbios > linux, plan9, memtest, etc. > - we encourage other projects to move away from needing a bios > this is mainly xyzbsd > - we use emulation for the option roms so that PPC and other non-x86 > will work (this is almost done) a bonus: these are all architecture-independent. > - we provide (for those who want it) PCBIOS support as an option And this is for legacy OSes and very architecture-dependent. ron From ve5jor at rac.ca Sat Dec 20 21:28:01 2003 From: ve5jor at rac.ca (Another Happy Linux User) Date: Sat Dec 20 21:28:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <200312201931.32599.ve5jor@rac.ca> Hi, When I read the part about being Windows-proof, I *really* liked that idea. Also, about the audit-proof aspect. Would built-in file encryption be a foolish thing to wish for some day? (Maybe when the chips are bigger?) Jorgen ve5jor at rac.ca ps This list is *very* informative, and I am grateful for having access to it. I wish my talents were greater, and especially more current, so that I could contribute. Thanks to all, in the list. Merry Christmas, & Happy Holidays to all. --------------------------------------------------------------------------- On Saturday 20 December 2003 11:21 am, ron minnich wrote: ...... - we provide (for those who want it) PCBIOS support as an option Making it optional allows vendors to build Windows-proof PCs, and I have had some interest expressed in that concept: if you are Windows-proof, you are audit-proof. A desriable property. we should really make PCBIOS an option of last resort. We should not plan for it as anything but a hack for OSes that are doing the wrong thing -- using a PCBIOS. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From joshua at joshuawise.com Sat Dec 20 21:44:00 2003 From: joshua at joshuawise.com (Joshua Wise) Date: Sat Dec 20 21:44:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <200312201931.32599.ve5jor@rac.ca> References: <200312201931.32599.ve5jor@rac.ca> Message-ID: <200312202148.28563.joshua@joshuawise.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > When I read the part about being Windows-proof, I *really* liked that idea. > Also, about the audit-proof aspect. I think it would also work well for "grandpa's box" - you know, boots from a read-only CF that starts X and Mozilla - he can't mess anything up, and it takes about 5 seconds to boot. > Would built-in file encryption be a foolish thing to wish for some day? > (Maybe when the chips are bigger?) Not really possible if hard drive access doesn't go through the BIOS. And our goal is to completely eradicate the BIOS. However it could be possible to have encryption for BIOS-bound OSen such as DOS, and require an "auth sector" be present on the boot media to allow access... > Jorgen > ve5jor at rac.ca /joshua - -- Joshua Wise | www.joshuawise.com GPG Key | 0xEA80E0B3 Quote | I akilled *@* by mistake In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/5Qn7Pn9tWOqA4LMRAs+wAJ9iDTHyj42cpmyS0xOpp3juHXA8kgCgiemb lHmO3eRpC25DvJjGmza/+bA= =Zsw+ -----END PGP SIGNATURE----- From rminnich at lanl.gov Sat Dec 20 22:45:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Dec 20 22:45:00 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: <200312201931.32599.ve5jor@rac.ca> Message-ID: On Sat, 20 Dec 2003, Another Happy Linux User wrote: > Would built-in file encryption be a foolish thing to wish for some day? > (Maybe when the chips are bigger?) we'll leave that in the hands of the kernel. ron kb2zcw From prl at peterlister.co.uk Sun Dec 21 18:28:01 2003 From: prl at peterlister.co.uk (Peter Lister) Date: Sun Dec 21 18:28:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <1072049499.4876.60.camel@eddie> On Fri, 2003-12-19 at 00:36, Eric W. Biederman wrote: > Brainstorming earlier today I think I have found a way to use > an linux kernel for the boot loader and to implement pcbios > compatibility without too much cost. The idea is to use > a uclinux kernel. And implement a ``user space'' aplication > that is a user space shim that makes kernel calls. > > There are a few nasty details to work out like how to handle > services that are expected to work in vm86 mode. But I'm > not certain I care. > > Other thoughts? Curse you, Eric, this was my idea. :) But I approached it from a different angle. Getting Etherboot (the driver library and higher level code) to export PXE - effectively Intel's retrofit of networking code into the legacy BIOS - is similar to exporting LinuxBIOS's hardware initialisation library and a non-trivial OS via PC BIOS services. If VMWare, bochs or whatever can do it as a user space process, then it can be done all of a pece in firmware, right? [For those of you not on etherboot-developers, I've waved my arms about recently at Eric, Ken Yap and others about how to resurrect the PXE code in Etherboot]. And yes, the "interesting" stuff is how to switch modes as appropriate and to sort out how to organise memory without frightening the horses. I'm on a very steep learning curve. And on the bottom of it, frankly. The only difference between us is that I was thinking of building this on eCos, not uclinux. eCos is designed to minimally load only those bits of functionality needed. I don't think this affects the basic idea. From prl at peterlister.co.uk Sun Dec 21 18:29:04 2003 From: prl at peterlister.co.uk (Peter Lister) Date: Sun Dec 21 18:29:04 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: Message-ID: <1072049521.4876.63.camel@eddie> On Fri, 2003-12-19 at 05:56, Eric W. Biederman wrote: > Regardless of the actual details what I like is the added requirement > that we attempt to support the legacy pcbios interface. It's ugly it's > nasty but if we can do that with a Linux kernel driving the hardware > we have a single solution which can work for everyone. Some people > can strip it down and not include all of the features but... Or - cf the PXE discussions on etherboot-developers - have the stripped version as the "normal" code and load in the pc bios services as required. Indeed, why not add a "legacy layer" to OSs which need it, so that rather than adding the code to the loader, add it to the *loadee*; the common services can be lean, mean, open source, virtualised or whatever we please. From kees at lunatix-linux.org Sun Dec 21 19:42:01 2003 From: kees at lunatix-linux.org (Kees Meijs) Date: Sun Dec 21 19:42:01 2003 Subject: Success stories Message-ID: <000901c3c825$b62db5e0$9601a8c0@kees> Hello there, I'd like to flash my ChainTech motherboard with a Linux kernel or just grub. Did anyone did this before? And if so, how did you do it? Cheers, Kees P.S. It's a pity the documentation on the web is very sparse, maybe I can write some? From gwatson at lanl.gov Sun Dec 21 19:51:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Sun Dec 21 19:51:01 2003 Subject: IDEA: Linux kernel and pcbios compatibility... In-Reply-To: References: <20031219135615.GA14339@suse.de> Message-ID: At 2:02 PM -0700 12/19/03, Eric W. Biederman wrote: > > >Any interest in porting kexec to the ppc? It is not strictly required >if you can get your kernel to avoid the memory problem but it is quite >useful. Yes. I want to do the two kernel monte thing on the PPC. Another thing on the todo list. Greg From rsmith at bitworks.com Mon Dec 22 12:05:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon Dec 22 12:05:01 2003 Subject: Tiny linux In-Reply-To: <1072049521.4876.63.camel@eddie> References: <1072049521.4876.63.camel@eddie> Message-ID: <3FE72505.1090804@bitworks.com> Has anyone tried this to see how small it compiles down to? Probally won't ever get as small as uclinux but might be useable for somebody. http://lwn.net/Articles/62858/ -- Richard A. Smith rsmith at bitworks.com From ebiederman at lnxi.com Mon Dec 22 16:27:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Dec 22 16:27:01 2003 Subject: Tiny linux In-Reply-To: <3FE72505.1090804@bitworks.com> References: <1072049521.4876.63.camel@eddie> <3FE72505.1090804@bitworks.com> Message-ID: Richard Smith writes: > Has anyone tried this to see how small it compiles down to? Probally won't ever > > get as small as uclinux but might be useable for somebody. > > http://lwn.net/Articles/62858/ uclinux is in the same source tree. It looks like they have patches to compile out all of the recent bloat. If the maintenance continues it looks very promising. But I'm on vacataion at the moment so someone else gets to be the ginny pig. Eric From ijpriya at hotmail.com Mon Dec 22 22:01:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Mon Dec 22 22:01:00 2003 Subject: Flash mapped to lower address? Message-ID: If i have my Flash memory mapped to the lower address (0x0000-0x3FFFFF), then what modification should be made to linux bios? _________________________________________________________________ NRI?s, Free Money transfer to India. http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp?type=hottag Click here. From ebiederman at lnxi.com Tue Dec 23 12:29:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Dec 23 12:29:01 2003 Subject: Flash mapped to lower address? In-Reply-To: References: Message-ID: "Devi Priya" writes: > If i have my Flash memory mapped to the lower address > (0x0000-0x3FFFFF), then what modification should be made to linux bios? If this is x86 and that is your only flash address then you can't boot. x86 cpus start at address 0xfffffff0. Unless there are some embedded variants I am not familiar with. If this is ARM where flash is normally mapped to 0 that makes sense but currently we don't have an arm port. I don't think it would be too difficult though. So I really can't answer without more information. Eric From dwh at lanl.gov Tue Dec 23 18:13:00 2003 From: dwh at lanl.gov (Hendricks David W.) Date: Tue Dec 23 18:13:00 2003 Subject: Success stories Message-ID: Can you be more specific about your mainboard? Chaintech makes dozens of models. Copy / paste your lspci output if possible. From kees at lunatix-linux.org Wed Dec 24 05:26:00 2003 From: kees at lunatix-linux.org (Kees Meijs) Date: Wed Dec 24 05:26:00 2003 Subject: Success stories References: Message-ID: <000b01c3ca09$a259dae0$9601a8c0@kees> Dear David, It's all about a ChainTech 7AJA2 ATX mainboard. Here's the lspci listing: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:10.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00f2 (rev 01) 00:11.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] 00:13.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV280 [Radeon 9200] (rev 01) 01:00.1 Display controller: ATI Technologies Inc: Unknown device 5941 (rev 01) Thank you in advance and a merry Christmas to all list members! Cheers, Kees From ssingh at totalise.co.uk Wed Dec 24 13:44:01 2003 From: ssingh at totalise.co.uk (Surjan Singh) Date: Wed Dec 24 13:44:01 2003 Subject: EPIA + non-standard flash chip In-Reply-To: <20031223170001.7686.80158.Mailman@nwn.definitive.org> Message-ID: <000a01c3ca4e$94fe00c0$29060a0a@i8000> Hello, Wondering if anyone can help me with this one: I have a basic EPIA board (http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21) , the one with the 533MHz CPU. Anyway, I managed to find myself a PLCC Flash chip which seems like it will work (http://www.farnell.com/datasheets/23247.pdf), but when I run the flash program it complains that it does not recognise the chip. So, I added an entry for the chip in "flash.h" hoping I could use the regular routines for the EPIA, but it says it cannot unlock the chip. Can someone help me with this one pls? Could someone supply a diff, using the above datasheet, that would enable me to use the chip? Even some tips on what I'd need to do if I had to write the code would be appreciated. Thanks, Surj From dwh at lanl.gov Wed Dec 24 16:52:01 2003 From: dwh at lanl.gov (Hendricks David W.) Date: Wed Dec 24 16:52:01 2003 Subject: EPIA + non-standard flash chip In-Reply-To: <000a01c3ca4e$94fe00c0$29060a0a@i8000> Message-ID: You might want to try Linux MTD (Look in the kernel or http://www.linux-mtd.infradead.org/ ) if you're using flash_n_burn. On Wed, 24 Dec 2003, Surjan Singh wrote: > Hello, > > Wondering if anyone can help me with this one: > > I have a basic EPIA board > (http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21) > , the one with the 533MHz CPU. > > Anyway, I managed to find myself a PLCC Flash chip which seems like it > will work (http://www.farnell.com/datasheets/23247.pdf), but when I run > the flash program it complains that it does not recognise the chip. So, > I added an entry for the chip in "flash.h" hoping I could use the > regular routines for the EPIA, but it says it cannot unlock the chip. > > Can someone help me with this one pls? Could someone supply a diff, > using the above datasheet, that would enable me to use the chip? Even > some tips on what I'd need to do if I had to write the code would be > appreciated. > > Thanks, > Surj > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Wed Dec 24 20:35:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 24 20:35:01 2003 Subject: Flash mapped to lower address? In-Reply-To: Message-ID: On Tue, 23 Dec 2003, Devi Priya wrote: > If i have my Flash memory mapped to the lower address (0x0000-0x3FFFFF), > then what modification should be made to linux bios? why on earth would you map flash to this address? it makes no sense to me. ron From bari at onelabs.com Thu Dec 25 19:39:01 2003 From: bari at onelabs.com (Bari Ari) Date: Thu Dec 25 19:39:01 2003 Subject: Flash mapped to lower address? In-Reply-To: References: Message-ID: <3FEB84E2.7040509@onelabs.com> Devi Priya wrote: > If i have my Flash memory mapped to the lower address (0x0000-0x3FFFFF), > then what modification should be made to linux bios? > If you have you Flash mapped to 0x0000 - 0x3FFFF then you can't use your Flash as a Boot Device since the "SCx200 Core Logic module positively decodes memory addresses 000F0000h-000FFFFFh (64 KB) and FFFC0000h-FFFFFFFFh (256 KB) at reset". Why don't you just get the application note "AMD Geode? SC1200/SC2200/ SC3200 Processors: External NAND Flash Memory Circuit" and the Geode data sheet from AMD? They explain how all this works. -Bari From ijpriya at hotmail.com Fri Dec 26 21:33:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Fri Dec 26 21:33:00 2003 Subject: Flash mapped to lower address? Message-ID: Hi, From bari at onelabs.com Fri Dec 26 21:40:00 2003 From: bari at onelabs.com (Bari Ari) Date: Fri Dec 26 21:40:00 2003 Subject: Flash mapped to lower address? In-Reply-To: References: Message-ID: <3FECF255.6010600@onelabs.com> Devi Priya wrote: > If i have my Flash memory mapped to the lower address (0x0000-0x3FFFFF), > then what modification should be made to linux bios? Are you using NAND Flash or DOC or both ? Are you trying to boot from the DOC? You may also want to look at the Geode? IA on a Chip Devices: Booting from the M-Systems DiskOnChip Millennium Application Note http://www.m-sys.com/files/documentation/doc/App_Note_047_Des_DOC_FD_Boot_Rev1.0.pdf http://www.m-sys.com/files/documentation/doc/App_Note_031_PC_Rev_2.2.pdf -Bari From bari at onelabs.com Fri Dec 26 22:31:01 2003 From: bari at onelabs.com (Bari Ari) Date: Fri Dec 26 22:31:01 2003 Subject: Flash mapped to lower address? In-Reply-To: References: Message-ID: <3FECFEA6.7010708@onelabs.com> Devi Priya wrote: > I like to use either Flash memory or DOC and not both. I want to know if > I have my Flash memory or DOC mapped to lower address what modification > should I do to the linuxbios coding. like regarding setiing the RAMBASE, > ROMBASE........... > The power-up reset address for the Geode is FFFFFFF0h, you can't change that. Your only strapping options are: (1) Enable either an 8 bit or 16 bit boot ROM access (2) Enable either a LPC or ISA boot ROM access. -Bari > Regards, > Priya. > > >> From: Bari Ari >> To: Devi Priya >> CC: linuxbios at clustermatic.org >> Subject: Re: Flash mapped to lower address? >> Date: Fri, 26 Dec 2003 20:45:41 -0600 >> >> >> >> Devi Priya wrote: >> >>> If i have my Flash memory mapped to the lower address >>> (0x0000-0x3FFFFF), then what modification should be made to linux bios? >> >> >> Are you using NAND Flash or DOC or both ? Are you trying to boot from >> the DOC? >> >> You may also want to look at the >> >> Geode? IA on a Chip Devices: Booting from the M-Systems DiskOnChip >> Millennium Application Note >> >> http://www.m-sys.com/files/documentation/doc/App_Note_047_Des_DOC_FD_Boot_Rev1.0.pdf >> >> >> http://www.m-sys.com/files/documentation/doc/App_Note_031_PC_Rev_2.2.pdf >> >> -Bari >> >> >> >> _______________________________________________ >> Linuxbios mailing list >> Linuxbios at clustermatic.org >> http://www.clustermatic.org/mailman/listinfo/linuxbios > > > _________________________________________________________________ > NRI?s, Free Money transfer to India. > http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp?type=hottag > Click here. > > > From ijpriya at hotmail.com Sun Dec 28 23:52:00 2003 From: ijpriya at hotmail.com (Devi Priya) Date: Sun Dec 28 23:52:00 2003 Subject: Filesystem for DOCM? Message-ID: Hi, Which file system should I use for diskonchip millennium while using with linuxbios? _________________________________________________________________ Free transactions in any ATM across India. http://server1.msn.co.in/msnleads/suvidha/dec03.asp?type=hottag Click here. From stepan at suse.de Mon Dec 29 05:36:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Dec 29 05:36:01 2003 Subject: Filesystem for DOCM? In-Reply-To: References: Message-ID: <20031229104137.GA9076@suse.de> * Devi Priya [031229 05:57]: > Hi, > Which file system should I use for diskonchip millennium while using > with linuxbios? Depends. If you just put a kernel and an initrd in flash you don't want a filesystem at all. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From adam at megacz.com Mon Dec 29 15:42:00 2003 From: adam at megacz.com (Adam Megacz) Date: Mon Dec 29 15:42:00 2003 Subject: ide emulation based on network block device for arbitrary OSes? Message-ID: I've heard that you can use LinuxBIOS to bootload other operating systems (like Windows, etc). Is it possible for LinuxBIOS to boot the device and install a block of code in memory that handles BIOS disk requests using some sort of network block device protocol? Failing this, does anybody know of a cheap hardware device that would do the same thing? Thanks. - a -- "If Darl McBride [the CEO of SCO, who claims the GPL 'destroys intellectual property'] was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution" -- Linus Torvalds From rminnich at lanl.gov Wed Dec 31 12:03:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 31 12:03:01 2003 Subject: Filesystem for DOCM? In-Reply-To: Message-ID: On Mon, 29 Dec 2003, Devi Priya wrote: > Which file system should I use for diskonchip millennium while using > with linuxbios? it makes no difference, since linuxbios does not care. ron From rminnich at lanl.gov Wed Dec 31 12:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Dec 31 12:15:01 2003 Subject: ide emulation based on network block device for arbitrary OSes? In-Reply-To: Message-ID: On Mon, 29 Dec 2003, Adam Megacz wrote: > > I've heard that you can use LinuxBIOS to bootload other operating > systems (like Windows, etc). Is it possible for LinuxBIOS to boot the > device and install a block of code in memory that handles BIOS disk > requests using some sort of network block device protocol? ouch. What is the motivation? thanks ron