From dkotian3 at vsnl.net Thu May 1 00:54:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 00:54:01 2003 Subject: Generate a config file on LinuxBIOS site Message-ID: <20030501060212.226F25008E@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From dkotian3 at vsnl.net Thu May 1 01:03:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 01:03:01 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS Message-ID: <20030501061137.7005F500B8@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From rminnich at lanl.gov Thu May 1 02:09:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 02:09:00 2003 Subject: ADLO is GO In-Reply-To: <20030430205053.P54030-100000@www.missl.cs.umd.edu> Message-ID: ok, richard, how about a HOWTO? ron From rminnich at lanl.gov Thu May 1 02:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 02:15:01 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS In-Reply-To: <20030501061137.7005F500B8@bom6.vsnl.net.in> Message-ID: On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > Basically, I have to put the etherboot payload and LinuxBIOS on > 256K/512K FLASH ROMS and the Linux kernel image(2.4.18-3) > and application on Compact Flash ide. > Some kind of HOWTO/experience from many who have tried > etherboot in this situation. target pcm-5823 mainboard advantech/pcm-5823 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 option TTYS0_BAUD=38400 option DEFAULT_CONSOLE_LOGLEVEL=9 option DEBUG option RAMTEST=1 option USE_GENERIC_ROM=1 option USE_ELF_BOOT=1 option ROM_SIZE=262144 option STD_FLASH=1 #payload ../elfImage.9load payload ../eepro100.ebi option PAYLOAD_SIZE=196608 === This will build a 256K linuxbios with etherboot in it. Get an etherboot that will load from IDE. To get your payload on CF: First, you MUST fdisk the CF. Make the whole thing a DOS partition, doesn't matter. I have found the hard way that for some reason etherboot will not work right unless the CF has a partition table on it. I have not followed the whole thing through and I assume it is a need for C/H/S info that is not there without a partition table or some such. Then mkelfImage on the kernel of choice. Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 That's what I do. ron From dkotian3 at vsnl.net Thu May 1 03:36:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 03:36:01 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS Message-ID: <20030501084428.387F24FFF3@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From ts1 at cma.co.jp Thu May 1 04:00:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 1 04:00:00 2003 Subject: errors compiling the vga bios stuff In-Reply-To: References: <3EB00B70.5020505@bitworks.com> Message-ID: <20030501083434.GA6304@cma.co.jp> On Wed, Apr 30, 2003 at 01:41:31PM -0600, ron minnich wrote: > Second, as regards VGA, no build errors here. Here is my .config for an > epia. See the last two lines. And vgabios.o and idt.o get build and linked > in. Is this config for VGA stuff supposed to "work" on EPIA? Or just a test to build? > # > # LinuxBIOS config file for: VIA epia mini-itx > # > > target epia > > # via epia > mainboard via/epia > > # Enable Serial Console for debugging > option SERIAL_CONSOLE=1 > option TTYS0_BAUD=115200 > option DEFAULT_CONSOLE_LOGLEVEL=9 > option DEBUG=1 > > # Use 256KB Standard Flash as Normal BIOS > option RAMTEST=1 > option USE_GENERIC_ROM=1 > option STD_FLASH=1 > #option ZKERNEL_START=0xfffc0000 > option ROM_SIZE=262144 > > # payload size = 192KB > option PAYLOAD_SIZE=196608 > > # use ELF Loader to load Etherboot > option USE_ELF_BOOT=1 > > # Use Etherboot as our payload > payload ../lnxieepro100.ebi > > option CONFIG_VGABIOS=1 > option CONFIG_REALMODE_IDT=1 -- Takeshi From dkotian3 at vsnl.net Thu May 1 05:23:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 05:23:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts Message-ID: <20030501103101.435864FE16@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From CHall at optos.com Thu May 1 05:43:00 2003 From: CHall at optos.com (Colin Hall) Date: Thu May 1 05:43:00 2003 Subject: Test post without confidentiality disclaimer (was RE: Debugging t he linuxBIOS code) Message-ID: This is a test posting. > > Please do not send confidential email to public mailing lists. > > > //Peter > In response to Peter and Gregg's posts my sys admin has reconfigured our corporate mail server so that posts from me to this forum are free of confidentiality disclaimers. Hopefully this posting will not contain the automatically appended disclaimer. Thanks for your patience. Regards, Colin. From nhan.ngodinh at dilogix.it Thu May 1 07:53:01 2003 From: nhan.ngodinh at dilogix.it (Nhan NGO DINH) Date: Thu May 1 07:53:01 2003 Subject: southbridge vt82c686 Message-ID: <5.2.0.9.2.20030501142413.00a39070@mail.dilogix.it> Greetings, With the latest CVS I have problems with the support for the southbridge in subject. Here is a part of the make output: === gcc ... -o southbridge.o /usr/src/freebios/src/southbridge/via/vt82c686/southbri dge.c /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c: In function `keybo ard_on': /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:32: warning: passin g arg 3 of `pci_read_config_byte' discards qualifiers from pointer target type /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:48: warning: passin g arg 3 of `pci_read_config_byte' discards qualifiers from pointer target type /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c: In function `south bridge_fixup': /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:83: warning: implic it declaration of function `memcpy' /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:96: `devfn' undecla red (first use in this function) /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:96: (Each undeclare d identifier is reported only once /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:96: for each functi on it appears in.) /usr/src/freebios/src/southbridge/via/vt82c686/southbridge.c:96: too many argume nts to function `pci_write_config_byte' make: *** [southbridge.o] Error 1 === At line 96, there is a wrong parameters count for pci_write_config_byte function. Any suggestions? Bye. Nhan NGO DINH From public at demiansinclair.com Thu May 1 08:43:00 2003 From: public at demiansinclair.com (demian sinclair) Date: Thu May 1 08:43:00 2003 Subject: not sure what to do next Message-ID: <20030501081828.7f4fdb7e.public@demiansinclair.com> I followed this howto: http://www.linuxbios.org/developer/portguides/M810LR/ but used the config for the m758lmr+ I am running debian woody and I used 2.4.19 for the kernel. It looked like it flashed the diskonchip ok, here is the output: rmmod: module docprobe is not loaded rmmod: module doc2001 is not loaded rmmod: module docecc is not loaded 16+1 records in 17+0 records out 0+1 records in 1+0 records out Erase Total 1024 Units 1+0 records in 1+0 records out 1+0 records in 1+0 records out 126+0 records in 126+0 records out 2176+0 records in 2176+0 records out docecc: Device or resource busy The modules weren't unloaded though - here is lsmod: Module Size Used by Not tainted doc2000 10756 0 (autoclean) nand_ids 920 0 [doc2000] mtdcore 2592 1 [doc2000] docecc 3680 0 [doc2000] So I rebooted and nothing. I connected a serial cable and nothing. Any ideas for me? Perhaps I am not using minicom correctly? I set it to use /dev/ttyS0 with 115200 8N1 do I need to do anything else? Sorry for the beginner questions - please educate me! -DS From agnew at cs.umd.edu Thu May 1 09:41:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 1 09:41:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts In-Reply-To: <20030501103101.435864FE16@bom6.vsnl.net.in> Message-ID: <20030501102229.Q55309-100000@www.missl.cs.umd.edu> etherboot-5.0.9 is NOT supposed to work. you want etherboot-5.0.6 probably and the patch against it at http://www.missl.cs.umd.edu/~agnew/ On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > Hi, > > I have tried etherboot on my machine which has > Compact Flash IDE and FLASHROMS(256K/512K). Not > successful.. > The payload I got was from etherboot-5.0.9, which is > rtl8139.ebi which is my ethernet chip. > > Did an Compact flash.. > fdisk /dev/hdc, created 2 partions hdc1 and hdc2, both > of ext3 type. > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > Set these parameters in my config file. > option RAMTEST=1 > option USE_GENERIC_ROM=1 > option USE_ELF_BOOT=1 > option ROM_SIZE=524288 > option STD_FLASH=1 > > #payload ../elfImage.9load > payload ../rtl8139.ebi > option PAYLOAD_SIZE=196608 > > burned the romimage using the uniflash tool. > > It seems to have found the elfimage, but just restarts all over > again, could someone please spot what could be > the problem and the solution to it. > Any help on this would really nice. Please find the log > below. > > **********Error Log start**** > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > Ram1 > Ram2 > Ram3 > Ram Enable 1 > Ram Enable 2 > Ram Enable 3 > Ram Enable 4 > Ram Enable 5 > Ram4 > Ram5 > Ram6 > Copying LinuxBIOS to ram. > Jumping to LinuxBIOS. > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 booting... > Finding PCI configuration type. > PCI: Using configuration type 1 > handle_superio start, nsuperio 1 > handle_superio Pass 0, check #0, s 00009680 s->super 0000a97c > handle_superio: Pass 0, Superio w83627hf > handle_superio port 0x0, defaultport 0x2e > handle_superio Using port 0x2e > handle_superio Pass 0, done #0 > handle_superio done > Scanning PCI bus...PCI: pci_scan_bus for bus 0 > PCI: 00:00.0 [8086/7124] > PCI: 00:1e.0 [8086/2418] > PCI: 00:1f.0 [8086/2410] > PCI: 00:1f.1 [8086/2411] > PCI: 00:1f.2 [8086/2412] > PCI: 00:1f.3 [8086/2413] > PCI: 00:1f.5 [8086/2415] > PCI: 00:1f.6 [8086/2416] > PCI: pci_scan_bus for bus 1 > PCI: 01:04.0 [10ec/8139] > PCI: 01:05.0 [10ec/8139] > PCI: pci_scan_bus returning with max=01 > PCI: pci_scan_bus returning with max=01 > done > Allocating PCI resources... > ASSIGN RESOURCES, bus 0 > PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io > PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem > PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem > ASSIGN RESOURCES, bus 1 > PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io > PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem > PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io > PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem > ASSIGNED RESOURCES, bus 1 > PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io > PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io > PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io > PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io > PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io > PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io > PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io > ASSIGNED RESOURCES, bus 0 > done. > Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 > PCI: 00:1e.0 cmd <- 07 > PCI: 00:1f.0 cmd <- 0f > PCI: 00:1f.1 cmd <- 01 > PCI: 00:1f.2 cmd <- 01 > PCI: 00:1f.3 cmd <- 01 > PCI: 00:1f.5 cmd <- 01 > PCI: 00:1f.6 cmd <- 01 > PCI: 01:04.0 cmd <- 03 > PCI: 01:05.0 cmd <- 03 > done. > Initializing PCI devices... > PCI devices initialized > DRP0 = 0x9 > DIMM0 - size = 64M > DIMM1 - size = 0M > DRP1 = 0x0 > DIMM2 - size = 0M > totalram: 64M > Initializing CPU #0 > Updating microcode > microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 > 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: 64MB, 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 : 0x07 > Processor Mask : 0x00 > Processor Stepping : 0x08 > Feature flags : 0x00803035 > > > MTRR check > Fixed MTRRs : Enabled > Variable MTRRs: Enabled > > Configuring L2 cache...Not 'GenuineIntel' Processor > Enable Cache > done. > Disabling local apic...done. > CPU #0 Initialized > ioapic southbridge enabled 180 > RTC Init > Invalid CMOS LB checksum > set power on after power fail > Please turn on nvram > handle_superio start, nsuperio 1 > handle_superio Pass 1, check #0, s 00009680 s->super 0000a97c > handle_superio: Pass 1, Superio w83627hf > handle_superio port 0x2e, defaultport 0x2e > handle_superio Using port 0x2e > Call init > Enabling com device: 03 > iobase = 0x02f8 irq=3 > handle_superio Pass 1, done #0 > handle_superio done > handle_superio start, nsuperio 1 > handle_superio Pass 2, check #0, s 00009680 s->super 0000a97c > handle_superio: Pass 2, Superio w83627hf > handle_superio port 0x2e, defaultport 0x2e > handle_superio Using port 0x2e > handle_superio Pass 2, done #0 > handle_superio done > Wrote linuxbios table at: 00000500 - 00000648 checksum 268b > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.2 > > 203:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000007f > Searching for 16 byte tags > 64:rom_read_bytes() - overflowed source buffer. max_block = 3 > init_bytes found 0 tags > Initialized controller... > Read completed... > scanning elf header... > Found ELF candiate at offset 0 > scan complete... > header_offset is 0 > calling elf load... > New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 filesz: 0x00 > 000000000038d4 > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > Jumping to boot code at 0x94000 > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > Ram1 > Ram2 > .... > **********Error Log end**** > > Thanks and Regards > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From dkotian3 at vsnl.net Thu May 1 10:24:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 10:24:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts Message-ID: <20030501153242.29F6D4FE52@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From dkotian3 at vsnl.net Thu May 1 10:35:00 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 1 10:35:00 2003 Subject: Etherboot boot problem after jumping to boot code it restarts Message-ID: <20030501154325.AF5044FEB8@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From rsmith at bitworks.com Thu May 1 10:42:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 10:42:00 2003 Subject: ADLO is GO Message-ID: <3EB13A17.6070303@bitworks.com> > ok, richard, how about a HOWTO? > Over the last 2 weeks.. I've been building a FAQ/HOWTO from my own experience + stuff that has been coming across the list. I'm updateing it for ADLO now. Then I'll release the pre-alpha version to the list. -- Richard A. Smith rsmith at bitworks.com From agnew at cs.umd.edu Thu May 1 10:42:09 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 1 10:42:09 2003 Subject: Etherboot boot problem after jumping to boot code it restarts In-Reply-To: <20030501154325.AF5044FEB8@bom6.vsnl.net.in> Message-ID: <20030501112225.K55309-100000@www.missl.cs.umd.edu> What's in that patch is my config files. You can make a valid elf-boot image from that version of etherboot with "make bin32/sis900.ebi" and then use that as your payload. From what you're showing me below, it looks like you're not using a valid payload and the system is resetting. See how the very end looks like the very beginning? That's because your system rebooted itself. On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > Sorry, this may also help. > Probably, you may also like to share the procedure > of your etherboot for my case and also > the share the config file. > It would be good help for me.. > > > > Regards > Deepak > > > agnew at cs.umd.edu wrote > etherboot-5.0.9 is NOT supposed to work. you want etherboot-5.0.6 > probably and the patch against it at http://www.missl.cs.umd.edu/~agnew/ > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > Hi, > > > > I have tried etherboot on my machine which has > > Compact Flash IDE and FLASHROMS(256K/512K). Not > > successful.. > > The payload I got was from etherboot-5.0.9, which is > > rtl8139.ebi which is my ethernet chip. > > > > Did an Compact flash.. > > fdisk /dev/hdc, created 2 partions hdc1 and hdc2, both > > of ext3 type. > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > > > Set these parameters in my config file. > > option RAMTEST=1 > > option USE_GENERIC_ROM=1 > > option USE_ELF_BOOT=1 > > option ROM_SIZE=524288 > > option STD_FLASH=1 > > > > #payload ../elfImage.9load > > payload ../rtl8139.ebi > > option PAYLOAD_SIZE=196608 > > > > burned the romimage using the uniflash tool. > > > > It seems to have found the elfimage, but just restarts all over > > again, could someone please spot what could be > > the problem and the solution to it. > > Any help on this would really nice. Please find the log > > below. > > > > **********Error Log start**** > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > Ram1 > > Ram2 > > Ram3 > > Ram Enable 1 > > Ram Enable 2 > > Ram Enable 3 > > Ram Enable 4 > > Ram Enable 5 > > Ram4 > > Ram5 > > Ram6 > > Copying LinuxBIOS to ram. > > Jumping to LinuxBIOS. > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 booting... > > Finding PCI configuration type. > > PCI: Using configuration type 1 > > handle_superio start, nsuperio 1 > > handle_superio Pass 0, check #0, s 00009680 s->super 0000a97c > > handle_superio: Pass 0, Superio w83627hf > > handle_superio port 0x0, defaultport 0x2e > > handle_superio Using port 0x2e > > handle_superio Pass 0, done #0 > > handle_superio done > > Scanning PCI bus...PCI: pci_scan_bus for bus 0 > > PCI: 00:00.0 [8086/7124] > > PCI: 00:1e.0 [8086/2418] > > PCI: 00:1f.0 [8086/2410] > > PCI: 00:1f.1 [8086/2411] > > PCI: 00:1f.2 [8086/2412] > > PCI: 00:1f.3 [8086/2413] > > PCI: 00:1f.5 [8086/2415] > > PCI: 00:1f.6 [8086/2416] > > PCI: pci_scan_bus for bus 1 > > PCI: 01:04.0 [10ec/8139] > > PCI: 01:05.0 [10ec/8139] > > PCI: pci_scan_bus returning with max=01 > > PCI: pci_scan_bus returning with max=01 > > done > > Allocating PCI resources... > > ASSIGN RESOURCES, bus 0 > > PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io > > PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem > > PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem > > ASSIGN RESOURCES, bus 1 > > PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io > > PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem > > PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io > > PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem > > ASSIGNED RESOURCES, bus 1 > > PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io > > PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io > > PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io > > PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io > > PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io > > PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io > > PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io > > ASSIGNED RESOURCES, bus 0 > > done. > > Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 > > PCI: 00:1e.0 cmd <- 07 > > PCI: 00:1f.0 cmd <- 0f > > PCI: 00:1f.1 cmd <- 01 > > PCI: 00:1f.2 cmd <- 01 > > PCI: 00:1f.3 cmd <- 01 > > PCI: 00:1f.5 cmd <- 01 > > PCI: 00:1f.6 cmd <- 01 > > PCI: 01:04.0 cmd <- 03 > > PCI: 01:05.0 cmd <- 03 > > done. > > Initializing PCI devices... > > PCI devices initialized > > DRP0 = 0x9 > > DIMM0 - size = 64M > > DIMM1 - size = 0M > > DRP1 = 0x0 > > DIMM2 - size = 0M > > totalram: 64M > > Initializing CPU #0 > > Updating microcode > > microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 > > 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: 64MB, 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 : 0x07 > > Processor Mask : 0x00 > > Processor Stepping : 0x08 > > Feature flags : 0x00803035 > > > > > > MTRR check > > Fixed MTRRs : Enabled > > Variable MTRRs: Enabled > > > > Configuring L2 cache...Not 'GenuineIntel' Processor > > Enable Cache > > done. > > Disabling local apic...done. > > CPU #0 Initialized > > ioapic southbridge enabled 180 > > RTC Init > > Invalid CMOS LB checksum > > set power on after power fail > > Please turn on nvram > > handle_superio start, nsuperio 1 > > handle_superio Pass 1, check #0, s 00009680 s->super 0000a97c > > handle_superio: Pass 1, Superio w83627hf > > handle_superio port 0x2e, defaultport 0x2e > > handle_superio Using port 0x2e > > Call init > > Enabling com device: 03 > > iobase = 0x02f8 irq=3 > > handle_superio Pass 1, done #0 > > handle_superio done > > handle_superio start, nsuperio 1 > > handle_superio Pass 2, check #0, s 00009680 s->super 0000a97c > > handle_superio: Pass 2, Superio w83627hf > > handle_superio port 0x2e, defaultport 0x2e > > handle_superio Using port 0x2e > > handle_superio Pass 2, done #0 > > handle_superio done > > Wrote linuxbios table at: 00000500 - 00000648 checksum 268b > > > > Welcome to elfboot, the open sourced starter. > > January 2002, Eric Biederman. > > Version 1.2 > > > > 203:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000007f > > Searching for 16 byte tags > > 64:rom_read_bytes() - overflowed source buffer. max_block = 3 > > init_bytes found 0 tags > > Initialized controller... > > Read completed... > > scanning elf header... > > Found ELF candiate at offset 0 > > scan complete... > > header_offset is 0 > > calling elf load... > > New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 filesz: 0x00 > > 000000000038d4 > > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > > Jumping to boot code at 0x94000 > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > Ram1 > > Ram2 > > .... > > **********Error Log end**** > > > > Thanks and Regards > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Thu May 1 10:55:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 10:55:01 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS In-Reply-To: <20030501084428.387F24FFF3@bom6.vsnl.net.in> Message-ID: On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > Thanks. > Do we need to set any of these options as well in this case > option BOOT_IDE=1 > option IDE_BOOT_DRIVE=2 > option ONE_TRACK=32 well, rather than doing that, why don't you do a config with this config file and see how those options are set. And do some experimentation. There is no substitute for doing the work with this type of system -- you'll never learn anything otherwise. ron From rminnich at lanl.gov Thu May 1 10:55:14 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 10:55:14 2003 Subject: errors compiling the vga bios stuff In-Reply-To: <20030501083434.GA6304@cma.co.jp> Message-ID: On Thu, 1 May 2003, SONE Takeshi wrote: > Is this config for VGA stuff supposed to "work" on EPIA? > Or just a test to build? just a test to build. ron From rminnich at lanl.gov Thu May 1 10:58:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 10:58:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts In-Reply-To: <20030501103101.435864FE16@bom6.vsnl.net.in> Message-ID: On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > The payload I got was from etherboot-5.0.9, which is > rtl8139.ebi which is my ethernet chip. how is that going to work with compact flash? I may have led you astray but I though I told you to get a payload from etherboot that would load over ide. What motherboard are you using? You're getting close, though, so congratulations! ron From rminnich at lanl.gov Thu May 1 11:01:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 11:01:01 2003 Subject: southbridge vt82c686 In-Reply-To: <5.2.0.9.2.20030501142413.00a39070@mail.dilogix.it> Message-ID: we'll have to find out who broke it; I saw some commits fly by but didn't watch them closely enough. thanks ron From rminnich at lanl.gov Thu May 1 11:12:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 11:12:00 2003 Subject: not sure what to do next In-Reply-To: <20030501081828.7f4fdb7e.public@demiansinclair.com> Message-ID: I don't think it burned. Something went wrong in setting up docecc. Once you do burn it, you should dd if=/dev/mt0 | cmp -l - your_flash_file see if they match. ron From public at demiansinclair.com Thu May 1 11:58:00 2003 From: public at demiansinclair.com (demian sinclair) Date: Thu May 1 11:58:00 2003 Subject: not sure what to do next In-Reply-To: References: <20030501111029.1c007352.public@demiansinclair.com> Message-ID: <20030501113253.698ff650.public@demiansinclair.com> On Thu, 1 May 2003 10:16:24 -0600 (MDT) ron minnich wrote: > On Thu, 1 May 2003, demian sinclair wrote: > > > am I supposed to have a single build image? > > I thought docipl linuxbios.block and bmlinux.bin.gz.block were the > > files that were burned? > > those get concatenated into the romimage file. > > Make sure they are getting concatenated and take it from there. > > Andrew, do you have a confile file that works with DoC that you can > send to demian as a model. > > ron > You were right, I compared the files and it looks like it didn't burn. Since I have all of about 2 days experience with mtd where should i go next to figure out why id didn't burn. modprobe docprobe does detect the chip properly. Also, if anyone has a working local boot config file for the m758lmr plz send it my way! Thanks everyone, DS From rminnich at lanl.gov Thu May 1 12:05:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 12:05:00 2003 Subject: not sure what to do next In-Reply-To: <20030501113253.698ff650.public@demiansinclair.com> Message-ID: On Thu, 1 May 2003, demian sinclair wrote: > Since I have all of about 2 days experience with mtd where should i go > next to figure out why id didn't burn. > modprobe docprobe does detect the chip properly. let's hope dave woodhouse is still reading the list and will tell you what went wrong. I have not done DoC for more than a year so am not current with the problems. ron From dkotian3 at vsnl.net Thu May 1 13:50:00 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Thu May 1 13:50:00 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS References: Message-ID: <000101c3100e$26cf1d00$223e41db@vsnl.net> Got it. I thought there is a standard procedure for etherboot in these situtation. I am checking out various combination and will continue to do that... Thanks Regards Deepak ----- Original Message ----- From: "ron minnich" To: Cc: Sent: Thursday, May 01, 2003 8:58 PM Subject: Re: Experiences on Etherboot for IDE Compact flash and FLASHROMS > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > Thanks. > > Do we need to set any of these options as well in this case > > option BOOT_IDE=1 > > option IDE_BOOT_DRIVE=2 > > option ONE_TRACK=32 > > well, rather than doing that, why don't you do a config with this config > file and see how those options are set. And do some experimentation. There > is no substitute for doing the work with this type of system -- you'll > never learn anything otherwise. > > > ron > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From stepan at suse.de Thu May 1 14:08:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu May 1 14:08:00 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS In-Reply-To: ; from rminnich@lanl.gov on Thu, May 01, 2003 at 12:48:54AM -0600 References: <20030501061137.7005F500B8@bom6.vsnl.net.in> Message-ID: <20030501204315.A27078@suse.de> * ron minnich [030501 08:48]: > Then mkelfImage on the kernel of choice. > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > should be seek, not skip i think: seek=BLOCKS skip BLOCKS obs-sized blocks at start of output skip=BLOCKS skip BLOCKS ibs-sized blocks at start of input otherwise you loose your partition table. Stefan -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From dkotian3 at vsnl.net Thu May 1 14:10:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Thu May 1 14:10:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts References: <20030501112225.K55309-100000@www.missl.cs.umd.edu> Message-ID: <000301c3100b$c9f0ec00$303e41db@vsnl.net> I had done make bin32/rtl8139.ebi after applying the patch because this is the LAN chip I have, So, that is why I have kept this payload, correct me, If I am wrong . I think sis900.ebi is specific for your motherboard. Could one Please elaborate more this.. ----- Original Message ----- From: "Adam Agnew" To: Cc: Sent: Thursday, May 01, 2003 8:54 PM Subject: Re: Etherboot boot problem after jumping to boot code it restarts > What's in that patch is my config files. > You can make a valid elf-boot image from that version of etherboot with > "make bin32/sis900.ebi" and then use that as your payload. From what > you're showing me below, it looks like you're not using a valid payload > and the system is resetting. See how the very end looks like the very > beginning? That's because your system rebooted itself. > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > Sorry, this may also help. > > Probably, you may also like to share the procedure > > of your etherboot for my case and also > > the share the config file. > > It would be good help for me.. > > > > > > > > Regards > > Deepak > > > > > > agnew at cs.umd.edu wrote > > etherboot-5.0.9 is NOT supposed to work. you want etherboot-5.0.6 > > probably and the patch against it at http://www.missl.cs.umd.edu/~agnew/ > > > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > > > Hi, > > > > > > I have tried etherboot on my machine which has > > > Compact Flash IDE and FLASHROMS(256K/512K). Not > > > successful.. > > > The payload I got was from etherboot-5.0.9, which is > > > rtl8139.ebi which is my ethernet chip. > > > > > > Did an Compact flash.. > > > fdisk /dev/hdc, created 2 partions hdc1 and hdc2, both > > > of ext3 type. > > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > > > > > Set these parameters in my config file. > > > option RAMTEST=1 > > > option USE_GENERIC_ROM=1 > > > option USE_ELF_BOOT=1 > > > option ROM_SIZE=524288 > > > option STD_FLASH=1 > > > > > > #payload ../elfImage.9load > > > payload ../rtl8139.ebi > > > option PAYLOAD_SIZE=196608 > > > > > > burned the romimage using the uniflash tool. > > > > > > It seems to have found the elfimage, but just restarts all over > > > again, could someone please spot what could be > > > the problem and the solution to it. > > > Any help on this would really nice. Please find the log > > > below. > > > > > > **********Error Log start**** > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > Ram1 > > > Ram2 > > > Ram3 > > > Ram Enable 1 > > > Ram Enable 2 > > > Ram Enable 3 > > > Ram Enable 4 > > > Ram Enable 5 > > > Ram4 > > > Ram5 > > > Ram6 > > > Copying LinuxBIOS to ram. > > > Jumping to LinuxBIOS. > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 booting... > > > Finding PCI configuration type. > > > PCI: Using configuration type 1 > > > handle_superio start, nsuperio 1 > > > handle_superio Pass 0, check #0, s 00009680 s->super 0000a97c > > > handle_superio: Pass 0, Superio w83627hf > > > handle_superio port 0x0, defaultport 0x2e > > > handle_superio Using port 0x2e > > > handle_superio Pass 0, done #0 > > > handle_superio done > > > Scanning PCI bus...PCI: pci_scan_bus for bus 0 > > > PCI: 00:00.0 [8086/7124] > > > PCI: 00:1e.0 [8086/2418] > > > PCI: 00:1f.0 [8086/2410] > > > PCI: 00:1f.1 [8086/2411] > > > PCI: 00:1f.2 [8086/2412] > > > PCI: 00:1f.3 [8086/2413] > > > PCI: 00:1f.5 [8086/2415] > > > PCI: 00:1f.6 [8086/2416] > > > PCI: pci_scan_bus for bus 1 > > > PCI: 01:04.0 [10ec/8139] > > > PCI: 01:05.0 [10ec/8139] > > > PCI: pci_scan_bus returning with max=01 > > > PCI: pci_scan_bus returning with max=01 > > > done > > > Allocating PCI resources... > > > ASSIGN RESOURCES, bus 0 > > > PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io > > > PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem > > > PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem > > > ASSIGN RESOURCES, bus 1 > > > PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io > > > PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem > > > PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io > > > PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem > > > ASSIGNED RESOURCES, bus 1 > > > PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io > > > PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io > > > PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io > > > PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io > > > PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io > > > PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io > > > PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io > > > ASSIGNED RESOURCES, bus 0 > > > done. > > > Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 > > > PCI: 00:1e.0 cmd <- 07 > > > PCI: 00:1f.0 cmd <- 0f > > > PCI: 00:1f.1 cmd <- 01 > > > PCI: 00:1f.2 cmd <- 01 > > > PCI: 00:1f.3 cmd <- 01 > > > PCI: 00:1f.5 cmd <- 01 > > > PCI: 00:1f.6 cmd <- 01 > > > PCI: 01:04.0 cmd <- 03 > > > PCI: 01:05.0 cmd <- 03 > > > done. > > > Initializing PCI devices... > > > PCI devices initialized > > > DRP0 = 0x9 > > > DIMM0 - size = 64M > > > DIMM1 - size = 0M > > > DRP1 = 0x0 > > > DIMM2 - size = 0M > > > totalram: 64M > > > Initializing CPU #0 > > > Updating microcode > > > microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 > > > 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: 64MB, 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 : 0x07 > > > Processor Mask : 0x00 > > > Processor Stepping : 0x08 > > > Feature flags : 0x00803035 > > > > > > > > > MTRR check > > > Fixed MTRRs : Enabled > > > Variable MTRRs: Enabled > > > > > > Configuring L2 cache...Not 'GenuineIntel' Processor > > > Enable Cache > > > done. > > > Disabling local apic...done. > > > CPU #0 Initialized > > > ioapic southbridge enabled 180 > > > RTC Init > > > Invalid CMOS LB checksum > > > set power on after power fail > > > Please turn on nvram > > > handle_superio start, nsuperio 1 > > > handle_superio Pass 1, check #0, s 00009680 s->super 0000a97c > > > handle_superio: Pass 1, Superio w83627hf > > > handle_superio port 0x2e, defaultport 0x2e > > > handle_superio Using port 0x2e > > > Call init > > > Enabling com device: 03 > > > iobase = 0x02f8 irq=3 > > > handle_superio Pass 1, done #0 > > > handle_superio done > > > handle_superio start, nsuperio 1 > > > handle_superio Pass 2, check #0, s 00009680 s->super 0000a97c > > > handle_superio: Pass 2, Superio w83627hf > > > handle_superio port 0x2e, defaultport 0x2e > > > handle_superio Using port 0x2e > > > handle_superio Pass 2, done #0 > > > handle_superio done > > > Wrote linuxbios table at: 00000500 - 00000648 checksum 268b > > > > > > Welcome to elfboot, the open sourced starter. > > > January 2002, Eric Biederman. > > > Version 1.2 > > > > > > 203:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000007f > > > Searching for 16 byte tags > > > 64:rom_read_bytes() - overflowed source buffer. max_block = 3 > > > init_bytes found 0 tags > > > Initialized controller... > > > Read completed... > > > scanning elf header... > > > Found ELF candiate at offset 0 > > > scan complete... > > > header_offset is 0 > > > calling elf load... > > > New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > > (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > > Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 filesz: 0x00 > > > 000000000038d4 > > > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > > > Jumping to boot code at 0x94000 > > > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > Ram1 > > > Ram2 > > > .... > > > **********Error Log end**** > > > > > > Thanks and Regards > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From agnew at cs.umd.edu Thu May 1 14:15:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 1 14:15:00 2003 Subject: Etherboot boot problem after jumping to boot code it restarts In-Reply-To: <000301c3100b$c9f0ec00$303e41db@vsnl.net> Message-ID: <20030501145550.C57627-100000@www.missl.cs.umd.edu> Yes, it is. Okay, you should be fine with rtl8139. More importantly, does your ethernet payload load now? On Thu, 1 May 2003, Deepak Kotian wrote: > I had done make bin32/rtl8139.ebi after applying the patch > because this is the LAN chip I have, So, that is why I have kept this > payload, > correct me, If I am wrong . > > I think sis900.ebi is specific for your motherboard. > Could one Please elaborate more this.. > > > ----- Original Message ----- > From: "Adam Agnew" > To: > Cc: > Sent: Thursday, May 01, 2003 8:54 PM > Subject: Re: Etherboot boot problem after jumping to boot code it restarts > > > > What's in that patch is my config files. > > You can make a valid elf-boot image from that version of etherboot with > > "make bin32/sis900.ebi" and then use that as your payload. From what > > you're showing me below, it looks like you're not using a valid payload > > and the system is resetting. See how the very end looks like the very > > beginning? That's because your system rebooted itself. > > > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > > > Sorry, this may also help. > > > Probably, you may also like to share the procedure > > > of your etherboot for my case and also > > > the share the config file. > > > It would be good help for me.. > > > > > > > > > > > > Regards > > > Deepak > > > > > > > > > agnew at cs.umd.edu wrote > > > etherboot-5.0.9 is NOT supposed to work. you want etherboot-5.0.6 > > > probably and the patch against it at http://www.missl.cs.umd.edu/~agnew/ > > > > > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > > > > > Hi, > > > > > > > > I have tried etherboot on my machine which has > > > > Compact Flash IDE and FLASHROMS(256K/512K). Not > > > > successful.. > > > > The payload I got was from etherboot-5.0.9, which is > > > > rtl8139.ebi which is my ethernet chip. > > > > > > > > Did an Compact flash.. > > > > fdisk /dev/hdc, created 2 partions hdc1 and hdc2, both > > > > of ext3 type. > > > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > > > > > > > Set these parameters in my config file. > > > > option RAMTEST=1 > > > > option USE_GENERIC_ROM=1 > > > > option USE_ELF_BOOT=1 > > > > option ROM_SIZE=524288 > > > > option STD_FLASH=1 > > > > > > > > #payload ../elfImage.9load > > > > payload ../rtl8139.ebi > > > > option PAYLOAD_SIZE=196608 > > > > > > > > burned the romimage using the uniflash tool. > > > > > > > > It seems to have found the elfimage, but just restarts all over > > > > again, could someone please spot what could be > > > > the problem and the solution to it. > > > > Any help on this would really nice. Please find the log > > > > below. > > > > > > > > **********Error Log start**** > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > > Ram1 > > > > Ram2 > > > > Ram3 > > > > Ram Enable 1 > > > > Ram Enable 2 > > > > Ram Enable 3 > > > > Ram Enable 4 > > > > Ram Enable 5 > > > > Ram4 > > > > Ram5 > > > > Ram6 > > > > Copying LinuxBIOS to ram. > > > > Jumping to LinuxBIOS. > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 booting... > > > > Finding PCI configuration type. > > > > PCI: Using configuration type 1 > > > > handle_superio start, nsuperio 1 > > > > handle_superio Pass 0, check #0, s 00009680 s->super 0000a97c > > > > handle_superio: Pass 0, Superio w83627hf > > > > handle_superio port 0x0, defaultport 0x2e > > > > handle_superio Using port 0x2e > > > > handle_superio Pass 0, done #0 > > > > handle_superio done > > > > Scanning PCI bus...PCI: pci_scan_bus for bus 0 > > > > PCI: 00:00.0 [8086/7124] > > > > PCI: 00:1e.0 [8086/2418] > > > > PCI: 00:1f.0 [8086/2410] > > > > PCI: 00:1f.1 [8086/2411] > > > > PCI: 00:1f.2 [8086/2412] > > > > PCI: 00:1f.3 [8086/2413] > > > > PCI: 00:1f.5 [8086/2415] > > > > PCI: 00:1f.6 [8086/2416] > > > > PCI: pci_scan_bus for bus 1 > > > > PCI: 01:04.0 [10ec/8139] > > > > PCI: 01:05.0 [10ec/8139] > > > > PCI: pci_scan_bus returning with max=01 > > > > PCI: pci_scan_bus returning with max=01 > > > > done > > > > Allocating PCI resources... > > > > ASSIGN RESOURCES, bus 0 > > > > PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io > > > > PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem > > > > PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem > > > > ASSIGN RESOURCES, bus 1 > > > > PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io > > > > PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem > > > > PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io > > > > PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem > > > > ASSIGNED RESOURCES, bus 1 > > > > PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io > > > > PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io > > > > PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io > > > > PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io > > > > PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io > > > > PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io > > > > PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io > > > > ASSIGNED RESOURCES, bus 0 > > > > done. > > > > Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 > > > > PCI: 00:1e.0 cmd <- 07 > > > > PCI: 00:1f.0 cmd <- 0f > > > > PCI: 00:1f.1 cmd <- 01 > > > > PCI: 00:1f.2 cmd <- 01 > > > > PCI: 00:1f.3 cmd <- 01 > > > > PCI: 00:1f.5 cmd <- 01 > > > > PCI: 00:1f.6 cmd <- 01 > > > > PCI: 01:04.0 cmd <- 03 > > > > PCI: 01:05.0 cmd <- 03 > > > > done. > > > > Initializing PCI devices... > > > > PCI devices initialized > > > > DRP0 = 0x9 > > > > DIMM0 - size = 64M > > > > DIMM1 - size = 0M > > > > DRP1 = 0x0 > > > > DIMM2 - size = 0M > > > > totalram: 64M > > > > Initializing CPU #0 > > > > Updating microcode > > > > microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 > > > > 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: 64MB, 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 : 0x07 > > > > Processor Mask : 0x00 > > > > Processor Stepping : 0x08 > > > > Feature flags : 0x00803035 > > > > > > > > > > > > MTRR check > > > > Fixed MTRRs : Enabled > > > > Variable MTRRs: Enabled > > > > > > > > Configuring L2 cache...Not 'GenuineIntel' Processor > > > > Enable Cache > > > > done. > > > > Disabling local apic...done. > > > > CPU #0 Initialized > > > > ioapic southbridge enabled 180 > > > > RTC Init > > > > Invalid CMOS LB checksum > > > > set power on after power fail > > > > Please turn on nvram > > > > handle_superio start, nsuperio 1 > > > > handle_superio Pass 1, check #0, s 00009680 s->super 0000a97c > > > > handle_superio: Pass 1, Superio w83627hf > > > > handle_superio port 0x2e, defaultport 0x2e > > > > handle_superio Using port 0x2e > > > > Call init > > > > Enabling com device: 03 > > > > iobase = 0x02f8 irq=3 > > > > handle_superio Pass 1, done #0 > > > > handle_superio done > > > > handle_superio start, nsuperio 1 > > > > handle_superio Pass 2, check #0, s 00009680 s->super 0000a97c > > > > handle_superio: Pass 2, Superio w83627hf > > > > handle_superio port 0x2e, defaultport 0x2e > > > > handle_superio Using port 0x2e > > > > handle_superio Pass 2, done #0 > > > > handle_superio done > > > > Wrote linuxbios table at: 00000500 - 00000648 checksum 268b > > > > > > > > Welcome to elfboot, the open sourced starter. > > > > January 2002, Eric Biederman. > > > > Version 1.2 > > > > > > > > 203:init_bytes() - zkernel_start:0xfffc0000 > zkernel_mask:0x0000007f > > > > Searching for 16 byte tags > > > > 64:rom_read_bytes() - overflowed source buffer. max_block = 3 > > > > init_bytes found 0 tags > > > > Initialized controller... > > > > Read completed... > > > > scanning elf header... > > > > Found ELF candiate at offset 0 > > > > scan complete... > > > > header_offset is 0 > > > > calling elf load... > > > > New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > > > (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize > 0x38d4 > > > > Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 > filesz: 0x00 > > > > 000000000038d4 > > > > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > > > > Jumping to boot code at 0x94000 > > > > > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > > Ram1 > > > > Ram2 > > > > .... > > > > **********Error Log end**** > > > > > > > > Thanks and Regards > > > > > > > > _______________________________________________ > > > > Linuxbios mailing list > > > > Linuxbios at clustermatic.org > > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From dkotian3 at vsnl.net Thu May 1 14:18:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Thu May 1 14:18:01 2003 Subject: Etherboot boot problem after jumping to boot code it restarts References: <20030501145550.C57627-100000@www.missl.cs.umd.edu> Message-ID: <004201c31012$ccf0e160$223e41db@vsnl.net> Nio, it did not .. ----- Original Message ----- From: "Adam Agnew" To: "Deepak Kotian" Cc: Sent: Friday, May 02, 2003 12:27 AM Subject: Re: Etherboot boot problem after jumping to boot code it restarts > Yes, it is. Okay, you should be fine with rtl8139. More importantly, does > your ethernet payload load now? > > On Thu, 1 May 2003, Deepak Kotian wrote: > > > I had done make bin32/rtl8139.ebi after applying the patch > > because this is the LAN chip I have, So, that is why I have kept this > > payload, > > correct me, If I am wrong . > > > > I think sis900.ebi is specific for your motherboard. > > Could one Please elaborate more this.. > > > > > > ----- Original Message ----- > > From: "Adam Agnew" > > To: > > Cc: > > Sent: Thursday, May 01, 2003 8:54 PM > > Subject: Re: Etherboot boot problem after jumping to boot code it restarts > > > > > > > What's in that patch is my config files. > > > You can make a valid elf-boot image from that version of etherboot with > > > "make bin32/sis900.ebi" and then use that as your payload. From what > > > you're showing me below, it looks like you're not using a valid payload > > > and the system is resetting. See how the very end looks like the very > > > beginning? That's because your system rebooted itself. > > > > > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > > > > > Sorry, this may also help. > > > > Probably, you may also like to share the procedure > > > > of your etherboot for my case and also > > > > the share the config file. > > > > It would be good help for me.. > > > > > > > > > > > > > > > > Regards > > > > Deepak > > > > > > > > > > > > agnew at cs.umd.edu wrote > > > > etherboot-5.0.9 is NOT supposed to work. you want etherboot-5.0.6 > > > > probably and the patch against it at http://www.missl.cs.umd.edu/~agnew/ > > > > > > > > On Thu, 1 May 2003 dkotian3 at vsnl.net wrote: > > > > > > > > > Hi, > > > > > > > > > > I have tried etherboot on my machine which has > > > > > Compact Flash IDE and FLASHROMS(256K/512K). Not > > > > > successful.. > > > > > The payload I got was from etherboot-5.0.9, which is > > > > > rtl8139.ebi which is my ethernet chip. > > > > > > > > > > Did an Compact flash.. > > > > > fdisk /dev/hdc, created 2 partions hdc1 and hdc2, both > > > > > of ext3 type. > > > > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > > > > > > > > > Set these parameters in my config file. > > > > > option RAMTEST=1 > > > > > option USE_GENERIC_ROM=1 > > > > > option USE_ELF_BOOT=1 > > > > > option ROM_SIZE=524288 > > > > > option STD_FLASH=1 > > > > > > > > > > #payload ../elfImage.9load > > > > > payload ../rtl8139.ebi > > > > > option PAYLOAD_SIZE=196608 > > > > > > > > > > burned the romimage using the uniflash tool. > > > > > > > > > > It seems to have found the elfimage, but just restarts all over > > > > > again, could someone please spot what could be > > > > > the problem and the solution to it. > > > > > Any help on this would really nice. Please find the log > > > > > below. > > > > > > > > > > **********Error Log start**** > > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > > > Ram1 > > > > > Ram2 > > > > > Ram3 > > > > > Ram Enable 1 > > > > > Ram Enable 2 > > > > > Ram Enable 3 > > > > > Ram Enable 4 > > > > > Ram Enable 5 > > > > > Ram4 > > > > > Ram5 > > > > > Ram6 > > > > > Copying LinuxBIOS to ram. > > > > > Jumping to LinuxBIOS. > > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 booting... > > > > > Finding PCI configuration type. > > > > > PCI: Using configuration type 1 > > > > > handle_superio start, nsuperio 1 > > > > > handle_superio Pass 0, check #0, s 00009680 s->super 0000a97c > > > > > handle_superio: Pass 0, Superio w83627hf > > > > > handle_superio port 0x0, defaultport 0x2e > > > > > handle_superio Using port 0x2e > > > > > handle_superio Pass 0, done #0 > > > > > handle_superio done > > > > > Scanning PCI bus...PCI: pci_scan_bus for bus 0 > > > > > PCI: 00:00.0 [8086/7124] > > > > > PCI: 00:1e.0 [8086/2418] > > > > > PCI: 00:1f.0 [8086/2410] > > > > > PCI: 00:1f.1 [8086/2411] > > > > > PCI: 00:1f.2 [8086/2412] > > > > > PCI: 00:1f.3 [8086/2413] > > > > > PCI: 00:1f.5 [8086/2415] > > > > > PCI: 00:1f.6 [8086/2416] > > > > > PCI: pci_scan_bus for bus 1 > > > > > PCI: 01:04.0 [10ec/8139] > > > > > PCI: 01:05.0 [10ec/8139] > > > > > PCI: pci_scan_bus returning with max=01 > > > > > PCI: pci_scan_bus returning with max=01 > > > > > done > > > > > Allocating PCI resources... > > > > > ASSIGN RESOURCES, bus 0 > > > > > PCI: 00:1e.0 1c <- [0x00001000 - 0x00001fff] bus 1 io > > > > > PCI: 00:1e.0 24 <- [0xfec00000 - 0xfebfffff] bus 1 prefmem > > > > > PCI: 00:1e.0 20 <- [0xfeb00000 - 0xfebfffff] bus 1 mem > > > > > ASSIGN RESOURCES, bus 1 > > > > > PCI: 01:04.0 10 <- [0x00001000 - 0x000010ff] io > > > > > PCI: 01:04.0 14 <- [0xfeb00000 - 0xfeb000ff] mem > > > > > PCI: 01:05.0 10 <- [0x00001400 - 0x000014ff] io > > > > > PCI: 01:05.0 14 <- [0xfeb01000 - 0xfeb010ff] mem > > > > > ASSIGNED RESOURCES, bus 1 > > > > > PCI: 00:1f.1 20 <- [0x000028e0 - 0x000028ef] io > > > > > PCI: 00:1f.2 20 <- [0x000028c0 - 0x000028df] io > > > > > PCI: 00:1f.3 20 <- [0x000028f0 - 0x000028ff] io > > > > > PCI: 00:1f.5 10 <- [0x00002000 - 0x000020ff] io > > > > > PCI: 00:1f.5 14 <- [0x00002880 - 0x000028bf] io > > > > > PCI: 00:1f.6 10 <- [0x00002400 - 0x000024ff] io > > > > > PCI: 00:1f.6 14 <- [0x00002800 - 0x0000287f] io > > > > > ASSIGNED RESOURCES, bus 0 > > > > > done. > > > > > Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 > > > > > PCI: 00:1e.0 cmd <- 07 > > > > > PCI: 00:1f.0 cmd <- 0f > > > > > PCI: 00:1f.1 cmd <- 01 > > > > > PCI: 00:1f.2 cmd <- 01 > > > > > PCI: 00:1f.3 cmd <- 01 > > > > > PCI: 00:1f.5 cmd <- 01 > > > > > PCI: 00:1f.6 cmd <- 01 > > > > > PCI: 01:04.0 cmd <- 03 > > > > > PCI: 01:05.0 cmd <- 03 > > > > > done. > > > > > Initializing PCI devices... > > > > > PCI devices initialized > > > > > DRP0 = 0x9 > > > > > DIMM0 - size = 64M > > > > > DIMM1 - size = 0M > > > > > DRP1 = 0x0 > > > > > DIMM2 - size = 0M > > > > > totalram: 64M > > > > > Initializing CPU #0 > > > > > Updating microcode > > > > > microcode_info: sig = 0x00000678 pf=0x00000001 rev = 0x00000000 > > > > > 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: 64MB, 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 : 0x07 > > > > > Processor Mask : 0x00 > > > > > Processor Stepping : 0x08 > > > > > Feature flags : 0x00803035 > > > > > > > > > > > > > > > MTRR check > > > > > Fixed MTRRs : Enabled > > > > > Variable MTRRs: Enabled > > > > > > > > > > Configuring L2 cache...Not 'GenuineIntel' Processor > > > > > Enable Cache > > > > > done. > > > > > Disabling local apic...done. > > > > > CPU #0 Initialized > > > > > ioapic southbridge enabled 180 > > > > > RTC Init > > > > > Invalid CMOS LB checksum > > > > > set power on after power fail > > > > > Please turn on nvram > > > > > handle_superio start, nsuperio 1 > > > > > handle_superio Pass 1, check #0, s 00009680 s->super 0000a97c > > > > > handle_superio: Pass 1, Superio w83627hf > > > > > handle_superio port 0x2e, defaultport 0x2e > > > > > handle_superio Using port 0x2e > > > > > Call init > > > > > Enabling com device: 03 > > > > > iobase = 0x02f8 irq=3 > > > > > handle_superio Pass 1, done #0 > > > > > handle_superio done > > > > > handle_superio start, nsuperio 1 > > > > > handle_superio Pass 2, check #0, s 00009680 s->super 0000a97c > > > > > handle_superio: Pass 2, Superio w83627hf > > > > > handle_superio port 0x2e, defaultport 0x2e > > > > > handle_superio Using port 0x2e > > > > > handle_superio Pass 2, done #0 > > > > > handle_superio done > > > > > Wrote linuxbios table at: 00000500 - 00000648 checksum 268b > > > > > > > > > > Welcome to elfboot, the open sourced starter. > > > > > January 2002, Eric Biederman. > > > > > Version 1.2 > > > > > > > > > > 203:init_bytes() - zkernel_start:0xfffc0000 > > zkernel_mask:0x0000007f > > > > > Searching for 16 byte tags > > > > > 64:rom_read_bytes() - overflowed source buffer. max_block = 3 > > > > > init_bytes found 0 tags > > > > > Initialized controller... > > > > > Read completed... > > > > > scanning elf header... > > > > > Found ELF candiate at offset 0 > > > > > scan complete... > > > > > header_offset is 0 > > > > > calling elf load... > > > > > New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 > > > > > (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize > > 0x38d4 > > > > > Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 > > filesz: 0x00 > > > > > 000000000038d4 > > > > > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > > > > > Jumping to boot code at 0x94000 > > > > > > > > > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > > > > > Ram1 > > > > > Ram2 > > > > > .... > > > > > **********Error Log end**** > > > > > > > > > > Thanks and Regards > > > > > > > > > > _______________________________________________ > > > > > Linuxbios mailing list > > > > > Linuxbios at clustermatic.org > > > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > _______________________________________________ > > > > Linuxbios mailing list > > > > Linuxbios at clustermatic.org > > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > > _______________________________________________ > > > > Linuxbios mailing list > > > > Linuxbios at clustermatic.org > > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rsmith at bitworks.com Thu May 1 15:00:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 15:00:00 2003 Subject: My Linux bios FAQ/HOWTO preAlpha Message-ID: <3EB17664.3030905@bitworks.com> Over the last 2 weeks or so I've been building a FAQ/HOWTO based on all my experience getting LB up on our system. This is the result of those efforts. Its pre-Alpha. I've barely reviewed it. It's not spell checked and I didn't even consider grammer. Just raw stuff as I came across it. Its heavly based on things that I have direct experince with. But when I saw questions and good answers come up on the list I snagged them. Going back over it I realized that in the cases where I just block copied what someone else wrote I failed to include credit to the orginal author. My apologies. If you want credit for something you recognize let me know and I'll add it. If future I'll try to do a better job on getting that right in the first place. I'm happy to take on maintainance of this doc. So please send me any answers or improvements and I'll incorporate them. In places where I need more info I enclosed my request for info in <> please if you know answers or have info send it to me. One area that sorely lacking is the Config options Appendix. I have as many options documented as I have come across but I know there are many more. Please pick an option or 2 that you use thats not yet documented and send me an explaniation. One thing I would like to add as well is a 'Related Options' section to each option. And perhaps a 'Conflicts With' or 'Overides' section Ron: I'm thinking that this needs to be setup as some sort of LinuxDOC format or someother text processing package so we can generate html/pdf/text etc. What do you think is best? Also do you have the current FAQ in text format that I can incorpoate into this? -- Richard A. Smith rsmith at bitworks.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lb_faq.txt URL: From rsmith at bitworks.com Thu May 1 15:00:16 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 15:00:16 2003 Subject: 440bx ownership Message-ID: <3EB176B9.1040501@bitworks.com> I see the 440bx is listed as unsupported. Guess I need to pick up ownership of that. What do I need to do? -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Thu May 1 15:03:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 15:03:00 2003 Subject: ADLO 440bx loader patch Message-ID: <3EB17742.1030604@bitworks.com> This patch enables booting of ADLO on a 440bx chipset. cd to freebios/util/ADLO and do a 'patch < loader_440bx.diff' -- Richard A. Smith rsmith at bitworks.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: loader_440bx.diff URL: From rsmith at bitworks.com Thu May 1 15:15:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 15:15:01 2003 Subject: FAQ Ver 0.0.2 Message-ID: <3EB179D2.3020009@bitworks.com> After I sent that I realized that the word wrap was greater than 80 charactes. Told you it was raw. Heres a version wraped to 80 columns. -- Richard A. Smith rsmith at bitworks.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lb_faq.txt URL: From tyson at irobot.com Thu May 1 15:23:01 2003 From: tyson at irobot.com (tyson at irobot.com) Date: Thu May 1 15:23:01 2003 Subject: 440bx ownership In-Reply-To: <3EB176B9.1040501@bitworks.com> References: <3EB176B9.1040501@bitworks.com> Message-ID: <3EB17C56.2060002@irobot.com> Richard Smith wrote: > I see the 440bx is listed as unsupported. Guess I need to pick up > ownership of that. What do I need to do? > I was the original 440bx developer. iRobot currently uses a very old version of that stuff that fills our needs well enought that I haven't been able to find time to update to more recent code. Though I continue to monitor the mailing list with interest, I would have a hard time arguing that I have taken any responsibility for it for, what, a couple of years how? ...no toes to step on here. Though I'm so far out of date with respect to linuxbios that I may not be helpful, I'm not against attempting to answer questions that might come up. Cheers! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division tsawyer at irobot.com Robots for the Real World 603-654-3400 ext 206 http://www.irobot.com From rsmith at bitworks.com Thu May 1 16:01:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 1 16:01:00 2003 Subject: 440bx ownership In-Reply-To: <3EB17C56.2060002@irobot.com> References: <3EB176B9.1040501@bitworks.com> <3EB17C56.2060002@irobot.com> Message-ID: <3EB184C1.9050304@bitworks.com> tyson at irobot.com wrote: > I was the original 440bx developer. iRobot currently uses a very old > version of that stuff that fills our needs well enought that I haven't Oh.. I see how you are.. _Now_ you speak up after I've aready solved all my problems. Where were you when I was tearing my hair out getting RAM up? *grin* Really, though, thanks for all your efforts. It would have been a _whole_ lot more difficult if I would have had to start from scratch. > been able to find time to update to more recent code. Though I That's done now. A large part of me debugging scheme was "Hmmm.. this seems broken.. Lets just replace it with Erik's generic code and see what happens." I've submitted a patch to Ron who should check it in sometime in the future. > Though I'm so far out of date with respect to linuxbios that I may not > be helpful, I'm not against attempting to answer questions that might > come up. Perhaps I should send you my diff against the current CVS and let you take a gander an see if there is anything lurking out to bite me. Got any generic 440bx board laying around that you could test the new code on? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Thu May 1 21:43:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 21:43:01 2003 Subject: 440bx ownership In-Reply-To: <3EB176B9.1040501@bitworks.com> Message-ID: On Thu, 1 May 2003, Richard Smith wrote: > I see the 440bx is listed as unsupported. Guess I need to pick up > ownership of that. What do I need to do? just tell me and I'll put you on. So you did it already :-) ron From tcc_linuxbios at thinkthink.com Thu May 1 21:55:01 2003 From: tcc_linuxbios at thinkthink.com (tcc_linuxbios at thinkthink.com) Date: Thu May 1 21:55:01 2003 Subject: (no subject) Message-ID: <200305020233.TAA16963@sunshine.thinkthink.com> I see people are using linuxbios in embedded systems for booting the embedded kernel. Why does linuxbios have to boot anything? I would think for an embedded system that is using linux anyway, you could just use the linuxbios linux as your kernel. thanx, tom.c LinuxBIOS as the, "real" kernel... From agnew at cs.umd.edu Thu May 1 22:01:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 1 22:01:00 2003 Subject: (no subject) In-Reply-To: <200305020233.TAA16963@sunshine.thinkthink.com> Message-ID: <20030501223951.J58953-100000@www.missl.cs.umd.edu> Because LinuxBIOS doesn't contain a kernel. LinuxBIOS initializes hardware. One way to use LinuxBIOS, however, is to put the Linux Kernel on the same eeprom and boot it directly. However, that's not always possible due to small eeproms, it also makes it difficult to update that kernel. Therefore, there are a variety of other ways to acquire the kernel and boot it. On Thu, 1 May 2003 tcc_linuxbios at thinkthink.com wrote: > I see people are using linuxbios in embedded systems for booting the > embedded kernel. Why does linuxbios have to boot anything? I would > think for an embedded system that is using linux anyway, you could > just use the linuxbios linux as your kernel. > > thanx, tom.c > LinuxBIOS as the, "real" kernel... > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From tcc_linuxbios at thinkthink.com Thu May 1 22:55:01 2003 From: tcc_linuxbios at thinkthink.com (tcc_linuxbios at thinkthink.com) Date: Thu May 1 22:55:01 2003 Subject: PCMCIA Support Message-ID: <200305020333.UAA17110@sunshine.thinkthink.com> The reason I'm interested in linuxbios is that I'd like to create a self-contained (not remote booted) no-moving-parts system for ruggetized use. I'd be open to a better idea - but so far I'm thinking of putting an OpenBSD fs on a pcmcia ATA flash card and access it through one of those PCI<->pcmcia cards. This should make for a neat off-the-shelf system for firewalls, gateways, etc. Most bios's don't support pcmcia because most mb's don't have pcmcia hw... Therefore my linuxbios interest. Has anyone considered putting in PCMCIA support? A grep of sources and mail archive comes up blank, except for booting off of CF. CF would work but I suspect I have to buy a special (read expensive) mb that has CF support. Am I getting myself into a project? :) tom.c From adam at cfar.umd.edu Thu May 1 22:57:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 1 22:57:00 2003 Subject: PCMCIA Support In-Reply-To: <200305020333.UAA17110@sunshine.thinkthink.com> Message-ID: <20030501233923.U56829-100000@www.missl.cs.umd.edu> CF talks in ATA protocol, so just order simple pass-thru plate ($20) which will allow you to connect CF to IDE cable and that's it.. On Thu, 1 May 2003 tcc_linuxbios at thinkthink.com wrote: > The reason I'm interested in linuxbios is that I'd like to create a > self-contained (not remote booted) no-moving-parts system for > ruggetized use. > > I'd be open to a better idea - but so far I'm thinking of putting > an OpenBSD fs on a pcmcia ATA flash card and access it through one of > those PCI<->pcmcia cards. This should make for a neat off-the-shelf > system for firewalls, gateways, etc. Most bios's don't support pcmcia > because most mb's don't have pcmcia hw... Therefore my linuxbios > interest. Has anyone considered putting in PCMCIA support? A grep of > sources and mail archive comes up blank, except for booting off of CF. > CF would work but I suspect I have to buy a special (read expensive) mb > that has CF support. > > Am I getting myself into a project? :) > > tom.c > _______________________________________________ > 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 agnew at cs.umd.edu Thu May 1 22:59:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 1 22:59:01 2003 Subject: PCMCIA Support In-Reply-To: <200305020333.UAA17110@sunshine.thinkthink.com> Message-ID: <20030501233933.T58953-100000@www.missl.cs.umd.edu> No plans that I know of to add PCMCIA support. And if I may make a recommendation, why not get a compact flash on ide adapter? Our friends at cwlinux.com still sell such a beast i believe. And plenty of us on the list use this solution. - Adam Agnew On Thu, 1 May 2003 tcc_linuxbios at thinkthink.com wrote: > The reason I'm interested in linuxbios is that I'd like to create a > self-contained (not remote booted) no-moving-parts system for > ruggetized use. > > I'd be open to a better idea - but so far I'm thinking of putting > an OpenBSD fs on a pcmcia ATA flash card and access it through one of > those PCI<->pcmcia cards. This should make for a neat off-the-shelf > system for firewalls, gateways, etc. Most bios's don't support pcmcia > because most mb's don't have pcmcia hw... Therefore my linuxbios > interest. Has anyone considered putting in PCMCIA support? A grep of > sources and mail archive comes up blank, except for booting off of CF. > CF would work but I suspect I have to buy a special (read expensive) mb > that has CF support. > > Am I getting myself into a project? :) > > tom.c > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From adam at cfar.umd.edu Thu May 1 23:09:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 1 23:09:00 2003 Subject: PCMCIA Support In-Reply-To: <20030501233933.T58953-100000@www.missl.cs.umd.edu> Message-ID: <20030501234305.T56829-100000@www.missl.cs.umd.edu> on technical note, it *is* possible to do this way. just use: linuxbios+linux kernel (built in pcmcia support)+kexec in this way you can use linux kernel to boot off whatever linux supports. of course your initial boot medium must be big enough to support linuxbios+linux kernel+kexec. ... but as I (and the other Adam) said before CF is *is* an ATA device.. so just get CF<=>ATA adapter and connect it to it. that's it.. On Thu, 1 May 2003, Adam Agnew wrote: > > No plans that I know of to add PCMCIA support. And if I may make a > recommendation, why not get a compact flash on ide adapter? Our friends > at cwlinux.com still sell such a beast i believe. And plenty of us on the > list use this solution. > - Adam Agnew > > > On Thu, 1 May 2003 tcc_linuxbios at thinkthink.com wrote: > > > The reason I'm interested in linuxbios is that I'd like to create a > > self-contained (not remote booted) no-moving-parts system for > > ruggetized use. > > > > I'd be open to a better idea - but so far I'm thinking of putting > > an OpenBSD fs on a pcmcia ATA flash card and access it through one of > > those PCI<->pcmcia cards. This should make for a neat off-the-shelf > > system for firewalls, gateways, etc. Most bios's don't support pcmcia > > because most mb's don't have pcmcia hw... Therefore my linuxbios > > interest. Has anyone considered putting in PCMCIA support? A grep of > > sources and mail archive comes up blank, except for booting off of CF. > > CF would work but I suspect I have to buy a special (read expensive) mb > > that has CF support. > > > > Am I getting myself into a project? :) > > > > tom.c > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > 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 rminnich at lanl.gov Thu May 1 23:26:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 23:26:01 2003 Subject: PCMCIA Support In-Reply-To: <200305020333.UAA17110@sunshine.thinkthink.com> Message-ID: On Thu, 1 May 2003 tcc_linuxbios at thinkthink.com wrote: > The reason I'm interested in linuxbios is that I'd like to create a > self-contained (not remote booted) no-moving-parts system for > ruggetized use. This has been done in several cases. Some embedded systems boot linux out of flash and that's the system they run. If you have 1 MB of flash that's plenty of room for a 2.4 kernel and initrd. ron From rminnich at lanl.gov Thu May 1 23:27:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 1 23:27:01 2003 Subject: PCMCIA Support In-Reply-To: <20030501234305.T56829-100000@www.missl.cs.umd.edu> Message-ID: On Thu, 1 May 2003, Adam Sulmicki wrote: > > on technical note, it *is* possible to do this way. just use: > > linuxbios+linux kernel (built in pcmcia support)+kexec > > in this way you can use linux kernel to boot off whatever linux supports. and we've done this too. Works fine with a 1MB flash part. We also had a 104-node Alpha cluster that worked this way. ron From nhan.ngodinh at dilogix.it Fri May 2 02:05:01 2003 From: nhan.ngodinh at dilogix.it (Nhan NGO DINH) Date: Fri May 2 02:05:01 2003 Subject: flash utility Message-ID: <5.2.0.9.2.20030502083726.00a3ebe0@mail.dilogix.it> I've a Lex CV860A motherboard, which support has been recently added to LinuxBIOS. I can't find any flash program for that: the flash chip is an AMIC A290021TL-70. http://www.amictechnology.com/pdf/A290021.pdf Does mtd in Linux kernel support this kind of stuff? Thx. Nhan From yenneo at oreka.com Fri May 2 02:57:00 2003 From: yenneo at oreka.com (Philippe CABANNES) Date: Fri May 2 02:57:00 2003 Subject: EEPROM not found Message-ID: <200305020731.JAA80161@mailhub7.isdnet.net> >> I think the flash write enabled, I use this : >> setpci -s 0:11.0 40.b=54 >send me an lspci. Are you sure this is the right chip? I don?t know if it?s the right chip. Here is my lspci : 00:00.0 Host bridge: VIA Technologies, Inc.: Unknow device 3123 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant IEEE 1394 Host Controller (rev 80) 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc.: Unknow device 3104(rev 80) 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknow device 3177 00:11.1 IDE interface: VIA Technologies, Inc: Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74) 01:00.0 VGA Compatible controller: VIA Technologies, Inc.: Unknow device 3122 (rev 03) thanks. -------------------------------------------------- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com From yenneo at oreka.com Fri May 2 02:59:01 2003 From: yenneo at oreka.com (Philippe CABANNES) Date: Fri May 2 02:59:01 2003 Subject: EEPROM not found Message-ID: <200305020733.JAA81268@mailhub7.isdnet.net> >> I think the flash write enabled, I use this : >> setpci -s 0:11.0 40.b=54 >send me an lspci. Are you sure this is the right chip? I don?t know if it?s the right chip. Here is my lspci : 00:00.0 Host bridge: VIA Technologies, Inc.: Unknow device 3123 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant IEEE 1394 Host Controller (rev 80) 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc.: Unknow device 3104(rev 80) 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknow device 3177 00:11.1 IDE interface: VIA Technologies, Inc: Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74) 01:00.0 VGA Compatible controller: VIA Technologies, Inc.: Unknow device 3122 (rev 03) thanks. -------------------------------------------------- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com From ts1 at cma.co.jp Fri May 2 04:23:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri May 2 04:23:01 2003 Subject: EEPROM not found In-Reply-To: <200305020733.JAA81268@mailhub7.isdnet.net> References: <200305020733.JAA81268@mailhub7.isdnet.net> Message-ID: <20030502085748.GA4082@cma.co.jp> On Fri, May 02, 2003 at 09:25:48AM +0100, Philippe CABANNES wrote: > >> I think the flash write enabled, I use this : > >> setpci -s 0:11.0 40.b=54 > > >send me an lspci. Are you sure this is the right chip? > > I don't know if it's the right chip. It is not. The above setpci command is for VT8231 southbridge. (what's in non-"M" EPIA) And the equivalent operation is now done by the flash_rom program. Yours is VT8233. I don't know how they are different (couldn't find a datasheet online), but just try inserting this line around line 437 of flash_rom.c (inside enables[] = {...}) and see what happens: {0x1106, 0x3177, "VT8233", enable_flash_vt8231}, > > Here is my lspci : > > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknow device 3123 > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] > 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant > IEEE 1394 Host Controller (rev 80) > > 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.3 USB Controller: VIA Technologies, Inc.: Unknow device 3104(rev > 80) > 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknow device 3177 > 00:11.1 IDE interface: VIA Technologies, Inc: Bus Master IDE (rev 06) > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio > Controller (rev 50) > 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet > Controller (rev 74) > 01:00.0 VGA Compatible controller: VIA Technologies, Inc.: Unknow > device 3122 (rev 03) -- Takeshi From rminnich at lanl.gov Fri May 2 10:12:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 2 10:12:01 2003 Subject: EEPROM not found In-Reply-To: <200305020731.JAA80161@mailhub7.isdnet.net> Message-ID: On Fri, 2 May 2003, Philippe CABANNES wrote: > >> I think the flash write enabled, I use this : > >> setpci -s 0:11.0 40.b=54 > > >send me an lspci. Are you sure this is the right chip? > > I don?t know if it?s the right chip. > > Here is my lspci : > > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknow device 3123 > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] > 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant > IEEE 1394 Host Controller (rev 80) > > 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) > 00:10.3 USB Controller: VIA Technologies, Inc.: Unknow device 3104(rev > 80) > 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknow device 3177 ^^^^^^^^^^^ That looks bad. What part #? do you have docs? ron From rminnich at lanl.gov Fri May 2 10:21:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 2 10:21:01 2003 Subject: EEPROM not found In-Reply-To: <20030502085748.GA4082@cma.co.jp> Message-ID: On Fri, 2 May 2003, SONE Takeshi wrote: > I don't know how they are different (couldn't find a datasheet online), > but just try inserting this line around line 437 of flash_rom.c > (inside enables[] = {...}) and see what happens: > > {0x1106, 0x3177, "VT8233", enable_flash_vt8231}, If this works I'll commit it. Please let me know if it works. ron From pyro at linuxlabs.com Fri May 2 10:45:01 2003 From: pyro at linuxlabs.com (steven james) Date: Fri May 2 10:45:01 2003 Subject: Bounce buffers and stack Message-ID: Greetings, I'm doing some work on payloads, chaining, and returning from an elf image and have run into an 'interesting' problem. Currently, when elfload sees that an image will overwrite LinuxBIOS, it moves everything (including the stack) up into high memory. So far, so good. However, in the case where it will not overwrite, it leaves things alone. The problem comes in where the payload then loads an image over the stack. So, for example, LinuxBIOS loads payload at 0x1000-0x4000, payload loads image at 0x5000-0x10000 and BOOM. The best bet is to have the first payload move the stack to the top of ram under the 4GB mark and somehow mark that memory as 'pre-boot reserved', meaning that bootloaders should leave it alone, but a final boot target such as Linux may use it after moving the stack. The idea is to allow for chaining by having each stage reserve it's chunk of memory (including bounce buffer) at top of ram-reserved, then move reserved down. jmp_to_elf_entry then just worries about IP and leaves ESP and EBP alone. Ideally, LinuxBIOS itself would create the stack high in the first place, but we are near the freeze, and the first stage payload can easily enough handle the ugliness and set a flag within baremetal to deal with this. Any thoughts? G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From russell at abc9986.demon.co.uk Fri May 2 11:45:01 2003 From: russell at abc9986.demon.co.uk (Russell Gower) Date: Fri May 2 11:45:01 2003 Subject: Sourceforge CVS Message-ID: <008b01c310c6$b8141a00$0f01a8c0@winxp> Has something change with sourceforges cvs since Feburary as i can't do an anonymous login any more. help :-) Russell ICQ 4186920 From rsmith at bitworks.com Fri May 2 12:05:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 2 12:05:01 2003 Subject: Sourceforge CVS In-Reply-To: <008b01c310c6$b8141a00$0f01a8c0@winxp> References: <008b01c310c6$b8141a00$0f01a8c0@winxp> Message-ID: <3EB29F11.5030403@bitworks.com> Russell Gower wrote: > Has something change with sourceforges cvs since Feburary as i can't do an > anonymous login any more. > > help :-) Must be on your end as I did one yesterday. -- Richard A. Smith rsmith at bitworks.com From joey at joescan.com Fri May 2 15:30:00 2003 From: joey at joescan.com (Joey Nelson) Date: Fri May 2 15:30:00 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS In-Reply-To: Message-ID: <009c01c310e5$e75e0680$6501a8c0@pink> ron minnich wrote > To get your payload on CF: > First, you MUST fdisk the CF. Make the whole thing a DOS partition, > doesn't matter. I have found the hard way that for some > reason etherboot > will not work right unless the CF has a partition table on > it. I have not > followed the whole thing through and I assume it is a need > for C/H/S info > that is not there without a partition table or some such. > > Then mkelfImage on the kernel of choice. > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 Alternately using sfdisk you can set the first partition to start at sector 1. I configure my CF with a sandisk compact flash usb adapter at /dev/sda. sfdisk -uS /dev/sda The '-uS' is to use sectors as the standard unit. sfdisk is not as friendly as the standard fdisk, but the standard fdisk doesn't allow the first partition to start at sector 1 on my system. Just make sure the first partition is large enough to hold your elf kernel image. You can do what ever you want with the remaining space. Then when you want to write the kernel out to the flash dd if=kernel.elf of=/dev/sda1 bs=4096 This has been working great for me. I have my rootfs as a read only ext2 fs on the second partition. Joey From rminnich at lanl.gov Fri May 2 16:01:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 2 16:01:00 2003 Subject: Bounce buffers and stack In-Reply-To: Message-ID: What if there were and elf section for the stack? then elfboot would know to avoid that too. ron From pyro at linuxlabs.com Fri May 2 17:10:01 2003 From: pyro at linuxlabs.com (steven james) Date: Fri May 2 17:10:01 2003 Subject: Bounce buffers and stack In-Reply-To: Message-ID: Greetings, I'm not sure how that would work?!? The problem only happens when the first payload doesn't conflict with anything and the second one conflicts with the LinuxBIOS stack. By that time, the only thing the running code knows is where ESP was when it started (but not where the top of the stack is). I did a test in bootselect where I just move the stack then. That plus a quick hack to the elf loader (the private copy in baremetal) to allocate the bounce buffer below the stack helps a lot. G'day, sjames On Fri, 2 May 2003, ron minnich wrote: > What if there were and elf section for the stack? then elfboot would know > to avoid that too. > > ron > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From dkotian3 at vsnl.net Sat May 3 13:18:00 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Sat May 3 13:18:00 2003 Subject: Experiences on Etherboot for IDE Compact flash and FLASHROMS References: <009c01c310e5$e75e0680$6501a8c0@pink> Message-ID: <009b01c3119c$c69f39c0$1f3e41db@vsnl.net> Thanks .I will keep this in mind. But, I am still too far to see the CF IDE from my LinuxBIOS, It mostly cannot detect my etherboot or for that matter even ADLO payload gives the same result. It just spins/resets after Jumping to code at xxx ....... Regards Deepak ----- Original Message ----- From: "Joey Nelson" To: Sent: Saturday, May 03, 2003 1:33 AM Subject: RE: Experiences on Etherboot for IDE Compact flash and FLASHROMS > > ron minnich wrote > > To get your payload on CF: > > First, you MUST fdisk the CF. Make the whole thing a DOS partition, > > doesn't matter. I have found the hard way that for some > > reason etherboot > > will not work right unless the CF has a partition table on > > it. I have not > > followed the whole thing through and I assume it is a need > > for C/H/S info > > that is not there without a partition table or some such. > > > > Then mkelfImage on the kernel of choice. > > > > Then dd if=elfImage_of_kernel of=/dev/hdc bs=4096 skip=1 > > Alternately using sfdisk you can set the first partition to start at > sector 1. I configure my CF with a sandisk compact flash usb adapter at > /dev/sda. > > sfdisk -uS /dev/sda > > The '-uS' is to use sectors as the standard unit. sfdisk is not as > friendly as the standard fdisk, but the standard fdisk doesn't allow the > first partition to start at sector 1 on my system. Just make sure the > first partition is large enough to hold your elf kernel image. You can > do what ever you want with the remaining space. > > Then when you want to write the kernel out to the flash > > dd if=kernel.elf of=/dev/sda1 bs=4096 > > This has been working great for me. I have my rootfs as a read only > ext2 fs on the second partition. > > Joey > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From pyro at linuxlabs.com Sat May 3 15:48:00 2003 From: pyro at linuxlabs.com (steven james) Date: Sat May 3 15:48:00 2003 Subject: jmp_to_elf_entry Message-ID: Greetings, Looks like I've trodden on an unused code path, and found a bug. In arch/i386/boot/boot.c: jmp_to_elf_entry, the idea is to copy all of the running code (linuxbios, or a baremetal payload) to a bounce buffer, jump into the copy there, copy the bounce buffer of the target elf into place, and call it. Upon return, the process is reversed, so that (in theory) jmp_to_elf_entry returns and further processing can happen. For some reason, the lines that subtract the adjustment from EAX, then jump to move execution back to the proper place was failing. I've patched it in the copy kept in util/baremetal/lib so that instead, it loads the eventual jmp target into ecx, then saves it away on the stack. I'm surely missing something here, but the original goes into space while the simple save off is working. I suppose that's just because we've never tried to return to LinuxBIOS from a payload before. The baremetal version also skips adjusting ESP since I'm moving the stack out of the way first. Ignore the // debugging stuff, that was just to see where things were going wrong (I'll be getting rid of that). Eric, since you wrote that part, I wanted to run this by you before making any changes in LinuxBIOS itself. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- -------------- next part -------------- --- ../../../src/arch/i386/boot/boot.c Thu Oct 10 15:02:28 2002 +++ boot.c Sat May 3 15:54:10 2003 @@ -67,6 +67,7 @@ } +#if 1 void jmp_to_elf_entry(void *entry, unsigned long buffer) { extern unsigned char _ram_seg, _eram_seg; @@ -121,15 +122,19 @@ " movl 8(%%esp), %%ecx\n\n" " shrl $2, %%ecx\n\t" " rep movsl\n\t" - +#ifdef MOVE_STACK /* Adjust the stack pointer to point into the new linuxBIOS image */ " addl 20(%%esp), %%esp\n\t" +#endif /* Adjust the instruction pointer to point into the new linuxBIOS image */ " movl $1f, %%eax\n\t" " addl 20(%%esp), %%eax\n\t" + " movl $2f, %%ecx\n\t" " jmp *%%eax\n\t" "1: \n\t" + + " movl %%ecx, 20(%%esp)\n\t" /* Copy the linuxBIOS bounce buffer over linuxBIOS */ /* Move ``longs'' the linuxBIOS size is 4 byte aligned */ " movl 16(%%esp), %%edi\n\t" @@ -142,6 +147,10 @@ " movl $0x0E1FB007, %%eax\n\t" " movl 0(%%esp), %%ebx\n\t" " call *4(%%esp)\n\t" +// debygging + " mov $0x41, %%al\n\t" + " mov $0x3f8, %%dx\n\t" + " outb %%al, %%dx\n\t" /* The loaded image returned? */ " cli \n\t" @@ -155,15 +164,22 @@ " movl 8(%%esp), %%ecx\n\t" " shrl $2, %%ecx\n\t" " rep movsl\n\t" - +#ifdef MOVE_STACK /* Adjust the stack pointer to point into the old linuxBIOS image */ " subl 20(%%esp), %%esp\n\t" +#endif /* Adjust the instruction pointer to point into the old linuxBIOS image */ - " movl $1f, %%eax\n\t" - " subl 20(%%esp), %%eax\n\t" +// " movl $1f, %%eax\n\t" +// " subl 20(%%esp), %%eax\n\t" + " movl 20(%%esp), %%eax\n\t" " jmp *%%eax\n\t" - "1: \n\t" + "2: \n\t" + +// debygging + " mov $0x42, %%al\n\t" + " mov $0x3f8, %%dx\n\t" + " outb %%al, %%dx\n\t" /* Drop the parameters I was passed */ " addl $24, %%esp\n\t" @@ -177,6 +193,16 @@ "g" (lb_start), "g" (buffer), "g" (lb_size), "g" (entry), "g"(adjusted_boot_notes) ); + + printk("jmp_to_elf_entry returning\n"); } +#else +void jmp_to_elf_entry(void *entry, unsigned long buffer) +{ + void (*newmain)() = entry; + newmain(); + return; +} +#endif From ebiederman at lnxi.com Sat May 3 18:10:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat May 3 18:10:00 2003 Subject: jmp_to_elf_entry In-Reply-To: References: Message-ID: steven james writes: > Greetings, > > Looks like I've trodden on an unused code path, and found a bug. > In arch/i386/boot/boot.c: jmp_to_elf_entry, the idea is to copy all of the > running code (linuxbios, or a baremetal payload) to a bounce buffer, jump > into the copy there, copy the bounce buffer of the target elf into place, > and call it. Upon return, the process is reversed, so that (in > theory) jmp_to_elf_entry returns and further processing can happen. > > For some reason, the lines that subtract the adjustment from EAX, then > jump to move execution back to the proper place was failing. I've patched > it in the copy kept in util/baremetal/lib so that instead, it loads the > eventual jmp target into ecx, then saves it away on the stack. > > I'm surely missing something here, but the original goes into space while > the simple save off is working. I suppose that's just because we've never > tried to return to LinuxBIOS from a payload before. That sounds correct. It was there for completeness rather than a real need. And I never did test it. > The baremetal version also skips adjusting ESP since I'm moving the stack > out of the way first. > > Ignore the // debugging stuff, that was just to see where things were > going wrong (I'll be getting rid of that). > > Eric, since you wrote that part, I wanted to run this by you before making > any changes in LinuxBIOS itself. I would not be surprised to learn that the returning to LinuxBIOS was not working. For LinuxBIOS itself all we can do is call hard_reset like we do for the other weird cases. But for the baremetal tool kit there we can definitely do something interesting. I will have to look at what you are looking at stack wise but I certainly think we should have a stack that is out of the way as well, and we cannot have that in LinuxBIOS until we actually know our final memory size. And that information is not know until late. There is one glitch in the LinuxBIOS code. After thinking and looking at things and see what works most reliably. We should be passing the address of the parameter block with the standard C calling conventions (and on x86 this is on the stack). I have modified etherboot to do this. I have not gotten back to the LinuxBIOS code. With respect to memory maps. That is one piece of information that we should pass both ways. Both in the LinuxBIOS table, and in the parameter block we pass to the loaded image. This allows someone to find the real memory usage as well as to find what the bootloader thinks about the current situation. A memory map is something fundamental enough that the memory allocation will always be changing. I need to take my that specifies things about ELF booting and do another version. But I have not gotten quite that far yet. Eric From pyro at linuxlabs.com Sun May 4 06:40:01 2003 From: pyro at linuxlabs.com (steven james) Date: Sun May 4 06:40:01 2003 Subject: jmp_to_elf_entry In-Reply-To: Message-ID: Greetings, This message got more involved than I intended. I'd best preface it! Most of the bolow message is potential policy in payloads. LinuxBIOS need not (and probably should not) implement it, but will need to facillitate, or at least accomodate it: The fixups I'm now doing in bootselect seem to be working reasonably well, but certainly have issues to be addressed. To start, the top of RAM works well enough on the board I'm using, but that will have to be adjusted on a system that actually uses an SMA framebuffer. Also, it would definatly fail on a wierd system that has holes in memory near the top, but that will be fixed in the real production code (as opposed to the quick and dirty exploritory code I'm using now). Currently, I'm doing the stack relocation with: unsigned long int ramtop; unsigned long int free_ramtop; int _main(void) { lbmem = get_lbmem(); DPRINTF("Got lbmem struct: %08x\n", (unsigned int) lbmem); ramtop = find_ramtop(lbmem); DPRINTF("Top of RAM = %08x\n", ramtop); __asm__ __volatile__( "movl %%ebp, %%eax\n" "subl %%esp, %%eax\n" "movl %0, %%esp\n" "movl %0, %%ebp\n" "pushl %%ebp\n" "subl %%eax, %%esp\n" :: "d" (ramtop)); // reserve a stack free_ramtop = ramtop - 0x8000; DPRINTF("ramtop = %08x, free_ramtop = %08x\n", ramtop, free_ramtop); DPRINTF("Calling main\n"); return(main()); } In reality, if _main returns, it will surely crash. So, _main should call main, then hard_reset. This can remain inside the payloads, by moving _main into libbaremetal and checking for a setup signature before messing with the stack, or LinuxBIOS itself can do the initial setup and have the payloads just cooperate. Note that a payload that will not return can ignore the change other than avoiding stack overwrite. One goal is to have baremetal share as much of the code with LinuxBIOS as possible. Much of it simply uses the source directly in the tree, a few source files (boot.c elfboot.c) are slightly modified copies from the tree, and linuxbios.c (modified) from etherboot. One good approach would be for LinuxBIOS to move the stack in whatever function calls elfload. At that point, it will know as much as it ever will about areas to avoid. With that, the mods to elfboot and boot.c can be folded back in without incident. LinuxBIOS can handle return from the payload by either calling hard_reset, or trying the next stream pointer and calling hard_resset when it encounters a null pointer (I note that the linker scripts do support multiple streams, but the feature isn't used now). Moving on to memory allocation, as I see it, there are several possible states for an address region: 1. reserved (non-existant, flash, or a device) 2. available (real memory) 3. in use, only wipe out if you will never return. 4. stack, only wipe out after making other arrangements and you will never return. Case 3 may either be hierarchical (removed before returning), or persistant (consider a 'driver' payload that leaves function pointers and some code behind in a table when it returns). I'm not sure where the latter is going (or not), but it'd be nice to leave the option open. I believe that the non-returning payloads out there now can ignore 3, and already do the right thing for 4, but they would need to either understand the additional flags in the memory table (to the extent that they realize that 3 and 4 are usable memory for them), or have 3 and 4 specified in some other structure. One simple approach is a system wide variable that holds the highest address that isn't somehow spoken for, and make sure all case 3 and 4 memory allocations are made out of high RAM. G'day, sjames On 3 May 2003, Eric W. Biederman wrote: > steven james writes: > > > Greetings, > > > > Looks like I've trodden on an unused code path, and found a bug. > > In arch/i386/boot/boot.c: jmp_to_elf_entry, the idea is to copy all of the > > running code (linuxbios, or a baremetal payload) to a bounce buffer, jump > > into the copy there, copy the bounce buffer of the target elf into place, > > and call it. Upon return, the process is reversed, so that (in > > theory) jmp_to_elf_entry returns and further processing can happen. > > > > For some reason, the lines that subtract the adjustment from EAX, then > > jump to move execution back to the proper place was failing. I've patched > > it in the copy kept in util/baremetal/lib so that instead, it loads the > > eventual jmp target into ecx, then saves it away on the stack. > > > > I'm surely missing something here, but the original goes into space while > > the simple save off is working. I suppose that's just because we've never > > tried to return to LinuxBIOS from a payload before. > > That sounds correct. It was there for completeness rather than a real > need. And I never did test it. > > > The baremetal version also skips adjusting ESP since I'm moving the stack > > out of the way first. > > > > Ignore the // debugging stuff, that was just to see where things were > > going wrong (I'll be getting rid of that). > > > > Eric, since you wrote that part, I wanted to run this by you before making > > any changes in LinuxBIOS itself. > > I would not be surprised to learn that the returning to LinuxBIOS > was not working. > > For LinuxBIOS itself all we can do is call hard_reset like we do > for the other weird cases. But for the baremetal tool kit there > we can definitely do something interesting. > > I will have to look at what you are looking at stack wise but I certainly > think we should have a stack that is out of the way as well, and we cannot > have that in LinuxBIOS until we actually know our final memory > size. And that information is not know until late. > > There is one glitch in the LinuxBIOS code. After thinking and > looking at things and see what works most reliably. We should > be passing the address of the parameter block with the standard > C calling conventions (and on x86 this is on the stack). I have > modified etherboot to do this. I have not gotten back to the > LinuxBIOS code. > > With respect to memory maps. That is one piece of information that > we should pass both ways. Both in the LinuxBIOS table, and in > the parameter block we pass to the loaded image. > > This allows someone to find the real memory usage as well as to > find what the bootloader thinks about the current situation. > A memory map is something fundamental enough that the memory > allocation will always be changing. > > I need to take my that specifies things about ELF booting and do > another version. But I have not gotten quite that far yet. > > Eric > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From dkotian3 at vsnl.net Mon May 5 02:12:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Mon May 5 02:12:01 2003 Subject: readelf O/P of romiage(linuxbios+etherboot) question Message-ID: <20030505072058.F0AA250037@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From yenneo at oreka.com Mon May 5 02:30:00 2003 From: yenneo at oreka.com (Philippe CABANNES) Date: Mon May 5 02:30:00 2003 Subject: EEPROM not found Message-ID: <200305050706.JAA86285@mailhub10.isdnet.net> >Yours is VT8233. >I don't know how they are different (couldn't find a datasheet >online), >but just try inserting this line around line 437 of flash_rom.c >(inside enables[] = {...}) and see what happens: > {0x1106, 0x3177, "VT8233", enable_flash_vt8231}, This doesn?t work but my south bridge is a vt8235. I also didn?t find data sheets and i really wonder how to do... -------------------------------------------------- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com From xpegenaute at telepolis.es Mon May 5 05:54:00 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Mon May 5 05:54:00 2003 Subject: Documentation Message-ID: <3EB64A9E.6060707@telepolis.es> Hello, i'm doing documentation about the code of LinuxBios with ADLO for my thesis, and i thought that may be you can helpme in things that are usefull to know for understand the code of LinuxBios. Of course after the document can be for linuxbios. I started by a mail of Greg Watson that explain how is linked crt0.S and linuxbios, after this i started to explain the main things of hardwaremain.c that jump to the elfboot and finally elfboot to kernel. Any one thing that is usefull to explain something else ? Another thing that is a little confused in me .., the true point of start code, in some info say that is in 0xf0000, but in the compilation of ms7308e i see that is in: linuxbios.map:00080004 T _start i supose that then it depends of the motherboard ... At the moment it's all. Thanks for all. Xavi. From s.sorrenti at regia.tv Mon May 5 06:05:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Mon May 5 06:05:01 2003 Subject: make rom problem! Message-ID: <20030505095525.10124.qmail@learninghut.com> # This will make a target directory of ./pcchips target pcchips # PCCHIPS M810LMR mainboard mainboard pcchips/m810lmr # We are using a k7 cpu (???) cpu k7 # Set up udelay - needed option CONFIG_UDELAY_TSC=1 # This SHOULD enable the video console with messages about what's going on option VIDEO_CONSOLE=1 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # Sets the log level, from 9 to 1 (???) option DEFAULT_CONSOLE_LOGLEVEL=6 # More debug options option SERIAL_POST=1 # Enables ethernet (?) option ENABLE_MII=1 # use DOC MIL option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 # Sets the amount of framebuffer memory # 0x80 (2MB/4MB) # 0x90 (4MB/8MB) # 0xA0 (8MB/16MB) # 0xB0 (16MB/32MB) # 0xC0 (32MB/64MB) # 0xD0 (64MB/na) option SMA_SIZE=0xC0 # Enables IDE boot option BOOT_IDE=1 # Selects which IDE device should boot from, using the following table: # /dev/hda -> 0 # /dev/hdb -> 1 # /dev/hdc -> 2 # /dev/hdd -> 3 option IDE_BOOT_DRIVE=0 # Partition table size (should be left untouched?) option ONE_TRACK=32 # Need to "relocate the gdt" to use a standard flash part (???) biosbase 0xffff0000 # Path to your kernel (vmlinux) linux /usr/src/linux # Kernel command line parameters commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 single This is my config file but when i done the make command in pcchips directory this is the error. gcc ... -o superio_sis_950.o /home/fino/src/superio/sis/950/superio.c /home/fino/src/superio/sis/950/superio.c:2: warning: `rcsid' defined but not used gcc ... -o nsuperio.o nsuperio.c gcc ... -o mainboard.o /home/fino/src/mainboard/pcchips/m810lmr/mainboard.c gcc ... -o irq_tables.o /home/fino/src/mainboard/pcchips/m810lmr/irq_tables.c gcc ... -o cpuid.o /home/fino/src/cpu/p5/cpuid.c /home/fino/src/cpu/p5/cpuid.c:3: warning: `rcsid' defined but not used gcc ... -o delay_tsc.o /home/fino/src/cpu/p5/delay_tsc.c /home/fino/src/cpu/p5/delay_tsc.c: In function `calibrate_tsc': /home/fino/src/cpu/p5/delay_tsc.c:102: warning: unused variable `allones' gcc ... -o microcode.o /home/fino/src/cpu/p6/microcode.c /home/fino/src/cpu/p6/microcode.c:7: warning: `rcsid' defined but not used gcc ... -o mtrr.o /home/fino/src/cpu/p6/mtrr.c /home/fino/src/cpu/p6/mtrr.c: In function `set_var_mtrr': /home/fino/src/cpu/p6/mtrr.c:132: warning: unused variable `tmp' /home/fino/src/cpu/p6/mtrr.c: At top level: /home/fino/src/cpu/p6/mtrr.c:29: warning: `rcsid' defined but not used gcc ... -o l2_cache.o /home/fino/src/cpu/p6/l2_cache.c /home/fino/src/cpu/p6/l2_cache.c:33: warning: `rcsid' defined but not used gcc ... -o cpufixup.o /home/fino/src/cpu/k7/cpufixup.c /home/fino/src/cpu/k7/cpufixup.c:8:1: warning: "TOP_MEM" redefined In file included from /home/fino/src/cpu/k7/cpufixup.c:6: /home/fino/src/include/cpu/k7/mtrr.h:38:1: warning: this is the location of the previous definition /home/fino/src/cpu/k7/cpufixup.c:9:1: warning: "TOP_MEM2" redefined /home/fino/src/include/cpu/k7/mtrr.h:39:1: warning: this is the location of the previous definition rm -f linuxbios.a ar cr linuxbios.a linuxbiosmain.o linuxpci.o newpci.o clog2.o printk.o serial_subr.o video_subr.o subr.o vsprintf.o memset.o memcpy.o memcmp.o malloc.o do_inflate.o delay.o compute_ip_checksum.o version.o keyboard.o mc146818rtc.o isa-dma.o vga_load_regs.o font_8x16.o vga_set_mode.o vga_load_pcx.o ide.o boot.o linuxbios_table.o i386_subr.o params.o hardwaremain.o pirq_routing.o c_start.o southbridge.o northbridge.o superio_sis_950.o nsuperio.o mainboard.o irq_tables.o keyboard.o cpuid.o delay_tsc.o microcode.o mtrr.o l2_cache.o cpufixup.o cpufixup.o gcc -nostdlib -r -o linuxbios_c.o c_start.o docmil_fill_inbuf.o ide_fill_inbuf.o linuxbios.a /usr/lib/gcc-lib/i386-linux/3.2.3/libgcc.a perl -e 'foreach $var (split(" ", $ENV{VARIABLES})) { if ($ENV{$var} =~ m/^(0x[0-9a-fA-F]+|0[0-7]+|[0-9]+)$/) { print "$var = $ENV{$var};\n"; }}' > ldoptions gcc -nostdlib -nostartfiles -static -o linuxbios_c -T /home/fino/src/config/linuxbios_c.ld linuxbios_c.o linuxbios_c.o(.text+0x45a7): In function `video_tx_byte': : undefined reference to `beep' collect2: ld returned 1 exit status make: *** [linuxbios_c] Error 1 samyr:/home/fino/freebios/util/config/pcchips# Tnx Serafino From pyro at linuxlabs.com Mon May 5 09:53:01 2003 From: pyro at linuxlabs.com (steven james) Date: Mon May 5 09:53:01 2003 Subject: Documentation In-Reply-To: <3EB64A9E.6060707@telepolis.es> Message-ID: Greetings, The confusion is that there are multiple stages to LinuxBIOS. All x86 machines start at 0xf000:fff0 in real mode. The flash itself lives at the top of the 4GB address space and the chipset arranges for an alias at the top of the 1MB real mode address space. The instruction at that start address will be a jmp to the assembly language initialization code. Once the memory is set up, the next stage is copied from rom (possibly with decompression) to 0x80000 which includes _start. That code consists of a little assembly language (equivilant to crt0 in a normal C application) followed by the bulk of LinuxBIOS which is compiled from C. That code is entered at hardwaremain. G'day, sjames On Mon, 5 May 2003, Xavier Pegenaute wrote: > Hello, > > i'm doing documentation about the code of LinuxBios with ADLO for my > thesis, and i thought that may be you can helpme in things that are > usefull to know for understand the code of LinuxBios. Of course after > the document can be for linuxbios. > > I started by a mail of Greg Watson that explain how is linked crt0.S and > linuxbios, after this i started to explain the main things of > hardwaremain.c that jump to the elfboot and finally elfboot to kernel. > > Any one thing that is usefull to explain something else ? > > Another thing that is a little confused in me .., the true point of > start code, in some info say that is in 0xf0000, but in the compilation > of ms7308e i see that is in: > > linuxbios.map:00080004 T _start > > i supose that then it depends of the motherboard ... > > At the moment it's all. > Thanks for all. > Xavi. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From rminnich at lanl.gov Mon May 5 10:00:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 10:00:00 2003 Subject: EEPROM not found In-Reply-To: <200305050706.JAA86285@mailhub10.isdnet.net> Message-ID: Philippe, this FLASH write problem of yours is getting harder. I am worried that you have a motherboard with a "secret write enable". If this is the case, you have a few choices. One is to take the romimage and convert it to a flash image that the standard FLASH rewrite tool can handle, and then use the standard tool. The second is to find the "secret write enable" and figure out how it works. If you don't do much hardware, get a hardware friend to help. This is easier work than it sounds. Are you sure there is not a flash enable jumper on the board? ron From rminnich at lanl.gov Mon May 5 10:05:44 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 10:05:44 2003 Subject: readelf O/P of romiage(linuxbios+etherboot) question In-Reply-To: <20030505072058.F0AA250037@bom6.vsnl.net.in> Message-ID: For this level of debugging I usually use xxd. See what you see with that. ron From rminnich at lanl.gov Mon May 5 10:12:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 10:12:00 2003 Subject: make rom problem! In-Reply-To: <20030505095525.10124.qmail@learninghut.com> Message-ID: On Mon, 5 May 2003, Serafino Sorrenti wrote: > gcc -nostdlib -nostartfiles -static -o linuxbios_c -T > /home/fino/src/config/linuxbios_c.ld linuxbios_c.o > linuxbios_c.o(.text+0x45a7): In function `video_tx_byte': > : undefined reference to `beep' > collect2: ld returned 1 exit status This is the second error I have heard of but not seen with 'beep'. Can the person who put 'beep' in there please explain why it is there and what it does? thanks ron From steve at nexpath.com Mon May 5 11:04:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 11:04:01 2003 Subject: make rom problem! In-Reply-To: References: Message-ID: <3EB6877E.9010702@nexpath.com> ron minnich wrote: > This is the second error I have heard of but not seen with 'beep'. > > Can the person who put 'beep' in there please explain why it is there and > what it does? thanks > > ron That would be me. It is part of the vga console, and is supposed to make a noise for the bell code (\a). It is built unconditionally in pc80, but only used to my knowledge when "option VIDEO_CONSOLE=1", not sure why there is a problem. Seems to work for me. Maybe a missing "extern" somewhere? What is the compiler version? Serafino, send me your configuration file and I will see if I can figure out what the problem is. -Steve From steve at nexpath.com Mon May 5 11:21:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 11:21:00 2003 Subject: Documentation In-Reply-To: References: Message-ID: <3EB68B79.2080006@nexpath.com> steven james wrote: > All x86 > machines start at 0xf000:fff0 in real mode. > To be strictly correct, x86 machines start at 0xfffffff0 in real mode. ( IA-32 Intel Architecture Software Developer?s Manual Volume 3, System Programming Guide, sect. 9.1.4.). Quoting the manual, for those that don't have it handy: "The first instruction that is fetched and executed following a hardware reset is located at physical address FFFFFFF0H. This address is 16 bytes below the processor?s uppermost physical address. The EPROM containing the software-initialization code must be located at this address The address FFFFFFF0H is beyond the 1-MByte addressable range of the processor while in real-address mode. The processor is initialized to this starting address as follows. The CS register has two parts: the visible segment selector part and the hidden base address part. In real-address mode, the base address is normally formed by shifting the 16-bit segment selector value 4 bits to the left to produce a 20-bit base address. However, during a hardware reset, the segment selector in the CS register is loaded with F000H and the base address is loaded with FFFF0000H. The starting address is thus formed by adding the base address to the value in the EIP register (that is, FFFF0000 + FFF0H = FFFFFFF0H). The first time the CS register is loaded with a new value after a hardware reset, the processor will follow the normal rule for address translation in real-address mode (that is, [CS base address = CS segment selector * 16]). To insure that the base address in the CS register remains unchanged until the EPROM based software-initialization code is completed, the code must not contain a far jump or far call or allow an interrupt to occur (which would cause the CS selector value to be changed)." ----------- If the biosbase option is not set, almost immediately, linuxbios does a far jump to 0xf0000:0004, and so reloads the segment register such that the aliasing of this address to the top 4G becomes important, as Steven James points out. But setting biosbase=0xffff0000 will use a relative jump and actually execute physically in the top 4G. -Steve From dkotian3 at vsnl.net Mon May 5 11:43:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Mon May 5 11:43:01 2003 Subject: Runtime flow of LinuxBIOS with a payload(etherboot for IDE) for FLASHROM and IDE References: Message-ID: <009f01c31321$f2c2b140$313e41db@vsnl.net> Hi, How does the runtime flow of LinuxBIOS go. If I see the Makefile, the romimage is done using cat payload linixbios >romimage. 1. Why is the payload stuck before linuxbios, any specific reason ? 2. Is there some specific addressing rule one needs to flow when making/burning the payload and linuxbios , basically the sizing? 3. I assume that the entherboot payload is also copied to RAM , is this correct ? If yes, is there a way to know, if it is done properly. Regards Deepak From s.sorrenti at regia.tv Mon May 5 11:48:59 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Mon May 5 11:48:59 2003 Subject: problem with rom Message-ID: <20030505153523.10825.qmail@learninghut.com> This is my pcchips.config, in i have set video_console=0 but when i probe to make the file i have this error.\ gcc ... -o superio_sis_950.o /home/fino/src/superio/sis/950/superio.c /home/fino/src/superio/sis/950/superio.c:2: warning: `rcsid' defined but not used gcc ... -o nsuperio.o nsuperio.c gcc ... -o mainboard.o /home/fino/src/mainboard/pcchips/m810lmr/mainboard.c gcc ... -o irq_tables.o /home/fino/src/mainboard/pcchips/m810lmr/irq_tables.c gcc ... -o cpuid.o /home/fino/src/cpu/p5/cpuid.c /home/fino/src/cpu/p5/cpuid.c:3: warning: `rcsid' defined but not used gcc ... -o delay_tsc.o /home/fino/src/cpu/p5/delay_tsc.c /home/fino/src/cpu/p5/delay_tsc.c: In function `calibrate_tsc': /home/fino/src/cpu/p5/delay_tsc.c:102: warning: unused variable `allones' gcc ... -o microcode.o /home/fino/src/cpu/p6/microcode.c /home/fino/src/cpu/p6/microcode.c:7: warning: `rcsid' defined but not used gcc ... -o mtrr.o /home/fino/src/cpu/p6/mtrr.c /home/fino/src/cpu/p6/mtrr.c: In function `set_var_mtrr': /home/fino/src/cpu/p6/mtrr.c:132: warning: unused variable `tmp' /home/fino/src/cpu/p6/mtrr.c: At top level: /home/fino/src/cpu/p6/mtrr.c:29: warning: `rcsid' defined but not used gcc ... -o l2_cache.o /home/fino/src/cpu/p6/l2_cache.c /home/fino/src/cpu/p6/l2_cache.c:33: warning: `rcsid' defined but not used gcc ... -o cpufixup.o /home/fino/src/cpu/k7/cpufixup.c /home/fino/src/cpu/k7/cpufixup.c:8:1: warning: "TOP_MEM" redefined In file included from /home/fino/src/cpu/k7/cpufixup.c:6: /home/fino/src/include/cpu/k7/mtrr.h:38:1: warning: this is the location of the previous definition /home/fino/src/cpu/k7/cpufixup.c:9:1: warning: "TOP_MEM2" redefined /home/fino/src/include/cpu/k7/mtrr.h:39:1: warning: this is the location of the previous definition rm -f linuxbios.a ar cr linuxbios.a linuxbiosmain.o linuxpci.o newpci.o clog2.o printk.o serial_subr.o subr.o vsprintf.o memset.o memcpy.o memcmp.o malloc.o do_inflate.o delay.o compute_ip_checksum.o version.o keyboard.o mc146818rtc.o isa-dma.o ide.o boot.o linuxbios_table.o i386_subr.o params.o hardwaremain.o pirq_routing.o c_start.o southbridge.o northbridge.o superio_sis_950.o nsuperio.o mainboard.o irq_tables.o keyboard.o cpuid.o delay_tsc.o microcode.o mtrr.o l2_cache.o cpufixup.o cpufixup.o gcc -nostdlib -r -o linuxbios_c.o c_start.o docmil_fill_inbuf.o ide_fill_inbuf.o linuxbios.a /usr/lib/gcc-lib/i386-linux/3.2.3/libgcc.a perl -e 'foreach $var (split(" ", $ENV{VARIABLES})) { if ($ENV{$var} =~ m/^(0x[0-9a-fA-F]+|0[0-7]+|[0-9]+)$/) { print "$var = $ENV{$var};\n"; }}' > ldoptions gcc -nostdlib -nostartfiles -static -o linuxbios_c -T /home/fino/src/config/linuxbios_c.ld linuxbios_c.o linuxbios_c.o(.text+0x51a): In function `displayinit': : undefined reference to `video_init' linuxbios_c.o(.text+0x52e): In function `__display_tx_byte': : undefined reference to `video_tx_byte' linuxbios_c.o(.text+0x5ec1): In function `set_display': : undefined reference to `video_col' linuxbios_c.o(.text+0x5ec9): In function `set_display': : undefined reference to `video_line' collect2: ld returned 1 exit status make: *** [linuxbios_c] Error 1 samyr:/home/fino/freebios/util/config/pcchips# Tnx Serafino -------------- next part -------------- # Sample config file for PCCHIPS M810LMR with DoC Millennium (as root) # This will make a target directory of ./pcchips target pcchips # PCCHIPS M810LMR mainboard mainboard pcchips/m810lmr # We are using a k7 cpu (???) cpu k7 # Set up udelay - needed option CONFIG_UDELAY_TSC=1 # This SHOULD enable the video console with messages about what's going on option VIDEO_CONSOLE=0 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # Sets the log level, from 9 to 1 (???) option DEFAULT_CONSOLE_LOGLEVEL=6 # More debug options option SERIAL_POST=1 # Enables ethernet (?) option ENABLE_MII=1 # use DOC MIL option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 # Sets the amount of framebuffer memory # 0x80 (2MB/4MB) # 0x90 (4MB/8MB) # 0xA0 (8MB/16MB) # 0xB0 (16MB/32MB) # 0xC0 (32MB/64MB) # 0xD0 (64MB/na) option SMA_SIZE=0xC0 # Enables IDE boot option BOOT_IDE=1 # Selects which IDE device should boot from, using the following table: # /dev/hda -> 0 # /dev/hdb -> 1 # /dev/hdc -> 2 # /dev/hdd -> 3 option IDE_BOOT_DRIVE=0 # Partition table size (should be left untouched?) option ONE_TRACK=32 # Need to "relocate the gdt" to use a standard flash part (???) biosbase 0xffff0000 # Path to your kernel (vmlinux) linux /usr/src/linux # Kernel command line parameters commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 single From steve at nexpath.com Mon May 5 12:19:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 12:19:00 2003 Subject: problem with rom In-Reply-To: <20030505153523.10825.qmail@learninghut.com> References: <20030505153523.10825.qmail@learninghut.com> Message-ID: <3EB6992F.30401@nexpath.com> Serafino Sorrenti wrote: > This is my pcchips.config, in i have set video_console=0 but when i > probe to make the file i have this error. Try removing the video_console setting completely. -Steve From rminnich at lanl.gov Mon May 5 12:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 12:29:01 2003 Subject: problem with rom In-Reply-To: <20030505153523.10825.qmail@learninghut.com> Message-ID: sigh, my pcchips no longer builds at all :=( OK, more to look at. Current error is: crt0.s:435: Error: subtraction of two symbols in different sections `gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 52 make: *** [crt0.o] Error 1 Steve, do you have your pcchips.config file? ron From steve at nexpath.com Mon May 5 12:46:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 12:46:00 2003 Subject: problem with rom In-Reply-To: <20030505153523.10825.qmail@learninghut.com> References: <20030505153523.10825.qmail@learninghut.com> Message-ID: <3EB69F72.5020108@nexpath.com> Serafino Sorrenti wrote: > # use DOC MIL > option USE_DOC_MIL=1 > docipl northsouthbridge/sis/730/ipl.S > > # Need to "relocate the gdt" to use a standard flash part (???) > biosbase 0xffff0000 I don't believe you want to mix these two settings. ipl.S is real mode code. I would remove the biosbase setting altogether. Further, some of the config you have is from the pcchips787. The pcchips787 config is for the sis630 section; the sis730 code is different and many of the option settings from the pcchips787 are not going to work well, unfortunately. I converted the real mode code in the 630 directory so it would work, I think the same thing might have to be done for the 730, but I am not sure. -Steve From steve at nexpath.com Mon May 5 12:52:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 12:52:01 2003 Subject: problem with rom In-Reply-To: References: Message-ID: <3EB6A099.2040609@nexpath.com> ron minnich wrote: > sigh, my pcchips no longer builds at all :=( > > OK, more to look at. > > Current error is: > > crt0.s:435: Error: subtraction of two symbols in different sections > `gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 52 > make: *** [crt0.o] Error 1 > > > Steve, do you have your pcchips.config file? > Hmm, sure. It is attached. Would you like for me to check out the latest and build? The gdt code in sis630 is no longer needed anyway, since Eric changed the gdt in c_start.S. -Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pcchips787.config URL: From hansolofalcon at worldnet.att.net Mon May 5 12:58:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Mon May 5 12:58:00 2003 Subject: problem with rom In-Reply-To: <3EB69F72.5020108@nexpath.com> Message-ID: <000501c3132b$e9583760$0100a8c0@who5> Hello from Gregg C Levine Steve, now I am completely confused. Can you elaborate on the term "gdt"? I am familiar with its use, on the PC, during the time period that covers the pre-Linux era. Namely working in assembler for the IBM-PC, itself, during the 1980s to the 1990s. After that, I don't remember how it works. So, can you further elaborate? ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Steve Gehlbach > Sent: Monday, May 05, 2003 1:29 PM > To: Serafino Sorrenti > Cc: linuxbios at clustermatic.org > Subject: Re: problem with rom > > Serafino Sorrenti wrote: > > > # use DOC MIL > > option USE_DOC_MIL=1 > > docipl northsouthbridge/sis/730/ipl.S > > > > > > # Need to "relocate the gdt" to use a standard flash part (???) > > biosbase 0xffff0000 > > > I don't believe you want to mix these two settings. ipl.S is real mode > code. I would remove the biosbase setting altogether. > > Further, some of the config you have is from the pcchips787. The > pcchips787 config is for the sis630 section; the sis730 code is > different and many of the option settings from the pcchips787 are not > going to work well, unfortunately. I converted the real mode code in > the 630 directory so it would work, I think the same thing might have to > be done for the 730, but I am not sure. > > -Steve > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon May 5 13:05:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 13:05:01 2003 Subject: problem with rom In-Reply-To: <3EB6A099.2040609@nexpath.com> Message-ID: On Mon, 5 May 2003, Steve Gehlbach wrote: > Hmm, sure. It is attached. Would you like for me to check out the > latest and build? The gdt code in sis630 is no longer needed anyway, > since Eric changed the gdt in c_start.S. yes, please, see if it builds. ron From rsmith at bitworks.com Mon May 5 13:11:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 5 13:11:00 2003 Subject: Runtime flow of LinuxBIOS with a payload(etherboot for IDE) for FLASHROM and IDE In-Reply-To: <009f01c31321$f2c2b140$313e41db@vsnl.net> References: <009f01c31321$f2c2b140$313e41db@vsnl.net> Message-ID: <3EB6A201.5020201@bitworks.com> Deepak Kotian wrote: > If I see the Makefile, the romimage is done using > cat payload linixbios >romimage. > > 1. Why is the payload stuck before linuxbios, any specific > reason ? Linuxbios has to be the last bit of code in your rom image. See the recient thread on how the x86 starts up. You have to have startup code located at that upper address or you will be attempting to run data. Plus most chipsets will only assert the BIOS rom chipselect for specific address ranges. So you have to have your bios code located in those ranges or your rom won't be selected. Basically its a hardware thing. Linuxbios (or at least the startup code) needs to be located in the last 64k of address space. > 2. Is there some specific addressing rule one needs to flow > when making/burning the payload and linuxbios , basically the sizing? That's kinda board specific. Depends on how the chipset works and the size of your rom. For example on my board I have 2 512KiB roms. So I have to tweak ROM_IMAGE_SIZE and PAYLOAD_SIZE such that they equal 512KiB which locates linuxbios in the right spot. > 3. I assume that the entherboot payload is also copied to RAM , is > this correct ? Yes. > If yes, is there a way to know, if it is done properly. Sure. If it boots its probally done correctly. *grin* There are a few other items you can use to test though. 1) is the ramtest.inc code. Include it directly after you get ram setup. see freebios/src/ram/ramtest.inc When I was using this I had the following in my mainboard config file dirctly after my northbridge and southbridge inits mainboardinit ram/ramtest.inc mainboardinit mainboard/bitworks/rim/do_ramtest.inc where do_ramtest.inc calls the ram test routine. 2) Is to build memtest86 as an elfimage and boot that. Memtest does extensive memory testing. Of course you need elfboot working first. -- Richard A. Smith rsmith at bitworks.com From steve at nexpath.com Mon May 5 14:01:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 14:01:01 2003 Subject: problem with rom In-Reply-To: <000501c3132b$e9583760$0100a8c0@who5> References: <000501c3132b$e9583760$0100a8c0@who5> Message-ID: <3EB6B132.10002@nexpath.com> Gregg C Levine wrote: > Hello from Gregg C Levine > Steve, now I am completely confused. Can you elaborate on the term > "gdt"? I am familiar with its use, on the PC, during the time period > that covers the pre-Linux era. Namely working in assembler for the > IBM-PC, itself, during the 1980s to the 1990s. The gdt is one of a number of registers in the IA-32 model used for protected mode memory management (ie, for 32-bit mode). Typically, it is loaded to point to a data structure that defines a flat (ie, 4 GB) data segment, and an identical code segment, although you can in reality have many segments defined. These segments are referenced by their offset into the gdt data structure, for example in linux startup, 0x18 defines the data segment, and you would put this into the %ds register. This means the segment is defined 24 bytes into the gdt table. This is very different, of course, from how you use the %ds in real or 16-bit mode. Originally in linuxbios, the gdt was defined in flash, and not changed until jumping to linux. However, linux will hang if the gdt is located above 1M (not sure why, but I have tested this many times). So if you setup biosbase=0xffff0000, this would put the gdt high, and it has to be loaded low so linux will work. However, recently, Eric setup a gdt reload in c_start.S, which is relocated into ram below 1M, and so this will work fine for linux. This makes some gdt reload code I put into the sis630 area unnecessary. But the bottom line is you have to setup the gdt to point to a compatible (read that identical) gdt table to linux, before jumping to linux. Linux expects to be in 32-bit mode with the gdt data structure a certain way. You can see it at the bottom of linux/arch/i386/boot/setup.S in the kernel source tree. Anytime you go into protected mode, you have to setup the gdt, and usually also the idt, which handles interrupts. You can find more that you would ever want to know about it in the Intel reference manuals, but most folks just copy the table data from someone else. It is very painful code to debug, many bytes of the entries in the table requiring bit by bit settings. -Steve From dkotian3 at vsnl.net Mon May 5 15:02:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Mon May 5 15:02:01 2003 Subject: readelf O/P of romiage(linuxbios+etherboot) question References: Message-ID: <058d01c3133d$b4504c80$233e41db@vsnl.net> This seems to be hexdump utility like od -cx, what exactly one should look for in this to convince onself that the romimage is OK, any pointers ? ----- Original Message ----- From: "ron minnich" To: Cc: Sent: Monday, May 05, 2003 8:02 PM Subject: Re: readelf O/P of romiage(linuxbios+etherboot) question > For this level of debugging I usually use xxd. See what you see with that. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon May 5 15:18:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 15:18:01 2003 Subject: readelf O/P of romiage(linuxbios+etherboot) question In-Reply-To: <058d01c3133d$b4504c80$233e41db@vsnl.net> Message-ID: On Tue, 6 May 2003, Deepak Kotian wrote: > This seems to be hexdump utility like od -cx, what exactly one should look > for in this to convince onself that the romimage is OK, any pointers ? Look at the image that works and the one that does not and you will see what you need to look for. I am being a bit obscure here because I feel you need to spend some time working this out. thanks ron From rsmith at bitworks.com Mon May 5 15:42:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 5 15:42:01 2003 Subject: No keyboard. In-Reply-To: <3EB6A099.2040609@nexpath.com> References: <3EB6A099.2040609@nexpath.com> Message-ID: <3EB6C6C5.2070608@bitworks.com> My keyboard under linux isn't working. Dosen't appear to work under ADLO either. I've got it enabled and I added some more debugging printk's to keyboard.c. Things appear to be happing correctly there. So I'm fairly confident that the hardware is turned on. I'm suspecting its an IRQ issue. I see reference to assignirq in the hardwaremain.c and to a assignirq.c. If I enable CONFIG_ASSIGNIRQ then the compile fails claiming it can't find the file assignirq.c I did a find but assignirq.c dosen't seem to exist in my tree. Which is only about a week old. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Mon May 5 15:54:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 15:54:00 2003 Subject: No keyboard. In-Reply-To: <3EB6C6C5.2070608@bitworks.com> Message-ID: On Mon, 5 May 2003, Richard Smith wrote: > I'm suspecting its an IRQ issue. I see reference to assignirq in the > hardwaremain.c and to a assignirq.c. If I enable CONFIG_ASSIGNIRQ then > the compile fails claiming it can't find the file assignirq.c ron forgets a cvs add again. OK, I will add this tonight. I hope to get this assign irq stuff in in some form before may 12 (final freeze date -- may 8 seemed bad as it was a wednesday). Sorry about that. The 'no keyboard' sounds more like it could be a chipset thing. Are you sure it is enabled properly in the PIIX4? ron From rsmith at bitworks.com Mon May 5 16:11:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 5 16:11:01 2003 Subject: No keyboard Message-ID: <3EB6CD78.2080601@bitworks.com> >>I'm suspecting its an IRQ issue. I see reference to assignirq in the >>hardwaremain.c and to a assignirq.c. If I enable CONFIG_ASSIGNIRQ then >>the compile fails claiming it can't find the file assignirq.c > > ron forgets a cvs add again. OK, I will add this tonight. I hope to get > this assign irq stuff in in some form before may 12 (final freeze date -- > may 8 seemed bad as it was a wednesday). > > Sorry about that. > > The 'no keyboard' sounds more like it could be a chipset thing. Are you > sure it is enabled properly in the PIIX4? Pretty sure. I added printk's into the keyboard.c all the right bits appear to be getting set and in serveral places the keyboard routines check for a specific return value back from port 60 if these don't happen then I print out a failure. That all seems to run fine. I suppose I could make the keyboard code spin and wait for a keypress. That would for sure tell me the hardware was enabled. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Mon May 5 16:33:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 5 16:33:00 2003 Subject: No keyboard. In-Reply-To: References: Message-ID: <3EB6D2A1.5060604@bitworks.com> ron minnich wrote: > > can you run a user-mode program in linux (with serial console of course) > and test the keyboard from that? > > I do that a lot for this type of thing, saves time. Not really sure how thats any faster than just doing it in keyboard.c? I hack in some debug code to linuxbios way faster then writing a user-mode program. Believe it or not I haven't even setup a kernel for this system with serial console enabled. Guess its about time to do that. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Mon May 5 16:39:27 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 5 16:39:27 2003 Subject: No keyboard. In-Reply-To: <3EB6D2A1.5060604@bitworks.com> Message-ID: On Mon, 5 May 2003, Richard Smith wrote: > Not really sure how thats any faster than just doing it in keyboard.c? > I hack in some debug code to linuxbios way faster then writing a > user-mode program. not faster, but it can tell you if there is something funny happening after linuxbios is out of the picture. ron From rsmith at bitworks.com Mon May 5 17:58:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 5 17:58:01 2003 Subject: No keyboard. In-Reply-To: References: Message-ID: <3EB6E6C3.1080803@bitworks.com> ron minnich wrote: > ron forgets a cvs add again. OK, I will add this tonight. I hope to get > this assign irq stuff in in some form before may 12 (final freeze date -- > may 8 seemed bad as it was a wednesday). > Can you post something when its available?] > The 'no keyboard' sounds more like it could be a chipset thing. Are you > sure it is enabled properly in the PIIX4? I make keyboard.c wait until a keypress and that works so that indicates that IRQ 1 isn't being un-masked some how? Oh and seems that src/include/part/keyboard.h has an error its stil using #ifndef NO_KEYBOARD rather than #if NO_KEYBOARD == [0|1] this causes keyboard_on() to be defined as do {} while(0); I didn't notice it before because I was calling keyboard_on() from my mainboard.c file but looking in hardwaremain.c showed that that was unneeded. Of course then my keyboard code stopped getting called. -- Richard A. Smith rsmith at bitworks.com From steve at nexpath.com Mon May 5 22:07:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon May 5 22:07:00 2003 Subject: problem with rom In-Reply-To: References: Message-ID: <3EB7254D.60503@nexpath.com> ron minnich wrote: > sigh, my pcchips no longer builds at all :=( > > OK, more to look at. > > Current error is: > > crt0.s:435: Error: subtraction of two symbols in different sections > `gdt_end' {*UND* section} - `gdt' {*UND* section} at file address 52 > make: *** [crt0.o] Error 1 > > Using gcc2.95 and util/config/pcchips787.config, with the latest checkout, I get an error regarding beep, nothing like what you have above. The beep error is caused by a change to this line in src/pc80/Config: < object beep.o --- > object beep.o CONFIG_BEEP This was done in r1.6: revision 1.6 date: 2003/04/14 22:54:36; author: rminnich; state: Exp; lines: +3 -3 PPC commit The beep error can be cured by adding "option CONFIG_BEEP=1" in the config file. I assume this was needed since beep.c is x86 specific code. At the time I added beep.c, I thought everything in src/pc80 was x86 specific. (yes no ??) However, since beep is only used in the video console to my knowledge, it might be better to change it to "object beep.o VIDEO_CONSOLE" unless x86 style video is possible on the ppc. Otherwise CONFIG_BEEP is an obscure setting that needs to be set when using VIDEO_CONSOLE. -Steve From yenneo at oreka.com Tue May 6 04:12:01 2003 From: yenneo at oreka.com (Philippe CABANNES) Date: Tue May 6 04:12:01 2003 Subject: EEPROM not found In-Reply-To: Message-ID: <200305060847.KAA21923@mailhub7.isdnet.net> Thanks a lot for the advices. I've tried the utility from via (awfl823b.exe) with their BIOS file *.BIN. This worked without problems that's why i think it's not a hardware problem. Also my motherboard data sheet doesn't mention any jumper to enable writting... You mean i have to convert my romimage in a *.BIN file? I've looked for an utility which could do that but i didn't find. Can you please give the name. thanks in advance. -------------------------------------------------- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com From aip at cwlinux.com Tue May 6 04:41:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue May 6 04:41:01 2003 Subject: EEPROM not found In-Reply-To: <200305060847.KAA21923@mailhub7.isdnet.net>; from Philippe CABANNES on Tue, May 06, 2003 at 10:58:25AM +0100 References: <200305060847.KAA21923@mailhub7.isdnet.net> Message-ID: <20030506171712.A27055@mail.cwlinux.com> Philippe, > I've tried the utility from via (awfl823b.exe) with their BIOS file > *.BIN. This worked without problems that's why i think it's not a > hardware problem. > Also my motherboard data sheet doesn't mention any jumper to enable > writting... > You mean i have to convert my romimage in a *.BIN file? > I've looked for an utility which could do that but i didn't find. Can > you please give the name. You should be able to flash romimage using awfl823b.exe. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From s.sorrenti at regia.tv Tue May 6 05:24:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Tue May 6 05:24:01 2003 Subject: flash_rom problem Message-ID: <200305061159.45888.s.sorrenti@regia.tv> with the commit on serial_video i don't have any problem to make linuxbios.rom but when i probe to run flash_rom linuxbios.rom i have this output root at hashOne:~/freebios/util/flash_and_burn# ./flash_rom ../config/pcchips/linuxbios.rom Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 574M loops per second OK, calibrated, now do the deed Trying Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Trying At29C040A, 512 KB probe_jedec: id1 0xda, id2 0xb Trying Mx29f002, 256 KB probe_29f002: id1 218, id2 11 Trying SST29EE020A, 256 KB probe_jedec: id1 0xda, id2 0xb Trying SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Trying SST39SF020A, 256 KB probe_39sf020: id1 0xda, id2 0xb Trying SST39VF020, 256 KB probe_39sf020: id1 0xda, id2 0xb Trying W29C011, 128 KB probe_jedec: id1 0xda, id2 0xb Trying W29C020C, 256 KB probe_jedec: id1 0xda, id2 0xb Trying W49F002U, 256 KB probe_49f002: id1 0xda, id2 0xb W49F002U found at physical address: 0xfffc0000 Part is W49F002U root at hashOne:~/freebios/util/flash_and_burn# Tnx Serafino From ts1 at cma.co.jp Tue May 6 05:45:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Tue May 6 05:45:00 2003 Subject: EPIA success and problem Message-ID: <20030506102105.GA12268@cma.co.jp> I somehow succeeded to enable all of 256MB SDRAM at 133MHz, and to enable video using ADLO with original VGA BIOS, on EPIA 5000. It now boots into GRUB in less than 2 seconds. :) (It's too fast for IDE drive to spin up, so I have to hit reset button after cold start.) And, now a strange thing is happening. When I disable USE_GENERIC_ROM and enable BOOT_IDE to boot up the Linux kernel from LinuxBIOS directly, it hangs at "Allocating PCI resources...". It is before these options should take effect. What is happening?? With USE_GENERIC_ROM, memtest86 instead of ADLO as payload works fine (several passes ran without an error, so there is no memory problem). Before I began tweaking DRAM and video registers, I was using BOOT_IDE to boot directly into Linux just fine. -- Takeshi From adam at cfar.umd.edu Tue May 6 11:28:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 6 11:28:01 2003 Subject: EPIA success and problem In-Reply-To: <20030506102105.GA12268@cma.co.jp> Message-ID: <20030506121151.P80126-100000@www.missl.cs.umd.edu> > I somehow succeeded to enable all of 256MB SDRAM at 133MHz, > and to enable video using ADLO with original VGA BIOS, on EPIA 5000. cool. > It now boots into GRUB in less than 2 seconds. :) > (It's too fast for IDE drive to spin up, so I have to hit reset > button after cold start.) hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or two and see if it helps? -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Tue May 6 11:48:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 6 11:48:00 2003 Subject: EPIA success and problem In-Reply-To: <20030506121151.P80126-100000@www.missl.cs.umd.edu> References: <20030506121151.P80126-100000@www.missl.cs.umd.edu> Message-ID: Adam Sulmicki writes: > > I somehow succeeded to enable all of 256MB SDRAM at 133MHz, > > and to enable video using ADLO with original VGA BIOS, on EPIA 5000. > > cool. > > > It now boots into GRUB in less than 2 seconds. :) > > (It's too fast for IDE drive to spin up, so I have to hit reset > > button after cold start.) > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or > two and see if it helps? You need to put in the code to spin on the busy bit. See the ehterboot source for an example. Except on out of spec hardware that always works, and making certain the busy bit is cleared before using a drive is required for correct operation in all cases. Eric From adam at cfar.umd.edu Tue May 6 11:52:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 6 11:52:01 2003 Subject: EPIA success and problem In-Reply-To: Message-ID: <20030506123456.G80126-100000@www.missl.cs.umd.edu> > > > It now boots into GRUB in less than 2 seconds. :) > > > (It's too fast for IDE drive to spin up, so I have to hit reset > > > button after cold start.) > > > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or > > two and see if it helps? > > You need to put in the code to spin on the busy bit. > > See the ehterboot source for an example. > > Except on out of spec hardware that always works, and making > certain the busy bit is cleared before using a drive > is required for correct operation in all cases. I think that this code is already there. It just that this spin has an time-out option, just so that it won't hang for some weird reason. ATA_WAIT_COUNT should increase this timeout. Still thanks for pointer to etherboot. I'll check it out, it might give me better ideas how to do it :-) -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Tue May 6 12:15:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 6 12:15:01 2003 Subject: EPIA success and problem In-Reply-To: <20030506123456.G80126-100000@www.missl.cs.umd.edu> References: <20030506123456.G80126-100000@www.missl.cs.umd.edu> Message-ID: Adam Sulmicki writes: > > > > It now boots into GRUB in less than 2 seconds. :) > > > > (It's too fast for IDE drive to spin up, so I have to hit reset > > > > button after cold start.) > > > > > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or > > > two and see if it helps? > > > > You need to put in the code to spin on the busy bit. > > > > See the ehterboot source for an example. > > > > Except on out of spec hardware that always works, and making > > certain the busy bit is cleared before using a drive > > is required for correct operation in all cases. > > I think that this code is already there. > > It just that this spin has an time-out option, just so that it won't hang > for some weird reason. ATA_WAIT_COUNT should increase this timeout. > > Still thanks for pointer to etherboot. I'll check it out, it might give me > better ideas how to do it :-) If nothing else your timeout needs to be something like 31-32 seconds long. The maximum specified in the latest ATA specs is either 30 or 31 seconds, plus an additional second as a fudge factor. Also in there is code that correctly handles > 120GB drives. Eric From ts1 at cma.co.jp Tue May 6 13:50:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Tue May 6 13:50:01 2003 Subject: EPIA success and problem In-Reply-To: <20030506121151.P80126-100000@www.missl.cs.umd.edu> References: <20030506102105.GA12268@cma.co.jp> <20030506121151.P80126-100000@www.missl.cs.umd.edu> Message-ID: <20030506182625.GA21276@tsn.or.jp> On Tue, May 06, 2003 at 12:13:09PM -0400, Adam Sulmicki wrote: > > It now boots into GRUB in less than 2 seconds. :) > > (It's too fast for IDE drive to spin up, so I have to hit reset > > button after cold start.) > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or > two and see if it helps? Tried it but no success. I increased that value to 0xFFFFFFFF (it should be infinite :) but nothing changed. Also, I put some debug statement like this: // If we found something sc = inb(iobase1+ATA_CB_SC); sn = inb(iobase1+ATA_CB_SN); printf("A\n"); if ( (sc == 0x55) && (sn == 0xaa) ) { printf("B\n"); write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN); // reset the channel ata_reset (device); printf("C\n"); // check for ATA or ATAPI outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0); sc = inb(iobase1+ATA_CB_SC); sn = inb(iobase1+ATA_CB_SN); if ( (sc==0x01) && (sn==0x01) ) { printf("D\n"); cl = inb(iobase1+ATA_CB_CL); And the output is this: Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ [BOCHS BIOS VER:1.79] [COMPILE DATE:May 7 2003 TIME:03:04:48] DEVICE:0 A int13_harddisk: function 02, unmapped device for DL=80 Boot from Hard Disk 0 failed FATAL: Could not read the boot disk Then tried this: // If we found something sc = inb(iobase1+ATA_CB_SC); sn = inb(iobase1+ATA_CB_SN); printf("sc=%x sn=%x\n", sc, sn); if ( (sc == 0x55) && (sn == 0xaa) ) { write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN); And the result: [COMPILE DATE:May 7 2003 TIME:03:17:52] DEVICE:0 sc=0080 sn=0080 int13_harddisk: function 02, unmapped device for DL=80 Hope this helps. -- Takeshi From adam at cfar.umd.edu Tue May 6 13:54:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 6 13:54:00 2003 Subject: EPIA success and problem In-Reply-To: <20030506182625.GA21276@tsn.or.jp> Message-ID: <20030506143810.L81139-100000@www.missl.cs.umd.edu> grumbe. This code should correct initalization as per ATA-3 specs. what hard disk is this? I have tested the code with IBM TravelStar laptop hdd's and with SAMSUNG's hdd's. On Wed, 7 May 2003, SONE Takeshi wrote: > On Tue, May 06, 2003 at 12:13:09PM -0400, Adam Sulmicki wrote: > > > It now boots into GRUB in less than 2 seconds. :) > > > (It's too fast for IDE drive to spin up, so I have to hit reset > > > button after cold start.) > > > > hmm, in rombios.c, can you try increasing ATA_WAIT_COUNT by magnitude or > > two and see if it helps? > > Tried it but no success. > I increased that value to 0xFFFFFFFF (it should be infinite :) > but nothing changed. > > Also, I put some debug statement like this: > > // If we found something > sc = inb(iobase1+ATA_CB_SC); > sn = inb(iobase1+ATA_CB_SN); > > printf("A\n"); > if ( (sc == 0x55) && (sn == 0xaa) ) { > printf("B\n"); > write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN); > > // reset the channel > ata_reset (device); > printf("C\n"); > > // check for ATA or ATAPI > outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0); > sc = inb(iobase1+ATA_CB_SC); > sn = inb(iobase1+ATA_CB_SN); > if ( (sc==0x01) && (sn==0x01) ) { > printf("D\n"); > cl = inb(iobase1+ATA_CB_CL); > > And the output is this: > > Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ > [BOCHS BIOS VER:1.79] > [COMPILE DATE:May 7 2003 TIME:03:04:48] > > DEVICE:0 > A > > int13_harddisk: function 02, unmapped device for DL=80 > Boot from Hard Disk 0 failed > FATAL: Could not read the boot disk > > Then tried this: > // If we found something > sc = inb(iobase1+ATA_CB_SC); > sn = inb(iobase1+ATA_CB_SN); > > printf("sc=%x sn=%x\n", sc, sn); > if ( (sc == 0x55) && (sn == 0xaa) ) { > write_byte(ebda_seg,&EbdaData->ata.devices[device].type,ATA_TYPE_UNKNOWN); > > > And the result: > > [COMPILE DATE:May 7 2003 TIME:03:17:52] > > DEVICE:0 > sc=0080 sn=0080 > > int13_harddisk: function 02, unmapped device for DL=80 > > > Hope this helps. > > -- > Takeshi > -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From adam at cfar.umd.edu Tue May 6 14:17:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 6 14:17:00 2003 Subject: EPIA success and problem In-Reply-To: <20030506184659.GA22174@tsn.or.jp> Message-ID: <20030506150119.A81139-100000@www.missl.cs.umd.edu> > > grumbe. This code should correct initalization as per ATA-3 specs. > > what hard disk is this? > > It's a 20GB drive from Fujitsu. > > I'm thinking to replace this with a 2.5" drive. > Should I avoid Fujitsu next time? :) heh. dunno. It would be interesting to see why it fails. Is that b/c the loop times out or is that b/c it does not confirm to ATA specs, or something else. unfortunatelly I'm at the present time busy with other things nor I have the hardware to test. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rminnich at lanl.gov Tue May 6 14:40:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 6 14:40:01 2003 Subject: EPIA success and problem In-Reply-To: <20030506150119.A81139-100000@www.missl.cs.umd.edu> Message-ID: On Tue, 6 May 2003, Adam Sulmicki wrote: > > I'm thinking to replace this with a 2.5" drive. > > Should I avoid Fujitsu next time? :) just try a different drive. You need more data points. ron From rsmith at bitworks.com Tue May 6 15:02:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Tue May 6 15:02:01 2003 Subject: Net Difficulities In-Reply-To: References: Message-ID: <3EB80ECE.9000807@bitworks.com> Ronald G Minnich wrote: > assignirq.c is committed > I can't seem to get to sf and mail directly to Ron isn't makeing it either. Some like between me and the west coast must be down. Can some one check out this file and send it to me? -- Richard A. Smith rsmith at bitworks.com From mapsemdnes at hotmail.com Tue May 6 15:04:02 2003 From: mapsemdnes at hotmail.com (asdfas asdfasdf) Date: Tue May 6 15:04:02 2003 Subject: Suitable Dual-x86 motherboard Message-ID: Hi, I'm looking to buy a dual-processor x86 motherboard for my home PC. I'd like to play with LinuxBIOS on it. Could someone please recommend a suitable motherboard ? Thanks, G _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From aip at cwlinux.com Tue May 6 15:04:08 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue May 6 15:04:08 2003 Subject: Debugging the linuxBIOS code In-Reply-To: <20030423051552.90E854FF07@bom6.vsnl.net.in>; from dkotian3@vsnl.net on Wed, Apr 23, 2003 at 10:15:52AM +0500 References: <20030423051552.90E854FF07@bom6.vsnl.net.in> Message-ID: <20030423140439.B4356@mail.cwlinux.com> Deepak, > Thanks. I like this list for it's good responses. > Could you please elaborate on "POST card", what is it exactly ? > You are correct, I do not have a simulator. It is a PCI card which displays the value of port address 80. In LinuxBIOS source, it is not hard to find, eg. intel_chip_post_macro(0x11) It will dump 0x11 to port 80, and POST card will display 11 on its LED. While debugging, you can record the value and search thru the source to see where LinuxBIOS hangs. However, you can't do backtracing with this device. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From linuxbiosquery at rediffmail.com Tue May 6 15:04:11 2003 From: linuxbiosquery at rediffmail.com (siva kumar) Date: Tue May 6 15:04:11 2003 Subject: Where to download the latest LinuxBIOS code Message-ID: <20030423064057.4589.qmail@webmail29.rediffmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From tjm at codegen.com Tue May 6 15:04:14 2003 From: tjm at codegen.com (Thomas J. Merritt) Date: Tue May 6 15:04:14 2003 Subject: Hammer Documentation is now Available at AMD's website In-Reply-To: Your message of 22 Apr 2003 11:40:06 -0600. Message-ID: <200304231727.h3NHRFqV031140@tenor.codegen.com> |<><><><><> Original message from Eric W. Biederman <><><><><> |So far I have just skimmed the Documentation but it appears that |AMD has now publicly published everything needed to do Hammer |LinuxBIOS port. | |No great surprise but it is nice to actually see it ! | |Yeah! The chaos with the Dual Athlons has finally paid off :) It does appear that they have released all of the documentation necessary. The learning curve is pretty steep though. There are a lot of registers to program to make a box sing. We have been able to bring SmartFirmware up on our AMD Solo box. It has taken about 5 months to get to the point that we can now boot NetBSD. We're currently unable to boot Linux, but making progress on that front. On the LinuxBIOS front we're planning to leverage our x86-64 experience and provide commercial support for LinuxBIOS on AMD64 processors. With AMD's public release of the processor and chipset documentation we should be releived of most of our NDA obligations, and this will now become possible. If anyone has hardware and is contemplating bring up LinuxBIOS please let me know, since I don't want to duplicate effort if we can avoid it. TJ Merritt tjm at codegen.com 1-925-462-4300 x115 From tjm at codegen.com Tue May 6 15:04:16 2003 From: tjm at codegen.com (Thomas J. Merritt) Date: Tue May 6 15:04:16 2003 Subject: Hammer Documentation is now Available at AMD's website In-Reply-To: Your message of Wed, 23 Apr 2003 23:27:49 +0530. <015501c309c1$db4b7740$253e41db@vsnl.net> Message-ID: <200304231849.h3NInNqV031884@tenor.codegen.com> |<><><><><> Original message from "Deepak Kotian" <><><><><> |Sorry. |Could one please give the exact link/url where |AMD has now publicly published the LinuxBIOS |Port documentation. Did not find it easily. http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_739_9003,00.html TJ Merritt tjm at codegen.com 1-925-462-4300 x125 From tjm at codegen.com Tue May 6 15:04:19 2003 From: tjm at codegen.com (Thomas J. Merritt) Date: Tue May 6 15:04:19 2003 Subject: Hammer Documentation is now Available at AMD's website In-Reply-To: Your message of 23 Apr 2003 20:53:57 -0600. Message-ID: <200304240416.h3O4GcqV037513@tenor.codegen.com> |<><><><><> Original message from Eric W. Biederman <><><><><> |"Thomas J. Merritt" writes: | |> |<><><><><> Original message from Eric W. Biederman <><><><><> |> |So far I have just skimmed the Documentation but it appears that |> |AMD has now publicly published everything needed to do Hammer |> |LinuxBIOS port. |> | |> |No great surprise but it is nice to actually see it ! |> | |> |Yeah! The chaos with the Dual Athlons has finally paid off :) |> |> It does appear that they have released all of the documentation |> necessary. The learning curve is pretty steep though. There are |> a lot of registers to program to make a box sing. We have been |> able to bring SmartFirmware up on our AMD Solo box. It has taken |> about 5 months to get to the point that we can now boot NetBSD. |> We're currently unable to boot Linux, but making progress on that front. | |Hmm. I wonder if that is because of the open firmware chaos. Open Firmware is pretty much out of the picture when the kernel takes over. The primary problem is the wired assumptions in the legacy PC chaos. |So far I have not seen anything out of the ordinary in the way of |a learning curve, and I just booted a linux kernel. Keep in mind that our background is primarily PowerPC, Sparc, MIPS and ARM processors and we've avoided x86 for the most part. Learning the Hammer side of things has been relatively easy, it has been more painful learning the legacy PC stuff that hangs out in the 8111 I/O Hub. |> On the LinuxBIOS front we're planning to leverage our x86-64 experience |> and provide commercial support for LinuxBIOS on AMD64 processors. |> With AMD's public release of the processor and chipset documentation we |> should be releived of most of our NDA obligations, and this will now |> become possible. If anyone has hardware and is contemplating bring up |> LinuxBIOS please let me know, since I don't want to duplicate effort if |> we can avoid it. | |You have heard the talk about the freebios2 tree? | |Anyway Stefan Reinauer at SuSe and I are busily bringing it up. |So far so good. We are still in the stage where you hard code things, |so you know you understand what registers need to be programmed, |but everything has been straight forward so far. As straight forward as a PC can I would say. Given that you have experience with prior AMD chipsets, the Hammer should look pretty familiar. We've reviewed about 5000 pages of documentation in the last several months and have most of it digested now. TJ Merritt tjm at codegen.com 1-925-462-4300 x115 From davidmurdie at yahoo.co.uk Tue May 6 15:04:22 2003 From: davidmurdie at yahoo.co.uk (=?iso-8859-1?q?David=20Murdie?=) Date: Tue May 6 15:04:22 2003 Subject: Missing file (tbootfile.c) Message-ID: <20030425092616.44474.qmail@web40311.mail.yahoo.com> Just thought I'd mention that one of the files on the developers download page is missing. Its the 'C' code for tbootfile (Second last link on the download page) and the current link refers to it being in /developer/code/tbootfile.c Just thought I'd let you know. I initially tried sending this to webmaster at linuxbios.org, but it got bounced so I thought this would be the next port of call. (It probably doesn't need to go to the mailing list) Thanks, -- David Murdie __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From ts1 at tsn.or.jp Tue May 6 15:04:25 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue May 6 15:04:25 2003 Subject: Delay in copying Linuxbios to ram In-Reply-To: References: <3EA80024.1080401@nexpath.com> <005a01c30a8d$a2f15fa0$373e41db@vsnl.net> <3EA8421F.3040805@nexpath.com> <20030425091117.GA5673@cma.co.jp> <3EA9770D.4040507@nexpath.com> Message-ID: <20030428183028.GA11030@tsn.or.jp> On Fri, Apr 25, 2003 at 06:55:37PM -0600, Eric W. Biederman wrote: > > > In cpu/p6/earlymtrr.inc, 0xf0000-0xfffff is left uncached. > > > (Only 0-640KB is cached, 640KB-1M is uncached) > > > I will try adding code there to set fixed MTRR for 0xf0000-0xfffff > > > WP caching. > > > It should be harmless for other boards that do not need this, > > > what do you think? > > > > > > > Not sure. Need to see if the RAM is turned on for this region later after the > > C-code starts, if so, then the cache memory type may have to be changed from WP > > to normal. I tried it anyway and it worked great. Now I can't see anything between 'Copying LinuxBIOS to ram' and IDE loading message because it's too fast! > The generic code should handle this. I believe all of the mtrrs are rebuilt. I think it's rebuilt in mtrr.c. My modification is below. -- Takeshi Index: earlymtrr.inc =================================================================== RCS file: /cvsroot/freebios/freebios/src/cpu/p6/earlymtrr.inc,v retrieving revision 1.4 diff -u -r1.4 earlymtrr.inc --- earlymtrr.inc 8 Aug 2001 02:45:09 -0000 1.4 +++ earlymtrr.inc 28 Apr 2003 18:17:51 -0000 @@ -35,6 +35,22 @@ movl $0x06060606, %edx movl $0x06060606, %eax wrmsr + +#if _ROMBASE < 0x100000 + /* enable Write Protect Cache for 0x000f0000-0x000fffff */ + movl $MTRRfix4K_F0000_MSR, %ecx + rdmsr + movl $0x05050505, %edx + movl $0x05050505, %eax + wrmsr + + movl $MTRRfix4K_F8000_MSR, %ecx + rdmsr + movl $0x05050505, %edx + movl $0x05050505, %eax + wrmsr +#endif /* _ROMBASE < 0x100000 */ + #endif /* MEMORY_HOLE */ set_var_mtrr: From ts1 at tsn.or.jp Tue May 6 15:04:27 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue May 6 15:04:27 2003 Subject: Via EPIA In-Reply-To: <006001c30daa$9f405260$0f01a8c0@winxp> References: <006001c30daa$9f405260$0f01a8c0@winxp> Message-ID: <20030428183542.GB11030@tsn.or.jp> On Mon, Apr 28, 2003 at 06:21:36PM +0100, Russell Gower wrote: > Could someone please point me in the right direction. I need to enable wake > on Ring for the onboard serial port and/or AC power recovery on a via epia > 5000 mainboard. Did you see the datasheet of the southbridge (vt8231)? I guess it is a matter of setting right value in the right register, which should be described in the manual. Perhaps it can be done after OS is started (outside of LinuxBIOS). -- Takeshi From djc at cisco.com Tue May 6 15:04:31 2003 From: djc at cisco.com (Donald J Christensen) Date: Tue May 6 15:04:31 2003 Subject: [Etherboot-users] Re: Linuxbios + Etherboot + tagged Kernel Image References: <3EAB5125.4030106@nexpath.com> Message-ID: <3EAEE80A.22254A1A@cisco.com> Steve Gehlbach wrote: (Hey, Steve! How's it going?) > ron minnich wrote: > > > my mistake. What I have done is this for now: > > dd if=elfImage of=/dev/hda bs=4096 skip=1 > > > > preserves partition information. A kludge, but it works. > > > > IMHO it is a better solution than non-standard partitioning. Actually I > think the region past the first sector (512 bytes) is unused, if I am > reading http://www.ata-atapi.com/hiwtab.htm correctly. The 62 sectors after the MBR are not officially used, but there are apps and OSes that do make use of that space. For example, the latest version of TurboTax sticks some crap in there somewhere for its DRM mechanism. There was a big stink about it by some users, because it hosed other apps that also use that space. So if the PC is used for anything other than Linux (I don't know of any Linux OS or app related uses of that space), you might want to be careful. > One should also point out that this overlaps into partition 1, if that > is not obvious, so partition 1 should be large enough and unused. > > -Steve Alternatively, could partition 1 start farther along on the disk, leaving enough space for the kernel at the front of the disk? This would eliminate the possible confusion of having a partition that is off limits. (I haven't used the newer Etherboot, so I am not very familiar with this boot-from-disk capability.) -Don -- Don Christensen Senior Software Development Engineer djc at cisco.com Cisco Systems, Santa Cruz, CA "It was a new day yesterday, but it's an old day now." From franz at caos.at Tue May 6 15:04:34 2003 From: franz at caos.at (Lehner Franz) Date: Tue May 6 15:04:34 2003 Subject: programming mistake Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i hope, this is the correct channel now, i am not suscribed. when i programmed the cromwell ( the Bios on the Xbox) i compared a little with the Linux-bios, to avid programming problems. i copy'd some sources out of the CPU init, special, the microcode update src/cpu/p6/microcode.c you did a struct microcode *m; m = (void *)µcode_updates; ... but basically, this is wrong. it should more look like: struct microcode *m; m = (struct microcode *)microcode_updates; otherwise, the compleate microcode update procedure is "sensless" i hope, this helped you in your project, and good luck for the future franz -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPrfr2RbHVw21GxJvEQJ5JgCgx+wRY7bcVoznyEGv9u7w7DuhMzUAn0Jb tDi8bz+Zy0APTVoFWawL/XtC =q3gZ -----END PGP SIGNATURE----- From ts1 at tsn.or.jp Tue May 6 15:04:36 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue May 6 15:04:36 2003 Subject: EPIA success and problem In-Reply-To: <20030506143810.L81139-100000@www.missl.cs.umd.edu> References: <20030506182625.GA21276@tsn.or.jp> <20030506143810.L81139-100000@www.missl.cs.umd.edu> Message-ID: <20030506184659.GA22174@tsn.or.jp> On Tue, May 06, 2003 at 02:39:09PM -0400, Adam Sulmicki wrote: > > grumbe. This code should correct initalization as per ATA-3 specs. > > what hard disk is this? It's a 20GB drive from Fujitsu. $ sudo hdparm -i /dev/hda /dev/hda: Model=FUJITSU MPG3204AT E, FwRev=80B5, SerialNo=VH01P0C02R02 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=DualPortCache, BuffSize=512kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40031712 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 1 2 3 4 5 I'm thinking to replace this with a 2.5" drive. Should I avoid Fujitsu next time? :) -- Takeshi From ts1 at tsn.or.jp Tue May 6 15:04:39 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue May 6 15:04:39 2003 Subject: EPIA success and problem In-Reply-To: <20030506150119.A81139-100000@www.missl.cs.umd.edu> References: <20030506184659.GA22174@tsn.or.jp> <20030506150119.A81139-100000@www.missl.cs.umd.edu> Message-ID: <20030506191538.GA22924@tsn.or.jp> On Tue, May 06, 2003 at 03:02:21PM -0400, Adam Sulmicki wrote: > > > > grumbe. This code should correct initalization as per ATA-3 specs. > > > what hard disk is this? > > > > It's a 20GB drive from Fujitsu. > > > > I'm thinking to replace this with a 2.5" drive. > > Should I avoid Fujitsu next time? :) > > heh. dunno. It would be interesting to see why it fails. Is that b/c the > loop times out or is that b/c it does not confirm to ATA specs, or > something else. > > unfortunatelly I'm at the present time busy with other things nor I have > the hardware to test. I inserted a call to wait_for_notbusy prior to any tests, and it worked. :) I think this is what etherboot is doing (with appropreate timeout). In my case, the timeout is infinite, but even if I changed it to probe 4 devices, no visible delay was observed. (this is not a diff, cvs server seems too busy to give me a diff...) // Disable interrupts outb(iobase2+ATA_CB_DC, ATA_CB_DC_HD15 | ATA_CB_DC_NIEN); + // Wait for device to spin up + ata_wait_for_notbusy(iobase1); // Look for device outb(iobase1+ATA_CB_DH, slave ? ATA_CB_DH_DEV1 : ATA_CB_DH_DEV0); outb(iobase1+ATA_CB_SC, 0x55); -- Takeshi From rminnich at lanl.gov Tue May 6 15:08:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 6 15:08:01 2003 Subject: Net Difficulities In-Reply-To: <3EB80ECE.9000807@bitworks.com> Message-ID: I was going to update here and mail it to you but sf.net is not letting me in either. Q@#$#@!$ Intel just moved their infiniband project to BitKeeper; I'm beginning to wonder .... ron From rminnich at lanl.gov Tue May 6 16:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 6 16:04:00 2003 Subject: sourceforge is back In-Reply-To: <3EB6E6C3.1080803@bitworks.com> Message-ID: Richard, the sourceforge appears to be back, my cvs update is working. ron From rminnich at lanl.gov Tue May 6 16:33:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 6 16:33:01 2003 Subject: problem with rom In-Reply-To: <3EB7254D.60503@nexpath.com> Message-ID: On Mon, 5 May 2003, Steve Gehlbach wrote: > The beep error can be cured by adding "option CONFIG_BEEP=1" in the > config file. I assume this was needed since beep.c is x86 specific > code. At the time I added beep.c, I thought everything in src/pc80 was > x86 specific. (yes no ??) it was intended to be, but so many systems use pc80-style hardware (power pc, alpha, etc.) that pc80 is now included in other platforms. Too bad. > However, since beep is only used in the video console to my knowledge, > it might be better to change it to "object beep.o VIDEO_CONSOLE" unless I will do it this way. Makes much more sense. Changed and commit'ed -- please try it out. We're getting close to freezing freebios1, and I'd like to see if we can get as many platforms buildable as possible. ron From stuge-linuxbios at cdy.org Tue May 6 21:42:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue May 6 21:42:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha In-Reply-To: <3EB17664.3030905@bitworks.com> References: <3EB17664.3030905@bitworks.com> Message-ID: <20030507020557.GB13585@foo.birdnet.se> On Thu, May 01, 2003 at 02:32:52PM -0500, Richard Smith wrote: > Over the last 2 weeks or so I've been building a FAQ/HOWTO based on all > my experience getting LB up on our system. This is an excellent writeup! Put it on the web for all to see immediately. > option PAYLOAD_SIZE = > default = ? > Sets the size of the elf payload that is added to the LB rom image. Could this be automated if it really is just the size of the payload? Maybe I'm ahead of my time with this, but I'm thinking that the flash part or at least the flash size should be the only required size/byte/addresswise values in the configuration file and all of the rest be calculated. This allows the build system to output a final file with correct size and positioning of all blocks, alternatively an error. (e.g. "the specified payload will not fit in your flash rom, are you trying to use the Linux kernel with a small (2/4Mbit) memory? Try etherboot or ADLO instead.") //Peter From ts1 at cma.co.jp Wed May 7 03:03:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed May 7 03:03:00 2003 Subject: [Etherboot-users] Re: Linuxbios + Etherboot + tagged Kernel Image In-Reply-To: <3EAEE80A.22254A1A@cisco.com> References: <3EAB5125.4030106@nexpath.com> <3EAEE80A.22254A1A@cisco.com> Message-ID: <20030507073841.GA3691@cma.co.jp> On Tue, Apr 29, 2003 at 02:00:58PM -0700, Donald J Christensen wrote: > > IMHO it is a better solution than non-standard partitioning. Actually I > > think the region past the first sector (512 bytes) is unused, if I am > > reading http://www.ata-atapi.com/hiwtab.htm correctly. > > The 62 sectors after the MBR are not officially used, but there are > apps and OSes that do make use of that space. For example, the latest > version of TurboTax sticks some crap in there somewhere for its DRM > mechanism. There was a big stink about it by some users, because it > hosed other apps that also use that space. > > So if the PC is used for anything other than Linux (I don't know of > any Linux OS or app related uses of that space), you might want to > be careful. I think GRUB is using this space to store its "stage1.5" image. It's 6-9KB in size. -- Takeshi From yapeehuey at hotmail.com Wed May 7 03:35:01 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Wed May 7 03:35:01 2003 Subject: tusl2-c Message-ID: Hi all, This is asus tusl2-c board : Using 82815ep as north and ich2 as south, sis900.ebi as etherboot. First problem is it repeats the RAM initialization before it can really go into booting... Second problem is it repeats from beginning after setting the MTRRs type: UC . Any idea ? Thanks. lspci is listed below . my outputs: LinuxBIOS-1.0.0 Wed May 7 15:50:07 EDT 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. LinuxBIOS-1.0.0 Wed May 7 15:50:07 EDT 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Wed May 7 15:50:07 EDT 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 [8086/1130] PCI: 00:01.0 [8086/1131] PCI: 00:1e.0 [8086/244e] PCI: 00:1f.0 [8086/2440] PCI: 00:1f.1 [8086/244b] PCI: 00:1f.2 [8086/2442] PCI: 00:1f.3 [8086/2443] PCI: 00:1f.4 [8086/2444] PCI: 00:1f.5 [8086/2445] PCI: 00:1f.6 [8086/2446] PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1002/5144] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus for bus 2 PCI: 02:07.0 [13f6/0111] PCI: 02:0a.0 [10b7/9055] PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus returning with max=02 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] prefmem PCI: 00:01.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:01.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem PCI: 00:01.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0x00001000 - 0x000010ff] io PCI: 01:00.0 18 <- [0xfc000000 - 0xfc07ffff] mem ASSIGNED RESOURCES, bus 1 PCI: 00:1e.0 1c <- [0x00002000 - 0x00002fff] bus 2 io PCI: 00:1e.0 24 <- [0xfc200000 - 0xfc1fffff] bus 2 prefmem PCI: 00:1e.0 20 <- [0xfc100000 - 0xfc1fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:07.0 10 <- [0x00002000 - 0x000020ff] io PCI: 02:0a.0 10 <- [0x00002400 - 0x0000247f] io PCI: 02:0a.0 14 <- [0xfc100000 - 0xfc10007f] mem ASSIGNED RESOURCES, bus 2 PCI: 00:1f.1 20 <- [0x00003c00 - 0x00003c0f] io PCI: 00:1f.2 20 <- [0x000038c0 - 0x000038df] io PCI: 00:1f.3 20 <- [0x00003c10 - 0x00003c1f] io PCI: 00:1f.4 20 <- [0x000038e0 - 0x000038ff] io PCI: 00:1f.5 10 <- [0x00003000 - 0x000030ff] io PCI: 00:1f.5 14 <- [0x00003880 - 0x000038bf] io PCI: 00:1f.6 10 <- [0x00003400 - 0x000034ff] io PCI: 00:1f.6 14 <- [0x00003800 - 0x0000387f] io 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:1e.0 cmd <- 07 PCI: 00:1f.0 cmd <- 0f PCI: 00:1f.1 cmd <- 01 PCI: 00:1f.2 cmd <- 01 PCI: 00:1f.3 cmd <- 01 PCI: 00:1f.4 cmd <- 01 PCI: 00:1f.5 cmd <- 01 PCI: 00:1f.6 cmd <- 01 PCI: 01:00.0 cmd <- 83 PCI: 02:07.0 cmd <- 81 PCI: 02:0a.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized DRP0 = 0xe DIMM0 - size = 256M DIMM1 - size = 0M DRP1 = 0x0 DIMM2 - size = 0M totalram: 256M Initializing CPU #0 Updating microcode microcode_info: sig = 0x000006b1 pf=0x00000010 rev = 0x00000000 Enabling cache... Setting fixed MTRRs(0-88) type: UC LinuxBIOS-1.0.0 Wed May 7 15:50:07 EDT 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. I am using ASUS tusl2-c board : this is lspci 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 04) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 05) 00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 05) 00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 05) 00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 05) 00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 05) 00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 05) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon QD 02:07.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) Thx, regards, eehuey _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp From rminnich at lanl.gov Wed May 7 10:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 7 10:04:00 2003 Subject: tusl2-c In-Reply-To: Message-ID: It looks like a bad memory configuration to me. ron From rsmith at bitworks.com Wed May 7 11:08:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 7 11:08:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha In-Reply-To: <20030507020557.GB13585@foo.birdnet.se> References: <3EB17664.3030905@bitworks.com> <20030507020557.GB13585@foo.birdnet.se> Message-ID: <3EB92993.9060604@bitworks.com> Peter Stuge wrote: > On Thu, May 01, 2003 at 02:32:52PM -0500, Richard Smith wrote: > >>Over the last 2 weeks or so I've been building a FAQ/HOWTO based on all >>my experience getting LB up on our system. > > > This is an excellent writeup! Thank you *blush*. > Put it on the web for all to see immediately. Well it still needs a litte editing and proof reading yet before mass consumuption. I'd like to get some more info on all the config options. I also need to merge it with the current FAQ. Ron is that available in text form? Also Perhaps all the board owners can take a small break from hacking code and pick a few options they feel are important, write a small description and send them my way. >>option PAYLOAD_SIZE = >> default = ? >> Sets the size of the elf payload that is added to the LB rom image. > Could this be automated if it really is just the size of the payload? > > Maybe I'm ahead of my time with this, but I'm thinking that the flash part > or at least the flash size should be the only required size/byte/addresswise > values in the configuration file and all of the rest be calculated. Perhaps it is already and I just don't know how to use it. Currently I had to manually do the math for my rom size and payload size so that the result would match my rom part. > This allows the build system to output a final file with correct size and > positioning of all blocks, alternatively an error. (e.g. "the specified > payload will not fit in your flash rom, are you trying to use the Linux > kernel with a small (2/4Mbit) memory? Try etherboot or ADLO instead.") Sounds great. Would you like to try and code that up? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Wed May 7 11:55:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 7 11:55:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha In-Reply-To: <3EB92993.9060604@bitworks.com> Message-ID: On Wed, 7 May 2003, Richard Smith wrote: > I also need to merge it with the current FAQ. Ron is that available in > text form? yes, somebody had it and was going to fill it out with more info but I have not heard from them. I'll try to get it to you today. > >>option PAYLOAD_SIZE = > >> default = ? > >> Sets the size of the elf payload that is added to the LB rom image. yes. Start with a find . -name Config grep option .... and make a table. > > Maybe I'm ahead of my time with this, but I'm thinking that the flash part > > or at least the flash size should be the only required size/byte/addresswise > > values in the configuration file and all of the rest be calculated. yes, but not done yet. ron From dkotian3 at vsnl.net Wed May 7 14:24:00 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Wed May 7 14:24:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. Message-ID: <016b01c314ca$9a31a540$1f2141db@vsnl.net> Hi, after putting some debug statements, it seems the LinuxBIOS resets after the jmp instruction is boot.c ( " jmp *%%eax\n\t" in jmp_to_elf_entry) fails. I am using ETHERBOOT payload with IDE support. Is it because the ram initialization is not proper or something, has anyone experienced this kind of problem. Any pointers, why it should fail over here. Here is the extract of the log ... ********* calling elf load... New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 (cleaned up) New segment addr 0x94000 size 0x8128 offset 0x60 filesize 0x38d4 Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000008128 filesz: 0x00 000000000038d4 Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 Jumping to boot code at 0x94000 LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... Ram1 ********* Regards Deepak From rminnich at lanl.gov Wed May 7 15:05:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 7 15:05:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: <016b01c314ca$9a31a540$1f2141db@vsnl.net> Message-ID: that problem is typically RAM initialization. I think you are going to need to run memtest86 and look for problems. But congratulations, you are making progress. ron From rsmith at bitworks.com Wed May 7 15:20:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 7 15:20:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: <016b01c314ca$9a31a540$1f2141db@vsnl.net> References: <016b01c314ca$9a31a540$1f2141db@vsnl.net> Message-ID: <3EB964D7.5000009@bitworks.com> Deepak Kotian wrote: > I am using ETHERBOOT payload with IDE support. Is it because the ram > initialization is not proper or something, has anyone experienced this kind > of problem. > > Any pointers, why it should fail over here. > I would say a RAM problem. Have you run remtest.inc? -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Wed May 7 15:35:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 7 15:35:00 2003 Subject: No keyboard. Ahhaaa. In-Reply-To: <3EB6E6C3.1080803@bitworks.com> References: <3EB6E6C3.1080803@bitworks.com> Message-ID: <3EB9682D.8040701@bitworks.com> Richard Smith wrote: > >> The 'no keyboard' sounds more like it could be a chipset thing. Are >> you sure it is enabled properly in the PIIX4? I found the problem. Sure its enabled in the PIIX4 but that won't do much good when it's not enabled in the superIO. Seems all I did for the superIO was get setup_serial.inc to enable the serial port. So I guess I need to build one of them new fangled new_superIO config structures and get that into my mix. Whats the best superio.c and config example for the new superIO code to start with? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Wed May 7 15:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 7 15:41:01 2003 Subject: No keyboard. Ahhaaa. In-Reply-To: <3EB9682D.8040701@bitworks.com> Message-ID: On Wed, 7 May 2003, Richard Smith wrote: > So I guess I need to build one of them new fangled new_superIO config > structures and get that into my mix. yes. > Whats the best superio.c and config example for the new superIO code to > start with? ah. Well, try src/superio/winbond/w83977ef/superio.c ron From shubhangi.jadhav at patni.com Wed May 7 23:58:01 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Wed May 7 23:58:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbe the reason. In-Reply-To: Message-ID: Could you please elaborate on how to use memtest. Can we use it with etherboot, what is the procedure? Regards, Shubhangi -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org]On Behalf Of ron minnich Sent: Thursday, May 08, 2003 1:10 AM To: Deepak Kotian Cc: linuxbios at clustermatic.org Subject: Re: jmp INSTRUCTION IN boot.c fails and resets again , what couldbe the reason. that problem is typically RAM initialization. I think you are going to need to run memtest86 and look for problems. But congratulations, you are making progress. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From yapeehuey at hotmail.com Thu May 8 02:55:00 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Thu May 8 02:55:00 2003 Subject: tusl2-c Message-ID: Hi ron, Do you think my memory initialization failed ? RAMTEST is reporting "too many errors" so I disabled it . But how does the PCI codes run if my memory is not brought up ? Or do you mean the MTRR part only ? thx, regards, eehuey >From: ron minnich >To: Yap Ee Huey >CC: linuxbios at clustermatic.org >Subject: Re: tusl2-c >Date: Wed, 7 May 2003 08:38:14 -0600 (MDT) > >It looks like a bad memory configuration to me. > >ron > _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp From ts1 at cma.co.jp Thu May 8 03:02:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 8 03:02:00 2003 Subject: EPIA success and problem In-Reply-To: <20030506102105.GA12268@cma.co.jp> References: <20030506102105.GA12268@cma.co.jp> Message-ID: <20030508073840.GA1181@cma.co.jp> On Tue, May 06, 2003 at 07:21:05PM +0900, ts1 wrote: > And, now a strange thing is happening. > When I disable USE_GENERIC_ROM and enable BOOT_IDE to > boot up the Linux kernel from LinuxBIOS directly, > it hangs at "Allocating PCI resources...". > It is before these options should take effect. > What is happening?? I've found out a bit about this. When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9, the problem disappears. Also, when GCC 2.95 is used instead of GCC 3.2, it works ok. It looks like very delicate bug is some where in the code. As I said before, memtest86 does not find any RAM problem. -- Takeshi From stepan at suse.de Thu May 8 04:42:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu May 8 04:42:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: <016b01c314ca$9a31a540$1f2141db@vsnl.net> References: <016b01c314ca$9a31a540$1f2141db@vsnl.net> Message-ID: <20030508091820.GB927@suse.de> * Deepak Kotian [030507 20:55]: > after putting some debug statements, it seems the LinuxBIOS resets > after the jmp instruction is boot.c ( " jmp *%%eax\n\t" in jmp_to_elf_entry) > fails. > I am using ETHERBOOT payload with IDE support. Is it because the ram > initialization is not proper or something, has anyone experienced this kind > of problem. > > Any pointers, why it should fail over here. > > Clearing Segment: addr: 0x00000000000978d4 memsz: 0x0000000000004854 > Jumping to boot code at 0x94000 > > LinuxBIOS-1.0.0 Thu May 1 04:29:36 IST 2003 starting... > Ram1 I had the same thing after updating from etherbot 5.1.7 to 5.1.8 when I forgot to change the config file to build for LinuxBIOS instead of PC bios. I assume etherboot tries to call some intXX services early in that case which might cause the reboot. Did not investigate further after it worked though Best regards, Stefan Reinauer -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From dkotian3 at vsnl.net Thu May 8 05:01:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 8 05:01:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. Message-ID: <20030508101031.46B6450044@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From dkotian3 at vsnl.net Thu May 8 05:09:00 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Thu May 8 05:09:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. Message-ID: <20030508101837.49EC55008C@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From bendany at mistdl.com Thu May 8 05:45:00 2003 From: bendany at mistdl.com (bendany) Date: Thu May 8 05:45:00 2003 Subject: can not build std flash rom correctly Message-ID: <043001c316de$97481420$2a00a8c0@ben> I cann' t build the standard flashrom correctly. here is my config -------------------------------------------------------------- target k7sem mainboard elitegroup/k7sem cpu k7 option SERIAL_CONSOLE=1 option DEFAULT_CONSOLE_LOGLEVEL=8 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEBUG=1 option MII_ENABLE=1 option USE_GENERIC_ROM=1 option STD_FLASH=1 option ROM_SIZE=131072 option PAYLOAD_SIZE=65536 option USE_ELF_BOOT=1 payload ../sis900.ebi ---------------------------------------------- and after make. I found the romimage is strange. the lastest binary code is 0001ffe0h: EC 58 03 59 34 4D D3 19 42 03 69 6A 6B 6C 2C B2 ; ?X.Y4M?B.ijkl,? 0001fff0h: 4D D3 6D 6E 6F 02 DF 00 00 00 00 00 00 12 00 FF ; M?mno.?.......? and I know it should be (romimage from cwlinux.com) 0001ffe0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................ 0001fff0h: EA 04 00 00 F0 00 00 00 E9 5B 00 FF FF 00 00 00 ; ?..?..?[.??... and the linuxbios code does not start at address 00010000h, instead of 0001bbdch but when i use the follow config, and build again, the result code sounds correct. (the config I copy from the maillist) --------------------------------------------- target smartcore-p3 mainboard digitallogic/smartcore-p3 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 option DEFAULT_CONSOLE_LOGLEVEL=8 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEBUG=1 option USE_GENERIC_ROM=1 option STD_FLASH=1 option ROM_SIZE=131072 option ROM_IMAGE_SIZE=65536 option USE_ELF_BOOT=1 payload ../sis900.ebi -------------------------------------------------------------- is it something wrong with my config? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Thu May 8 09:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 09:07:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbe the reason. In-Reply-To: Message-ID: On Thu, 8 May 2003, Shubhangi Jadhav wrote: > Could you please elaborate on how to use memtest. > Can we use it with etherboot, what is the procedure? use memtest INSTEAD of etherboot as the payload. I have a memtest elfimage lying around here somewhere if you need it. ron From rminnich at lanl.gov Thu May 8 09:10:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 09:10:01 2003 Subject: tusl2-c In-Reply-To: Message-ID: On Thu, 8 May 2003, Yap Ee Huey wrote: > Do you think my memory initialization failed ? > RAMTEST is reporting "too many errors" so I disabled it . there is something wrong with your ram initialization. > But how does the PCI codes run if my memory is not brought up ? it's very strange what works and does not work when ram is "almost right". Partly this is because the cache can hide errors in RAM. At some point, however, the RAM errors cause failures. You will need to rework your RAM setup. I have forgotten what chipset you are using. ron From rminnich at lanl.gov Thu May 8 09:12:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 09:12:01 2003 Subject: EPIA success and problem In-Reply-To: <20030508073840.GA1181@cma.co.jp> Message-ID: On Thu, 8 May 2003, SONE Takeshi wrote: > I've found out a bit about this. > When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9, > the problem disappears. This sounds like a timing problem. > Also, when GCC 2.95 is used instead of GCC 3.2, > it works ok. not necessarily. I have had lots of trouble with via chipsets over the years that boiled down to race conditions in the chipset. I think you've hit another one. > It looks like very delicate bug is some where in the code. probably not a bug, but probably something we have to figure out how to work around. ron From shubhangi.jadhav at patni.com Thu May 8 09:24:00 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Thu May 8 09:24:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: Message-ID: I have tried it and it doesnot work. linuxbios resets at the jmp instruction, where it is supposed to jump from rom to ram. So how is memtest payload supposed to work, if there's a problem with ram initialization. Any other suggestions on how to use memtest. Regards, Shubhangi -----Original Message----- From: ron minnich [mailto:rminnich at lanl.gov] Sent: Thursday, May 08, 2003 7:12 PM To: Shubhangi Jadhav Cc: Deepak Kotian; linuxbios at clustermatic.org Subject: RE: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. On Thu, 8 May 2003, Shubhangi Jadhav wrote: > Could you please elaborate on how to use memtest. > Can we use it with etherboot, what is the procedure? use memtest INSTEAD of etherboot as the payload. I have a memtest elfimage lying around here somewhere if you need it. ron From ts1 at cma.co.jp Thu May 8 09:25:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 8 09:25:00 2003 Subject: EPIA success and problem In-Reply-To: References: <20030508073840.GA1181@cma.co.jp> Message-ID: <20030508140111.GA11808@cma.co.jp> On Thu, May 08, 2003 at 07:47:03AM -0600, ron minnich wrote: > > When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9, > > the problem disappears. > > This sounds like a timing problem. Note that in this case DEFAULT_CONSOLE_LOGLEVEL is still 8, so printk_spew's are compiled in but does not really print anything. > probably not a bug, but probably something we have to figure out how to > work around. Ok, it sounds like a delicate thing anyway... -- Takeshi From rminnich at lanl.gov Thu May 8 09:36:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 09:36:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: <20030508101837.49EC55008C@bom6.vsnl.net.in> Message-ID: RAMTEST is useful, but for real testing, you need memtest86. I hope your change fixed the problem. ron From rminnich at lanl.gov Thu May 8 09:40:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 09:40:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: Message-ID: On Thu, 8 May 2003, Shubhangi Jadhav wrote: > I have tried it and it doesnot work. > linuxbios resets at the jmp instruction, where it is supposed to jump from > rom to ram. So how is memtest payload supposed to work, if there's a problem > with ram initialization. are you setting CONFIG_COMPRESS=0 in your config? If not, do so. You don't want to use ram at all if ram is not working. ron From steve at nexpath.com Thu May 8 11:41:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu May 8 11:41:01 2003 Subject: problem with rom In-Reply-To: References: Message-ID: <3EBA84DA.2000605@nexpath.com> ron minnich wrote: > Changed and commit'ed -- > please try it out. I built the pcchips787.config and stpc.config, made roms and tested on the motherboards, all work okay, per the checked in configs. -Steve From nathanael at gnat.ca Thu May 8 11:59:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu May 8 11:59:00 2003 Subject: Flashing Bios Success... In-Reply-To: Message-ID: <1EB6CCCD-8173-11D7-8890-0003931B4D6A@gnat.ca> On Wednesday, May 7, 2003, at 03:06 PM, ron minnich wrote: > what is your southbridge part? can you look at the part directly? So I have the datasheet for the 5595 now (found using google so not sure whether I should send it to you) um either way to enable flash they talk about using the "address and data port, i.e. Port 70h and 71h, respectively. The access control with which the three portions of registers can be appropriately addressed are stored in PCI-ISA: 45h[3] (EXTEND_EN bit) and PCI-ISA: 45h[1](APCREG_EN bit)." but in the sis530 docs I get this for registers 70h: "Register 70h to register 76h define the attribute of the Shadow RAM from 640 KBytes to 1 MBytes. All of the registers 70h to 75h are defined as below, and each register defines the corresponding memory segment's attribute which are listed in the following table. REGISTER DEFINED RANGE REGISTER DEFINED RANGE Register 70h bits 7:5 0C0000h-0C3FFFh Register 73h bits 7:5 0D8000h-0DBFFFh" so I'm not sure how to set that in the 5595..? There must be some way through the pci bridge I think, but don't really know what I'm doing... so some pointers (or even pointers to some docs on how things work) would be great. Register 45h (on the 5595) controls the flash writability. But on the sis530 45h is "IDE Secondary Channel/Master Drive Data Active Time Control" so again it is a matter of knowing how to communicate with the 5595 instead of the main chipset. Now this is all great and what not, but I'm confused. We're having problems detecting the flash, not writing to it. So I'm not sure how this will help. As well in the flash_rom sources the enable_sis is never called. In going over the sources to devbios and the flash_rom, I realize that I don't know anything much about the pci/isa bridges and such... So basically I'm wondering what the next step is. 1) Does the write enable bit help with detecting? 2) Where do I get docs about how the pci & isa communication happens? 2a) do I need those docs? that's about it... -- Nathanael Noblet Gnat Solutions 4604 Monterey Ave NW Calgary, AB T3B 5K4 T/F 403.288.5360 C 403.809.5368 http://www.gnat.ca/ From rminnich at lanl.gov Thu May 8 12:08:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 12:08:01 2003 Subject: Flashing Bios Success... In-Reply-To: <1EB6CCCD-8173-11D7-8890-0003931B4D6A@gnat.ca> Message-ID: On Thu, 8 May 2003, Nathanael Noblet wrote: > So I have the datasheet for the 5595 now (found using google so not > sure whether I should send it to you) um either way to enable flash > they talk about using the send me the URL. > "Register 70h to register 76h define the attribute of the Shadow RAM > from 640 KBytes to 1 > MBytes. All of the registers 70h to 75h are defined as below, and each > register defines the > corresponding memory segment's attribute which are listed in the > following table. > REGISTER DEFINED RANGE REGISTER DEFINED RANGE > Register 70h bits 7:5 0C0000h-0C3FFFh Register 73h bits 7:5 > 0D8000h-0DBFFFh" not needed. > Register 45h (on the 5595) controls the flash writability. But on the > sis530 45h is "IDE Secondary Channel/Master Drive Data Active Time > Control" so again it is a matter of knowing how to communicate with the > 5595 instead of the main chipset. I think I need to see the doc. > Now this is all great and what not, but I'm confused. We're having > problems detecting the flash, not writing to it. So I'm not sure how > this will help. As well in the flash_rom sources the enable_sis is > never called. the reason is that you can't ID a flash without having write access to it. > 1) Does the write enable bit help with detecting? it is essential. Must have it. > 2) Where do I get docs about how the pci & isa communication happens? > 2a) do I need those docs? send me the URL first. If it's legal to look at the doc I will take a look. ron From stuge-linuxbios at cdy.org Thu May 8 12:32:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu May 8 12:32:01 2003 Subject: Flashing Bios Success... In-Reply-To: References: <1EB6CCCD-8173-11D7-8890-0003931B4D6A@gnat.ca> Message-ID: <20030508165601.GC24858@foo.birdnet.se> On Thu, May 08, 2003 at 10:42:52AM -0600, ron minnich wrote: > On Thu, 8 May 2003, Nathanael Noblet wrote: > > > Now this is all great and what not, but I'm confused. We're having > > problems detecting the flash, not writing to it. So I'm not sure how > > this will help. As well in the flash_rom sources the enable_sis is > > never called. > > the reason is that you can't ID a flash without having write access to it. > > > 1) Does the write enable bit help with detecting? > > it is essential. Must have it. To clarify this a bit; Most flash ROM chips are identified, erased and programmed according to a standard set by JEDEC. Byte-program, sector-erase, block-erase, chip-erase, software-id-entry and software-id-exit are the most common (the only?) commands available. Each command is up to six write cycles long. E.g. for byte-program: Write 0xaah to address 0x5555h in the ROM. Write 0x55h to address 0x2aaah in the ROM. Write 0xa0h to address 0x5555h in the ROM. Write byte-data to desired address in the ROM. Memory chips are identified by first entering the software-id mode: Write 0xaah to address 0x5555h in the ROM. Write 0x55h to address 0x2aaah in the ROM. Write 0x90h to address 0x5555h in the ROM. Now the 'manufacturer ID' and the 'device ID' bytes can be read from addresses 0 and 1 in the ROM, respectively. After reading the IDs, exit software-id mode thusly: Write 0xaah to address 0x5555h in the ROM. Write 0x55h to address 0x2aaah in the ROM. Write 0xf0h to address 0x5555h in the ROM. And so on. Grab a datasheet for the flash ROM chip you are working with, this will most likely be documented there too. //Peter From nathanael at gnat.ca Thu May 8 12:54:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu May 8 12:54:00 2003 Subject: Flashing Bios Success... In-Reply-To: <20030508165601.GC24858@foo.birdnet.se> Message-ID: On Thursday, May 8, 2003, at 10:56 AM, Peter Stuge wrote: > > To clarify this a bit; > > Most flash ROM chips are identified, erased and programmed according > to a > standard set by JEDEC. > > E.g. for byte-program: > > Write 0xaah to address 0x5555h in the ROM. > Write 0x55h to address 0x2aaah in the ROM. > Write 0xa0h to address 0x5555h in the ROM. > Write byte-data to desired address in the ROM. > > > Memory chips are identified by first entering the software-id mode: > Write 0xaah to address 0x5555h in the ROM. > Write 0x55h to address 0x2aaah in the ROM. > Write 0x90h to address 0x5555h in the ROM. > > Now the 'manufacturer ID' and the 'device ID' bytes can be read from > addresses 0 and 1 in the ROM, respectively. > > After reading the IDs, exit software-id mode thusly: > Write 0xaah to address 0x5555h in the ROM. > Write 0x55h to address 0x2aaah in the ROM. > Write 0xf0h to address 0x5555h in the ROM. > > And so on. Grab a datasheet for the flash ROM chip you are working > with, > this will most likely be documented there too. I have these, the problem is in detecting the flash in the first place, these sequences of commands don't return what they should. Ron is telling me this is because the write enable bit isn't set. So I now have the docks for the SiS5595 that I didn't know I had (doesn't show in lspci). So what I need to know is how to get access to the registers in the SiS 5595 that set the write enable so that we can detect it properly... and then all the JEDEC stuff would work. -- Nathanael Noblet Gnat Solutions 4604 Monterey Ave NW Calgary, AB T3B 5K4 T/F 403.288.5360 C 403.809.5368 http://www.gnat.ca/ From nathanael at gnat.ca Thu May 8 14:41:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu May 8 14:41:00 2003 Subject: Flashing Bios Success... In-Reply-To: Message-ID: On Thursday, May 8, 2003, at 01:04 PM, ron minnich wrote: > On 8 May 2003, Nathanael D. Noblet wrote: > >> 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev >> b3) >> 00: 39 10 08 00 0f 00 00 02 b3 00 01 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: c8 80 80 80 80 60 00 02 ff ff 10 0f 11 20 04 01 >> 50: 11 28 02 01 62 00 66 00 9c 2e 12 00 0c e9 00 00 >> 60: 0c 80 7f 00 34 01 00 00 90 02 80 00 20 1d 00 00 >> 70: 1e 00 00 80 80 08 00 00 00 00 00 80 00 00 80 00 >> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 90: 00 50 00 00 00 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 >> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > this is the south bridge. This is the "function" (sub-device) of the > southbridge that controls flash write. > > reg 0x45 has a value of: > 0x60, binary 0110 0000 > to make eeprom flashable, bits 5,2 must == 01. see page 76 of the book. > > bit 5 is 1 and bit 2 is 0, which I think is 10. We need to flip them. > > 0100 0100 > > 4 4 > > Try this > setpci -s 0:1.0 45.b (read the value) > setpci -s 0:1.0 45.b=44 > setpci -s 0:1.0 45.b (read the value back and make sure it is 44) > > then run flash_rom and see what happens. EEPROM Found! nice! So now I'll try getting good old linuxbios on there... Seriously thanks alot... Is there anything I need to do to flash_rom.c to get that to work all the time? having someone explain what the -xxx output is sure helps understand what it is (besides knowing it is a hex dump)... -- Nathanael Noblet Gnat Solutions 4604 Monterey Ave NW Calgary, AB T3B 5K4 T/F 403.288.5360 C 403.809.5368 http://www.gnat.ca/ From rminnich at lanl.gov Thu May 8 14:45:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 14:45:00 2003 Subject: Flashing Bios Success... In-Reply-To: Message-ID: well, now that we know what works, I want to patch flash_rom and have you test it. ron From rminnich at lanl.gov Thu May 8 14:57:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 14:57:01 2003 Subject: Flashing Bios Success... In-Reply-To: Message-ID: On Thu, 8 May 2003, Nathanael Noblet wrote: > Is there anything I need to do to flash_rom.c to get that to work all > the time? I just fixed flash_rom and committed. If you could reset your board (to reset the southbridge) and try just running flash_rom (NO manual setpci commands) let me know if this worked. ron From mwilkinson at ndirect.co.uk Thu May 8 15:15:01 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Thu May 8 15:15:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. Message-ID: <200305082041.09094.mwilkinson@ndirect.co.uk> Hi All, I think a bug has been introduced somewhere in the Via vt8601 ram initialisation which is causing this symptom. I have a VIA Epia 5000 mainboard with 128M ram, and using a fresh checkout from the CVS (when sourceforge finally let me :-) I built a fresh romimage. While this linuxbios image correctly reported 127M of ram (I assume that 1M grabbed by the vga chip) I kept seeing the fail, reset problem, where linuxbios would reset before getting a chance to jump to the loaded elf image. After commenting out the bit in the northbridge sizeram routine which sets the correct memory size, and just let it return the good old 64M, not only does the Image boot and load correctly, but memtest86 (v2.9) loaded and started running. Does this give anyone any ideas as to the problem ? Regards, Mark. From nathanael at gnat.ca Thu May 8 15:23:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu May 8 15:23:00 2003 Subject: Flashing Bios Success... In-Reply-To: Message-ID: <87AF0CDC-818F-11D7-A119-0003931B4D6A@gnat.ca> On Thursday, May 8, 2003, at 01:32 PM, ron minnich wrote: > I just fixed flash_rom and committed. If you could reset your board (to > reset the southbridge) and try just running flash_rom (NO manual setpci > commands) let me know if this worked. Sorry no it didn't though the output from your new function prints out OK... the ids 1 & 2 = 0xff -- Nathanael Noblet Gnat Solutions 4604 Monterey Ave NW Calgary, AB T3B 5K4 T/F 403.288.5360 C 403.809.5368 http://www.gnat.ca/ From rminnich at lanl.gov Thu May 8 15:28:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 15:28:00 2003 Subject: Flashing Bios Success... In-Reply-To: <87AF0CDC-818F-11D7-A119-0003931B4D6A@gnat.ca> Message-ID: On Thu, 8 May 2003, Nathanael Noblet wrote: > Sorry no it didn't though the output from your new function prints out > OK... > the ids 1 & 2 = 0xff never fails. Can you run flash_rom and send me this: lspci -s 0:1.0 -xxx thanks ron From rsmith at bitworks.com Thu May 8 15:41:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 8 15:41:00 2003 Subject: nsuperio compile error question In-Reply-To: References: Message-ID: <3EBABA06.9060907@bitworks.com> I'm haveing a little difficulity with the nsuperio setup. I keep getting a undefined reference to superio_NSC_pc87351_control I see that nlbconfig generates a prototype reference extern struct superio_control superio_NSC_pc87351_control; in nsuperio.c but I don't see where the the actual struct definition is/should be. -- Richard A. Smith rsmith at bitworks.com From mwilkinson at ndirect.co.uk Thu May 8 15:42:01 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Thu May 8 15:42:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: <200305082041.09094.mwilkinson@ndirect.co.uk> References: <200305082041.09094.mwilkinson@ndirect.co.uk> Message-ID: <200305082108.53957.mwilkinson@ndirect.co.uk> Hi All, Further to my previous message, I've modified the raminit.inc file to setup the RAM banks as the Award BIOS configured them, and let the sizeram routing do it's stuff as it should. The romimage, again reports the 127M, but this time jumps to the elf image correctly. Does anybody know how to correctly setup the RAM bank registers so that these values are not hard coded ? Ron, I've included a patch to modify the raminit.inc file (northbridge/via/vt8601) for 128M of ram. Regards Mark. On Thursday 08 May 2003 20:41, you wrote: > Hi All, > I think a bug has been introduced somewhere in the Via vt8601 ram > initialisation which is causing this symptom. > > I have a VIA Epia 5000 mainboard with 128M ram, and using a fresh checkout > from the CVS (when sourceforge finally let me :-) I built a fresh romimage. > > While this linuxbios image correctly reported 127M of ram (I assume that 1M > grabbed by the vga chip) I kept seeing the fail, reset problem, where > linuxbios would reset before getting a chance to jump to the loaded elf > image. > > After commenting out the bit in the northbridge sizeram routine which sets > the correct memory size, and just let it return the good old 64M, not only > does the Image boot and load correctly, but memtest86 (v2.9) loaded and > started running. > > Does this give anyone any ideas as to the problem ? > > Regards, > Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: 128Mram.patch Type: text/x-diff Size: 1150 bytes Desc: not available URL: From rminnich at lanl.gov Thu May 8 16:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 16:07:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: <200305082108.53957.mwilkinson@ndirect.co.uk> Message-ID: wow, what a pain that 8601 has been over the years. I think you should reset to the broken linuxbios settings, do a dumpnorth, and then dump the award settings and try to figure out, bit for bit, what's different and why. It's ugly and painful but usually the only thing that works. ron From rsmith at bitworks.com Thu May 8 16:07:09 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 8 16:07:09 2003 Subject: nsuperio... Never mind I found it. In-Reply-To: <3EBABA06.9060907@bitworks.com> References: <3EBABA06.9060907@bitworks.com> Message-ID: <3EBAC166.80500@bitworks.com> Richard Smith wrote: > in nsuperio.c but I don't see where the the actual struct definition > is/should be. I found it.. I missed updating that from the WinBond example I started with in my NSC/pc87351/superio.c file. -- Richard A. Smith rsmith at bitworks.com From james.mcmechan at navy.mil Thu May 8 18:36:01 2003 From: james.mcmechan at navy.mil (McMechan, James W CIV) Date: Thu May 8 18:36:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha Message-ID: <02E6075B2450E94CA159E22331C16204980F57@NAWECHLKEX02VA.nadsuswe.nads.navy.mil> >> I also need to merge it with the current FAQ. Ron is that available in >> text form? > > yes, somebody had it and was going to fill it out with more info > but I have not heard from them. > > I'll try to get it to you today. That would be me. I was still going over the faq. Alas I am slow... The source to the FAQ appears to be the web page's html. From rsmith at bitworks.com Thu May 8 19:18:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 8 19:18:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha In-Reply-To: <02E6075B2450E94CA159E22331C16204980F57@NAWECHLKEX02VA.nadsuswe.nads.navy.mil> References: <02E6075B2450E94CA159E22331C16204980F57@NAWECHLKEX02VA.nadsuswe.nads.navy.mil> Message-ID: <3EBAEE1A.5080208@bitworks.com> McMechan, James W CIV wrote: >>yes, somebody had it and was going to fill it out with more info >>but I have not heard from them. >> >>I'll try to get it to you today. > > That would be me. I was still going over the faq. > Alas I am slow... > The source to the FAQ appears to be the web page's html. Ok.. Well let me know when are ready to add in my stuff. I've added a few more items since my last post. On a sidenote... I've learned that OpenOffice 1.1beta can do DocBook stuff. I'd like to move my text document over to something like that so that you can autogenerate various formats. I pulled down OO1.1b but so far haven't been able to get the DocBook stuff enabled. (You have to go edit some XML config files and I don't seem to have done it correctly). As soon as I can get that setup I'll port my stuff over and attempt to do someting better with the format. And generate it into html,pdf,text, etc. Until then I'm not worrying about formatting. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Thu May 8 19:34:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 8 19:34:01 2003 Subject: Yay. Keyboard In-Reply-To: References: Message-ID: <3EBAF1A5.3020500@bitworks.com> I _finally_ got keyboard. Theres a bit in one of my superIO registers that handles the muxing of IRQ pins and some other functions. The default was not to have IRQ 1 enabled. I can see where if you have mutiple sio's in the system where you might want this bit set in one and not set in others. However the current superio config dosen't seem to have any facility for allowing configuration like this. You have to do it in code. Perhaps we should add a few new superio items to allow for this? like maybe struct sio_config_settings { unsigned char offset; unsigned char value; } And then in superio struct sio_config_settings config1, config2, config3; That would give you 3 other registers that you could set via the nsuperio statement. Or perhaps a new function pointer in superio_control specifically for per-chip setups that don't fall into the pre-defined catagories? -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Thu May 8 19:44:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 8 19:44:00 2003 Subject: more superio In-Reply-To: References: Message-ID: <3EBAF41A.4000203@bitworks.com> Also there dosen't seem to be any mouse device. The NSC pc87351 also does the mouse for our system. Can I add a mouse to the superio struct and the nlbconfig with out breaking everything? or just wait until freebios2 and just handle it in superio.c? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Thu May 8 20:07:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 20:07:01 2003 Subject: My Linux bios FAQ/HOWTO preAlpha In-Reply-To: <3EBAEE1A.5080208@bitworks.com> Message-ID: lyx claims to do docbook too. ron From rminnich at lanl.gov Thu May 8 20:09:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 20:09:00 2003 Subject: Yay. Keyboard In-Reply-To: <3EBAF1A5.3020500@bitworks.com> Message-ID: On Thu, 8 May 2003, Richard Smith wrote: > Or perhaps a new function pointer in superio_control specifically for > per-chip setups that don't fall into the pre-defined catagories? We need this. This is the type of thing Eric has mentioned. Richard, if you want to take a stab at structuring this we can get the new structure into freebios2. We also need to see how we would specify it in the Config files. ron From rminnich at lanl.gov Thu May 8 20:11:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 20:11:00 2003 Subject: more superio In-Reply-To: <3EBAF41A.4000203@bitworks.com> Message-ID: On Thu, 8 May 2003, Richard Smith wrote: > Can I add a mouse to the superio struct and the nlbconfig with out > breaking everything? or just wait until freebios2 and just handle it in > superio.c? let's fix this and get it right in freebios2. The overall approach of superio is I think OK, but it clearly needs to move away from the generic structure to a per-device type of structure, and we need a way to specify initialization of that structure in the config file. ron From stuge-linuxbios at cdy.org Thu May 8 21:17:00 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu May 8 21:17:00 2003 Subject: Flashing Bios Success... In-Reply-To: References: <20030508165601.GC24858@foo.birdnet.se> Message-ID: <20030509014140.GC10563@foo.birdnet.se> On Thu, May 08, 2003 at 11:30:19AM -0600, Nathanael Noblet wrote: > On Thursday, May 8, 2003, at 10:56 AM, Peter Stuge wrote: > > > >Memory chips are identified by first entering the software-id mode: > >Write 0xaah to address 0x5555h in the ROM. > >Write 0x55h to address 0x2aaah in the ROM. > >Write 0x90h to address 0x5555h in the ROM. > > > >Now the 'manufacturer ID' and the 'device ID' bytes can be read from > >addresses 0 and 1 in the ROM, respectively. > > > >After reading the IDs, exit software-id mode thusly: > >Write 0xaah to address 0x5555h in the ROM. > >Write 0x55h to address 0x2aaah in the ROM. > >Write 0xf0h to address 0x5555h in the ROM. > > I have these, the problem is in detecting the flash in the first place, > these sequences of commands don't return what they should. Ron is > telling me this is because the write enable bit isn't set. Exactly, three writes to the chip are required before the ID can be read. Without write enable signals flying the right way, no ID will be found. (Reading the ID is how the flash is "detected".) > So I now > have the docks for the SiS5595 that I didn't know I had (doesn't show > in lspci). So what I need to know is how to get access to the registers > in the SiS 5595 that set the write enable so that we can detect it > properly... and then all the JEDEC stuff would work. Yep, I saw that you've got this down now. Excellent! :) //Peter From ebiederman at lnxi.com Thu May 8 22:07:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu May 8 22:07:00 2003 Subject: Status freebios2... Message-ID: I am busily working on getting the switching from fallback to normal mode working in LinuxBIOS. To that end I have just implemented and committed structure and typedef support in LinuxBIOS. I realized the other day that to remove assembly code I would need to be able to call rdmsr && wrmsr from code compiled with romcc. rdmsr returns 2 values so I needed structure support. And typedef support was simple to implement and so I fixed it while I was in there. Hopefully I can now make some more progress. Eric From ebiederman at lnxi.com Thu May 8 22:26:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu May 8 22:26:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: References: Message-ID: ron minnich writes: > RAMTEST is useful, but for real testing, you need memtest86. > > I hope your change fixed the problem. RAMTEST is usually good enough to catch errors so bad you can't get past the BIOS without fixing them. Eric From rminnich at lanl.gov Thu May 8 22:41:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 8 22:41:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: Message-ID: On 8 May 2003, Eric W. Biederman wrote: > RAMTEST is usually good enough to catch errors so bad you > can't get past the BIOS without fixing them. Agreed. But the part in question has proved in the past to be unusually difficult (for me anyway) to get working. For this case I think memtest86 is appropriate. ron From noshel at idis.co.kr Fri May 9 03:53:01 2003 From: noshel at idis.co.kr (Edward J. Lee) Date: Fri May 9 03:53:01 2003 Subject: [linuxBIOS] IDE HDD detecting Message-ID: <3EBBE572.8090206@idis.co.kr> Hi guys, I'm new on the list. I'm using my own mainboard and I'm having problems with IDE HDD probing. the function ide_init() seems to return 0 *even* there are no HDDs attached on the system. Anyone know what to do? The one thing I noticed is that if there is no HDD ******************************** init_drive: sectors_per_track=[108], num_heads=[108], num_cylinders=[108] IDE1 108/108/108 cap: 006c ******************************** is printed. From shubhangi.jadhav at patni.com Fri May 9 04:46:01 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Fri May 9 04:46:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethereason. In-Reply-To: Message-ID: tried even setting CONFIG_COMPRESS=0 , but no luck.... -Shubhangi -----Original Message----- From: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org]On Behalf Of ron minnich Sent: Thursday, May 08, 2003 7:44 PM To: Shubhangi Jadhav Cc: Deepak Kotian; linuxbios at clustermatic.org Subject: RE: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethereason. On Thu, 8 May 2003, Shubhangi Jadhav wrote: > I have tried it and it doesnot work. > linuxbios resets at the jmp instruction, where it is supposed to jump from > rom to ram. So how is memtest payload supposed to work, if there's a problem > with ram initialization. are you setting CONFIG_COMPRESS=0 in your config? If not, do so. You don't want to use ram at all if ram is not working. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From shubhangi.jadhav at patni.com Fri May 9 09:52:00 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Fri May 9 09:52:00 2003 Subject: 810E northbridge initialization problem Message-ID: Hi, Here's the northdump and the lspci dump for the 810E northbridge. The only difference I see is in the PCISTS (PCI status) register setting (0x06-07h). Does this affect the ram initialization. In raminit.inc I'm setting the value of this register to 0x2080, but cannot see it being reflected in the northdump output. Could this cause problems in ram initialization? Also I have this small program which sets the value of the PCISTS register, however it modified the register value only the first time and never after that. Any pointers on what could be the reason? **************************northdump output :******************************* 00: 86 80 24 71 06 00 80 00 03 00 00 06 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 86 80 24 71 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 00 00 00 00 00 00 00 00 50: 28 53 0a 38 00 00 00 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: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: c6 78 18 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 eb fb 00 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 **************************northdump output :******************************* **************************lspci output :************************************* 00:00.0 Host bridge: Intel Corporation 82810E GMCH [Graphics Memory Controller Hub] (rev 03) 00: 86 80 24 71 06 00 80 20 03 00 00 06 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 86 80 24 71 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 00 00 00 00 00 00 00 00 50: 28 53 0a 38 00 00 00 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: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: c6 78 18 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 eb fb 00 00 00 00 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: 00 00 00 00 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 **************************lspci output :************************************* Regards, Shubhangi -------------- next part -------------- A non-text attachment was scrubbed... Name: testnorth.c Type: application/octet-stream Size: 1182 bytes Desc: not available URL: From s.sorrenti at regia.tv Fri May 9 10:23:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Fri May 9 10:23:01 2003 Subject: problem on boot Message-ID: <200305091659.02073.s.sorrenti@regia.tv> After make the linuxbios rom i have this problem, the machine is look on boot, and this is the log of the serial port. PCI devices initialized Enabled in SIS 503 regs 0x40 and 0x45 handle_superio start, s 0000b040 nsuperio 1 s->super 0000b318 handle_superio Pass 1, check #0, s 0000b040 s->super 0000b318 handle_superio: Pass 1, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 1, done #0 handle_superio done PCCHIPS M810LMR (and similar)...Entering the initregs process Southbridge fixup done for SIS 503 handle_superio start, s 0000b040 nsuperio 1 s->super 0000b318 handle_superio Pass 2, check #0, s 0000b040 s->super 0000b318 handle_superio: Pass 2, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e Call finishup handle_superio Pass 2, done #0 handle_superio done Copying IRQ routing tables to 0xf0000...done. Wrote linuxbios table at: 00000500 - 0000066c checksum ba14 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 New segment addr 0x400000 size 0xcba0 offset 0x60 filesize 0x8789 (cleaned up) New segment addr 0x400000 size 0xcba0 offset 0x60 filesize 0x8789 Loading Segment: addr: 0x0000000000400000 memsz: 0x000000000000cba0 filesz: 0x0000000000008789 Clearing Segment: addr: 0x0000000000408789 memsz: 0x0000000000004417 Jumping to boot code ROM segment 0x0000 length 0x0000 reloc 0x0000 Etherboot 5.0.6 (GPL) ELF for [SIS900] Boot from (N)etwork or from (L)ocal? clocks_per_tick = 784576 N I am now initializing the ide system init_drive sectors_per_track = [0], num_heads = [0],num_cylinders=[0], num_sectors = [0] CHS mode... Boot: (hd0,0)/kernel The machine is stalled with this messagges. Tnx Serafino From aod at unisys.com.br Fri May 9 10:37:00 2003 From: aod at unisys.com.br (Andre Dias) Date: Fri May 9 10:37:00 2003 Subject: PLCC paged flash? Message-ID: <5.1.0.14.0.20030509005928.0195e780@pop.unisys.com.br> Hello Folks, Is there any PLCC fkash chip that has paged memory like DOC, so we could use in the new motherboards? From rminnich at lanl.gov Fri May 9 10:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 10:41:01 2003 Subject: 810E northbridge initialization problem In-Reply-To: Message-ID: I need a URL for the 810e, please send it and I'll look at this. ron From rminnich at lanl.gov Fri May 9 10:46:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 10:46:01 2003 Subject: problem on boot In-Reply-To: <200305091659.02073.s.sorrenti@regia.tv> Message-ID: On Fri, 9 May 2003, Serafino Sorrenti wrote: > init_drive sectors_per_track = [0], num_heads = [0],num_cylinders=[0], > num_sectors = [0] > CHS mode... > > Boot: (hd0,0)/kernel you're going to need more debug prints. I have no good guess as to what this could be. ron From shubhangi.jadhav at patni.com Fri May 9 10:47:00 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Fri May 9 10:47:00 2003 Subject: 810E northbridge initialization problem In-Reply-To: Message-ID: Here's the datasheet for the 82810E GMCH www.intel.com/design/chipsets/datashts/29067602.pdf -Shubhangi -----Original Message----- From: ron minnich [mailto:rminnich at lanl.gov] Sent: Friday, May 09, 2003 8:46 PM To: Shubhangi Jadhav Cc: LinuxBIOS Subject: Re: 810E northbridge initialization problem I need a URL for the 810e, please send it and I'll look at this. ron From rminnich at lanl.gov Fri May 9 10:48:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 10:48:00 2003 Subject: PLCC paged flash? In-Reply-To: <5.1.0.14.0.20030509005928.0195e780@pop.unisys.com.br> Message-ID: On Fri, 9 May 2003, Andre Dias wrote: > Is there any PLCC fkash chip that has paged memory like DOC, so we could > use in the new motherboards? not that I have found. However the new intel 82801ac is the next best thing, 1 Mbyte and it Just Works Correctly. Let's hope intel gets bigger 82801 parts out. ron From s.sorrenti at regia.tv Fri May 9 10:56:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Fri May 9 10:56:01 2003 Subject: problem on boot Message-ID: <200305091732.40468.s.sorrenti@regia.tv> this is the full log of minicom Welcome to minicom 2.00.0 OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n Compiled on Apr 30 2003, 17:04:09. Press CTRL-A Z for help on special keys 0 LinuxBIOS-1.0.0 Tue Aug 13 16:28:27 HKT 2002 starting... Copying LinuxBIOS to ram. LinuxBIOS-1.0.0 Tue Aug 13 16:28:27 HKT 2002 booting... Finding PCI configuration type. PCI: Using configuration type 1 handle_superio start, s 0000b040 nsuperio 1 s->super 0000b318 handle_superio Pass 0, check #0, s 0000b040 s->super 0000b318 handle_superio: Pass 0, Superio SiS 950 handle_superio port 0x0, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1039/0730] PCI: 00:00.1 [1039/5513] PCI: 00:01.0 [1039/0008] PCI: 00:01.1 [1039/0900] PCI: 00:01.2 [1039/7001] PCI: 00:01.3 [1039/7001] PCI: 00:01.4 [1039/7018] PCI: 00:01.6 [1039/7013] PCI: 00:02.0 [1039/0001] PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1039/6300] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done totalram: 1016M 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: 512MB, type WB Setting variable MTRR 1, base: 512MB, range: 256MB, type WB Setting variable MTRR 2, base: 768MB, range: 128MB, type WB Setting variable MTRR 3, base: 896MB, range: 64MB, type WB Setting variable MTRR 4, base: 960MB, range: 32MB, type WB Setting variable MTRR 5, base: 992MB, range: 16MB, 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 : AuthenticAMD Processor Type : 0x00 Processor Family : 0x06 Processor Model : 0x08 Processor Mask : 0x00 Processor Stepping : 0x00 Feature flags : 0x0183f9ff MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Disabling local apic...done. CPU #0 Initialized Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] mem PCI: 00:00.1 10 <- [0x00002c90 - 0x00002c93] io PCI: 00:00.1 14 <- [0x00002ca0 - 0x00002ca3] io PCI: 00:00.1 18 <- [0x00002cb0 - 0x00002cb3] io PCI: 00:00.1 1c <- [0x00002cc0 - 0x00002cc3] io PCI: 00:00.1 20 <- [0x00002c80 - 0x00002c8f] io PCI: 00:01.1 10 <- [0x00002000 - 0x000020ff] io PCI: 00:01.1 14 <- [0xfc100000 - 0xfc100fff] mem PCI: 00:01.2 10 <- [0xfc101000 - 0xfc101fff] mem PCI: 00:01.3 10 <- [0xfc102000 - 0xfc102fff] mem PCI: 00:01.4 10 <- [0x00002400 - 0x000024ff] io PCI: 00:01.4 14 <- [0xfc103000 - 0xfc103fff] mem PCI: 00:01.6 10 <- [0x00002800 - 0x000028ff] io PCI: 00:01.6 14 <- [0x00002c00 - 0x00002c7f] io PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 ??????io PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 ??????prefmem PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 ??????mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io Allocating VGA resource done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07 PCI: 00:00.1 cmd <- 01 PCI: 00:01.0 cmd <- 0c PCI: 00:01.1 cmd <- 03 PCI: 00:01.2 cmd <- 02 PCI: 00:01.3 cmd <- 02 PCI: 00:01.4 cmd <- 03 PCI: 00:01.6 cmd <- 01 PCI: 00:02.0 cmd <- 27 PCI: 01:00.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized Enabled in SIS 503 regs 0x40 and 0x45 handle_superio start, s 0000b040 nsuperio 1 s->super 0000b318 handle_superio Pass 1, check #0, s 0000b040 s->super 0000b318 handle_superio: Pass 1, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 1, done #0 handle_superio done PCCHIPS M810LMR (and similar)...Entering the initregs process Southbridge fixup done for SIS 503 handle_superio start, s 0000b040 nsuperio 1 s->super 0000b318 handle_superio Pass 2, check #0, s 0000b040 s->super 0000b318 handle_superio: Pass 2, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e Call finishup handle_superio Pass 2, done #0 handle_superio done Copying IRQ routing tables to 0xf0000...done. Wrote linuxbios table at: 00000500 - 0000066c checksum ba14 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 New segment addr 0x400000 size 0xcba0 offset 0x60 filesize 0x8789 (cleaned up) New segment addr 0x400000 size 0xcba0 offset 0x60 filesize 0x8789 Loading Segment: addr: 0x0000000000400000 memsz: 0x000000000000cba0 filesz: 0x0000000000008789 Clearing Segment: addr: 0x0000000000408789 memsz: 0x0000000000004417 Jumping to boot code ROM segment 0x0000 length 0x0000 reloc 0x0000 Etherboot 5.0.6 (GPL) ELF for [SIS900] Boot from (N)etwork or from (L)ocal? clocks_per_tick = 784463 N I am now initializing the ide system init_drive sectors_per_track = [0], num_heads = [0],num_cylinders=[0], num_sectors = [0] CHS mode... Boot: (hd0,0)/kernel this is the output of the serial boot n boot. Tnx Serafino From mwilkinson at ndirect.co.uk Fri May 9 11:21:00 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Fri May 9 11:21:00 2003 Subject: Via VT8601 Northbridge sizeram Message-ID: <009001c31643$ab91e0f0$ce40a8c0@2pmtech.com> Hi Ron, While looking at the differences between the LinuxBIOS setting and the Award settings as you suggested yesterday, I came across this little problem. It seems that the sizeram routine is incorrectly reducing the memory size by 1M when there is nothing assigned to the VGA framebuffer. I've attached a patch that corrects the calculation. Regards Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sizeram.patch Type: application/octet-stream Size: 985 bytes Desc: not available URL: From rsmith at bitworks.com Fri May 9 11:36:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 11:36:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. Message-ID: <3EBBD356.9010000@bitworks.com> >>RAMTEST is usually good enough to catch errors so bad you >>can't get past the BIOS without fixing them. > > Agreed. But the part in question has proved in the past to be unusually > difficult (for me anyway) to get working. For this case I think memtest86 > is appropriate. I guess I don't understand how memtest86 is going to load and run if he can't sucessfully jump to a loaded elf image. -- Richard A. Smith rsmith at bitworks.com -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Fri May 9 11:40:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 11:40:01 2003 Subject: problem on boot In-Reply-To: <200305091659.02073.s.sorrenti@regia.tv> References: <200305091659.02073.s.sorrenti@regia.tv> Message-ID: <3EBBD446.4080405@bitworks.com> Serafino Sorrenti wrote: > Etherboot 5.0.6 (GPL) ELF for [SIS900] > Boot from (N)etwork or from (L)ocal? clocks_per_tick = 784463 > I am now initializing the ide system > init_drive sectors_per_track = [0], num_heads = [0],num_cylinders=[0], > num_sectors = [0] > CHS mode... Dosen't look like your IDE drive is getting detected properly whigh keeps it from loading a valid kernel image. Try Etherboot 5.1.8 and see what happens. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Fri May 9 11:50:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 11:50:00 2003 Subject: [linuxBIOS] IDE HDD detecting In-Reply-To: <3EBBE572.8090206@idis.co.kr> References: <3EBBE572.8090206@idis.co.kr> Message-ID: <3EBBD6A7.30409@bitworks.com> Edward J. Lee wrote: > Hi guys, I'm new on the list. Welcome to linuxBIOS. > I'm using my own mainboard and I'm having problems with > IDE HDD probing. the function ide_init() seems to return 0 > *even* there are no HDDs attached on the system. > > Anyone know what to do? Well when I had issues with the native LinuxBIOS IDE code not detecting the CHS properly with my CF the response I received was to use the ide driver of Etherboot. So I got Etherboot 5.1.8 and that fixed my issues. I would say try etherboot and see if that works then when you know your hardware is correctly configured and working you can do some compare/contrast with etherboot and see whats wrong with LB IDE. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Fri May 9 11:59:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 11:59:01 2003 Subject: more superio In-Reply-To: References: Message-ID: <3EBBD8C8.5050202@bitworks.com> ron minnich wrote: >>Can I add a mouse to the superio struct and the nlbconfig with out >>breaking everything? or just wait until freebios2 and just handle it in >>superio.c? > > let's fix this and get it right in freebios2. > > The overall approach of superio is I think OK, but it clearly needs to > move away from the generic structure to a per-device type of structure, > and we need a way to specify initialization of that structure in the > config file. Hmmmm.... I'll think about this.. but I'm a little time constrained right now... I worry about not giving it enought thought and coming up with something that will end up being undocumented and difficult to config. Figureing out what all the config options do already is quite involved. I'm sure Eric will have some good ideas as well when he gets further along with freebios2. Maybe we should attempt to generate a list of requirements the new structure would need. List members can then chime in on if it would meet thier needs or not. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri May 9 13:06:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 13:06:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what could be the reason. In-Reply-To: <3EBBD356.9010000@bitworks.com> Message-ID: On Fri, 9 May 2003, Richard Smith wrote: > I guess I don't understand how memtest86 is going to load and run if he > can't sucessfully jump to a loaded elf image. oops. sorry. ignore me on this one :-) ron From russell at abc9986.demon.co.uk Fri May 9 13:46:01 2003 From: russell at abc9986.demon.co.uk (Russell Gower) Date: Fri May 9 13:46:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. Message-ID: <008901c31658$059c2c40$0f01a8c0@winxp> > I couldn't get the ram init to work at all with any of my DIMMS on a Epia > 5000. > So I hacked my build to use the generic SPD routines for ram init, It works > a treat but i'm way out of sync with CVS now! and i don't know how to > produce the right sort of diff ( don't laugh) If you tell me what > parameters to use i'll have a go if anyone is intrested. > > > Russell > > Sorry if this appears twice, I'll remember to send it from the right Email address one day! From bari at onelabs.com Fri May 9 14:00:01 2003 From: bari at onelabs.com (Bari Ari) Date: Fri May 9 14:00:01 2003 Subject: PLCC paged flash? References: Message-ID: <3EBBF565.5020900@onelabs.com> ron minnich wrote: >Let's hope intel gets bigger 82801 parts out. > > > ST makes a 2MB (16Mb) part: http://www.st.com/stonline/books/pdf/docs/9353.pdf larger parts are on the way since EFI is currently in the crystal ball. --Bari From adam at cfar.umd.edu Fri May 9 14:13:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri May 9 14:13:00 2003 Subject: PLCC paged flash? In-Reply-To: <3EBBF565.5020900@onelabs.com> Message-ID: <20030509145458.F96799-100000@www.missl.cs.umd.edu> > >Let's hope intel gets bigger 82801 parts out. > ST makes a 2MB (16Mb) part: > http://www.st.com/stonline/books/pdf/docs/9353.pdf > larger parts are on the way since EFI is currently in the crystal ball. nice... while this chip is nice TSOP40 packaging is not. It is so incredibly fragile :-( For that matter. Does anyone here uses AD40-TS40-FLASH adapter? I have here one from Ice Technologies Lcd. Now the issue is that I'm not 100% sure where is the Pin 1 both in the TSOP socket as well as in the DIP. Also on my motherboard I have this coffin-like socket for TSOP40. Has anyone got such socket to work with Rom Emulator? -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rsmith at bitworks.com Fri May 9 14:59:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 14:59:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: <008901c31658$059c2c40$0f01a8c0@winxp> References: <008901c31658$059c2c40$0f01a8c0@winxp> Message-ID: <3EBC02C5.6030301@bitworks.com> Russell Gower wrote: >>I couldn't get the ram init to work at all with any of my DIMMS on a Epia >>5000. >>So I hacked my build to use the generic SPD routines for ram init, It > > works Eric's code is good stuff eh? Did you remember to change the row page size to look at the number of column address bits rather than the row address bits? >>a treat but i'm way out of sync with CVS now! and i don't know how to >>produce the right sort of diff ( don't laugh) If you tell me what >>parameters to use i'll have a go if anyone is intrested. Insure that you have 'diff' installed on your system. 'diff --version' If not then install it. Move your tree to a new directory. Lets call it 'freebios_russell'. then re-checkout the freebios module from cvs. Move up to a directory above freebios and freebios_russell Now do a: 'diff -c -r -b --exclude=CVS ./path/to/freebios ./path/to/freebios_russell > lb_russell.diff' Note: my mailer wrapped the above line... It's all one command. Then send that rusulting lb_russell.dif to Ron. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri May 9 15:42:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 15:42:01 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: <004501c31657$51f08970$0f01a8c0@winxp> Message-ID: I think the best bet is cvs diff -u, and then send it to andrew ip and me, and we'll see what we can do. ron From ebiederman at lnxi.com Fri May 9 15:56:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri May 9 15:56:01 2003 Subject: more superio In-Reply-To: <3EBBD8C8.5050202@bitworks.com> References: <3EBBD8C8.5050202@bitworks.com> Message-ID: Richard Smith writes: > ron minnich wrote: > > >> Can I add a mouse to the superio struct and the nlbconfig with out breaking > >> everything? or just wait until freebios2 and just handle it in superio.c? > > let's fix this and get it right in freebios2. The overall approach of superio > > is I think OK, but it clearly needs to move away from the generic structure to > > > a per-device type of structure, and we need a way to specify initialization of > > > that structure in the config file. > > Hmmmm.... I'll think about this.. but I'm a little time constrained right now... > > I worry about not giving it enought thought and coming up with something that > will end up being undocumented and difficult to config. Figureing out what all > the config options do already is quite involved. > > I'm sure Eric will have some good ideas as well when he gets further along with > freebios2. > > Maybe we should attempt to generate a list of requirements the new structure > would need. List members can then chime in on if it would meet thier needs or > not. How the structure stuff gets generated needs more work. But it will definitely not be one structure it will be a list of structures. That way we can reuse a generic serial or irq structure, and only invent new structures for new things that come along. This has been talked about some before but we haven't quite got that far yet. Eric From rsmith at bitworks.com Fri May 9 16:08:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 16:08:00 2003 Subject: jmp INSTRUCTION IN boot.c fails and resets again , what couldbethe reason. In-Reply-To: References: Message-ID: <3EBC130C.6080305@bitworks.com> ron minnich wrote: > I think the best bet is cvs diff -u, and then send it to andrew ip and me, > and we'll see what we can do. I though I remembered a specific request for context output format on diffs. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Fri May 9 17:02:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri May 9 17:02:00 2003 Subject: IRQ routing table? In-Reply-To: References: Message-ID: <3EBC1FC1.4000806@bitworks.com> Do I have to have a that big IRQ routing table or is there a simpler LinuxBIOS way? If not since I don't have a table to begin with I'll have to hand generate one. The microsoft documentation claims that the IRQ routing table is for legacy systems that cannot do dynamic IRQ routing and that ACPI systems should use the ACPI based method. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri May 9 17:13:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 9 17:13:00 2003 Subject: IRQ routing table? In-Reply-To: <3EBC1FC1.4000806@bitworks.com> Message-ID: On Fri, 9 May 2003, Richard Smith wrote: > Do I have to have a that big IRQ routing table or is there a simpler > LinuxBIOS way? If not since I don't have a table to begin with I'll > have to hand generate one. If you know what values to set on the irq pin for each PCI device for your board, just hard-wire them in hardwaremain, and set the router settings too. You only need the IRQ table if you want linux to do all the routing work. > The microsoft documentation claims that the IRQ routing table is for > legacy systems that cannot do dynamic IRQ routing and that ACPI systems > should use the ACPI based method. ah, what do they know anyway :-) I saw that comment on ACPI but fact is, our newest mobos still have that IRQ table in there. ron From pyro at linuxlabs.com Fri May 9 17:28:00 2003 From: pyro at linuxlabs.com (steven james) Date: Fri May 9 17:28:00 2003 Subject: e7501 ram w/ 533 FSB Message-ID: Greetings, I finally got some hardware in to test that. I have it working now and will commit once I verify it still works for the 400 FSB case. Seems that setting 0x0bb1 into 0x80 on the northbridge is a good idea after all. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From noshel at idis.co.kr Fri May 9 20:21:01 2003 From: noshel at idis.co.kr (Edward J. Lee) Date: Fri May 9 20:21:01 2003 Subject: [linuxBIOS] IDE HDD detecting In-Reply-To: <3EBBD6A7.30409@bitworks.com> References: <3EBBE572.8090206@idis.co.kr> <3EBBD6A7.30409@bitworks.com> Message-ID: <3EBCCC56.5080401@idis.co.kr> Richard Smith wrote: > Edward J. Lee wrote: > >> Hi guys, I'm new on the list. > > > Welcome to linuxBIOS. > >> I'm using my own mainboard and I'm having problems with >> IDE HDD probing. the function ide_init() seems to return 0 >> *even* there are no HDDs attached on the system. >> >> Anyone know what to do? > > > Well when I had issues with the native LinuxBIOS IDE code not > detecting the CHS properly with my CF the response I received was to > use the ide driver of Etherboot. So I got Etherboot 5.1.8 and that > fixed my issues. > > I would say try etherboot and see if that works then when you know > your hardware is correctly configured and working you can do some > compare/contrast with etherboot and see whats wrong with LB IDE. > The important issue was that linuxBIOS 'thinks' to have detected an IDE device even when I didn't attach any. (of course, the disk info gets read awfully). When an IDE HDD exists, everything goes just fine for me. (ide_init() works great) I had to fix this problem by reading in a 'magic number' from the partition table to check if an HDD really exists. Thx, anywayz Ed. From pyro at linuxlabs.com Sat May 10 10:33:00 2003 From: pyro at linuxlabs.com (steven james) Date: Sat May 10 10:33:00 2003 Subject: E7501 raminit.inc Message-ID: Greetings, I have confirmed that setting 0x80 = 0x0bb6 in the northbridge gets ram going both for 533 and 400 MHz FSB CPUs on x5dpr and tiger i7501 boards. Eric, unless you have a specific objection to that change, I will commit it. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From jarcher at pobox.com Sat May 10 18:15:00 2003 From: jarcher at pobox.com (jarcher) Date: Sat May 10 18:15:00 2003 Subject: Status of 2.0? Message-ID: <5.2.1.1.2.20030510154740.00b9b8c0@cybermorph.com> Howdy, I see that Eric has started a 2.0 port for the BIOS. I'm interested in the status and the plans. I've a couple of projects that are looking at using Linux BIOS and I'm doing a test port for a new platform. Eric, can you fill me in? Jordan From bendany at mistdl.com Sun May 11 09:41:01 2003 From: bendany at mistdl.com (bendany) Date: Sun May 11 09:41:01 2003 Subject: ASUS TX97LE mainboard seems support too. Message-ID: <057601c3195b$205cd920$2a00a8c0@ben> ASUS TX97LE , the northbridge is 82439TX, southbridge is 82371AB, and I try it with the linuxbios build by mainboard digitallogic/smartcore-p5, test it. and succeeded loading the etherboot payload. need more test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Sun May 11 17:23:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun May 11 17:23:01 2003 Subject: freebios2 Message-ID: Eric may be too busy to explain freebios2 so I'll pitch in. We are trying to freeze the current freebios code base (current goal is 5/15 since fixes keep rolling in) and give people something that works. First frozen version will be 1.0.1. Then we want to move to a new 'cruft-free' code base. This seemed the right time to branch. I would hope that folks who own mainboards, and who are committers, would start looking at the new code base and seeing what it takes to get moved to it. I will be personally starting work on an Arima K8 mainboard this week. ron From rminnich at lanl.gov Sun May 11 22:24:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun May 11 22:24:01 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <057601c3195b$205cd920$2a00a8c0@ben> Message-ID: As soon as you verify this is working we will add it to the tree. Please move fast I will hold up the freeze of this one! ron From hcyun at etri.re.kr Mon May 12 03:16:00 2003 From: hcyun at etri.re.kr (Heechul Yun) Date: Mon May 12 03:16:00 2003 Subject: Using LILO without running VGABIOS on ADLO. References: <20030506150119.A81139-100000@www.missl.cs.umd.edu> Message-ID: <003201c3185b$752ab6d0$0200a8c0@hcyuncompaq> I've extended my serial debug patch to see entire vga text console message (printed via int10 vgabios service routine) on the serial temrnial. I needed this because I don't want run vgabios (due to it took several seconds) but I want to use lilo as a boot loader. Therfore, I skipped VGABIOS and handled int10 service to direct messages to serial console. As a result, I can use lilo instead of etherboot without performance degradation caused by running vgabios. I think this might be useful for those who don't need VGA text console or have problem with running VGABIOS, but want to use lilo or grub as a boot loader. Regard, Heechul. -------------- next part -------------- A non-text attachment was scrubbed... Name: rombios-serial-0512.patch Type: application/octet-stream Size: 4424 bytes Desc: not available URL: From ts1 at cma.co.jp Mon May 12 03:43:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Mon May 12 03:43:01 2003 Subject: Via VT8601 Northbridge sizeram In-Reply-To: <009001c31643$ab91e0f0$ce40a8c0@2pmtech.com> References: <009001c31643$ab91e0f0$ce40a8c0@2pmtech.com> Message-ID: <20030512081938.GB6168@cma.co.jp> On Fri, May 09, 2003 at 04:57:19PM +0100, Mark Wilkinson wrote: > Hi Ron, > While looking at the differences between the LinuxBIOS setting and > the Award settings as you suggested yesterday, I came across this little > problem. It seems that the sizeram routine is incorrectly reducing the > memory size by 1M when there is nothing assigned to the VGA framebuffer. > > > I've attached a patch that corrects the calculation. > > Regards > Mark. I think this is a correct fix and should be in the CVS tree. -- Takeshi From ts1 at cma.co.jp Mon May 12 04:05:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Mon May 12 04:05:01 2003 Subject: EPIA success and problem In-Reply-To: <20030508140111.GA11808@cma.co.jp> References: <20030508073840.GA1181@cma.co.jp> <20030508140111.GA11808@cma.co.jp> Message-ID: <20030512084211.GA8195@cma.co.jp> On Thu, May 08, 2003 at 11:01:11PM +0900, ts1 wrote: > On Thu, May 08, 2003 at 07:47:03AM -0600, ron minnich wrote: > > > When I change MAXIMUM_CONSOLE_LOGLEVEL from 8 to 9, > > > the problem disappears. > > > > This sounds like a timing problem. > > Note that in this case DEFAULT_CONSOLE_LOGLEVEL is still 8, > so printk_spew's are compiled in but does not really print anything. > > > probably not a bug, but probably something we have to figure out how to > > work around. > > Ok, it sounds like a delicate thing anyway... I removed most of lines from my vgainit.inc (which was originally posted by Andrew Ip, and I modified), as far as VGA is enabled, and the problem disappeared! Registers 0xf8 and 0xf9 are not necessory either (so, only 0xfb is the one to enable VGA), but it might be safe to leave them. Below is my current version of src/northbridge/via/vt8601/vgainit.inc. -- Takeshi /* Frame buffer size in MBytes */ #ifndef SMA_SIZE #define SMA_SIZE 8 #endif #if SMA_SIZE==2 #define FBREG 0x90 #elif SMA_SIZE==4 #define FBREG 0xa0 #elif SMA_SIZE==8 #define FBREG 0xb0 #else #error SMA_SIZE should be 2, 4, or 8 (MB) #endif CS_WRITE($0xf8, $0x22) // DRAM arbitation timer - AGP, Host CS_WRITE($0xf9, $0x42) // DRAM arbitation timer - VGA priority, normal CS_WRITE($0xfb, $FBREG) // VGA enable From pyro at linuxlabs.com Mon May 12 08:42:00 2003 From: pyro at linuxlabs.com (steven james) Date: Mon May 12 08:42:00 2003 Subject: [COMMIT] fix for e7501 Message-ID: Greetings, I have committed the fix for RAM on e7501 boards with 533MHz FSB cpus. This has been tested with 400MHz CPUs as well with no apparent problems. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From aip at cwlinux.com Mon May 12 09:03:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon May 12 09:03:01 2003 Subject: EPIA success and problem In-Reply-To: <20030512084211.GA8195@cma.co.jp>; from SONE Takeshi on Mon, May 12, 2003 at 05:42:11PM +0900 References: <20030508073840.GA1181@cma.co.jp> <20030508140111.GA11808@cma.co.jp> <20030512084211.GA8195@cma.co.jp> Message-ID: <20030512214047.A15344@mail.cwlinux.com> Takeshi, > I removed most of lines from my vgainit.inc (which was originally posted by > Andrew Ip, and I modified), as far as VGA is enabled, > and the problem disappeared! > Registers 0xf8 and 0xf9 are not necessory either > (so, only 0xfb is the one to enable VGA), > but it might be safe to leave them. > Below is my current version of > src/northbridge/via/vt8601/vgainit.inc. Have you got vga working on EPIA??? Does it have to be with ADLO? -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From ts1 at cma.co.jp Mon May 12 09:28:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Mon May 12 09:28:00 2003 Subject: EPIA success and problem In-Reply-To: <20030512214047.A15344@mail.cwlinux.com> References: <20030508073840.GA1181@cma.co.jp> <20030508140111.GA11808@cma.co.jp> <20030512084211.GA8195@cma.co.jp> <20030512214047.A15344@mail.cwlinux.com> Message-ID: <20030512140518.GA13362@cma.co.jp> On Mon, May 12, 2003 at 09:40:47PM +0800, Andrew Ip wrote: > Takeshi, > > > I removed most of lines from my vgainit.inc (which was originally posted by > > Andrew Ip, and I modified), as far as VGA is enabled, > > and the problem disappeared! > > Registers 0xf8 and 0xf9 are not necessory either > > (so, only 0xfb is the one to enable VGA), > > but it might be safe to leave them. > > Below is my current version of > > src/northbridge/via/vt8601/vgainit.inc. > Have you got vga working on EPIA??? Does it have to be with ADLO? Yes and yes. Basically, that vgainit.inc and this bit of code in northbridge_fixup() was enough for running ADLO with binary VGA BIOS. (also disable shadow ON/OFF code in loader.s) /* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write * PIRQ table, VGA BIOS, Bochs BIOS, etc. */ printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: "); pci_write_config_byte(pcidev, 0x61, 0xff); pci_write_config_byte(pcidev, 0x62, 0xff); pci_write_config_byte(pcidev, 0x63, 0xf0); printk_debug("done\n"); I also changed raminit.inc to work with my 256MB PC133 DIMM, and now improving it to detect memory (size and MA type) automatically. -- Takeshi From aip at cwlinux.com Mon May 12 09:35:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon May 12 09:35:01 2003 Subject: EPIA success and problem In-Reply-To: <20030512140518.GA13362@cma.co.jp>; from SONE Takeshi on Mon, May 12, 2003 at 11:05:18PM +0900 References: <20030508073840.GA1181@cma.co.jp> <20030508140111.GA11808@cma.co.jp> <20030512084211.GA8195@cma.co.jp> <20030512214047.A15344@mail.cwlinux.com> <20030512140518.GA13362@cma.co.jp> Message-ID: <20030512221241.A15654@mail.cwlinux.com> Takeshi, > Yes and yes. > Basically, that vgainit.inc and this bit of code in northbridge_fixup() > was enough for running ADLO with binary VGA BIOS. > (also disable shadow ON/OFF code in loader.s) > > > /* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write > * PIRQ table, VGA BIOS, Bochs BIOS, etc. */ > printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: "); > pci_write_config_byte(pcidev, 0x61, 0xff); > pci_write_config_byte(pcidev, 0x62, 0xff); > pci_write_config_byte(pcidev, 0x63, 0xf0); > printk_debug("done\n"); > > > I also changed raminit.inc to work with my 256MB PC133 DIMM, > and now improving it to detect memory (size and MA type) automatically. Sounds good. Would you send me the entire patch so that I can check in to the cvs? Good job!!! -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From bendany at mistdl.com Mon May 12 11:38:01 2003 From: bendany at mistdl.com (bendany) Date: Mon May 12 11:38:01 2003 Subject: ASUS TX97LE mainboard seems support too. References: Message-ID: <006601c31a34$b82415a0$2a00a8c0@ben> ASUS Tx97LE mainboard works fine with digitallogic/smartcore-p5 code. so I think you can add this mainboard to support list. the code current only support standard flash chip. I think if support DoC, will much better. I am glad to do some jobs, but I have no idea what to do next. or maybe you can give me some tips on how to get this mainboard support DoC. ----- Original Message ----- From: "ron minnich" To: "bendany" Cc: Sent: Monday, May 12, 2003 10:59 AM Subject: Re: ASUS TX97LE mainboard seems support too. > As soon as you verify this is working we will add it to the tree. Please > move fast I will hold up the freeze of this one! > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From agnew at cs.umd.edu Mon May 12 11:45:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Mon May 12 11:45:00 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <006601c31a34$b82415a0$2a00a8c0@ben> Message-ID: <20030512123151.L28883-100000@www.missl.cs.umd.edu> If you'd like to see if you can get ADLO with video working on that board, that would be good. - Adam Agnew On Thu, 15 May 2003, bendany wrote: > ASUS Tx97LE mainboard works fine with digitallogic/smartcore-p5 code. > so I think you can add this mainboard to support list. > > the code current only support standard flash chip. I think if support DoC, > will much better. > I am glad to do some jobs, but I have no idea what to do next. or maybe you > can give me > some tips on how to get this mainboard support DoC. > > ----- Original Message ----- > From: "ron minnich" > To: "bendany" > Cc: > Sent: Monday, May 12, 2003 10:59 AM > Subject: Re: ASUS TX97LE mainboard seems support too. > > > > As soon as you verify this is working we will add it to the tree. Please > > move fast I will hold up the freeze of this one! > > > > ron > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From jarcher at pobox.com Mon May 12 13:04:01 2003 From: jarcher at pobox.com (jarcher) Date: Mon May 12 13:04:01 2003 Subject: Fix in SMC superio? and RE: freebios2 In-Reply-To: <20030512160001.28235.71613.Mailman@nwn.definitive.org> Message-ID: <5.2.1.1.2.20030512103600.03575688@cybermorph.com> The current freebios (1.0) tree won't build correctly when using the FDC37N769 for me. I needed to change 53: cmp %al, $0x4 to 53: cmp $0x4, %al /* 2003-05-12-jordan: order was incorrect for assembler. in src/superio/SMC/fdc37c669/setup_serial.inc Jordan PS: Ron, Thanks for the info on 2.0. >Message: 1 >Date: Sun, 11 May 2003 15:58:31 -0600 (MDT) >From: ron minnich >To: linuxbios at clustermatic.org >Subject: freebios2 > >Eric may be too busy to explain freebios2 so I'll pitch in. > >We are trying to freeze the current freebios code base (current goal is >5/15 since fixes keep rolling in) and give people something that works. >First frozen version will be 1.0.1. > >Then we want to move to a new 'cruft-free' code base. This seemed the >right time to branch. > >I would hope that folks who own mainboards, and who are committers, would >start looking at the new code base and seeing what it takes to get moved >to it. I will be personally starting work on an Arima K8 mainboard this >week. > >ron From adam at cfar.umd.edu Mon May 12 15:00:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Mon May 12 15:00:01 2003 Subject: Debugging the linuxBIOS code In-Reply-To: <3EA77885.4070208@onelabs.com> Message-ID: <20030512154232.T29579-100000@www.missl.cs.umd.edu> > >For what it is worth, if anyone needs MiniPCI Port-80 boards: > > http://www.pctestpro.com/post/pcipost.htm (all the way at bottom) > > http://www.costronic.com/Ev014mp.htm > > http://siliconkit.dnsalias.com/cart/tpcim.html > > > Another option is to use a miniPCI to PCI adapter which you can plug > your regular 3.3V PCI POST card into. > > http://www.interfacemasters.com/products/pci_tools/mini_pci_to_pci/index.html Yeah, but the trick is to find an 3.3V PCI POST card. I finally got it from http://www.postcodemaster.com/products2.htm It is PCI Version Part #PCIPCM-11 The one listed on their web page is an 5V, but if you ask they can modify it for you so that it works with 3.3V PCI. In fact I just got it today and I was able to use it to get POST codes from IBM ThinkPad T23 which has 3.3V MiniPCI slot (I would use here IM300 MiniPCI->PCI adapter), and which would not work with my old 5V post card. Also they have an MiniPCI POST card (#MINIPCM-10) which could be used directly without adapter, but I have not tested this one. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rsmith at bitworks.com Mon May 12 17:37:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 12 17:37:00 2003 Subject: ADLO and older hard disk support In-Reply-To: <5.2.1.1.2.20030512103600.03575688@cybermorph.com> References: <5.2.1.1.2.20030512103600.03575688@cybermorph.com> Message-ID: <3EC01C87.6040408@bitworks.com> ADLO appears to choke on older harddrives. We have a box of bunch of < 512 Meg harddrives that we use for systems where we want a little more space than a 8 or 32 Meg CF to develop on. I wanted to use one to boot a different Linux install than the one I'm booting now. I tried about 6 or 7 different drives from different Mfgs and they all had a similar issue. ADLO would find the drive get a PCHS value and what sometimes looked like a resonable LCHS values. But the drive size would be 0 Meg. Then the int13 handler would barf about things being out of range. Usually 2 out of the 3 CHS values reported by int13 would be zero. Perhpas a LBA problem? Is the current HD stuff only good for say like drives that can do LBA32? Anyone else ran into this? This is mostly just a FYI for the archives as I'll just go cobble up another newer drive and move on. -- Richard A. Smith rsmith at bitworks.com From adam at cfar.umd.edu Mon May 12 17:50:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Mon May 12 17:50:01 2003 Subject: ADLO and older hard disk support In-Reply-To: <3EC01C87.6040408@bitworks.com> Message-ID: <20030512183535.V30665-100000@www.missl.cs.umd.edu> heh. I just assumed nobody would use those since my assumption was that if someone does port of LinuxBIOS then they would go with new hardware since it is where the monnies are :-) anyway, have a look at loaders.s specifically: ;----------------------------------------------------- ; V) tell BOCHS' BIOS we want to have LBA translation. ; 0x00 - NONE ; 0x01 - LBA <<<< ; 0x02 - LARGE ; 0x03 - R-CHS ; In future there will be 'fd failover'option in bochs. mov al, #0x39 ;; cmos_reg out 0x70, al mov al, #0x01 ;; val (LBA) out 0x71, al ;----------------------------------------------------- try puttting different values (other than LBA) into 'AL' and see if it helps. On Mon, 12 May 2003, Richard Smith wrote: > ADLO appears to choke on older harddrives. > > We have a box of bunch of < 512 Meg harddrives that we use for systems > where we want a little more space than a 8 or 32 Meg CF to develop on. > I wanted to use one to boot a different Linux install than the one I'm > booting now. > > I tried about 6 or 7 different drives from different Mfgs and they all > had a similar issue. ADLO would find the drive get a PCHS value and > what sometimes looked like a resonable LCHS values. But the drive size > would be 0 Meg. Then the int13 handler would barf about things being > out of range. Usually 2 out of the 3 CHS values reported by int13 would > be zero. > > Perhpas a LBA problem? Is the current HD stuff only good for say like > drives that can do LBA32? Anyone else ran into this? > > This is mostly just a FYI for the archives as I'll just go cobble up > another newer drive and move on. > > -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rsmith at bitworks.com Mon May 12 18:18:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 12 18:18:00 2003 Subject: ADLO and older hard disk support In-Reply-To: <20030512183535.V30665-100000@www.missl.cs.umd.edu> References: <20030512183535.V30665-100000@www.missl.cs.umd.edu> Message-ID: <3EC02612.4080108@bitworks.com> Adam Sulmicki wrote: > heh. I just assumed nobody would use those since my assumption was that if > someone does port of LinuxBIOS then they would go with new hardware since > it is where the monnies are :-) Here at Bitworks about once per project you end up doing something stupid like shorting 12V to the 5V rail, or the drive gets knocked off the bench, or my personal favorite where a well place short in a 120V control circuit that had the line and neutral reversed make the whole setup float at 120V. Looking for an easy ground the unsuspecting engineer goes to plug his scope ground (which was earthed properly) up to the ground on the HD. *Poof* When stuff happens it's painfull to know that you just waxed a 30+ gig drive. A < $1.00 ebay drive however is much eaiser to accept and sometimes even fun say if you have a big metal band saw around. I'll add HD method selection info to my FAQ after I've played with it. -- Richard A. Smith rsmith at bitworks.com From s.sorrenti at regia.tv Tue May 13 05:03:00 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Tue May 13 05:03:00 2003 Subject: etherboot Message-ID: <200305131133.14089.s.sorrenti@regia.tv> Hello, now i download etherboot 5.1.8, i need more information to use this! tnx Serafino From stepan at suse.de Tue May 13 05:49:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue May 13 05:49:00 2003 Subject: etherboot In-Reply-To: <200305131133.14089.s.sorrenti@regia.tv> References: <200305131133.14089.s.sorrenti@regia.tv> Message-ID: <20030513102647.GA14461@suse.de> * Serafino Sorrenti [030513 11:33]: > Hello, > now i download etherboot 5.1.8, i need more information to use this! You should unpack it, and build an etherboot image for the boot method you want. For LinuxBIOS you have to change the Config file to disable -DPCBIOS and instead use the LinuxBIOS settings. Now you can build a new image with i.e. make bin/ide_disk--tg3.zelf this will build a compressed image that can boot from an ide disk and from a tg3 broadcom ethernet card. Best regards, Stefan Reinauer -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From yapeehuey at hotmail.com Tue May 13 07:09:01 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Tue May 13 07:09:01 2003 Subject: TUSL2-C almost work..... Message-ID: Hi, I have some improvement on my TUSL2-C board (intel 82815ep chipset). The ram initialization is successful . However, it boots neither etherboot elf nor adlo payload. It hangs after the following messages from serial port . I put the tagged bzImage (not elf) on hda using : dd if=bzImage.ether of=/dev/hda bs=4096 skip=1 as suggested by ron but it does not seem to be recognized by linuxbios . I am using sis900.ebi as ide etherboot. Any idea ? Thanks. LinuxBIOS-1.0.0 Tue May 13 12:12:08 EDT 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Testing SDRAM : 00000000-0009ffff SDRAM fill: 00000000 00010000 00020000 LinuxBIOS-1.0.0 Tue May 13 12:12:08 EDT 2003 starting... Ram1 Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Testing SDRAM : 00000000-0009ffff SDRAM fill: 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 0009ffff SDRAM verify: 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 0009ffff Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Tue May 13 12:12:08 EDT 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 [8086/1130] PCI: 00:01.0 [8086/1131] PCI: 00:1e.0 [8086/244e] PCI: 00:1f.0 [8086/2440] PCI: 00:1f.1 [8086/244b] PCI: 00:1f.2 [8086/2442] PCI: 00:1f.3 [8086/2443] PCI: 00:1f.4 [8086/2444] PCI: 00:1f.5 [8086/2445] PCI: 00:1f.6 [8086/2446] PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1002/5144] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus for bus 2 PCI: 02:07.0 [13f6/0111] PCI: 02:0a.0 [10b7/9055] PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus returning with max=02 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] prefmem PCI: 00:01.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:01.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem PCI: 00:01.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0x00001000 - 0x000010ff] io PCI: 01:00.0 18 <- [0xfc000000 - 0xfc07ffff] mem ASSIGNED RESOURCES, bus 1 PCI: 00:1e.0 1c <- [0x00002000 - 0x00002fff] bus 2 io PCI: 00:1e.0 24 <- [0xfc200000 - 0xfc1fffff] bus 2 prefmem PCI: 00:1e.0 20 <- [0xfc100000 - 0xfc1fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:07.0 10 <- [0x00002000 - 0x000020ff] io PCI: 02:0a.0 10 <- [0x00002400 - 0x0000247f] io PCI: 02:0a.0 14 <- [0xfc100000 - 0xfc10007f] mem ASSIGNED RESOURCES, bus 2 PCI: 00:1f.1 20 <- [0x00003c00 - 0x00003c0f] io PCI: 00:1f.2 20 <- [0x000038c0 - 0x000038df] io PCI: 00:1f.3 20 <- [0x00003c10 - 0x00003c1f] io PCI: 00:1f.4 20 <- [0x000038e0 - 0x000038ff] io PCI: 00:1f.5 10 <- [0x00003000 - 0x000030ff] io PCI: 00:1f.5 14 <- [0x00003880 - 0x000038bf] io PCI: 00:1f.6 10 <- [0x00003400 - 0x000034ff] io PCI: 00:1f.6 14 <- [0x00003800 - 0x0000387f] io 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:1e.0 cmd <- 07 PCI: 00:1f.0 cmd <- 0f PCI: 00:1f.1 cmd <- 01 PCI: 00:1f.2 cmd <- 01 PCI: 00:1f.3 cmd <- 01 PCI: 00:1f.4 cmd <- 01 PCI: 00:1f.5 cmd <- 01 PCI: 00:1f.6 cmd <- 01 PCI: 01:00.0 cmd <- 83 PCI: 02:07.0 cmd <- 81 PCI: 02:0a.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized DRP0 = 0xc DIMM0 - size = 256M DIMM1 - size = 0M DRP1 = 0x0 DIMM2 - size = 0M totalram: 256M Initializing CPU #0 Updating microcode microcode_info: sig = 0x000006b1 pf=0x00000010 rev = 0x00000000 Enabling cache... Setting fixed MTRRs(0-88) type: UC inside set_fixed_mtrrs going out set_fixed_mtrrs Setting fixed MTRRs(0-16) type: WB inside set_fixed_mtrrs going out set_fixed_mtrrs DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 256MB, 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 : 2 Vendor ID : GenuineIntel Processor Type : 0x00 Processor Family : 0x06 Processor Model : 0x0b Processor Mask : 0x00 Processor Stepping : 0x01 Feature flags : 0x0383fbff Cache/TLB descriptor values: 1 reads required Desc 0x01 : Instr TLB: 4KB pages, 4-way set assoc, 32 entries Desc 0x02 : Instr TLB: 4MB pages, fully assoc, 2 entries Desc 0x03 : Data TLB: 4KB pages, 4-way set assoc, 64 entries Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x82 : L2 Unified cache: 256K bytes, 8-way set assoc, 32 byte line size Desc 0x08 : Inst cache: 16K bytes, 4-way set assoc, 32 byte line size Desc 0x04 : Data TLB: 4MB pages, 4-way set assoc, 8 entries Desc 0x0c : Data cache: 16K bytes, 2-way or 4-way set assoc, 32 byte line size MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Configuring L2 cache...CPU signature of 6b0 so no L2 cache configuration Enable Cache done. Disabling local apic...done. CPU #0 Initialized Please turn on nvram Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 00000660 checksum 393b Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 203:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Searching for 16 byte tags 64:rom_read_bytes() - overflowed source buffer. max_block = 15 init_bytes found 0 tags Found ELF candiate at offset 0 New segment addr 0x7c00 size 0x20400 offset 0x100 filesize 0x20400 (cleaned up) New segment addr 0x7c00 size 0x20400 offset 0x100 filesize 0x20400 Loading Segment: addr: 0x000000000ff667e8 memsz: 0x0000000000020400 filesz: 0x0000000000020400 Jumping to boot code at 0x7c00 regards, eehuey _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp From stepan at suse.de Tue May 13 07:27:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue May 13 07:27:00 2003 Subject: TUSL2-C almost work..... In-Reply-To: References: Message-ID: <20030513120438.GA29159@suse.de> * Yap Ee Huey [030513 13:46]: > The ram initialization is successful . However, it boots neither etherboot > elf > nor adlo payload. It hangs after the following messages from serial port . > I put the tagged bzImage (not elf) on hda using : > dd if=bzImage.ether of=/dev/hda bs=4096 skip=1 > as suggested by ron but it does not seem to be recognized by linuxbios . > I am using sis900.ebi as ide etherboot. > Any idea ? Thanks. I never got ADLO to say something either, when I tried it the last time. But etherboot works nicely here. Have you changed the etherboot config not to use legacy PC-BIOS cruft? When I forgot to do so, I got the same result on AMD64 Best regards, Stefan Reinauer -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From s.sorrenti at regia.tv Tue May 13 07:32:00 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Tue May 13 07:32:00 2003 Subject: etherboot Message-ID: <200305131408.16121.s.sorrenti@regia.tv> Tnx for help, now i have make the ide_disk.zelf but how use this file??? Now i make the tutorial for linuxbios with 810lmr + etherboot 5.1.8 Tnx Serafino From adam at cfar.umd.edu Tue May 13 08:09:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 13 08:09:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: <20030513120438.GA29159@suse.de> Message-ID: <20030513085508.P33475-100000@www.missl.cs.umd.edu> > * Yap Ee Huey [030513 13:46]: > > The ram initialization is successful . However, it boots neither etherboot > > elf > > nor adlo payload. It hangs after the following messages from serial port . > > I put the tagged bzImage (not elf) on hda using : > > dd if=bzImage.ether of=/dev/hda bs=4096 skip=1 > > as suggested by ron but it does not seem to be recognized by linuxbios . > > I am using sis900.ebi as ide etherboot. > > Any idea ? Thanks. > > I never got ADLO to say something either, when I tried it the last time. * did you adjust loader.s file to your system as needed? * did you try to use serial console path for ADLO posted by Heechul Yun -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rminnich at lanl.gov Tue May 13 08:20:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:20:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: Message-ID: On Tue, 13 May 2003, Yap Ee Huey wrote: > Hi, > > I have some improvement on my TUSL2-C board (intel 82815ep chipset). The > ram initialization is successful . However, it boots neither etherboot > elf nor adlo payload. It hangs after the following messages from serial > port . Your problem is that etherboot and adlo are not coming up. Are you sure that you built etherboot so that it only uses serial and does not require BIOS interrupts? I think that may be the problem. congratulations on getting this working -- it will be very useful. ron From rminnich at lanl.gov Tue May 13 08:21:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:21:00 2003 Subject: etherboot In-Reply-To: <200305131408.16121.s.sorrenti@regia.tv> Message-ID: On Tue, 13 May 2003, Serafino Sorrenti wrote: > now i have make the ide_disk.zelf but how use this file??? This will become the payload when you build linuxbios In your config file: payload ../ide_disk.zelf or whereever you have it. > Now i make the tutorial for linuxbios with 810lmr + etherboot 5.1.8 Thank you! ron From stepan at suse.de Tue May 13 08:35:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue May 13 08:35:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: References: Message-ID: <20030513131242.GA10668@suse.de> * Yap Ee Huey [030513 13:46]: > I put the tagged bzImage (not elf) on hda using : > dd if=bzImage.ether of=/dev/hda bs=4096 skip=1 ^^^^^^ This has to be seek=1, not skip=1. Otherwise you overwrite your partition table with an incomplete elf file instead of leaving your partition table there and writing the complete file. Stefan -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From rminnich at lanl.gov Tue May 13 08:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:39:00 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <057601c3195b$205cd920$2a00a8c0@ben> Message-ID: On Tue, 13 May 2003, bendany wrote: > ASUS TX97LE , the northbridge is 82439TX, southbridge is 82371AB, and I > try it with the linuxbios build by mainboard digitallogic/smartcore-p5, > test it. and succeeded loading the etherboot payload. I have added this mainboard, please test. The name is asus/tx97le. Please update the STATUS file if you wish to be the owner and send me the new file. ron From rminnich at lanl.gov Tue May 13 08:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:41:01 2003 Subject: EPIA success and problem In-Reply-To: <20030512221241.A15654@mail.cwlinux.com> Message-ID: andrew, did you apply that patch? I just asked SONE for it again. This is the shadow ram patch for EPIA. ron From rminnich at lanl.gov Tue May 13 08:41:08 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:41:08 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <006601c31a34$b82415a0$2a00a8c0@ben> Message-ID: On Thu, 15 May 2003, bendany wrote: > the code current only support standard flash chip. I think if support > DoC, will much better. I am glad to do some jobs, but I have no idea > what to do next. or maybe you can give me some tips on how to get this > mainboard support DoC. Is the socket DIP-32? I am not sure you can get that chipset turned on in 256 bytes, however. Does it look feasible? ron From rminnich at lanl.gov Tue May 13 08:45:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:45:01 2003 Subject: Fix in SMC superio? and RE: freebios2 In-Reply-To: <5.2.1.1.2.20030512103600.03575688@cybermorph.com> Message-ID: On Mon, 12 May 2003, jarcher wrote: > The current freebios (1.0) tree won't build correctly when using the > FDC37N769 for me. I needed to change > > 53: cmp %al, $0x4 > > to > > 53: cmp $0x4, %al /* 2003-05-12-jordan: order was incorrect > for assembler. committed, please try it now. ron From rminnich at lanl.gov Tue May 13 08:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 08:50:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: <20030513131242.GA10668@suse.de> Message-ID: On Tue, 13 May 2003, Stefan Reinauer wrote: > This has to be seek=1, not skip=1. Otherwise you overwrite your > partition table with an incomplete elf file instead of leaving > your partition table there and writing the complete file. > I am going to regret that particular typo of mine for a long time. Sorry. I think the solution of using sfdisk to build a /dev/hda1 that starts at sector 1 is better. Fixing etherboot to scan 64k in each direction is best. I tried that but it still didn't find the elfimage. ron From IBaab at becker.de Tue May 13 08:57:00 2003 From: IBaab at becker.de (Baab, Ingo) Date: Tue May 13 08:57:00 2003 Subject: VIA EPIA M10000 Message-ID: <1F6206BC53BCD3119059009027D1D3A206FDAB6E@OEKAEX01.becker.de> Has anybody knowledge/experience with the EPIA M10000? Is this Board able to do mulitmedia-stuff like playing Fullscreen-DVD-Playback etc.? Is there Suport in Linuxbios for the Chipset: CLE266 North Bridge- VT8235 South Bridge? best regards, Ingo ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* From s.sorrenti at regia.tv Tue May 13 09:34:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Tue May 13 09:34:01 2003 Subject: etherboot In-Reply-To: References: Message-ID: <200305131611.09901.s.sorrenti@regia.tv> I have added to the pcchips.config file the payload string but after flashing the rom i don't see any debug on the serial port. With rom m810-ide.rom from cwlinux i don't have any problem to boot my linuxbios from HD, but it has only 8Mb of video ram wich is not enough for me, and it fails booting from a compact flash mounted on a cf->ide adapter. i'm getting crazy for this problem :( pcchips.conf is my config file unz.config is the original config file tnx Serafino On Tuesday 13 May 2003 14:56, you wrote: > On Tue, 13 May 2003, Serafino Sorrenti wrote: > > now i have make the ide_disk.zelf but how use this file??? > > This will become the payload when you build linuxbios > > In your config file: > payload ../ide_disk.zelf > > or whereever you have it. > > > Now i make the tutorial for linuxbios with 810lmr + etherboot 5.1.8 > > Thank you! > > ron -------------- next part -------------- # Sample config file for PCCHIPS M810LMR with DoC Millennium (as root) # This will make a target directory of ./pcchips target pcchips # PCCHIPS M810LMR mainboard mainboard pcchips/m810lmr # We are using a k7 cpu (???) cpu k7 # Set up udelay - needed option CONFIG_UDELAY_TSC=1 # This SHOULD enable the video console with messages about what's going on #option VIDEO_CONSOLE=0 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # Sets the log level, from 9 to 1 (???) option DEFAULT_CONSOLE_LOGLEVEL=6 # More debug options option SERIAL_POST=1 # Enables ethernet (?) option ENABLE_MII=1 # use DOC MIL option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 # Sets the amount of framebuffer memory # 0x80 (2MB/4MB) # 0x90 (4MB/8MB) # 0xA0 (8MB/16MB) # 0xB0 (16MB/32MB) # 0xC0 (32MB/64MB) # 0xD0 (64MB/na) option SMA_SIZE=0xC0 # Enables IDE boot option BOOT_IDE=1 # Selects which IDE device should boot from, using the following table: # /dev/hda -> 0 # /dev/hdb -> 1 # /dev/hdc -> 2 # /dev/hdd -> 3 #option IDE_BOOT_DRIVE=0 payload /home/fino/ide_disk.zelf # Partition table size (should be left untouched?) option ONE_TRACK=32 # Need to "relocate the gdt" to use a standard flash part (???) biosbase 0xffff0000 # Path to your kernel (vmlinux) linux /usr/src/linux # Kernel command line parameters commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 single -------------- next part -------------- # Sample config file for PCCHIPS M810LMR with DoC Millennium (as root) # This will make a target directory of ./pcchips target pcchips # PCCHIPS M810LMR mainboard mainboard pcchips/m810lmr # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # use DOC MIL option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER payload /home/fino/ide_disk.zelf #option SMA_SIZE=0xC0 # Path to your kernel (vmlinux) linux /usr/src/linux # Kernel command line parameters commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 single From rminnich at lanl.gov Tue May 13 09:36:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 09:36:01 2003 Subject: RFC:new superio proposal Message-ID: Abstract: The superio architecture for linuxbios has worked for the last 2 years but is being stretched to the limit by the changes in superio chips. The architecture depended on superio resources being relatively constant between chips, but this assumption no longer holds. In this document we propose several alternatives and solicit comments. Overview: The superio architecture in linuxbios was developed over time, and modified as circumstances required. In the beginning it was relatively simple and assumed only one superio per mainboard. The latest version allows an arbitrary number of superios per mainboard, and allows complete specification of the superio base I/O address along with the specification of reasonable default valures for both the base I/O address and the superio parameters such as serial enable, baud rate, and so on. Specification of superio control parameters is done by a configuration line such as: nsuperio sis/950 com1={1} floppy=1 lpt=1 This fragment sets the superio type to sis/950; sets com1, floppy, and lpt to enabled; and leaves the defaults to com1 (baud rate, etc.) to the default values. While it is not obvious, these configuration parameters are fragments of a C initializer. The initializers are used to build a statically initialized structure of this type: struct superio { struct superio_control *super; // the ops for the device. unsigned int port; // if non-zero, overrides the default port // com ports. This is not done as an array (yet). // We think it's easier to set up from python if it is not an // array. struct com_ports com1, com2, com3, com4; // DMA, if it exists. struct lpt_ports lpt1, lpt2; /* flags for each device type. Unsigned int. */ // low order bit ALWAYS means enable. Next bit means to enable // LPT is in transition, so we leave this here for the moment. // The winbond chips really stretched the way this works. // so many functions! unsigned int ide, floppy, lpt; unsigned int keyboard, cir, game; unsigned int gpio1, gpio2, gpio3; unsigned int acpi,hwmonitor; }; These structures are, in turn, created and statically initialized by a config-tool-generated structure that defines all the superios. This file is called nsuperio.c, is created for each mainboard you build, only appears in the build directory, and looks like this: === extern struct superio_control superio_winbond_w83627hf_control; struct superio superio_winbond_w83627hf= { &superio_winbond_w83627hf_control, .com1={1}, .com2={1}, .floppy=1, .lpt=1, .keyboard=1, .hwmonitor=1}; struct superio *all_superio[] = {&superio_winbond_w83627hf, }; unsigned long nsuperio = 1; === This example shows a board with one superio (nsuperio). The superio consists of a winbond w83627hf, with com1, com2, floppy, lpt, keyboard, and hwmonitor enabled. Note that this structure also allows for over-riding the default superio base, although that capability is rarely used. The control structure is used to define how to access the superio for purposes of control. It looks like this: === struct superio_control { void (*pre_pci_init)(struct superio *s); void (*init)(struct superio *s); void (*finishup)(struct superio *s); unsigned int defaultport; /* the defaultport. Can be overridden * by commands in config */ // This is the print name for debugging char *name; }; === There are three methods for stages of hardwaremain. First is pre_pci_init (for chips like the acer southbridge that require you to enable some resources BEFORE pci scan); init, called during the 'middle' phase of hardwaremain; and finishup, called before the payload is loaded. This approach was inspired by and borrows heavily on the Plan 9 kernel configuration tools. The problem: When the first version of the superio structure came out it was much smaller. It has grown and in the limit this structure is the union of all possibly superio chips. Obviously, in the long term, this is not practical: we can not anticipate all possible superio chips for all time. The common PC BIOS solution to this type of problem is to continue with binary structures but add version numbers to them, so that all code that uses a given structure has to check the version number. Personally, I find this grotesque and would rather not work this way. Using textual strings for configuration is something I find far more attractive. Plan 9 has shown that this approach has no real limits and suffices for configuration tasks. The Linux kernel does more limited use of strings for configuration, but still depends on them. Strings are easier to read and work with than binary structures, and more important, a lot easier to deal with when things start going wrong. The proposed solution: What follows are three possible ideas for specifying superio resources and their settings. A common part of the new idea is to eliminate the common superio structure, due to the many variations in chips, and make it invisible outside a given superio source file -- the superio structure is now private to a given superio. Thus, sis/950/superio.c would contain its own superio structure definitions, and also might contain more than once instance of these structures (consider a board with 2 sis 950 chips). The control structure would change as follows: struct superio_control { int (*create)(struct superio *s); void (*pre_pci_init)(struct superio *s); void (*init)(struct superio *s); void (*finishup)(struct superio *s); unsigned int defaultport; /* the defaultport. Can be overridden * by commands in config */ // This is the print name for debugging char *name; }; I.e. we add a new function for creating the superio. Communication of superio settings from linuxbios to the superio would be via textual strings. The superio structure becomes this: struct superio { struct superio_control *super; // the ops for the device. unsigned int port; // if non-zero, overrides the default port struct configuration *config; }; So now the question becomes, what is the configuration structure? There are several choices. The simplest, from my point of view, are keyword-value pairs: struct configuration { const char *keyword; const char *value; }; These get filled in by the config tool as before. The linuxbios libary can then provide a generic parsing function for the superios to use. The remaining question is how should the superio command look in freebios2? superio sis/950 "com1=115200,8n1 lpt=1 com2=9600" or superio sis/950 "com1baud=115200 lpt=1 com1chars=8n1" or superio sis/950 ((com1 115200 8n1) (lpt 1)) So, my questions: 1. Does this new scheme look workable. If not, what needs to change? 2. What should the 'struct configuration' be? does keyword/value work? 3. what should the superio command look like? Comments welcome. I'd like to adopt this "RFC" approach for freebios2 as much as we can. There was a lot of give-and-take in the early days of linuxbios about structure and it proved useful. There's a lot that will start happening in freebios2 now, and we need to try to make sure it will work for everyone. Those of you who are doing mainboards, please look at freebios2 and see how it looks for you. There's a lot of good work that has been done (not by me so far, thanks Eric and Stefan), and more that needs to be done. Consider trying out romcc as an "assembly code killer". See how it fits together and if you can work with it or need changes. Bring comments back to this list. thanks ron From rminnich at lanl.gov Tue May 13 09:38:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 09:38:01 2003 Subject: etherboot In-Reply-To: <200305131611.09901.s.sorrenti@regia.tv> Message-ID: I recommend you exactly duplicate the config for 8 MB SMA just for testing and see if that works. You need to try to isolate the problem. ron From adam at cfar.umd.edu Tue May 13 10:01:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 13 10:01:00 2003 Subject: intel firmware hub parts In-Reply-To: Message-ID: <20030513104831.L33475-100000@www.missl.cs.umd.edu> On Tue, 22 Apr 2003, ron minnich wrote: > On Tue, 22 Apr 2003, Bari Ari wrote: > > > >82802ab, 82802ac > > and I just learned: > > N82802AC8 > > works in their data base much better :-) ARGH! N = PLCC package, E = TSOP package. Adam, the owner of 5 useless N82802AC8. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From stepan at suse.de Tue May 13 10:15:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue May 13 10:15:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: <20030513085508.P33475-100000@www.missl.cs.umd.edu> References: <20030513120438.GA29159@suse.de> <20030513085508.P33475-100000@www.missl.cs.umd.edu> Message-ID: <20030513145225.GA28822@suse.de> * Adam Sulmicki [030513 14:56]: > > I never got ADLO to say something either, when I tried it the last time. > > * did you adjust loader.s file to your system as needed? I did, but i might have overseen something. Especially I'm not sure whether i did the shadow enable thing right. Is there more that I need to get it talking? > * did you try to use serial console path for ADLO posted by Heechul Yun no, this was before Heechul did this great job. I'll retry working on this as soon as I find some time. Stefan -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra From s.sorrenti at regia.tv Tue May 13 10:45:00 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Tue May 13 10:45:00 2003 Subject: After make the linuxbios.rom Message-ID: <200305131722.32145.s.sorrenti@regia.tv> After make the linuxbios.rom with this config file i don't see any log in the serial ports, and the monitor is out of signal. tnx Serafino # Sample config file for PCCHIPS M810LMR with DoC Millennium (as root) # This will make a target directory of ./pcchips target pcchips # PCCHIPS M810LMR mainboard mainboard pcchips/m810lmr # We are using a k7 cpu (???) cpu k7 # Set up udelay - needed option CONFIG_UDELAY_TSC=1 # This SHOULD enable the video console with messages about what's going on #option VIDEO_CONSOLE=1 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # Sets the log level, from 9 to 1 (???) option DEFAULT_CONSOLE_LOGLEVEL=6 # More debug options option SERIAL_POST=1 # Enables ethernet (?) option ENABLE_MII=1 # use DOC MIL option USE_DOC_MIL=1 docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 # Sets the amount of framebuffer memory # 0x80 (2MB/4MB) # 0x90 (4MB/8MB) # 0xA0 (8MB/16MB) # 0xB0 (16MB/32MB) # 0xC0 (32MB/64MB) # 0xD0 (64MB/na) option SMA_SIZE=0xC0 # Enables IDE boot option BOOT_IDE=1 # Selects which IDE device should boot from, using the following table: # /dev/hda -> 0 # /dev/hdb -> 1 # /dev/hdc -> 2 # /dev/hdd -> 3 option IDE_BOOT_DRIVE=0 payload /home/fino/ide_disk.zelf # Partition table size (should be left untouched?) option ONE_TRACK=32 # Need to "relocate the gdt" to use a standard flash part (???) biosbase 0xffff0000 # Path to your kernel (vmlinux) linux /usr/src/linux # Kernel command line parameters commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 single From rminnich at lanl.gov Tue May 13 10:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 10:50:01 2003 Subject: After make the linuxbios.rom In-Reply-To: <200305131722.32145.s.sorrenti@regia.tv> Message-ID: On Tue, 13 May 2003, Serafino Sorrenti wrote: change this ... > # Sets the log level, from 9 to 1 (???) option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=9 this is a real pain, isn't it. Sorry I am not more useful, but I don't have an m810lmr any more. Andrew Ip is the expert on this board. ron From rminnich at lanl.gov Tue May 13 10:51:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 10:51:00 2003 Subject: After make the linuxbios.rom In-Reply-To: <200305131722.32145.s.sorrenti@regia.tv> Message-ID: On Tue, 13 May 2003, Serafino Sorrenti wrote: > payload /home/fino/ide_disk.zelf > > linux /usr/src/linux These are contradictory, comment out the 'linux /usr/src/linux' command. ron From adam at cfar.umd.edu Tue May 13 11:11:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 13 11:11:01 2003 Subject: TUSL2-C almost work..... In-Reply-To: <20030513145225.GA28822@suse.de> Message-ID: <20030513115827.O34535-100000@www.missl.cs.umd.edu> > > > I never got ADLO to say something either, when I tried it the last time. > > > > * did you adjust loader.s file to your system as needed? > > I did, but i might have overseen something. Especially I'm not sure > whether i did the shadow enable thing right. Is there more that I need > to get it talking? Usually no. However the whole shadow thing is the key and if it does not work right ADLO will not work at all. > > * did you try to use serial console path for ADLO posted by Heechul Yun > > no, this was before Heechul did this great job. I'll retry working on > this as soon as I find some time. cool. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rsmith at bitworks.com Tue May 13 12:22:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Tue May 13 12:22:00 2003 Subject: etherboot In-Reply-To: <200305131133.14089.s.sorrenti@regia.tv> References: <200305131133.14089.s.sorrenti@regia.tv> Message-ID: <3EC1243C.3020609@bitworks.com> Serafino Sorrenti wrote: > Hello, > now i download etherboot 5.1.8, i need more information to use this! > This is perhaps a little late but from my FAQ/HOWTO. How do I make LB use etherboot IDE? First you need to go get etherboot and compile it. You either get the developement branch with IDE support or the stable branch which need a patch to work. Now modify the etherboot config file so that its compatible with LB. Specifically the ./src/Config file and the arch//Config file For Ver 5.1.8 The options you need to make sure are set are: -DELF_IMAGE -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONFIG_PCI_DIRECT there are other options that are helpful like -DCONSOLE_SERIAL - DCOMCONSOLE=xxx The option(s) you need to make sure it NOT set are: -DPCBIOS Then compile etherboot. You want to compile with a specific make command so that it generates the elfimage for LB to load. This is done by taggin the .zelf on to your normal makefile command. For example to make the polling IDE loader elf image you need: make bin/ide_disk.zelf For Ver 5.0.x: Now modify your linuxbios config file to include: option USE_ELF_BOOT=1 option PAYLOAD_SIZE= payload /path/to/your/etherboot/driver A quick note about PAYLOAD_SIZE. This parameter does not specifiy the exact size of the image but rather its fed to the bs= option of 'dd'. This along with the 'sync' option causes dd to only output files that are a mutiple of the bs= size. So if you specify bs=32768 but your input filesize is 40000 you will end up with a output file thats 65536. So far I have just kept PAYLOAD_SIZE at 32768 and then go back and adjust ROM_SIZE such that the final image size is the size of my ROM part. You also need an input stream for the elfboot code to read from so you must set one (or more?) of the following options. USE_GENERIC_ROM=1 Now you need to create an elf kernel for the ether boot code to find. Go fetch the mkelfimage command at ftp://ftp.lnxi.com/pub/src/mkelfImage/ Generally the latest one is better. Note that there are several older versions of binutils that are broken and mkelfimage will expose those bugs. Insure that you are running a recient copy of binutils. The following shows the version output from a known working bintuils. # as --version GNU assembler 2.13.90.0.10 20021010 Debian GNU/Linux Now compile mkelfimage. Which should be as easy as ./configure, make, make install You can now create a elf kernel. Change to the directory where the image file for you kernel is. Normally this is somewhere in the kernel tree. In my case this is arch/i386/boot and the kernel image is bzImage. By defaut mkelfimage is installed in /usr/local/sbin so you would do /usr/local/sbin/mkelfimage bzImage elfimage Now you have your kernel elfized in the file 'elfimage' mkelfimage support several options for adding commandlines and initrd's to the kernel image type 'mkelfimage' without any arguments for the details. Ok final setp. Locate the kernel on the IDE device. Etherboot currently searchs the first 8k of disk space for the elf header. So you have to locate the start of that kernel within that space. If you don't care about having a proper partition table on your disk then you can just splat the kernel at the front of the disk. For the rest of the examples lets assume your disk is mounted in your *developement* machine as /dev/hde The following will write the kernel at the beginning of the IDE device. # cat elfimage > /dev/hde This works well if you don't need the IDE device for anything other than booting. If you want a filesystem on the device as well then you are going to have to protect the partition table as well. Currently the hack for accomplishing this is dd if=elfimage of=/dev/hde bs=4096 seek=1 This will skip over the partition table and write the data in the area where the first partition would normally be. So you have to create a disk with at least 2 partitions. /dev/hde1 should be large enough to hold your kernel plus any initrd you may want. You can then put your filesystem on /dev/hde2 Note. It appears that in some setups dd may whine about /dev/hde being an "Invalid argument" but it appears to write the data to the disk anyway. Somebody mentioned that it was a "buffer size" mismatch with dd and ext3 but nothing definitive was ever posted. If you receive this and solve the issue please report it. -- Richard A. Smith rsmith at bitworks.com From adam at cfar.umd.edu Tue May 13 13:16:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 13 13:16:01 2003 Subject: intel firmware hub parts In-Reply-To: <20030513104831.L33475-100000@www.missl.cs.umd.edu> Message-ID: <20030513140249.U35266-100000@www.missl.cs.umd.edu> > > > >82802ab, 82802ac > > > > and I just learned: > > N82802AC8 > > > > works in their data base much better :-) > > ARGH! > N = PLCC package, E = TSOP package. It seems that http://www.avnet.com/em/ has minimum order of 100 on those and they are out of sock anyway :/ http://www.arrow.com/ seems to have two kinds of those: E82802AC8 E82802AC8SB48 Anyone knows what's difference? -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rminnich at lanl.gov Tue May 13 13:32:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 13:32:00 2003 Subject: intel firmware hub parts In-Reply-To: <20030513140249.U35266-100000@www.missl.cs.umd.edu> Message-ID: On Tue, 13 May 2003, Adam Sulmicki wrote: > http://www.arrow.com/ seems to have two kinds of those: > > E82802AC8 > E82802AC8SB48 not sure, but sometimes that type of suffix can indicate extended temp. range. ron From stuge-linuxbios at cdy.org Tue May 13 16:26:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue May 13 16:26:01 2003 Subject: RFC:new superio proposal In-Reply-To: References: Message-ID: <20030513205104.GB17152@foo.birdnet.se> On Tue, May 13, 2003 at 08:11:46AM -0600, ron minnich wrote: [..snip..] > The remaining question is how should the superio command look in > freebios2? > > superio sis/950 "com1=115200,8n1 lpt=1 com2=9600" The way to go! As long as keywords are documented just like in the kernel, this is excellent! Just the fact that people may recognize this approach from the kernel is IMHO reason enough. > superio sis/950 "com1baud=115200 lpt=1 com1chars=8n1" Unneccessarily lengthy and 8n1 is related to 115200 so no need to separate them. > superio sis/950 ((com1 115200 8n1) (lpt 1)) Eww, lisp! Hehe. :) > So, my questions: > > 1. Does this new scheme look workable. If not, what needs to change? I think it looks very good and quite scalable. IANA LinuxBIOS expert though, so I might be overlooking things that are missing or unworkable. > 2. What should the 'struct configuration' be? does keyword/value work? I think so. Then leave value parsing up to each module, and maybe create a couple of common primitives that can be used. How much is left to each superio also depends on the diversity of keyword/value pairs. > 3. what should the superio command look like? See above. //Peter From ebiederman at lnxi.com Tue May 13 17:10:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 13 17:10:01 2003 Subject: [Status] freebios1.1 Message-ID: I have just merged a driver update from SuSE. IDE should now work. Resets new work to some extent. Romcc continues to stabilize. I have just found a bug in the register allocator and added a runtime check so the code will fail at compile time. In addition I have added a work around for the common case to let development continue. The problem is that some instructions must use a specific register, and when two of those instructions exist, use the same register and there is not an intermediate instruction that would move the value from one register to another then romcc fails to put the value into a different register. It skips the instruction because the register is already allocated. Fixing this problem and in general implement spilling from one register into another in romcc is now on the todo list. Doing this cleanly will take a little time. But it is also required to support storing values in the sse/mmx registers and other places. Eric From bari at onelabs.com Tue May 13 18:04:01 2003 From: bari at onelabs.com (Bari Ari) Date: Tue May 13 18:04:01 2003 Subject: RFC:new superio proposal References: Message-ID: <3EC174BB.9020609@onelabs.com> ron minnich wrote: >Abstract: > The superio architecture for linuxbios has worked for the last 2 >years but is being stretched to the limit by the changes in superio chips. >The architecture depended on superio resources being relatively constant >between chips, but this assumption no longer holds. In this document we >propose several alternatives and solicit comments. > > Another change in super i/o resources is the use of a microprocessor rather than a hardwired super i/o chip. In laptops and mobile devices the current and future trend is to use a 16 bit cpu with I/O ports (PS2, serial, parallel, keyboard scan, GPIO, SMbus) that interfaces to the chipset using LPC bus. The 16 bit cpu has internal flash for the firmware that may be reprogrammed in circuit via the LPC and/or other ports. This cpu is used as a system power keyboard controller as well as super i/o. We have been working a bit on having open firmware for these as well. The new super i/o structure of freebios2 should also account for these changes. --Bari From rminnich at lanl.gov Tue May 13 18:24:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 13 18:24:01 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC174BB.9020609@onelabs.com> Message-ID: On Tue, 13 May 2003, Bari Ari wrote: > The new super i/o structure of freebios2 should also account for these > changes. any suggestions on how this should look? I can see a src/superio//microprocessor, to which you pass all these parameters, and which talks to the microprocessor to set them up. Would that be sufficient? What new parameters would it need? ron From bari at onelabs.com Tue May 13 18:39:00 2003 From: bari at onelabs.com (Bari Ari) Date: Tue May 13 18:39:00 2003 Subject: RFC:new superio proposal References: Message-ID: <3EC16101.6020205@onelabs.com> ron minnich wrote: >Abstract: > The superio architecture for linuxbios has worked for the last 2 >years but is being stretched to the limit by the changes in superio chips. >The architecture depended on superio resources being relatively constant >between chips, but this assumption no longer holds. In this document we >propose several alternatives and solicit comments. > > > Another change in super i/o resources is the use of a microprocessor rather than a hardwired super i/o chip. In laptops and mobile devices the current and future trend is to use a 16 bit cpu with I/O ports (PS2, serial, parallel, keyboard scan, GPIO, SMbus) that interfaces to the chipset using LPC bus. The 16 bit cpu has internal flash for the firmware that may be reprogrammed in circuit via the LPC and/or other ports. This cpu is used as a system power keyboard controller as well as super i/o. We have been working a bit on having open firmware for these as well. The new super i/o structure of freebios2 should also account for these changes. --Bari From ebiederman at lnxi.com Tue May 13 20:24:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 13 20:24:01 2003 Subject: RFC:new superio proposal In-Reply-To: References: Message-ID: ron minnich writes: > Abstract: > The superio architecture for linuxbios has worked for the last 2 > years but is being stretched to the limit by the changes in superio chips. > The architecture depended on superio resources being relatively constant > between chips, but this assumption no longer holds. In this document we > propose several alternatives and solicit comments. > > Overview: > The superio architecture in linuxbios was developed over time, and > modified as circumstances required. In the beginning it was relatively > simple and assumed only one superio per mainboard. The latest version > allows an arbitrary number of superios per mainboard, and allows complete > specification of the superio base I/O address along with the specification > of reasonable default valures for both the base I/O address and the > superio parameters such as serial enable, baud rate, and so on. > > Specification of superio control parameters is done by a configuration > line such as: > > nsuperio sis/950 com1={1} floppy=1 lpt=1 > > This fragment sets the superio type to sis/950; sets com1, floppy, and lpt > to enabled; and leaves the defaults to com1 (baud rate, etc.) to the > default values. > > While it is not obvious, these configuration parameters are fragments of a > C initializer. The initializers are used to build a statically initialized > structure of this type: > > struct superio { > struct superio_control *super; // the ops for the device. > unsigned int port; // if non-zero, overrides the default port > // com ports. This is not done as an array (yet). > // We think it's easier to set up from python if it is not an > // array. > struct com_ports com1, com2, com3, com4; > // DMA, if it exists. > struct lpt_ports lpt1, lpt2; > /* flags for each device type. Unsigned int. */ > // low order bit ALWAYS means enable. Next bit means to enable > // LPT is in transition, so we leave this here for the moment. > // The winbond chips really stretched the way this works. > // so many functions! > unsigned int ide, floppy, lpt; > unsigned int keyboard, cir, game; > unsigned int gpio1, gpio2, gpio3; > unsigned int acpi,hwmonitor; > }; > > These structures are, in turn, created and statically initialized by a > config-tool-generated structure that defines all the superios. This file > is called nsuperio.c, is created for each mainboard you build, only > appears in the build directory, and looks like this: > > === > extern struct superio_control superio_winbond_w83627hf_control; > > struct superio superio_winbond_w83627hf= { > &superio_winbond_w83627hf_control, > .com1={1}, .com2={1}, .floppy=1, .lpt=1, .keyboard=1, .hwmonitor=1}; > > struct superio *all_superio[] = {&superio_winbond_w83627hf, > }; > > unsigned long nsuperio = 1; > === This last bit I really like because it falls out cleanly. Somewhere you need to specify what you take and what is a better definition than a structure definition. And just generating a structure initializer from a few well defined rules fells very clean. Structure initializes start getting wordy so we probably do not want to too much by hand. But with a convenient syntax for our purposes I don't see why we can't do something nice and clean. > This example shows a board with one superio (nsuperio). The superio > consists of a winbond w83627hf, with com1, com2, floppy, lpt, keyboard, > and hwmonitor enabled. Note that this structure also allows for > over-riding the default superio base, although that capability is rarely > used. > > The control structure is used to define how to access the superio for > purposes of control. It looks like this: > === > struct superio_control { > void (*pre_pci_init)(struct superio *s); > void (*init)(struct superio *s); > void (*finishup)(struct superio *s); > unsigned int defaultport; /* the defaultport. Can be overridden > * by commands in config > */ > // This is the print name for debugging > char *name; > }; > === > > There are three methods for stages of hardwaremain. First is pre_pci_init > (for chips like the acer southbridge that require you to enable some > resources BEFORE pci scan); init, called during the 'middle' phase of > hardwaremain; and finishup, called before the payload is loaded. > > This approach was inspired by and borrows heavily on the Plan 9 kernel > configuration tools. > > The problem: > > When the first version of the superio structure came out it was much > smaller. It has grown and in the limit this structure is the union of all > possibly superio chips. Obviously, in the long term, this is not > practical: we can not anticipate all possible superio chips for all time. > > The common PC BIOS solution to this type of problem is to continue with > binary structures but add version numbers to them, so that all code that > uses a given structure has to check the version number. Personally, I find > this grotesque and would rather not work this way. Version numbers are the wrong thing. Devices supporting multiple interfaces and a way to query which interface you have is much cleaner. In this case it is just data but still. > Using textual strings for configuration is something I find far more > attractive. Plan 9 has shown that this approach has no real limits and > suffices for configuration tasks. The Linux kernel does more limited use > of strings for configuration, but still depends on them. Strings are > easier to read and work with than binary structures, and more important, a > lot easier to deal with when things start going wrong. > > The proposed solution: > > What follows are three possible ideas for specifying superio resources and > their settings. > > A common part of the new idea is to eliminate the common superio > structure, due to the many variations in chips, and make it invisible > outside a given superio source file -- the superio structure is now > private to a given superio. Thus, sis/950/superio.c would contain its own > superio structure definitions, and also might contain more than once > instance of these structures (consider a board with 2 sis 950 chips). > > The control structure would change as follows: > struct superio_control { > int (*create)(struct superio *s); > void (*pre_pci_init)(struct superio *s); > void (*init)(struct superio *s); > void (*finishup)(struct superio *s); > unsigned int defaultport; /* the defaultport. Can be overridden > * by commands in config > */ > // This is the print name for debugging > char *name; > }; > > I.e. we add a new function for creating the superio. > > Communication of superio settings from linuxbios to the superio would be > via textual strings. The superio structure becomes this: > > struct superio { > struct superio_control *super; // the ops for the device. > unsigned int port; // if non-zero, overrides the default port > struct configuration *config; > }; > > > So now the question becomes, what is the configuration structure? > There are several choices. The simplest, from my point of view, are > keyword-value pairs: > struct configuration { > const char *keyword; > const char *value; > }; > > These get filled in by the config tool as before. The linuxbios libary can > then provide a generic parsing function for the superios to use. > > The remaining question is how should the superio command look in > freebios2? > > superio sis/950 "com1=115200,8n1 lpt=1 com2=9600" > > or > > superio sis/950 "com1baud=115200 lpt=1 com1chars=8n1" > > or > > superio sis/950 ((com1 115200 8n1) (lpt 1)) > > So, my questions: > > 1. Does this new scheme look workable. If not, what needs to change? A) The problem domain is two small it should address all devices and configuration for interrupt lines. We need to address the relative routes on how to get to devices. In particular we need a way to specify which configuration goes to which devices. I.e. how do you configure a board when someone places 2 identical superio on the board. 2 identical nics are already common. In some contexts both the pci bus and the pci function are variable. > 2. What should the 'struct configuration' be? does keyword/value work? My personal preference is actually much closer to the current scheme. But instead of 1 structure include things like struct com_ports n times, and struct lpt_ports n times. Have a linked list of the structures you need with a common header something like: struct config_header { struct config_header *next; int config_type; }; And then we can have things like: #define SERIAL_CONFIG 1 struct serial_struct { struct config_header header; int baud_rate; }; > 3. what should the superio command look like? I'm not certain and how to specify the pieces in the config file. We need to specify both the device tree, and parameters for each device. Possibly something like: (dev cpu0 (apic (initial_id 0))) (dev cpu1 (apic (initial_id 1))) (dev E7500 (bus pci0 (dev ich3 (bus lpc0 (dev sio0 (serial baud 115200) ) ) ) (dev pci-slot-1 (irqa 1) (irqb 2) (irqc 3) (irqd 4)) (dev pci-slot-2 (irqa 2) (irqb 3) (irqc 4) (irqd 1)) (dev pci-slot-3 (irqa 3) (irqb 4) (irqc 1) (irqd 2)) (dev pci-slot-4 (irqa 4) (irqb 1) (irqc 2) (irqd 3)) (dev pci-slot-5 (irqa 1) (irqb 2) (irqc 3) (irqd 4)) (dev pci-slot-6 (irqa 2) (irqb 3) (irqc 4) (irqd 1)) ) ) Where we have a shorthand easy way to specify devices and their configuration but at the same time have something that will generate structure initializers. What I have is still way off but it begins to describe the idea. There is a lot of information that needs to be specified, and a lot of it has standardized components so it should use the same description from piece to piece. > > I'd like to adopt this "RFC" approach for freebios2 as much as we can. > There was a lot of give-and-take in the early days of linuxbios about > structure and it proved useful. There's a lot that will start happening in > freebios2 now, and we need to try to make sure it will work for everyone. I mostly agree. But so far this is still a very formal request for discussion. A RFC contains a believed complete specification for an implementation. We need something similar for our external interfaces as well. Look at hardwaremain in the freebios2 tree. I want that to be the interface that initializes everything and if anything I want to make it more general and simpler than it is now. Eric From bendany at mistdl.com Tue May 13 22:38:00 2003 From: bendany at mistdl.com (bendany) Date: Tue May 13 22:38:00 2003 Subject: ASUS TX97LE mainboard seems support too. References: <20030512123151.L28883-100000@www.missl.cs.umd.edu> Message-ID: <019201c319c7$dbcfa270$2a00a8c0@ben> > > If you'd like to see if you can get ADLO with video working on that board, > that would be good. > > - Adam Agnew > I have tested the tx97le with ADLO. apply the ADLO 440bx patch. and I use the etherboot to load ADLO from network, works. but get some problems. I use a 3c905cx netcard & a winfast S600DX videocard. seems that bochs couldn't init the IDE controller. and vga display works. ======================== Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ [BOCHS BIOS VER:1.79] [COMPILE DATE:May 11 2003 TIME:19:16:53] DEVICE:0 int13_harddisk: function 02, unmapped device for DL=80 Boot from Hard Disk 0 failed FATAL: Could not read the boot disk ========================= I also try the polled IDE patch for the etherboot. ========================= Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ [BOCHS BIOS VER:1.79] [COMPILE DATE:May 11 2003 TIME:19:16:53] DEVICE:0 ROM segment 0xc800 length 0x8000 reloc 0x9400 int15: Func 24h, subfunc 01h, A20 gate control not supported Etherboot 5.0.6 (GPL) ELF for [EEPRO100] Trying polled ide Waiting for ide disks to spin up This is a hard coded delay and longer than necessary. I am now initializing the ide system Controller 0: detect FAILED Initializing the main controller failed! ========================= From bari at onelabs.com Tue May 13 22:44:00 2003 From: bari at onelabs.com (Bari Ari) Date: Tue May 13 22:44:00 2003 Subject: RFC:new superio proposal References: Message-ID: <3EC1B674.2000203@onelabs.com> ron minnich wrote: >On Tue, 13 May 2003, Bari Ari wrote: > > > >>The new super i/o structure of freebios2 should also account for these >>changes. >> >> > >any suggestions on how this should look? I can see a >src/superio//microprocessor, to which you pass all these >parameters, and which talks to the microprocessor to set them up. Would >that be sufficient? What new parameters would it need? > > > Besides just setting a few bits in registers to config the super i/o, one now has the option/ability to reload the binary firmware into the flash memory of the super i/o to customize the board. The binary may be 64KB for some cpu based super i/o's. Some examples of cpu based super i/o's http://www.renesas.com/eng/products/mpumcu/16bit/h8s/2100/index.html Bari From agnew at cs.umd.edu Tue May 13 22:51:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue May 13 22:51:01 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <019201c319c7$dbcfa270$2a00a8c0@ben> Message-ID: <20030513233141.U36111-100000@www.missl.cs.umd.edu> Neither Bochs/ADLO or Etherboot try to "initialize" the ide controllers. Rather they just detect them and assume that they've already been initialized. Perhaps you can check to see if the ide controllers are initialized in your linuxbios southbridge code? It's usually trivial to do. Great to hear that video works in ADLO, that part is turning out to work a lot more often then i really anticipated. - Adam Agnew On Wed, 14 May 2003, bendany wrote: > > > > If you'd like to see if you can get ADLO with video working on that board, > > that would be good. > > > > - Adam Agnew > > > I have tested the tx97le with ADLO. apply the ADLO 440bx patch. > and I use the etherboot to load ADLO from network, works. but get some > problems. > I use a 3c905cx netcard & a winfast S600DX videocard. > > seems that bochs couldn't init the IDE controller. and vga display works. > > ======================== > Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ > [BOCHS BIOS VER:1.79] > [COMPILE DATE:May 11 2003 TIME:19:16:53] > > DEVICE:0 > > int13_harddisk: function 02, unmapped device for DL=80 > Boot from Hard Disk 0 failed > FATAL: Could not read the boot disk > ========================= > > I also try the polled IDE patch for the etherboot. > > ========================= > Bochs BIOS, 1 cpu, $Revision: 1.1 $ $Date: 2002/11/25 02:07:53 $ > [BOCHS BIOS VER:1.79] > [COMPILE DATE:May 11 2003 TIME:19:16:53] > DEVICE:0 > > ROM segment 0xc800 length 0x8000 reloc 0x9400 > int15: Func 24h, subfunc 01h, A20 gate control not supported > Etherboot 5.0.6 (GPL) ELF for [EEPRO100] > > Trying polled ide > Waiting for ide disks to spin up > This is a hard coded delay and longer than necessary. > I am now initializing the ide system > Controller 0: detect FAILED > Initializing the main controller failed! > ========================= > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From adam at cfar.umd.edu Tue May 13 22:56:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Tue May 13 22:56:01 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC1B674.2000203@onelabs.com> Message-ID: <20030513233619.K35266-100000@www.missl.cs.umd.edu> > >>The new super i/o structure of freebios2 should also account for these > >>changes. > > > >any suggestions on how this should look? I can see a > >src/superio//microprocessor, to which you pass all these > >parameters, and which talks to the microprocessor to set them up. Would > >that be sufficient? What new parameters would it need? > > > > > > > Besides just setting a few bits in registers to config the super i/o, > one now has the option/ability to reload the binary firmware into the > flash memory of the super i/o to customize the board. The binary may be > 64KB for some cpu based super i/o's. > > Some examples of cpu based super i/o's > > http://www.renesas.com/eng/products/mpumcu/16bit/h8s/2100/index.html In other words, it is an computer inside of computer. in fact it seems to sort of change the whole firmware padagrim. we have main pc bios PCI video : video bios super io : standalone firmware some pci card : pci bios. what's significant here is that the superio is compiled with the super IO's cpu as target rather than main cpu being the compilation target. As time go on I expect there to be more subcompoents go like this. The very fact alone that the compilation target is differnet suggest it being removed from pc linuxbios main to large degree. Adam, who actually did go over that 1000 page pdf. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Wed May 14 00:32:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed May 14 00:32:01 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC1B674.2000203@onelabs.com> References: <3EC1B674.2000203@onelabs.com> Message-ID: Bari Ari writes: > ron minnich wrote: > > >On Tue, 13 May 2003, Bari Ari wrote: > > > > > >> The new super i/o structure of freebios2 should also account for these > >> changes. > >> > > > > any suggestions on how this should look? I can see a > > src/superio//microprocessor, to which you pass all these parameters, > > and which talks to the microprocessor to set them up. Would that be > > sufficient? What new parameters would it need? > > > > > Besides just setting a few bits in registers to config the super i/o, one now > has the option/ability to reload the binary firmware into the flash memory of > the super i/o to customize the board. The binary may be 64KB for some cpu based > super i/o's. > > Some examples of cpu based super i/o's > > http://www.renesas.com/eng/products/mpumcu/16bit/h8s/2100/index.html Actually if you look up the original keyboard controller it was also a cpu. Though a very limited one. If you look you can find cpus in some of the strangest places. As for the configuration process it is largely irrelevant. The important infrastructure piece is the call graph and some small hooks to allow the same drivers to be used in different hardware configurations. Once your driver gets control it can do whatever makes sense. And that 64K blob I suspect is something you can just setup to be compiled in. If that is a reasonable way to do things. Eric From bendany at mistdl.com Wed May 14 01:34:01 2003 From: bendany at mistdl.com (bendany) Date: Wed May 14 01:34:01 2003 Subject: doesn't support 2Mbit rom? Message-ID: <01aa01c319e0$88c55bb0$2a00a8c0@ben> I am testing another mainboard with linuxbios. base on 440bx chipset. onboard 82558 netcard, ati rage 128 videocard and ess 1938 soundcard. the eprom is MX29F004, 4Mbit. I use the config of digitallogic/smartcore-p3.use the etherboot 5.06 payload. I build a 1M romimage. burn it into Atmel 29c010a. linuxbios can succeed load the etherboot payload. but the etherboot failed detecting the onboard netcard. so I try ADLO, and I replace the etherboot payload with ADLO. build a 2Mbit romimage. burn it into SST 29EE020. but the elfboot cannot find the ELF image of ADLO. ---------output message---------------- done. Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 00000680 checksum fe7c Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000007f Cannot Load ELF Image ----------------------------------------- ----------my config file ---------------- target 440bx mainboard digitallogic/smartcore-p3 option SERIAL_CONSOLE=1 option DEFAULT_CONSOLE_LOGLEVEL=8 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEBUG=1 option USE_GENERIC_ROM=1 option ROM_SIZE=262144 option PAYLOAD_SIZE=196608 option USE_ELF_BOOT=1 #payload ../eepro100.ebi payload ../payload.adlo nooption RAMTEST -------------------------------- I have no idea how to deal with. any tips? BTW: if I use polled IDE patch + ADLO. videocard can init correctly. Regards. From ts1 at cma.co.jp Wed May 14 04:03:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed May 14 04:03:01 2003 Subject: EPIA VGA patch Message-ID: <20030514084104.GA3842@cma.co.jp> Hello, I started with a fresh checkout of CVS tree (since my current working tree is a mess) and made a minimum modification to boot ADLO with VGA BIOS to enable video on a EPIA. With attached patches, my EPIA 5000 boots into GRUB (then Linux) with VGA console. lb-epia.patch This applies to LinuxBIOS itself. Enables shadow RAM, adds vgainit.inc (it is harmless unless HAVE_FRAMEBUFFER is enabled), and a minimum fix to raminit.inc. Ron, please apply this one. adlo-epia.patch This is for ADLO. Since it includes changes specific to EPIA, it should not (entirely) go into CVS. Note that this includes serial debug patch by hcyun, and EPIA doesn't work without it. Perhaps a timing problem? pirq-EPIA.bin This should be put at util/ADLO/pirq. It was taken from LinuxBIOS, not Award BIOS (I think it makes sense). Of cource, VGA BIOS is also required and it must be taken from your box. As I said this is minimum modification, it does not boot very fast, and it may fail to detect IDE at cold boot. For these issues, I have already posted fixes to the list. RAM is fixed at 64MB, as current CVS is. If you change this, you have to hack raminit.inc, as well as CMOS value in the ADLO/loader.s. I'm working on automatic detection of RAM. Have fun. -- Takeshi -------------- next part -------------- diff -urN freebios-cvs/src/mainboard/via/epia/Config freebios-vga/src/mainboard/via/epia/Config --- freebios-cvs/src/mainboard/via/epia/Config 2002-12-14 15:34:34.000000000 +0900 +++ freebios-vga/src/mainboard/via/epia/Config 2003-05-14 04:10:50.000000000 +0900 @@ -11,6 +11,7 @@ mainboardinit pc80/serial.inc mainboardinit arch/i386/lib/console.inc mainboardinit northbridge/via/vt8601/raminit.inc +mainboardinit northbridge/via/vt8601/vgainit.inc mainboardinit southbridge/via/vt8231/ideconfig.inc # mainboardinit ram/dump_northbridge.inc # mainboardinit ram/ramtest.inc diff -urN freebios-cvs/src/northbridge/via/vt8601/northbridge.c freebios-vga/src/northbridge/via/vt8601/northbridge.c --- freebios-cvs/src/northbridge/via/vt8601/northbridge.c 2003-05-13 22:13:51.000000000 +0900 +++ freebios-vga/src/northbridge/via/vt8601/northbridge.c 2003-05-14 16:41:52.000000000 +0900 @@ -19,6 +19,15 @@ if (! pcidev) return 0; + + /* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write + * PIRQ table, VGA BIOS, Bochs BIOS, etc. + * -- ts1 05/14/03 */ + printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: "); + pci_write_config_byte(pcidev, 0x61, 0xff); + pci_write_config_byte(pcidev, 0x62, 0xff); + pci_write_config_byte(pcidev, 0x63, 0xf0); + printk_debug("done\n"); // Documentation on VT8601 - Pg 51 Rev 1.3 Sept 1999 says // Device 0 Offset FB - Frame buffer control @@ -69,7 +78,7 @@ static struct mem_range mem[3]; mem[0].basek = 0; mem[0].sizek = 640; - mem[1].basek = 1024; + mem[1].basek = 768; mem[1].sizek = __sizeram(); mem[2].basek = 0; mem[2].sizek = 0; diff -urN freebios-cvs/src/northbridge/via/vt8601/raminit.inc freebios-vga/src/northbridge/via/vt8601/raminit.inc --- freebios-cvs/src/northbridge/via/vt8601/raminit.inc 2003-05-14 03:49:33.000000000 +0900 +++ freebios-vga/src/northbridge/via/vt8601/raminit.inc 2003-05-14 03:50:41.000000000 +0900 @@ -175,7 +175,7 @@ helped a tiny bit. We can get to schedule() before we crash, but only if we set a breakpoint after the first loop in free_all_bootmem_core */ - CS_WRITE($0x56, $0x10) - CS_WRITE($0x57, $0x10) + CS_WRITE($0x56, $0x08) + CS_WRITE($0x57, $0x08) intel_chip_post_macro(0x36) diff -urN freebios-cvs/src/northbridge/via/vt8601/vgainit.inc freebios-vga/src/northbridge/via/vt8601/vgainit.inc --- freebios-cvs/src/northbridge/via/vt8601/vgainit.inc 1970-01-01 09:00:00.000000000 +0900 +++ freebios-vga/src/northbridge/via/vt8601/vgainit.inc 2003-05-14 03:51:56.000000000 +0900 @@ -0,0 +1,22 @@ +#if HAVE_FRAMEBUFFER + +/* Frame buffer size in MBytes */ +#ifndef SMA_SIZE +#define SMA_SIZE 8 +#endif + +#if SMA_SIZE==2 +#define FBREG 0x90 +#elif SMA_SIZE==4 +#define FBREG 0xa0 +#elif SMA_SIZE==8 +#define FBREG 0xb0 +#else +#error SMA_SIZE should be 2, 4, or 8 (MB) +#endif + + CS_WRITE($0xf8, $0x22) // DRAM arbitation timer - AGP, Host + CS_WRITE($0xf9, $0x42) // DRAM arbitation timer - VGA priority, normal + CS_WRITE($0xfb, $FBREG) // VGA enable + +#endif -------------- next part -------------- diff -urN freebios-cvs/util/ADLO/Makefile freebios-vga/util/ADLO/Makefile --- freebios-cvs/util/ADLO/Makefile 2002-11-25 11:07:53.000000000 +0900 +++ freebios-vga/util/ADLO/Makefile 2003-05-14 03:58:24.000000000 +0900 @@ -12,6 +12,7 @@ PIRQ_M=pirq/pirq-MS7308E.bin PIRQ_P=pirq/pirq-P6STMT.bin PIRQ_T=pirq/pirq-ThinkPad.T23.bin +PIRQ_EPIA=pirq/pirq-EPIA.bin BOCHS_R=bochs BOCHS_B=bochs/bios @@ -25,6 +26,7 @@ VIDEO64W=video/video.bios-WINFAST64kb.bin VIDEO64M= VIDEO64P=video/video.bios-P6STMT-64kb.bin +VIDEO64EPIA=video/video.bios-EPIA-64kb.bin PAYLOAD=payload @@ -37,7 +39,7 @@ #------------------------------------------------- build: loader.o bios - cat ${ELF129} ${LOADER} ${PIRQ_M} ${BIOS_B} ${VIDEO64P} > ${PAYLOAD} + cat ${ELF129} ${LOADER} ${PIRQ_EPIA} ${BIOS_B} ${VIDEO64EPIA} > ${PAYLOAD} #------------------------------------------------- Binary files freebios-cvs/util/ADLO/bochs/bios/rombios.bin and freebios-vga/util/ADLO/bochs/bios/rombios.bin differ diff -urN freebios-cvs/util/ADLO/bochs/bios/rombios.c freebios-vga/util/ADLO/bochs/bios/rombios.c --- freebios-cvs/util/ADLO/bochs/bios/rombios.c 2002-11-25 11:07:53.000000000 +0900 +++ freebios-vga/util/ADLO/bochs/bios/rombios.c 2003-05-14 04:34:10.000000000 +0900 @@ -1424,18 +1424,78 @@ pop bp ASM_END } - - void + +#define SERIAL_DEBUG + +#ifdef SERIAL_DEBUG + +/* Data */ +#define UART_RBR 0x00 +#define UART_TBR 0x00 + +/* Control */ +#define UART_IER 0x01 +#define UART_IIR 0x02 +#define UART_FCR 0x02 +#define UART_LCR 0x03 +#define UART_MCR 0x04 +#define UART_DLL 0x00 +#define UART_DLM 0x01 + +/* Status */ +#define UART_LSR 0x05 +#define UART_MSR 0x06 +#define UART_SCR 0x07 + +int uart_can_tx_byte(base_port) + Bit16u base_port; +{ + return inb(base_port + UART_LSR) & 0x20; +} + +void uart_wait_to_tx_byte(base_port) + Bit16u base_port; +{ + while(!uart_can_tx_byte(base_port)) + ; +} + +void uart_wait_until_sent(base_port) + Bit16u base_port; +{ + while(!(inb(base_port + UART_LSR) & 0x40)) + ; +} + +void uart_tx_byte(base_port, data) + Bit16u base_port; + Bit8u data; +{ + uart_wait_to_tx_byte(base_port); + outb(base_port + UART_TBR, data); + /* Make certain the data clears the fifos */ + uart_wait_until_sent(base_port); +} + +#endif + +void send(action, c) Bit16u action; Bit8u c; { + +#ifdef SERIAL_DEBUG // hcyun + if ( c == '\n') uart_tx_byte(0x3f8, '\r'); + uart_tx_byte(0x3f8, c); +#else if (action & BIOS_PRINTF_DEBUG) outb(DEBUG_PORT, c); if (action & BIOS_PRINTF_INFO) outb(INFO_PORT, c); if (action & BIOS_PRINTF_SCREEN) { if (c == '\n') wrch('\r'); wrch(c); - } + } +#endif } void Binary files freebios-cvs/util/ADLO/loader.o and freebios-vga/util/ADLO/loader.o differ diff -urN freebios-cvs/util/ADLO/loader.s freebios-vga/util/ADLO/loader.s --- freebios-cvs/util/ADLO/loader.s 2002-11-25 11:07:53.000000000 +0900 +++ freebios-vga/util/ADLO/loader.s 2003-05-14 14:39:05.000000000 +0900 @@ -50,13 +50,13 @@ ;***************************************************** ; B) shadow - ON (enable/read/write) -mov eax, #0x80000070 -mov dx, #0x0cf8 -out dx, eax - -mov eax, #0xFFFFFFFF -mov dx, #0x0cfc -out dx, eax +;mov eax, #0x80000070 +;mov dx, #0x0cf8 +;out dx, eax +; +;mov eax, #0xFFFFFFFF +;mov dx, #0x0cfc +;out dx, eax ;***************************************************** nop @@ -166,14 +166,14 @@ ;***************************************************** ; E) shadow - OFF (write) -mov eax, #0x80000070 -mov dx, #0x0cf8 -out dx, eax - -;mov eax, #0xFFFFFFFF -mov eax, #0x0000FFFF -mov dx, #0x0cfc -out dx, eax +;mov eax, #0x80000070 +;mov dx, #0x0cf8 +;out dx, eax +; +;;mov eax, #0xFFFFFFFF +;mov eax, #0x0000FFFF +;mov dx, #0x0cfc +;out dx, eax ;***************************************************** nop @@ -262,14 +262,17 @@ ; 077F - 10 = 07 6F ; 07 6F - 00 F0 = 06 7F +; for EPIA with 64MB RAM and 8MB frame buffer +; 0370 - 00F0 = 02 80 + mov al, #0x35 ;; cmos_reg out 0x70, al -mov al, #0x06 ;; val +mov al, #0x02 ;; val out 0x71, al mov al, #0x34 ;; cmos_reg out 0x70, al -mov al, #0x7F ;; val +mov al, #0x80 ;; val out 0x71, al mov al, #0x31 ;; cmos_reg Binary files freebios-cvs/util/ADLO/payload and freebios-vga/util/ADLO/payload differ Binary files freebios-cvs/util/ADLO/pirq/pirq-EPIA.bin and freebios-vga/util/ADLO/pirq/pirq-EPIA.bin differ Binary files freebios-cvs/util/ADLO/video/video.bios-EPIA-64kb.bin and freebios-vga/util/ADLO/video/video.bios-EPIA-64kb.bin differ -------------- next part -------------- A non-text attachment was scrubbed... Name: pirq-EPIA.bin Type: application/octet-stream Size: 256 bytes Desc: not available URL: -------------- next part -------------- # # LinuxBIOS config file for: VIA epia mini-itx # with ADLO and manufacturer's VGA BIOS # target epia-vga # via epia mainboard via/epia # Enable Serial Console for debugging option SERIAL_CONSOLE=1 option TTYS0_BAUD=115200 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option DEBUG=1 option SERIAL_POST=1 # Use 256KB Standard Flash as Normal BIOS option RAMTEST=1 option STD_FLASH=1 option ZKERNEL_START=0xfffc0000 option ROM_SIZE=262144 # payload size option PAYLOAD_SIZE=196608 # use ELF Loader option USE_ELF_BOOT=1 # Boot payload in IDE disk partition #option BOOT_IDE=1 #option CONFIG_UDELAY_TSC=1 # Boot payload in ROM option USE_GENERIC_ROM=1 # our payload #payload /home/ts1/memtest86-3.0/memtest payload /home/ts1/freebios-vga/util/ADLO/payload # Enable video option HAVE_FRAMEBUFFER=1 From s.sorrenti at regia.tv Wed May 14 06:05:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Wed May 14 06:05:01 2003 Subject: hello Message-ID: <200305141242.58973.s.sorrenti@regia.tv> Hello Richard, i'm very crazy for this problem, i have done the modify at the config file for etherboot but i don't see any log in to serial port, and i don't see the linuxbios status. Tnx any more Serafino From yapeehuey at hotmail.com Wed May 14 06:10:01 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Wed May 14 06:10:01 2003 Subject: TUSL2-C almost work..... Message-ID: > > This has to be seek=1, not skip=1. Otherwise you overwrite your > > partition table with an incomplete elf file instead of leaving > > your partition table there and writing the complete file. > > > >I am going to regret that particular typo of mine for a long time. > >Sorry. Doesn't matter, both not working for me. I follow Richard's etherboot instructions on etherboot 5.1.8 but still no luck. Could it be my IDE harddisk not recognized ? OUTPUTS: ------------------------------------------------------------------------------------------------------ Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 203:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Searching for 16 byte tags 64:rom_read_bytes() - overflowed source buffer. max_block = 15 init_bytes found 0 tags Found ELF candiate at offset 0 Loading Etherboot version: 5.1.8 Dropping non PT_LOAD segment New segment addr 0x20000 size 0xeee0 offset 0xb0 filesize 0x617c (cleaned up) New segment addr 0x20000 size 0xeee0 offset 0xb0 filesize 0x617c Loading Segment: addr: 0x000000000ff7ece8 memsz: 0x000000000000eee0 filesz: 0x000000000000617c Clearing Segment: addr: 0x000000000ff84e64 memsz: 0x0000000000008d64 Jumping to boot code at 0x20000 ------------------------------------------------------------------------------------------------------------ Then it restarts. > >I think the solution of using sfdisk to build a /dev/hda1 that starts at >sector 1 is better. Fixing etherboot to scan 64k in each direction is >best. I tried that but it still didn't find the elfimage. > >ron > _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp From rminnich at lanl.gov Wed May 14 09:02:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 14 09:02:00 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC1B674.2000203@onelabs.com> Message-ID: On Tue, 13 May 2003, Bari Ari wrote: > Besides just setting a few bits in registers to config the super i/o, > one now has the option/ability to reload the binary firmware into the > flash memory of the super i/o to customize the board. The binary may be > 64KB for some cpu based super i/o's. This is like the case of the microcode update. I think we can accomodate this case. ron From rsmith at bitworks.com Wed May 14 11:57:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 11:57:00 2003 Subject: TUSL2-C almost work..... In-Reply-To: References: Message-ID: <3EC27020.2030507@bitworks.com> Yap Ee Huey wrote: > Doesn't matter, both not working for me. > I follow Richard's etherboot instructions on etherboot 5.1.8 but still > no luck. Could it be my IDE harddisk not recognized ? > OUTPUTS: > ------------------------------------------------------------------------------------------------------ > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.2 > 203:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff > Searching for 16 byte tags > 64:rom_read_bytes() - overflowed source buffer. max_block = 15 This looks like a problem. I would start here and figure out whats up with this. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Wed May 14 12:28:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 12:28:00 2003 Subject: hello In-Reply-To: <200305141242.58973.s.sorrenti@regia.tv> References: <200305141242.58973.s.sorrenti@regia.tv> Message-ID: <3EC276EB.9090200@bitworks.com> Serafino Sorrenti wrote: > Hello Richard, > i'm very crazy for this problem, i have done the modify at the config file for > etherboot but i don't see any log in to serial port, and i don't see the > linuxbios status. Linux bios spits out lots of info on the serial port _very_ early on. Even before RAM is setup. If you don't have any serial info then LinuxBIOS probally has not started correctly. That or your serial port isn't setup properly. You need to verify that LinuxBIOS is even runing. Do you have a post card? Verify that LinuxBIOS is properly loaded into your ROM chip at the right location. You should probally look at the Bios chip select line and see if you are successfully strobing out data. If you only see like 20 or 30 strobes and then nothing you probally don't have the ROM flashed correctly. If you see lots and lots of strobes then you probally are at least starting up. You might also try putting some outs to port 80 in cpi/i386/entry16.inc and see if the IO Strobe line gets asserted. -- Richard A. Smith rsmith at bitworks.com From bari at onelabs.com Wed May 14 12:39:01 2003 From: bari at onelabs.com (Bari Ari) Date: Wed May 14 12:39:01 2003 Subject: RFC:new superio proposal References: Message-ID: <3EC27A32.4010201@onelabs.com> ron minnich wrote: >On Tue, 13 May 2003, Bari Ari wrote: > > > >>Besides just setting a few bits in registers to config the super i/o, >>one now has the option/ability to reload the binary firmware into the >>flash memory of the super i/o to customize the board. The binary may be >>64KB for some cpu based super i/o's. >> >> > >This is like the case of the microcode update. I think we can accomodate >this case. > > > Just so this doesn't get left out or limited somehow ;-) These are also being used in servers to take care of power and thermal management. --Bari From pyro at linuxlabs.com Wed May 14 12:41:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed May 14 12:41:01 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC16101.6020205@onelabs.com> Message-ID: Greetings, That sounds interesting can you point me to a mainboard that uses one of those? G'day, sjames On Tue, 13 May 2003, Bari Ari wrote: > Another change in super i/o resources is the use of a microprocessor > rather than a hardwired super i/o chip. In laptops and mobile devices > the current and future trend is to use a 16 bit cpu with I/O ports (PS2, > serial, parallel, keyboard scan, GPIO, SMbus) that interfaces to the > chipset using LPC bus. The 16 bit cpu has internal flash for the > firmware that may be reprogrammed in circuit via the LPC and/or other > ports. This cpu is used as a system power keyboard controller as well as > super i/o. > > We have been working a bit on having open firmware for these as well. > > The new super i/o structure of freebios2 should also account for these > changes. > > --Bari > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From rminnich at lanl.gov Wed May 14 12:41:05 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 14 12:41:05 2003 Subject: RFC:new superio proposal In-Reply-To: <3EC27A32.4010201@onelabs.com> Message-ID: I'm going to rewrite that RFC, with a proposal this time, taking into account your and Eric's comments. ron From adam at cfar.umd.edu Wed May 14 13:08:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Wed May 14 13:08:00 2003 Subject: RFC:new superio proposal In-Reply-To: Message-ID: <20030514135629.U40600-100000@www.missl.cs.umd.edu> mostly laptops. for example IBM ThinkPad T23 IBM ThinkPad T30 On Wed, 14 May 2003, steven james wrote: > Greetings, > > That sounds interesting can you point me to a mainboard that uses one of > those? > > G'day, > sjames > > > > On Tue, 13 May 2003, Bari Ari wrote: > > > Another change in super i/o resources is the use of a microprocessor > > rather than a hardwired super i/o chip. In laptops and mobile devices > > the current and future trend is to use a 16 bit cpu with I/O ports (PS2, > > serial, parallel, keyboard scan, GPIO, SMbus) that interfaces to the > > chipset using LPC bus. The 16 bit cpu has internal flash for the > > firmware that may be reprogrammed in circuit via the LPC and/or other > > ports. This cpu is used as a system power keyboard controller as well as > > super i/o. > > > > We have been working a bit on having open firmware for these as well. > > > > The new super i/o structure of freebios2 should also account for these > > changes. > > > > --Bari > > > > > > _______________________________________________ > > 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 frannk_m1 at yahoo.com Wed May 14 14:37:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Wed May 14 14:37:00 2003 Subject: cvs co error Message-ID: <20030514191515.67020.qmail@web13807.mail.yahoo.com> I am getting the following error when trying to co linuxbios for the first time: cvs [checkout aborted]: could not chdir to freebios/src/arch/alpha/config: Not a directory anyone have an idea as to what is going on... __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From agnew at cs.umd.edu Wed May 14 14:44:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Wed May 14 14:44:00 2003 Subject: cvs co error In-Reply-To: <20030514191515.67020.qmail@web13807.mail.yahoo.com> Message-ID: <20030514152944.Q41173-100000@www.missl.cs.umd.edu> I just checked out a fresh tree just fine to test out your problem, though i was having trouble logging in a second before that. I think sourceforge is just having issues, that is not uncommon. On Wed, 14 May 2003, Frank wrote: > I am getting the following error when trying to co linuxbios for > the first time: > cvs [checkout aborted]: could not chdir to > freebios/src/arch/alpha/config: Not a directory > > anyone have an idea as to what is going on... > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rsmith at bitworks.com Wed May 14 15:00:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 15:00:00 2003 Subject: cvs co error In-Reply-To: <20030514191515.67020.qmail@web13807.mail.yahoo.com> References: <20030514191515.67020.qmail@web13807.mail.yahoo.com> Message-ID: <3EC29AE4.5090509@bitworks.com> Frank wrote: > I am getting the following error when trying to co linuxbios for > the first time: > cvs [checkout aborted]: could not chdir to > freebios/src/arch/alpha/config: Not a directory Do you per chance have that on a filesystem that isn't case sensitive? In the alpha directory there is both a 'Config' file and a 'config' directory. -- Richard A. Smith rsmith at bitworks.com From frannk_m1 at yahoo.com Wed May 14 16:49:01 2003 From: frannk_m1 at yahoo.com (Frank) Date: Wed May 14 16:49:01 2003 Subject: cvs co error In-Reply-To: <3EC29AE4.5090509@bitworks.com> Message-ID: <20030514212635.75889.qmail@web13802.mail.yahoo.com> very good point. I'm doing under cygwin.:-( --- Richard Smith wrote: > Frank wrote: > > > I am getting the following error when trying to co linuxbios > for > > the first time: > > cvs [checkout aborted]: could not chdir to > > freebios/src/arch/alpha/config: Not a directory > > Do you per chance have that on a filesystem that isn't case > sensitive? > In the alpha directory there is both a 'Config' file and a > 'config' > directory. > > -- > Richard A. Smith > rsmith at bitworks.com > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rsmith at bitworks.com Wed May 14 17:35:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 17:35:01 2003 Subject: cvs co error In-Reply-To: <20030514212635.75889.qmail@web13802.mail.yahoo.com> References: <20030514212635.75889.qmail@web13802.mail.yahoo.com> Message-ID: <3EC2BF14.6060109@bitworks.com> Frank wrote: > very good point. I'm doing under cygwin.:-( > --- Richard Smith wrote: > >>>I am getting the following error when trying to co linuxbios >> >>for >> >>>the first time: >>>cvs [checkout aborted]: could not chdir to >>>freebios/src/arch/alpha/config: Not a directory >> >>Do you per chance have that on a filesystem that isn't case >>sensitive? >>In the alpha directory there is both a 'Config' file and a >>'config' This has come up before. Ron perhaps in new developemnet tree you should use an extension for the 'Config' file like Config.lbc or .nlb -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Wed May 14 17:42:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 17:42:01 2003 Subject: cvs co error In-Reply-To: <20030514214445.57108.qmail@web13808.mail.yahoo.com> References: <20030514214445.57108.qmail@web13808.mail.yahoo.com> Message-ID: <3EC2BFA3.3080101@bitworks.com> Frank wrote: > It looks like cvs under cygwin is the culprit. Anyone know how > to resolve this... I don't think there is a solution currently for use on a non-case sensitive filesystem. > --- Richard Smith wrote: > >>>I am getting the following error when trying to co linuxbios >>>the first time: >>>cvs [checkout aborted]: could not chdir to >>>freebios/src/arch/alpha/config: Not a directory >> >>Do you per chance have that on a filesystem that isn't case >>sensitive? >>In the alpha directory there is both a 'Config' file and a >>'config' >>directory. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Wed May 14 17:51:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 14 17:51:01 2003 Subject: cvs co error In-Reply-To: <3EC2BF14.6060109@bitworks.com> Message-ID: On Wed, 14 May 2003, Richard Smith wrote: > This has come up before. Ron perhaps in new developemnet tree you > should use an extension for the 'Config' file like Config.lbc or .nlb oh my, that would break so much. I think I'd rather rename the directory. ron From rsmith at bitworks.com Wed May 14 17:59:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed May 14 17:59:01 2003 Subject: cvs co error In-Reply-To: References: Message-ID: <3EC2C4D9.30209@bitworks.com> ron minnich wrote: > On Wed, 14 May 2003, Richard Smith wrote: > > >>This has come up before. Ron perhaps in new developemnet tree you >>should use an extension for the 'Config' file like Config.lbc or .nlb > > > oh my, that would break so much. I think I'd rather rename the directory. Why? Shouldn't that be a simple change in nlbconfig.py and then a find command that renames ever occurance of Config to Config.xxx? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Wed May 14 18:05:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 14 18:05:01 2003 Subject: cvs co error In-Reply-To: <3EC2C4D9.30209@bitworks.com> Message-ID: On Wed, 14 May 2003, Richard Smith wrote: > Why? Shouldn't that be a simple change in nlbconfig.py and then a find > command that renames ever occurance of Config to Config.xxx? good point, I just worry about these big changes as it always seems to uncover Something I Didn't Think Of. I'll try it out later this week. ron From gwatson at lanl.gov Wed May 14 18:14:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Wed May 14 18:14:00 2003 Subject: cvs co error In-Reply-To: <3EC2C4D9.30209@bitworks.com> References: <3EC2C4D9.30209@bitworks.com> Message-ID: I get this problem under MacOS X, since it uses a non case-sensitive filesystem as well. I'd support it being fixed if possible. Greg At 5:36 PM -0500 14/5/03, Richard Smith wrote: >ron minnich wrote: > >>On Wed, 14 May 2003, Richard Smith wrote: >> >>>This has come up before. Ron perhaps in new developemnet tree you >>>should use an extension for the 'Config' file like Config.lbc or >>>.nlb >> >> >>oh my, that would break so much. I think I'd rather rename the directory. > >Why? Shouldn't that be a simple change in nlbconfig.py and then a >find command that renames ever occurance of Config to Config.xxx? > >-- >Richard A. Smith >rsmith at bitworks.com > > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Wed May 14 19:05:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 14 19:05:00 2003 Subject: cvs co error In-Reply-To: Message-ID: On Wed, 14 May 2003, Greg Watson wrote: > I get this problem under MacOS X, since it uses a non case-sensitive > filesystem as well. I'd support it being fixed if possible. everyone who wants Config files to become Config.lbc tell me. Everyone who wants to rename the config directories as config.d, tell me. ron From hansolofalcon at worldnet.att.net Wed May 14 19:18:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed May 14 19:18:01 2003 Subject: cvs co error In-Reply-To: Message-ID: <001301c31a74$58a2d220$0100a8c0@who5> Hello again from Gregg C Levine Ron, gang, I use Linux to build Linux BIOS. So, I'll work with whatever is chosen. It matters not, to me. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of ron minnich > Sent: Wednesday, May 14, 2003 7:41 PM > To: Greg Watson > Cc: LinuxBIOS > Subject: Re: cvs co error > > On Wed, 14 May 2003, Greg Watson wrote: > > > I get this problem under MacOS X, since it uses a non case-sensitive > > filesystem as well. I'd support it being fixed if possible. > > everyone who wants Config files to become Config.lbc tell me. > > Everyone who wants to rename the config directories as config.d, tell me. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From gwatson at lanl.gov Wed May 14 19:30:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Wed May 14 19:30:01 2003 Subject: cvs co error In-Reply-To: References: Message-ID: My vote: keep config dirs the same. Rename Config to Config.lbc. Greg At 5:40 PM -0600 14/5/03, ron minnich wrote: >On Wed, 14 May 2003, Greg Watson wrote: > >> I get this problem under MacOS X, since it uses a non case-sensitive >> filesystem as well. I'd support it being fixed if possible. > >everyone who wants Config files to become Config.lbc tell me. > >Everyone who wants to rename the config directories as config.d, tell me. > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Wed May 14 20:01:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed May 14 20:01:01 2003 Subject: cvs co error In-Reply-To: References: Message-ID: ron minnich writes: > On Wed, 14 May 2003, Greg Watson wrote: > > > I get this problem under MacOS X, since it uses a non case-sensitive > > filesystem as well. I'd support it being fixed if possible. > > everyone who wants Config files to become Config.lbc tell me. > > Everyone who wants to rename the config directories as config.d, tell me. Renaming config to config.d won't help as you will retain phantom directories in CVS. So the problem will continue, except for releases. I don't know if renaming the Config files will help, either, but it should as deleted files are not checked out. How about just Config.lb I don't think the extra c buys us anything. In addition while I can see supporting case insensitive filesystems supporting only 8.3 filenames is out. We have files in the tree that are too long already and it will be too easy to make that mistake. Eric From aip at cwlinux.com Thu May 15 00:04:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu May 15 00:04:00 2003 Subject: EPIA VGA patch In-Reply-To: <20030514084104.GA3842@cma.co.jp>; from SONE Takeshi on Wed, May 14, 2003 at 05:41:04PM +0900 References: <20030514084104.GA3842@cma.co.jp> Message-ID: <20030515124123.A25365@mail.cwlinux.com> Takeshi, > I started with a fresh checkout of CVS tree (since my current working tree > is a mess) and made a minimum modification to boot ADLO with VGA BIOS > to enable video on a EPIA. > > With attached patches, my EPIA 5000 boots into GRUB (then Linux) > with VGA console. > > lb-epia.patch > This applies to LinuxBIOS itself. > Enables shadow RAM, adds vgainit.inc (it is harmless unless > HAVE_FRAMEBUFFER is enabled), and a minimum fix to raminit.inc. > Ron, please apply this one. I think I will integrate this patch during the weekend. > adlo-epia.patch > This is for ADLO. > Since it includes changes specific to EPIA, it should not (entirely) > go into CVS. > Note that this includes serial debug patch by hcyun, and EPIA > doesn't work without it. Perhaps a timing problem? > pirq-EPIA.bin > This should be put at util/ADLO/pirq. > It was taken from LinuxBIOS, not Award BIOS (I think it makes sense). > Of cource, VGA BIOS is also required and it must be taken from your box. Ron, would you check this?? I'm not familiar with ADLO. > RAM is fixed at 64MB, as current CVS is. > If you change this, you have to hack raminit.inc, as well as CMOS value > in the ADLO/loader.s. > I'm working on automatic detection of RAM. I thought I have fixed it. Check out northbridge/via/vt8601/northbridge.c -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From adam at cfar.umd.edu Thu May 15 00:20:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 15 00:20:01 2003 Subject: EPIA VGA patch In-Reply-To: <20030514084104.GA3842@cma.co.jp> Message-ID: <20030515010243.Y43376-100000@www.missl.cs.umd.edu> > adlo-epia.patch > This is for ADLO. > Since it includes changes specific to EPIA, it should not (entirely) > go into CVS. > Note that this includes serial debug patch by hcyun, and EPIA > doesn't work without it. Perhaps a timing problem? standalone patch with stuff specific to EPIA probably would be better. as for timing isuses you may want to play with ide driver. > pirq-EPIA.bin > This should be put at util/ADLO/pirq. > It was taken from LinuxBIOS, not Award BIOS (I think it makes sense). > Of cource, VGA BIOS is also required and it must be taken from your box. Actually it is not clear if this particular stuff is needed at all. Initally we were using it to get Win2k to work, but later on it came out that windows boots without this stuff anyway. Perhaps it would be needed to get FreeBSD to boot. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From horen at mail.iucc.ac.il Thu May 15 01:31:01 2003 From: horen at mail.iucc.ac.il (Jonathan B. Horen) Date: Thu May 15 01:31:01 2003 Subject: Intel L440GX+ Message-ID: <3EC32EDE.10003@mail.iucc.ac.il> Shalom! While reading the LinuxBIOS website FAQ, I looked for instructions for building the romimage for the Intel L440GX+ motherboard -- they're missing; I also tried the link for Intel's "System Update Package" -- it's a dead link. So, can anyone send me build instructions for my motherboard and a pointer to the SUP? TIA! (33-node Beowulf cluster, wanting to move to LinuxBIOS/BeoBOOT/BProc) -- JONATHAN B. HOREN UNIX SYSTEMS ADMINISTRATOR E: horen at mail.iucc.ac.il Inter-University Computation Center T: +972-(0)3-640-5203 Tel-Aviv University F: +972-(0)3-640-9118 Ramat-Aviv 69978 Israel From hcyun at etri.re.kr Thu May 15 01:51:01 2003 From: hcyun at etri.re.kr (hcyun at etri.re.kr) Date: Thu May 15 01:51:01 2003 Subject: TUSL2-C almost work..... Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A9CD743@cms3> > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.2 > 203:init_bytes() - zkernel_start:0xfff00000 > zkernel_mask:0x0000ffff > Searching for 16 byte tags > 64:rom_read_bytes() - overflowed source buffer. max_block = 15 > init_bytes found 0 tags > Found ELF candiate at offset 0 > Loading Etherboot version: 5.1.8 > Dropping non PT_LOAD segment > New segment addr 0x20000 size 0xeee0 offset 0xb0 filesize 0x617c > (cleaned up) New segment addr 0x20000 size 0xeee0 offset 0xb0 > filesize > 0x617c > Loading Segment: addr: 0x000000000ff7ece8 memsz: > 0x000000000000eee0 filesz: > 0x000000000000617c > Clearing Segment: addr: 0x000000000ff84e64 memsz: 0x0000000000008d64 > Jumping to boot code at 0x20000 > -------------------------------------------------------------- > ---------------------------------------------- > > Then it restarts. It seems like you should specify ZKERNEL_START correctly. If you have 256KB flash part, ZKERNEL_START should be 0xfffc0000. Heechul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts1 at cma.co.jp Thu May 15 02:43:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 15 02:43:00 2003 Subject: EPIA VGA patch In-Reply-To: <20030515010243.Y43376-100000@www.missl.cs.umd.edu> References: <20030514084104.GA3842@cma.co.jp> <20030515010243.Y43376-100000@www.missl.cs.umd.edu> Message-ID: <20030515072040.GA850@cma.co.jp> On Thu, May 15, 2003 at 01:05:10AM -0400, Adam Sulmicki wrote: > > adlo-epia.patch > > This is for ADLO. > > Since it includes changes specific to EPIA, it should not (entirely) > > go into CVS. > > Note that this includes serial debug patch by hcyun, and EPIA > > doesn't work without it. Perhaps a timing problem? > > standalone patch with stuff specific to EPIA probably would be better. My patch is all about trivial stuff to build correctly for EPIA. Doesn't ADLO need a generic configuration mechanism? In current form, everything is hardcoded, so patches like mine are hard to get in. It is enough to have a simplest configuration mechanism, like Makefile includes that specify which video BIOS to use, which shadow ON/OFF code to include, etc. > as for timing isuses you may want to play with ide driver. It hangs before hitting IDE code. Video is not initialized. -- Takeshi From adam at cfar.umd.edu Thu May 15 03:01:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 15 03:01:00 2003 Subject: EPIA VGA patch In-Reply-To: <20030515072040.GA850@cma.co.jp> Message-ID: <20030515034204.W44081-100000@www.missl.cs.umd.edu> > > > adlo-epia.patch > > > This is for ADLO. > > > Since it includes changes specific to EPIA, it should not (entirely) > > > go into CVS. > > > Note that this includes serial debug patch by hcyun, and EPIA > > > doesn't work without it. Perhaps a timing problem? > > > > standalone patch with stuff specific to EPIA probably would be better. > > My patch is all about trivial stuff to build correctly for EPIA. > Doesn't ADLO need a generic configuration mechanism? > In current form, everything is hardcoded, so patches like mine are > hard to get in. > It is enough to have a simplest configuration mechanism, > like Makefile includes that specify which video BIOS to use, video bios is copyrighted. we can't collect/distribute those. I belive. > which shadow ON/OFF code to include, etc. Well the idea was to move all motherboard-dependant stuff into LinuxBIOS and and leave ADLO motherboard-independent. After all, we are talking here only about control of shadow ram and that's about it. There was some discussion on it before, there was some talk, there was some plans but nothing came out of it so far. Perhaps potentially a message in it self (ie did we over-engieer the proposed solution?) Either way, right now I'm busy with other stuff so far as ADLO goes I sort of limit it to support on mailing list and archiving patches on list (if you send an ADLO patch cc me as well so that it get suffed in my personal mailbox too). But I don't touch code at present time. > > as for timing isuses you may want to play with ide driver. > > It hangs before hitting IDE code. Video is not initialized. Weird. Perhaps u can try playing with port-80? maybe it is keyboard? -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From yapeehuey at hotmail.com Thu May 15 03:54:00 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Thu May 15 03:54:00 2003 Subject: TUSL2-C almost work..... Message-ID: Hi, I thought zkernel_start could be the reason, but not : --------------------------------------------------------------------------- Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 203:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000007f Searching for 16 byte tags 64:rom_read_bytes() - overflowed source buffer. max_block = 3 init_bytes found 0 tags Found ELF candiate at offset 0 Loading Etherboot version: 5.1.8 Dropping non PT_LOAD segment New segment addr 0x20000 size 0x12e0f offset 0xb0 filesize 0x3f5d (cleaned up) New segment addr 0x20000 size 0x12e0f offset 0xb0 filesize 0x3f5d Loading Segment: addr: 0x000000000ff7ec68 memsz: 0x0000000000012e0f filesz: 0x0000000000003f5d Clearing Segment: addr: 0x000000000ff82bc5 memsz: 0x000000000000eeb2 Jumping to boot code at 0x20000 (Restarted) LinuxBIOS-1.0.0 Tue May 13 11:51:30 EDT 2003 starting... Ram1 Ram2 ................. --------------------------------------------------------------------------- Still looping............ My kernel was built by : mkelfImage --command-line="root=/dev/hda5 console=ttyS0,19200" --kernel vmlinux -o vmlinux..elf But the ELF image cannot be tagged. (invalid linux kernel) Also, the tagged bzImage cannot be made ELF. (Not an linux kernel at line 73) Could it be a problem ? I should have a tagged ELF according to the Documentation. Thanks a lot. regards, eehuey >From: hcyun at etri.re.kr >To: yapeehuey at hotmail.com, rminnich at lanl.gov >CC: linuxbios at clustermatic.org >Subject: RE: TUSL2-C almost work..... >Date: Thu, 15 May 2003 15:28:14 +0900 > > > > Welcome to elfboot, the open sourced starter. > > January 2002, Eric Biederman. > > Version 1.2 > > 203:init_bytes() - zkernel_start:0xfff00000 > > zkernel_mask:0x0000ffff > > Searching for 16 byte tags > > 64:rom_read_bytes() - overflowed source buffer. max_block = 15 > > init_bytes found 0 tags > > Found ELF candiate at offset 0 > > Loading Etherboot version: 5.1.8 > > Dropping non PT_LOAD segment > > New segment addr 0x20000 size 0xeee0 offset 0xb0 filesize 0x617c > > (cleaned up) New segment addr 0x20000 size 0xeee0 offset 0xb0 > > filesize > > 0x617c > > Loading Segment: addr: 0x000000000ff7ece8 memsz: > > 0x000000000000eee0 filesz: > > 0x000000000000617c > > Clearing Segment: addr: 0x000000000ff84e64 memsz: 0x0000000000008d64 > > Jumping to boot code at 0x20000 > > -------------------------------------------------------------- > > ---------------------------------------------- > > > > Then it restarts. > >It seems like you should specify ZKERNEL_START correctly. If you have 256KB >flash part, ZKERNEL_START should be 0xfffc0000. > >Heechul. > _________________________________________________________________ Download the latest MSN Messenger http://messenger.msn.com.my From ts1 at cma.co.jp Thu May 15 04:04:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 15 04:04:01 2003 Subject: EPIA VGA patch In-Reply-To: <20030515034204.W44081-100000@www.missl.cs.umd.edu> References: <20030515072040.GA850@cma.co.jp> <20030515034204.W44081-100000@www.missl.cs.umd.edu> Message-ID: <20030515084126.GA4171@cma.co.jp> On Thu, May 15, 2003 at 03:49:30AM -0400, Adam Sulmicki wrote: > video bios is copyrighted. we can't collect/distribute those. I belive. I knew that, and I'm talking about lines like these from Makefile: 25 VIDEO64W=video/video.bios-WINFAST64kb.bin 26 VIDEO64M= 27 VIDEO64P=video/video.bios-P6STMT-64kb.bin 39 build: loader.o bios 40 cat ${ELF129} ${LOADER} ${PIRQ_M} ${BIOS_B} ${VIDEO64P} > ${PAYLOAD} I call this hardcode. Although it is trivial to adapt those lines to a specific board (that's almost all in patch), I don't think this the right way to do things. > > which shadow ON/OFF code to include, etc. > > Well the idea was to move all motherboard-dependant stuff into LinuxBIOS > and and leave ADLO motherboard-independent. After all, we are talking here > only about control of shadow ram and that's about it. My patch enables shadow RAM in LinuxBIOS, and doesn't touch those registers in ADLO at all. > > > as for timing isuses you may want to play with ide driver. > > > It hangs before hitting IDE code. Video is not initialized. > > Weird. > > Perhaps u can try playing with port-80? > > maybe it is keyboard? I don't have a POST card, and connecting or disconnecting keyboard doesn't help. Probably LinuxBIOS enables cache on my shadow RAM area, and it might be a cache problem. -- Takeshi From ts1 at cma.co.jp Thu May 15 04:59:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 15 04:59:00 2003 Subject: Passes RAM test, but hangs at jumping to RAM Message-ID: <20030515093717.GA8687@cma.co.jp> What could be a problem when it passes RAM test but hangs immediately after jumping to RAM? I'm developing a new raminit code and this happens only with a particular installation of DIMM. DIMM itself is not bad, it works when move to another slot, or another slot is filled with another DIMM. Award BIOS runs just fine with this DIMM installation. LinuxBIOS-1.0.0 Thu May 15 07:27:04 JST 2003 starting... Enabled first bank of RAM: 0x10000000 bytes Testing SDRAM : 00000000-0009ffff SDRAM fill: 0009ffff SDRAM verify: 0009ffff Done. Testing SDRAM : 00100000-01000000 SDRAM fill: 01000000 SDRAM verify: 01000000 Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. (hangs up here) -- Takeshi From stuge-linuxbios at cdy.org Thu May 15 05:18:00 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Thu May 15 05:18:00 2003 Subject: TUSL2-C almost work..... In-Reply-To: References: Message-ID: <20030515094256.GA30321@foo.birdnet.se> On Thu, May 15, 2003 at 08:31:45AM +0000, Yap Ee Huey wrote: > I thought zkernel_start could be the reason, but not : [..snip..] > My kernel was built by : > mkelfImage --command-line="root=/dev/hda5 console=ttyS0,19200" > --kernel vmlinux -o vmlinux..elf > > But the ELF image cannot be tagged. (invalid linux kernel) > Also, the tagged bzImage cannot be made ELF. (Not an linux kernel at line > 73) > > Could it be a problem ? I should have a tagged ELF according to the > Documentation. Try getting a fresh version of mkelfimage. You should be able to run mkelfimage (note small i in newer versions) on bzImage without problems.. //Peter From s.sorrenti at regia.tv Thu May 15 05:24:01 2003 From: s.sorrenti at regia.tv (Serafino Sorrenti) Date: Thu May 15 05:24:01 2003 Subject: etherboot In-Reply-To: <3EC1243C.3020609@bitworks.com> References: <200305131133.14089.s.sorrenti@regia.tv> <3EC1243C.3020609@bitworks.com> Message-ID: <200305151158.31476.s.sorrenti@regia.tv> Hello Richard i've tried to put the kernel on the compact flash but there are problems here: > Currently the hack for accomplishing this is > > dd if=elfimage of=/dev/hde bs=4096 seek=1 > it seems to erase the partition table, do i have to skip some bytes at the beginning of the disk ? i've tried also with: dd if=elfimage of=/dev/hde1 bs=4096 seek=1 but linuxbios does not find hd0,0 /kernel when it starts. i have a question: if i use dd do raw copy from a file to the disk, how can linuxbios use /kernel ? i don't think there is any reference to a file :| Tnx Serafino From aip at cwlinux.com Thu May 15 05:30:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu May 15 05:30:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030515093717.GA8687@cma.co.jp>; from SONE Takeshi on Thu, May 15, 2003 at 06:37:17PM +0900 References: <20030515093717.GA8687@cma.co.jp> Message-ID: <20030515180249.A30234@mail.cwlinux.com> Do you have option CONFIG_COMPRESS=0 -Andrew On Thu, May 15, 2003 at 06:37:17PM +0900, SONE Takeshi wrote: > What could be a problem when it passes RAM test but hangs > immediately after jumping to RAM? > > I'm developing a new raminit code and > this happens only with a particular installation of DIMM. > DIMM itself is not bad, it works when move to another slot, > or another slot is filled with another DIMM. > Award BIOS runs just fine with this DIMM installation. > > > LinuxBIOS-1.0.0 Thu May 15 07:27:04 JST 2003 starting... > Enabled first bank of RAM: 0x10000000 bytes > Testing SDRAM : 00000000-0009ffff > SDRAM fill: > 0009ffff > SDRAM verify: > 0009ffff > Done. > Testing SDRAM : 00100000-01000000 > SDRAM fill: > 01000000 > SDRAM verify: > 01000000 > Done. > Copying LinuxBIOS to ram. > Jumping to LinuxBIOS. > (hangs up here) > > -- > Takeshi > _______________________________________________ > 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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From agnew at cs.umd.edu Thu May 15 05:36:27 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 15 05:36:27 2003 Subject: etherboot In-Reply-To: <200305151158.31476.s.sorrenti@regia.tv> Message-ID: <20030515061637.A44277-100000@www.missl.cs.umd.edu> eep. Hrmm.. It looks like you're following the directions for one etherboot, but using a different etherboot. If you're using etherboot 5.0.6 with my polled io / file system patch, then you want to: 1) Make sure that compact flash adapter is the primary master (hda not hde as long as you're going to use (hd0,0) ). 2) Just make a regular partition table, make sure the first primary partition is ext2 or ext3, and then save that kernel image as /kernel . 3) Only follow the directions for writted a kernel to the compact flash raw if you're going to use the development branch of etherboot (5.1.8 presently) - Adam Agnew On Thu, 15 May 2003, Serafino Sorrenti wrote: > Hello Richard > i've tried to put the kernel on the compact flash but there are problems here: > > > Currently the hack for accomplishing this is > > > > dd if=elfimage of=/dev/hde bs=4096 seek=1 > > > > it seems to erase the partition table, do i have to skip some bytes at the > beginning of the disk ? > > i've tried also with: > > dd if=elfimage of=/dev/hde1 bs=4096 seek=1 > > but linuxbios does not find hd0,0 /kernel when it starts. > > i have a question: if i use dd do raw copy from a file to the disk, how can > linuxbios use /kernel ? i don't think there is any reference to a file :| > > > > Tnx > Serafino > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From ts1 at cma.co.jp Thu May 15 05:53:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 15 05:53:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030515180249.A30234@mail.cwlinux.com> References: <20030515093717.GA8687@cma.co.jp> <20030515180249.A30234@mail.cwlinux.com> Message-ID: <20030515103046.GA10952@cma.co.jp> On Thu, May 15, 2003 at 06:02:49PM +0800, Andrew Ip wrote: > Do you have option CONFIG_COMPRESS=0 No. I didn't think it matters but I'll try it anyway. -- Takeshi From rminnich at lanl.gov Thu May 15 09:12:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 09:12:01 2003 Subject: EPIA VGA patch In-Reply-To: <20030515124123.A25365@mail.cwlinux.com> Message-ID: andrew, do a cvs update before committing any patches, as I have committed some of those. ron From rminnich at lanl.gov Thu May 15 09:26:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 09:26:00 2003 Subject: Intel L440GX+ In-Reply-To: <3EC32EDE.10003@mail.iucc.ac.il> Message-ID: oh boy, the Island of Misfit Motherboards. Reviving the L440gx+ will be tough. Let me dig a little. ron From frannk_m1 at yahoo.com Thu May 15 09:37:53 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 09:37:53 2003 Subject: debugger Message-ID: <20030515140356.67904.qmail@web13804.mail.yahoo.com> Can anyone recommend a debugger for bringing up LinuxBios on an x86 system... __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rminnich at lanl.gov Thu May 15 09:51:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 09:51:00 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030515093717.GA8687@cma.co.jp> Message-ID: On Thu, 15 May 2003, SONE Takeshi wrote: > What could be a problem when it passes RAM test but hangs > immediately after jumping to RAM? > > I'm developing a new raminit code and > this happens only with a particular installation of DIMM. > DIMM itself is not bad, it works when move to another slot, > or another slot is filled with another DIMM. > Award BIOS runs just fine with this DIMM installation. Every time I've seen this it is either drive strength settings or timing (esp. on the 8601, it is VERY sensitive to buffer strength). You really need to dump the northbridge and make sure you know exactly, for each setting, why award set it one way and why linuxbios set it the same way or differently. This is very tedious but it is your only choice. With the 8601 I saw one case where all the bits except one were correct on a data read. It only takes on wrong bit, however, to wreak havoc. ron From rminnich at lanl.gov Thu May 15 10:03:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 10:03:01 2003 Subject: debugger In-Reply-To: <20030515140356.67904.qmail@web13804.mail.yahoo.com> Message-ID: On Thu, 15 May 2003, Frank wrote: > Can anyone recommend a debugger for bringing up LinuxBios on an > x86 system... what kind of chip? and how much money can you spend? ron From frannk_m1 at yahoo.com Thu May 15 11:11:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 11:11:00 2003 Subject: debugger In-Reply-To: Message-ID: <20030515154913.1160.qmail@web13803.mail.yahoo.com> It depends on what's available... --- ron minnich wrote: > On Thu, 15 May 2003, Frank wrote: > > > Can anyone recommend a debugger for bringing up LinuxBios on > an > > x86 system... > > what kind of chip? and how much money can you spend? > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rsmith at bitworks.com Thu May 15 11:23:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 15 11:23:01 2003 Subject: etherboot In-Reply-To: <20030515061637.A44277-100000@www.missl.cs.umd.edu> References: <20030515061637.A44277-100000@www.missl.cs.umd.edu> Message-ID: <3EC3B727.50006@bitworks.com> Adam Agnew wrote: > eep. Hrmm.. It looks like you're following the directions for one > etherboot, but using a different etherboot. If you're using etherboot > 5.0.6 with my polled io / file system patch, then you want to: > > 1) Make sure that compact flash adapter is the primary master (hda not hde > as long as you're going to use (hd0,0) ). > > 2) Just make a regular partition table, make sure the first primary > partition is ext2 or ext3, and then save that kernel image as /kernel . > > 3) Only follow the directions for writted a kernel to the compact flash > raw if you're going to use the development branch of etherboot (5.1.8 > presently) Ah my bad. Looks like my howto is in error then. I only have the building of etherboot seperated out. I didn't realise the boot method was different as well. Adam can you do a short writeup on building etherboot 5.0.x apply your patches and then the process above? I'll make 2 different sections in my FAQ/HOWTO) one for each etherboot version. -- Richard A. Smith rsmith at bitworks.com From frannk_m1 at yahoo.com Thu May 15 11:35:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 11:35:00 2003 Subject: debugger In-Reply-To: Message-ID: <20030515155044.3698.qmail@web13801.mail.yahoo.com> sis55x SOC x86 based --- ron minnich wrote: > On Thu, 15 May 2003, Frank wrote: > > > Can anyone recommend a debugger for bringing up LinuxBios on > an > > x86 system... > > what kind of chip? and how much money can you spend? > > ron > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rminnich at lanl.gov Thu May 15 11:48:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 11:48:00 2003 Subject: debugger In-Reply-To: <20030515154913.1160.qmail@web13803.mail.yahoo.com> Message-ID: On Thu, 15 May 2003, Frank wrote: > It depends on what's available... you can drop anywhere from a few $K to $44K ron From rsmith at bitworks.com Thu May 15 11:59:56 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 15 11:59:56 2003 Subject: etherboot In-Reply-To: <200305151158.31476.s.sorrenti@regia.tv> References: <200305131133.14089.s.sorrenti@regia.tv> <3EC1243C.3020609@bitworks.com> <200305151158.31476.s.sorrenti@regia.tv> Message-ID: <3EC3BB82.9090606@bitworks.com> Serafino Sorrenti wrote: > i've tried to put the kernel on the compact flash but there are problems here: > > >> Currently the hack for accomplishing this is >> >> dd if=elfimage of=/dev/hde bs=4096 seek=1 >> > > > it seems to erase the partition table, do i have to skip some bytes at the > beginning of the disk ? Hmmm... I't shouldn't. Thats what the seek=1 does. Its skips over 4Kib of space before it begins writing. That should more than clear your partition table. Are you sure it nuked your partition table? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Thu May 15 12:13:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 12:13:01 2003 Subject: debugger In-Reply-To: <20030515155044.3698.qmail@web13801.mail.yahoo.com> Message-ID: On Thu, 15 May 2003, Frank wrote: > sis55x SOC x86 based then the other trick is can you put an ICE in there, some boards make it physically impossible. do you have URL with pics? ron From jarcher at pobox.com Thu May 15 12:46:01 2003 From: jarcher at pobox.com (jarcher) Date: Thu May 15 12:46:01 2003 Subject: debugger Message-ID: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> To add to Ron's message. It varies a lot with your experience and how dirty you want to get. A simple POST card and a lot of creative POST code bread crumbs is the cheap and dirty way to go, until you get the serial port debugger up and running. But it requires you to be really creative in crawling through the code. And takes a lot of time. But you can move up the a logic analyzer looking at bus cycles or an ICE (in circuit emulator) looking at CPU activity These two are expensive (lots of $10K), but you can often rent them. Setup is usually the time burner here. But with a LA you can take selective pictures of events chained together in time. I don't know if SIS has an ICE for their SOC products. Jordan PS: Has anyone done a USB interface low level debugger? Early BIOS or at least just prior to payload decompress. At 12:00 PM 5/15/2003 -0400, you wrote: >Message: 10 >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) >From: Frank >Subject: Re: debugger >To: ron minnich >Cc: linuxbios at clustermatic.org > >sis55x SOC x86 based >--- ron minnich wrote: > > On Thu, 15 May 2003, Frank wrote: > > > > > Can anyone recommend a debugger for bringing up LinuxBios on > > an > > > x86 system... > > > > what kind of chip? and how much money can you spend? > > > > ron From frannk_m1 at yahoo.com Thu May 15 12:59:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 12:59:00 2003 Subject: debugger In-Reply-To: Message-ID: <20030515173613.23815.qmail@web13803.mail.yahoo.com> No and it isn't socketed so I guess that's out... --- ron minnich wrote: > On Thu, 15 May 2003, Frank wrote: > > > sis55x SOC x86 based > > then the other trick is can you put an ICE in there, some > boards make it > physically impossible. do you have URL with pics? > > ron > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rminnich at lanl.gov Thu May 15 13:05:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 15 13:05:01 2003 Subject: debugger In-Reply-To: <20030515173613.23815.qmail@web13803.mail.yahoo.com> Message-ID: On Thu, 15 May 2003, Frank wrote: > No and it isn't socketed so I guess that's out... Richard Smith (I think) can recommend good flash rom emulators that do debugging too. ron From frannk_m1 at yahoo.com Thu May 15 13:17:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 13:17:00 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: <20030515175450.46313.qmail@web13806.mail.yahoo.com> I don't mind getting dirty. as a matter of fact i prefer to work in the dirt. That's why I'm looking at linuxbios.:-) I come from a ppc and mips world where debuuger's are a lot more plentiful and cheaper. What is a "POST card"... --- jarcher wrote: > To add to Ron's message. > > It varies a lot with your experience and how dirty you want to > get. > > A simple POST card and a lot of creative POST code bread > crumbs is the > cheap and dirty way to go, until you get the serial port > debugger up and > running. But it requires you to be really creative in > crawling through the > code. And takes a lot of time. > > But you can move up the a logic analyzer looking at bus cycles > or an ICE > (in circuit emulator) looking at CPU activity These two are > expensive > (lots of $10K), but you can often rent them. Setup is usually > the time > burner here. But with a LA you can take selective pictures of > events > chained together in time. I don't know if SIS has an ICE for > their SOC > products. > > Jordan > > PS: Has anyone done a USB interface low level debugger? Early > BIOS or at > least just prior to payload decompress. > > > At 12:00 PM 5/15/2003 -0400, you wrote: > >Message: 10 > >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) > >From: Frank > >Subject: Re: debugger > >To: ron minnich > >Cc: linuxbios at clustermatic.org > > > >sis55x SOC x86 based > >--- ron minnich wrote: > > > On Thu, 15 May 2003, Frank wrote: > > > > > > > Can anyone recommend a debugger for bringing up > LinuxBios on > > > an > > > > x86 system... > > > > > > what kind of chip? and how much money can you spend? > > > > > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From pyro at linuxlabs.com Thu May 15 13:31:26 2003 From: pyro at linuxlabs.com (steven james) Date: Thu May 15 13:31:26 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: On Thu, 15 May 2003, jarcher wrote: > PS: Has anyone done a USB interface low level debugger? Early BIOS or at > least just prior to payload decompress. I've looked into it, but it's a bit complex to have up at that point (at least with the regular UHCI and OHCI). At the least, it will require RAM and a portion of PCI to be up and running. At that point, might as well just put it in the C code after PCI init. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From frannk_m1 at yahoo.com Thu May 15 13:38:01 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 13:38:01 2003 Subject: debugger In-Reply-To: Message-ID: <20030515175559.46550.qmail@web13808.mail.yahoo.com> Cool, where are you Richard Smith... --- ron minnich wrote: > On Thu, 15 May 2003, Frank wrote: > > > No and it isn't socketed so I guess that's out... > > Richard Smith (I think) can recommend good flash rom emulators > that do > debugging too. > > > ron > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From jarcher at pobox.com Thu May 15 13:43:45 2003 From: jarcher at pobox.com (jarcher) Date: Thu May 15 13:43:45 2003 Subject: debugger In-Reply-To: References: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: <5.2.1.1.2.20030515105648.02e7f580@cybermorph.com> That may work. Longer term I'm more worried about debugging payloads. As they will probably change more often than the prebios stuff. Jordan At 01:55 PM 5/15/2003 -0400, steven james wrote: >On Thu, 15 May 2003, jarcher wrote: > > > PS: Has anyone done a USB interface low level debugger? Early BIOS or at > > least just prior to payload decompress. > >I've looked into it, but it's a bit complex to have up at that point (at >least with the regular UHCI and OHCI). At the least, it will require RAM >and a portion of PCI to be up and running. At that point, might as well >just put it in the C code after PCI init. > >G'day, >sjames > > >-- >-------------------------steven james, director of research, linux labs >... ........ ..... .... 230 peachtree st nw ste 2701 >the original linux labs atlanta.ga.us 30303 > -since 1995 http://www.linuxlabs.com > office 404.577.7747 fax 404.577.7743 >----------------------------------------------------------------------- From jarcher at pobox.com Thu May 15 13:49:28 2003 From: jarcher at pobox.com (jarcher) Date: Thu May 15 13:49:28 2003 Subject: debugger In-Reply-To: <20030515175450.46313.qmail@web13806.mail.yahoo.com> References: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: <5.2.1.1.2.20030515105844.02e808e8@cybermorph.com> A POST (power on self test) card is basically a dumb card that decodes an I/O port (80h) and displays the value. Nothing but the CPU access to the ROM and I/O bus (PCI or ISA) has to work to access the card. mov al, CRUMB_1 out 80h,al Like I said really down and dirty. But sometimes that's the only way to debug a system. I snagged a link to some sources from a message posted here a couple of days ago. Jordan At 10:54 AM 5/15/2003 -0700, Frank wrote: >I don't mind getting dirty. as a matter of fact i prefer to work >in the dirt. That's why I'm looking at linuxbios.:-) >I come from a ppc and mips world where debuuger's are a lot more >plentiful and cheaper. What is a "POST card"... >--- jarcher wrote: > > To add to Ron's message. > > > > It varies a lot with your experience and how dirty you want to > > get. > > > > A simple POST card and a lot of creative POST code bread > > crumbs is the > > cheap and dirty way to go, until you get the serial port > > debugger up and > > running. But it requires you to be really creative in > > crawling through the > > code. And takes a lot of time. > > > > But you can move up the a logic analyzer looking at bus cycles > > or an ICE > > (in circuit emulator) looking at CPU activity These two are > > expensive > > (lots of $10K), but you can often rent them. Setup is usually > > the time > > burner here. But with a LA you can take selective pictures of > > events > > chained together in time. I don't know if SIS has an ICE for > > their SOC > > products. > > > > Jordan > > > > PS: Has anyone done a USB interface low level debugger? Early > > BIOS or at > > least just prior to payload decompress. > > > > > > At 12:00 PM 5/15/2003 -0400, you wrote: > > >Message: 10 > > >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) > > >From: Frank > > >Subject: Re: debugger > > >To: ron minnich > > >Cc: linuxbios at clustermatic.org > > > > > >sis55x SOC x86 based > > >--- ron minnich wrote: > > > > On Thu, 15 May 2003, Frank wrote: > > > > > > > > > Can anyone recommend a debugger for bringing up > > LinuxBios on > > > > an > > > > > x86 system... > > > > > > > > what kind of chip? and how much money can you spend? > > > > > > > > ron > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > >__________________________________ >Do you Yahoo!? >The New Yahoo! Search - Faster. Easier. Bingo. >http://search.yahoo.com From frannk_m1 at yahoo.com Thu May 15 13:56:01 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 13:56:01 2003 Subject: debugger In-Reply-To: <000101c31b0d$33c9e4e0$0100a8c0@who5> Message-ID: <20030515181540.35034.qmail@web13801.mail.yahoo.com> Got it. I use the same technique with boards that have multiple (4 or more) led's. I can write a value to the led to tell me where i am in the code. Where can i get a POST card from... --- Gregg C Levine wrote: > Hello from Gregg C Levine > A POST card? How to explain simply... A POST card, was > created, (Or > designed), to display the activities of the computer, through > Port 80, > while it works from power on, the final prompt. The term POST > means, > Power On Self Test. It descends from the original IBM-PC > world. They > are very useful, in this world, because we are creating the > next > generation BIOS from the ground, or bare metal, up. There are > a preset > sequence of events, numbered 00 to FF to go through. Each of > them, > properly documented, can tell a designer why his new system > isn't > working. And then there are a specific series of POST codes > that can > be useful to designers, when running supplied diagnostics. > > At least that was the case, about ten years ago. It's been > that long > since I did that kind of work. The repairing of such systems, > that is. > > Okay, Ron, Richard, how did I do? > ------------------- > Gregg C Levine hansolofalcon at worldnet.att.net > ------------------------------------------------------------ > "The Force will be with you...Always." Obi-Wan Kenobi > "Use the Force, Luke."? Obi-Wan Kenobi > (This company dedicates this E-Mail to General Obi-Wan Kenobi > ) > (This company dedicates this E-Mail to Master Yoda ) > > > > > -----Original Message----- > > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > > admin at clustermatic.org] On Behalf Of Frank > > Sent: Thursday, May 15, 2003 1:55 PM > > To: jarcher; linuxbios at clustermatic.org > > Subject: Re:debugger > > > > I don't mind getting dirty. as a matter of fact i prefer to > work > > in the dirt. That's why I'm looking at linuxbios.:-) > > I come from a ppc and mips world where debuuger's are a lot > more > > plentiful and cheaper. What is a "POST card"... > > --- jarcher wrote: > > > To add to Ron's message. > > > > > > It varies a lot with your experience and how dirty you > want to > > > get. > > > > > > A simple POST card and a lot of creative POST code bread > > > crumbs is the > > > cheap and dirty way to go, until you get the serial port > > > debugger up and > > > running. But it requires you to be really creative in > > > crawling through the > > > code. And takes a lot of time. > > > > > > But you can move up the a logic analyzer looking at bus > cycles > > > or an ICE > > > (in circuit emulator) looking at CPU activity These two > are > > > expensive > > > (lots of $10K), but you can often rent them. Setup is > usually > > > the time > > > burner here. But with a LA you can take selective > pictures of > > > events > > > chained together in time. I don't know if SIS has an ICE > for > > > their SOC > > > products. > > > > > > Jordan > > > > > > PS: Has anyone done a USB interface low level debugger? > Early > > > BIOS or at > > > least just prior to payload decompress. > > > > > > > > > At 12:00 PM 5/15/2003 -0400, you wrote: > > > >Message: 10 > > > >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) > > > >From: Frank > > > >Subject: Re: debugger > > > >To: ron minnich > > > >Cc: linuxbios at clustermatic.org > > > > > > > >sis55x SOC x86 based > > > >--- ron minnich wrote: > > > > > On Thu, 15 May 2003, Frank wrote: > > > > > > > > > > > Can anyone recommend a debugger for bringing up > > > LinuxBios on > > > > > an > > > > > > x86 system... > > > > > > > > > > what kind of chip? and how much money can you spend? > > > > > > > > > > ron > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > __________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo. > > http://search.yahoo.com > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From hansolofalcon at worldnet.att.net Thu May 15 14:01:48 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu May 15 14:01:48 2003 Subject: debugger In-Reply-To: <20030515175450.46313.qmail@web13806.mail.yahoo.com> Message-ID: <000101c31b0d$33c9e4e0$0100a8c0@who5> Hello from Gregg C Levine A POST card? How to explain simply... A POST card, was created, (Or designed), to display the activities of the computer, through Port 80, while it works from power on, the final prompt. The term POST means, Power On Self Test. It descends from the original IBM-PC world. They are very useful, in this world, because we are creating the next generation BIOS from the ground, or bare metal, up. There are a preset sequence of events, numbered 00 to FF to go through. Each of them, properly documented, can tell a designer why his new system isn't working. And then there are a specific series of POST codes that can be useful to designers, when running supplied diagnostics. At least that was the case, about ten years ago. It's been that long since I did that kind of work. The repairing of such systems, that is. Okay, Ron, Richard, how did I do? ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Frank > Sent: Thursday, May 15, 2003 1:55 PM > To: jarcher; linuxbios at clustermatic.org > Subject: Re:debugger > > I don't mind getting dirty. as a matter of fact i prefer to work > in the dirt. That's why I'm looking at linuxbios.:-) > I come from a ppc and mips world where debuuger's are a lot more > plentiful and cheaper. What is a "POST card"... > --- jarcher wrote: > > To add to Ron's message. > > > > It varies a lot with your experience and how dirty you want to > > get. > > > > A simple POST card and a lot of creative POST code bread > > crumbs is the > > cheap and dirty way to go, until you get the serial port > > debugger up and > > running. But it requires you to be really creative in > > crawling through the > > code. And takes a lot of time. > > > > But you can move up the a logic analyzer looking at bus cycles > > or an ICE > > (in circuit emulator) looking at CPU activity These two are > > expensive > > (lots of $10K), but you can often rent them. Setup is usually > > the time > > burner here. But with a LA you can take selective pictures of > > events > > chained together in time. I don't know if SIS has an ICE for > > their SOC > > products. > > > > Jordan > > > > PS: Has anyone done a USB interface low level debugger? Early > > BIOS or at > > least just prior to payload decompress. > > > > > > At 12:00 PM 5/15/2003 -0400, you wrote: > > >Message: 10 > > >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) > > >From: Frank > > >Subject: Re: debugger > > >To: ron minnich > > >Cc: linuxbios at clustermatic.org > > > > > >sis55x SOC x86 based > > >--- ron minnich wrote: > > > > On Thu, 15 May 2003, Frank wrote: > > > > > > > > > Can anyone recommend a debugger for bringing up > > LinuxBios on > > > > an > > > > > x86 system... > > > > > > > > what kind of chip? and how much money can you spend? > > > > > > > > ron > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From adam at cfar.umd.edu Thu May 15 14:08:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 15 14:08:01 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515105844.02e808e8@cybermorph.com> Message-ID: <20030515145156.B46013-100000@www.missl.cs.umd.edu> On Thu, 15 May 2003, jarcher wrote: > A POST (power on self test) card is basically a dumb card that decodes an > I/O port (80h) and displays the value. Nothing but the CPU access to the > ROM and I/O bus (PCI or ISA) has to work to access the card. > > mov al, CRUMB_1 > out 80h,al Speaking of PORt-80 cards. Something I was wondering about is how are they implemented from technical viewpoint. Anyone care to elaborate? Is chipset support required for such card to work? Would this be south-bridge? What exactly gets send over PCI/ISA bus. Also Compaq seems to use port 84.. would this mean they switched some GPIO leads to south bridge that make POST card? Speaking of those stuff it reminds me Alpha which had like 4 leds on motherboard. However unlike POST on x86 it was memory mapped instead of port mapped. So you would simply write into memory. Obviously my expereince with Alpha was from OS perespective so not sure if those debugging leds would work from PROM level as well. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From rsmith at bitworks.com Thu May 15 14:28:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 15 14:28:00 2003 Subject: debugger In-Reply-To: <20030515175559.46550.qmail@web13808.mail.yahoo.com> References: <20030515175559.46550.qmail@web13808.mail.yahoo.com> Message-ID: <3EC3E4CD.50505@bitworks.com> Frank wrote: > Cool, where are you Richard Smith... AT lunch. :) > --- ron minnich wrote: > >>Richard Smith (I think) can recommend good flash rom emulators >>that do >>debugging too. There are some that do that. We don't have any though. I just have various rom emulators from techtools (http://www.tech-tools.com/) and if I have to go lower I break out the logic scope and just do spot grabs. Adam Sulmicki uses the following device. http://www.emutec.com/pjetmain.html Its pretty neat in the respect that it has a 2 way channel to the emulator. They claim that with software on the target you can get ICE functionality without traditional ICE costs. Oh it has a ethernet interface as well so it should be pretty easy to make linux friendly. I think that it would be totally cool if someone would write a software ICE target for the promjet. You might see how responsive emutech would be to that. That would make the promjet the "must have" piece of equipment for bringing up new ports since you would pretty much have a bare metal debugging ouput channel. -- Richard A. Smith rsmith at bitworks.com From agnew at cs.umd.edu Thu May 15 15:27:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 15 15:27:00 2003 Subject: etherboot In-Reply-To: <3EC3B727.50006@bitworks.com> Message-ID: <20030515160012.E46662-200000@www.missl.cs.umd.edu> > Adam can you do a short writeup on building etherboot 5.0.x apply your > patches and then the process above? I'll make 2 different sections in > my FAQ/HOWTO) one for each etherboot version. Certainly. See the attached diff, feel free to edit. Also, did you decide on a permanent format? I don't mind getting better at latex if that could be of assistance to you. - Adam A. ----------------- Adam Agnew Independent Contractor www.adamagnew.com -------------- next part -------------- 248a249,314 > For Ver 5.0.6 > > The Config file is already correct for most instances. > Note that -DPCBIOS is NOT set and -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 > -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE and -DPOLLED_IDE are. > > You will want to modify the top of polled_ide.h to specify where to find your kernel. The default is > "(hd0,0)/kernel" (uses grub naming scheme) > > If you're using compact flash on an IDE adapter to boot (this is common for people using LinuxBIOS for > embedded applications) then you'll also want to remove the delay on line 22 of polled_ide.c so > etherboot does not wait for a hard drive to spin up to operational speed when the hard drive is > actually instant-on compact flash! > > You then select an ethernet device as a back up if booting off of ide fails. For this example, we'll > assume your board has the sis900. You then run "make bin32/sis900.ebi". bin32/sis900.ebi will now be > your LinuxBIOS payload! > > Now modify your linuxbios config file to include: > > option USE_ELF_BOOT=1 > option PAYLOAD_SIZE= > payload /path/to/your/etherboot/driver > > You also need an input stream for the elfboot code to read from > so you must set one (or more?) of the following options. > > USE_GENERIC_ROM=1 > > > > Now you need to create an elf kernel for the ether boot code to find. > Go fetch the mkelfimage command at > > ftp://ftp.lnxi.com/pub/src/mkelfImage/ > > Generally the latest one is better. Note that there are several older versions > of binutils that are broken and mkelfimage will expose those bugs. Insure that > you are running a recient copy of binutils. The following shows the version > output from a known working bintuils. > > # as --version > GNU assembler 2.13.90.0.10 20021010 Debian GNU/Linux > > Now compile mkelfimage. Which should be as easy as ./configure, make, make install > > You can now create a elf kernel. > > Change to the directory where the image file for you kernel is. Normally this is > somewhere in the kernel tree. In my case this is is arch/i386/boot and the kernel > image is bzImage. > > By defaut mkelfimage is installed in /usr/local/sbin so you would do > > /usr/local/sbin/mkelfimage bzImage elfimage > > Now you have your kernel elfized in the file 'elfimage' > > mkelfimage support several options for adding commandlines and initrd's to the kernel image > type 'mkelfimage' without any arguments for the details. > > Now take that file 'elfimage' and copy it to the destination you gave etherboot (remember > "(hd0,0)/kernel"?) Etherboot 5.0.6 with the polled ide/file system patch can find your file on vfat, > ext2, or ext3 formatted partitions! > > 269,272d334 < For Ver 5.0.x: < < < 595c657 < \ No newline at end of file --- > From rsmith at bitworks.com Thu May 15 15:50:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 15 15:50:01 2003 Subject: etherboot In-Reply-To: <20030515160012.E46662-200000@www.missl.cs.umd.edu> References: <20030515160012.E46662-200000@www.missl.cs.umd.edu> Message-ID: <3EC3F83C.2070206@bitworks.com> Adam Agnew wrote: > Also, did you decide on a permanent format? I don't mind getting better at > latex if that could be of assistance to you. No not yet. I was kinda thinking DocBook since thats the defacto FAQ and HOWTO format. But I don't have any of the tools to mess with it setup and it does look a little complex. I was hoping Open office would make that a whole lot eaiser. (plus run on my doze machine which makes it eaiser for me to work with) Also David Barr has offered to Proofread/Technical Edit it as well so I want to use whatever he feels is best. >> For Ver 5.0.6 Don't you have to apply some patches to get to this point? Where are they available at and what are the steps to apply them? >> The Config file is already correct for most instances. >> Note that -DPCBIOS is NOT set and -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 >> -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE and -DPOLLED_IDE are. >> -- Richard A. Smith rsmith at bitworks.com From frannk_m1 at yahoo.com Thu May 15 15:57:01 2003 From: frannk_m1 at yahoo.com (Frank) Date: Thu May 15 15:57:01 2003 Subject: debugger In-Reply-To: <3EC3E4CD.50505@bitworks.com> Message-ID: <20030515203523.50182.qmail@web13804.mail.yahoo.com> Cool, I'll look into it... --- Richard Smith wrote: > Frank wrote: > > Cool, where are you Richard Smith... > > AT lunch. :) > > > --- ron minnich wrote: > > > >>Richard Smith (I think) can recommend good flash rom > emulators > >>that do > >>debugging too. > > There are some that do that. We don't have any though. I > just have > various rom emulators from techtools > (http://www.tech-tools.com/) and if > I have to go lower I break out the logic scope and just do > spot grabs. > > Adam Sulmicki uses the following device. > > http://www.emutec.com/pjetmain.html > > Its pretty neat in the respect that it has a 2 way channel to > the > emulator. They claim that with software on the target you can > get ICE > functionality without traditional ICE costs. Oh it has a > ethernet > interface as well so it should be pretty easy to make linux > friendly. > > I think that it would be totally cool if someone would write a > software > ICE target for the promjet. You might see how responsive > emutech would > be to that. That would make the promjet the "must have" piece > of > equipment for bringing up new ports since you would pretty > much have a > bare metal debugging ouput channel. > > -- > Richard A. Smith > rsmith at bitworks.com > > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From agnew at cs.umd.edu Thu May 15 16:18:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Thu May 15 16:18:01 2003 Subject: etherboot In-Reply-To: <3EC3F83C.2070206@bitworks.com> Message-ID: <20030515165925.F46963-100000@www.missl.cs.umd.edu> > >> For Ver 5.0.6 > > Don't you have to apply some patches to get to this point? Where are > they available at and what are the steps to apply them? Line 228 of your FAQ already answers that, kinda.. so.. download etherboot-5.0.6.tar.gz from etherboot.org download etherboot-5.0.6.polled1.diff from http://www.missl.cs.umd.edu/~agnew/ (save them to the same directory) tar -vzxf etherboot-5.0.6.tar.gz cd etherboot-5.0.6 patch -p1 < ../etherboot-5.0.6.polled1.diff - Adam A. ------------------ Adam Agnew Independent Contractor www.adamagnew.com From ollie at sis.com.tw Thu May 15 21:16:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Thu May 15 21:16:01 2003 Subject: debugger In-Reply-To: <20030515173613.23815.qmail@web13803.mail.yahoo.com> References: <20030515173613.23815.qmail@web13803.mail.yahoo.com> Message-ID: <1053049640.20104.184.camel@ollie> On Fri, 2003-05-16 at 01:36, Frank wrote: > No and it isn't socketed so I guess that's out... > --- ron minnich wrote: > > On Thu, 15 May 2003, Frank wrote: > > > > > sis55x SOC x86 based > > > > then the other trick is can you put an ICE in there, some > > boards make it > > physically impossible. do you have URL with pics? > > I don't think sis55x physically support JTAG signal for any kind of HW ICE. The only way to debug an sis55x here is via post card. -- ollie lho From ollie at sis.com.tw Thu May 15 21:24:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Thu May 15 21:24:00 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> References: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: <1053050152.20104.188.camel@ollie> On Fri, 2003-05-16 at 01:23, jarcher wrote: > To add to Ron's message. > > It varies a lot with your experience and how dirty you want to get. > > A simple POST card and a lot of creative POST code bread crumbs is the > cheap and dirty way to go, until you get the serial port debugger up and > running. But it requires you to be really creative in crawling through the > code. And takes a lot of time. > > But you can move up the a logic analyzer looking at bus cycles or an ICE > (in circuit emulator) looking at CPU activity These two are expensive > (lots of $10K), but you can often rent them. Setup is usually the time > burner here. But with a LA you can take selective pictures of events > chained together in time. I don't know if SIS has an ICE for their SOC > products. > > Jordan > > PS: Has anyone done a USB interface low level debugger? Early BIOS or at > least just prior to payload decompress. > BTW, why didn't we come up with a GDB stub in LinuxBIOS ?? -- ollie lho From ebiederman at lnxi.com Thu May 15 21:56:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu May 15 21:56:01 2003 Subject: debugger In-Reply-To: <1053050152.20104.188.camel@ollie> References: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> <1053050152.20104.188.camel@ollie> Message-ID: ollie lho writes: > On Fri, 2003-05-16 at 01:23, jarcher wrote: > > To add to Ron's message. > > > > It varies a lot with your experience and how dirty you want to get. > > > > A simple POST card and a lot of creative POST code bread crumbs is the > > cheap and dirty way to go, until you get the serial port debugger up and > > running. But it requires you to be really creative in crawling through the > > code. And takes a lot of time. > > > > But you can move up the a logic analyzer looking at bus cycles or an ICE > > (in circuit emulator) looking at CPU activity These two are expensive > > (lots of $10K), but you can often rent them. Setup is usually the time > > burner here. But with a LA you can take selective pictures of events > > chained together in time. I don't know if SIS has an ICE for their SOC > > products. > > > > Jordan > > > > PS: Has anyone done a USB interface low level debugger? Early BIOS or at > > least just prior to payload decompress. > > > > BTW, why didn't we come up with a GDB stub in LinuxBIOS ?? Primarily no one submitted it?. Someone reportedly wrote one a while ago. Admittedly I don't think I would every use it, as I don't see the point. Except for the resource allocation code practically everything in LinuxBIOS is pretty trivial straight forward code. And it should remain so. Eric From jarcher at pobox.com Thu May 15 22:56:00 2003 From: jarcher at pobox.com (jarcher) Date: Thu May 15 22:56:00 2003 Subject: debugger In-Reply-To: References: <1053050152.20104.188.camel@ollie> <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> <1053050152.20104.188.camel@ollie> Message-ID: <5.2.1.1.2.20030515203403.02c029f8@cybermorph.com> It might be helpful in debugging the stuff that get loaded after the core BIOS runs. Jordan At 08:39 PM 5/15/2003 -0600, Eric W. Biederman wrote: >ollie lho writes: > > > On Fri, 2003-05-16 at 01:23, jarcher wrote: > > > To add to Ron's message. > > > > > > It varies a lot with your experience and how dirty you want to get. > > > > > > A simple POST card and a lot of creative POST code bread crumbs is the > > > cheap and dirty way to go, until you get the serial port debugger up and > > > running. But it requires you to be really creative in crawling > through the > > > code. And takes a lot of time. > > > > > > But you can move up the a logic analyzer looking at bus cycles or an ICE > > > (in circuit emulator) looking at CPU activity These two are expensive > > > (lots of $10K), but you can often rent them. Setup is usually the time > > > burner here. But with a LA you can take selective pictures of events > > > chained together in time. I don't know if SIS has an ICE for their SOC > > > products. > > > > > > Jordan > > > > > > PS: Has anyone done a USB interface low level debugger? Early BIOS > or at > > > least just prior to payload decompress. > > > > > > > BTW, why didn't we come up with a GDB stub in LinuxBIOS ?? > >Primarily no one submitted it?. >Someone reportedly wrote one a while ago. > >Admittedly I don't think I would every use it, as I don't see the point. >Except for the resource allocation code practically everything in LinuxBIOS >is pretty trivial straight forward code. And it should remain so. > >Eric From ebiederman at lnxi.com Fri May 16 00:16:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri May 16 00:16:01 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515203403.02c029f8@cybermorph.com> References: <1053050152.20104.188.camel@ollie> <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> <1053050152.20104.188.camel@ollie> <5.2.1.1.2.20030515203403.02c029f8@cybermorph.com> Message-ID: jarcher writes: > It might be helpful in debugging the stuff that get loaded after the core BIOS > runs. It might be easier to just put the debugging stubs in the payload. But again I'm not against it (unless it clusters the code). I just don't think I will use it. Eric From hcyun at etri.re.kr Fri May 16 03:45:00 2003 From: hcyun at etri.re.kr (Heechul Yun) Date: Fri May 16 03:45:00 2003 Subject: Does ADLO support cd-rom boot? References: <20030515145156.B46013-100000@www.missl.cs.umd.edu> Message-ID: <004a01c31b84$499b3f90$0200a8c0@hcyuncompaq> Does ADLO support cdrom boot?. I tested it by setting cmos 0x3d as 0x003 and connecting cd-rom as primary slave device. But it failed to detect cd-rom. Heechul From aip at cwlinux.com Fri May 16 04:21:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri May 16 04:21:00 2003 Subject: AMD Sledge Hammer Message-ID: <20030516165915.A18037@mail.cwlinux.com> Does anyone know what is the statue of AMD Hammer? I have seen it in freebios2, but would like to know how far it is from being stable? Thanks. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From rogerxxmaillist at san.rr.com Fri May 16 05:12:00 2003 From: rogerxxmaillist at san.rr.com (roger) Date: Fri May 16 05:12:00 2003 Subject: Tyan Tiger 1832DL Motherboard (SMP P3 -- 440BX) Message-ID: <1053078562.13401.278.camel@localhost3.localdomain> Tyan Tiger 1832DL Motherboard (SMP P3 -- 440BX) -- Chip Info -- (looks like a 2MB eeprom?) Main bios chip markings: Winbond W29C020-90 92900292073701V Other Sticker #1: 8x32 116A (or 118A) Other Sticker #2: AMIBIOS 686 1985-95 American Megatrends B254065 -- Roger http://www.eskimo.com/~roger/index.html From ts1 at cma.co.jp Fri May 16 05:25:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri May 16 05:25:00 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: References: <20030515093717.GA8687@cma.co.jp> Message-ID: <20030516100322.GB4283@cma.co.jp> On Thu, May 15, 2003 at 08:01:01AM -0600, ron minnich wrote: > On Thu, 15 May 2003, SONE Takeshi wrote: > > > What could be a problem when it passes RAM test but hangs > > immediately after jumping to RAM? > > > > I'm developing a new raminit code and > > this happens only with a particular installation of DIMM. > > DIMM itself is not bad, it works when move to another slot, > > or another slot is filled with another DIMM. > > Award BIOS runs just fine with this DIMM installation. > > Every time I've seen this it is either drive strength settings or timing > (esp. on the 8601, it is VERY sensitive to buffer strength). I've found 0x6B is once asssigned the same value as Aword, then rewritten later with different value. (it's from CVS's raminit.inc) I thought this is something to do with drive strength (changes slew rate) but removing the latter one doesn't really change things. I also tried COMFIG_COMPRESS=0, then Steve M. Gehlbach's copy-verify hack (found here: http://www.clustermatic.org/pipermail/linuxbios/2002-October/000527.html ), and totally disabling cache. Everytime I change something, it stops execution at different point. > You really need to dump the northbridge and make sure you know exactly, > for each setting, why award set it one way and why linuxbios set it the > same way or differently. This is very tedious but it is your only choice. > With the 8601 I saw one case where all the bits except one were correct on > a data read. It only takes on wrong bit, however, to wreak havoc. Thanks. I'll again have to look at those hexadecimal dumps and the book. It really exhausts my eyes... -- Takeshi From rogerxxmaillist at san.rr.com Fri May 16 08:03:01 2003 From: rogerxxmaillist at san.rr.com (roger) Date: Fri May 16 08:03:01 2003 Subject: Items that should be in the FAQ or README Message-ID: <1053088768.8519.284.camel@localhost3.localdomain> recommended/required hardware should be listed in the FAQ or README (or did I pass-over it?) 1) Diskonchip model(s) number for ordering (Diskonchip Millenium 8MB MD2810-D08? --> www.m-sys.com) 2) Zif socket model/ordering numbers (so far, i'm looking at a 32-6554-11 32-pin zif dip .6 spacing (gold over nickel plating) <-- is this a good one? pulled from linuxbios mail list archives) Roger http://www.eskimo.com/~roger/index.html From rminnich at lanl.gov Fri May 16 09:51:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 16 09:51:00 2003 Subject: debugger In-Reply-To: <1053050152.20104.188.camel@ollie> Message-ID: On 16 May 2003, ollie lho wrote: > BTW, why didn't we come up with a GDB stub in LinuxBIOS ?? somebody did this, and I asked for the patches but I don't think I ever got them. ron From rminnich at lanl.gov Fri May 16 09:51:55 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 16 09:51:55 2003 Subject: debugger In-Reply-To: <5.2.1.1.2.20030515203403.02c029f8@cybermorph.com> Message-ID: On Thu, 15 May 2003, jarcher wrote: > It might be helpful in debugging the stuff that get loaded after the core > BIOS runs. I mostly saw it as a useful learning tool for people trying to follow the code. ron From rminnich at lanl.gov Fri May 16 10:04:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 16 10:04:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030516100322.GB4283@cma.co.jp> Message-ID: The symptoms you are describing sound almost certainly like RAM problems. ron From frannk_m1 at yahoo.com Fri May 16 11:19:01 2003 From: frannk_m1 at yahoo.com (Frank) Date: Fri May 16 11:19:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030516100322.GB4283@cma.co.jp> Message-ID: <20030516155644.32924.qmail@web13803.mail.yahoo.com> Sounds like you may have a signal integrety problem. try hanging a scope on the address and data lines and look for transients... --- SONE Takeshi wrote: > On Thu, May 15, 2003 at 08:01:01AM -0600, ron minnich wrote: > > On Thu, 15 May 2003, SONE Takeshi wrote: > > > > > What could be a problem when it passes RAM test but hangs > > > immediately after jumping to RAM? > > > > > > I'm developing a new raminit code and > > > this happens only with a particular installation of DIMM. > > > DIMM itself is not bad, it works when move to another > slot, > > > or another slot is filled with another DIMM. > > > Award BIOS runs just fine with this DIMM installation. > > > > Every time I've seen this it is either drive strength > settings or timing > > (esp. on the 8601, it is VERY sensitive to buffer strength). > > > I've found 0x6B is once asssigned the same value as Aword, > then > rewritten later with different value. (it's from CVS's > raminit.inc) > I thought this is something to do with drive strength (changes > slew rate) > but removing the latter one doesn't really change things. > > I also tried COMFIG_COMPRESS=0, then Steve M. Gehlbach's > copy-verify > hack (found here: > http://www.clustermatic.org/pipermail/linuxbios/2002-October/000527.html > ), > and totally disabling cache. > Everytime I change something, it stops execution at different > point. > > > You really need to dump the northbridge and make sure you > know exactly, > > for each setting, why award set it one way and why linuxbios > set it the > > same way or differently. This is very tedious but it is your > only choice. > > With the 8601 I saw one case where all the bits except one > were correct on > > a data read. It only takes on wrong bit, however, to wreak > havoc. > > Thanks. I'll again have to look at those hexadecimal dumps and > the book. > It really exhausts my eyes... > > -- > Takeshi > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From rminnich at lanl.gov Fri May 16 11:48:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 16 11:48:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030516155644.32924.qmail@web13803.mail.yahoo.com> Message-ID: On Fri, 16 May 2003, Frank wrote: > Sounds like you may have a signal integrety problem. try hanging > a scope on the address and data lines and look for transients... To show you how bad this can get. The last problem I had with an 8601 before I gave up was that a function got called from, e.g, address f8048. The return PC got pushed on the stack as something like f804c. These are not the exact numbers as this was a long time ago. The data error was such that most of linuxbios was working, but in this case, bit 3 got corrupted. When the RET was executed, the return address was f8048. Infinite loop. At that point I gave up. These data corruption problems can be very difficult. ron From jarcher at pobox.com Fri May 16 13:07:00 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Fri May 16 13:07:00 2003 Subject: debugger In-Reply-To: References: <5.2.1.1.2.20030515203403.02c029f8@cybermorph.com> Message-ID: <5.2.1.1.2.20030516104104.02765be0@cybermorph.com> It might be helpful for other developers who are not used to debugging at the firmware level. I don't know what the theme of LinuxBIOS is meant to be, but an optional debugger would probably make it easier for others to adopt LinuxBIOS use. Loading a payload OS core image would be nice through GDB. Jordan At 08:27 AM 5/16/2003 -0600, ron minnich wrote: >On Thu, 15 May 2003, jarcher wrote: > > > It might be helpful in debugging the stuff that get loaded after the core > > BIOS runs. > >I mostly saw it as a useful learning tool for people trying to follow the >code. > >ron From adam at cfar.umd.edu Fri May 16 15:00:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri May 16 15:00:01 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <20030513233141.U36111-100000@www.missl.cs.umd.edu> Message-ID: <20030516153110.N50796-100000@www.missl.cs.umd.edu> On Tue, 13 May 2003, Adam Agnew wrote: > Neither Bochs/ADLO or Etherboot try to "initialize" the ide controllers. > Rather they just detect them and assume that they've already been > initialized. Perhaps you can check to see if the ide controllers are > initialized in your linuxbios southbridge code? It's usually trivial to > do. Great to hear that video works in ADLO, that part is turning out to > work a lot more often then i really anticipated. You did doubt about my design? I'm hurt. Anyway, the purose of this email is to remind folks that there are are TWO Adams on the list and BOTH are from University of Maryland at College Park, and BOTH work on LinuxBIOS. Thus, the following two are *DISTINCT* individuals. Adam Agnew http://www.adamagnew.com Adam Sulmicki http://www.eax.com -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From adam at cfar.umd.edu Fri May 16 15:16:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri May 16 15:16:00 2003 Subject: Does ADLO support cd-rom boot? In-Reply-To: <004a01c31b84$499b3f90$0200a8c0@hcyuncompaq> Message-ID: <20030516160348.S50796-100000@www.missl.cs.umd.edu> > Does ADLO support cdrom boot?. I tested it by setting cmos 0x3d as 0x003 > and connecting cd-rom as primary slave device. But it failed to detect > cd-rom. There's some CD-ROM booting code in BOCHS BIOS (as you have noticed), but at the present status it is untested. My guesstimate is that it should work but you will have to fix timing problems. For example I would guess that it does not detect CD because it is slower in responding than a typical hdd would be. Hope it helps, Adam -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Fri May 16 16:01:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri May 16 16:01:01 2003 Subject: AMD Sledge Hammer In-Reply-To: <20030516165915.A18037@mail.cwlinux.com> References: <20030516165915.A18037@mail.cwlinux.com> Message-ID: Andrew Ip writes: > Does anyone know what is the statue of AMD Hammer? I have seen > it in freebios2, but would like to know how far it is from being > stable? Thanks. The code works, for a subset of cases but it has a way to go before it is production grade code. I believe there is an AMD sponsored port going on at SuSe. But I they guys I was working with have grown mysteriously silent. As for me I am busy working on it, which means there will be a solid port eventually. Eric From hansolofalcon at worldnet.att.net Fri May 16 19:21:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Fri May 16 19:21:01 2003 Subject: ASUS TX97LE mainboard seems support too. In-Reply-To: <20030516153110.N50796-100000@www.missl.cs.umd.edu> Message-ID: <001901c31c07$2d99aa60$0100a8c0@who5> Hello from Gregg C Levine Okay, Adam Agnew why did you doubt him? As far as I am concerned, there's nothing wrong with a little doubt now and then. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Adam Sulmicki > Sent: Friday, May 16, 2003 3:50 PM > To: Adam Agnew > Cc: bendany; linuxbios at clustermatic.org > Subject: Re: ASUS TX97LE mainboard seems support too. > > On Tue, 13 May 2003, Adam Agnew wrote: > > > Neither Bochs/ADLO or Etherboot try to "initialize" the ide controllers. > > Rather they just detect them and assume that they've already been > > initialized. Perhaps you can check to see if the ide controllers are > > initialized in your linuxbios southbridge code? It's usually trivial to > > do. Great to hear that video works in ADLO, that part is turning out to > > work a lot more often then i really anticipated. > > > You did doubt about my design? I'm hurt. > > > Anyway, the purose of this email is to remind folks that there are are TWO > Adams on the list and BOTH are from University of Maryland at College > Park, and BOTH work on LinuxBIOS. > > Thus, the following two are *DISTINCT* individuals. > > Adam Agnew > http://www.adamagnew.com > > Adam Sulmicki > http://www.eax.com > > -- > Adam Sulmicki > http://www.eax.com The Supreme Headquarters of the 32 bit registers > > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From bendany at mistdl.com Sat May 17 07:03:01 2003 From: bendany at mistdl.com (bendany) Date: Sat May 17 07:03:01 2003 Subject: am I wrong? about build romimage of k7sem mb. Message-ID: <001301c31c69$66b09c20$2a00a8c0@ben> I found the Config of elitegroup/k7sem has missed something... without the following lines. I can't build the correct romimage. --------------------------- mainboardinit cpu/i386/reset16.inc ldscript cpu/i386/reset16.lds --------------------------- but with these lines, I can build the correct image, but linuxbios don't go. output message is : ---------------------------- LinuxBIOS-1.0.0 Sat May 17 19:34:29 CST 2003 starting... 0 LinuxBIOS-1.0.0 Sat May 17 19:34:29 CST 2003 starting... 0 LinuxBIOS-1.0.0 Sat May 17 19:34:29 CST 2003 starting... 0 ---------------------------- while I download the romimage from cwlinux.com. I can run LinuxBIOS. here is my config file ------------------------------------- target k7sem mainboard elitegroup/k7sem cpu k7 option ZKERNEL_START=0xfffc0000 option SERIAL_CONSOLE=1 option DEFAULT_CONSOLE_LOGLEVEL=8 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEBUG=1 option MII_ENABLE=1 option USE_GENERIC_ROM=1 option STD_FLASH=1 option CONFIG_COMPRESS=0 option ROM_SIZE=131072 option PAYLOAD_SIZE=65536 option USE_ELF_BOOT=1 payload ../sis900.ebi --------------------------------------- am I miss something? From pyro at linuxlabs.com Sat May 17 09:17:00 2003 From: pyro at linuxlabs.com (steven james) Date: Sat May 17 09:17:00 2003 Subject: [COMMIT] Baremetal environment Message-ID: Greetings, I have committed a few cleanups to baremetal to make the environment a bit more useful. The lib directory contains a new startup function in _main.c which locates the top of RAM using the linuxbios table and checks for a signature there. If absent, it moves the stack to high ram, and initializes a simple structure containing pointers to the lbmemory structs in the table, and the highest address of freely usable ram. Bounce buffers and such are allocated by subtracting from the dree RAM value. When an additional baremetal program is run, it will detect the existant structure and use its values. Together, this allows for arbitrary stacking of payloads and safely returning to the calling payload. A 'terminal payload' such as a kernel elf image may simply ignore all of that and do what it wants. This is still subject to change, and amounts to a platform for discussion and a little practical exprimentation. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From dkotian3 at vsnl.net Sat May 17 10:25:00 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Sat May 17 10:25:00 2003 Subject: PIRQ problem (Please try using pci=biosirq) Message-ID: <20030517153652.47B714FFD2@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From xpegenaute at telepolis.es Sat May 17 10:37:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Sat May 17 10:37:01 2003 Subject: Map of the memory Message-ID: <3EC65E9C.3020805@telepolis.es> Hi, i was trying to make a memory map in the eeprom but i have some questions when i saw linuxbios_c.map and linuxbios.map ... We "compile" linuxbios_c with c_start.o and linuxbios.a until generate linuxbios_payload and linuxbios_c.map. We "compile" crt0.S and we make the crt0.o. After we "compile" crt0.o with linuxbios_payload generating linuxbios binary and linuxbios.map If we see inside the map files, i can see that there are labels at the same position in the both map files for example: linuxbios_c.map : 00004000 A _RAMBASE 00080000 A _ROMBASE linuxbios.map: 00004000 A _RAMBASE 00080000 A _ROMBASE How is it possible ? when in theory al linuxbios_c is in the payload of linuxbios? linuxbios.map: 000805a0 D _payload 00085e5d D _epayload also i saw in some file (.ld) in the tree of freebios a picture of memory: Memory map: 0x00000 (4*4096 bytes) : stack 0x04000 (4096 bytes) : private data 0x05000 : data space 0x90000 : kernel stack 0xf0000 (64 Kbyte) : EPROM Is it right ? i think that i'm confusing the memory in RAM and the memory in EPROM. But i don't know how build a correct idea. Thanks. Xavi. From rminnich at lanl.gov Sat May 17 10:43:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat May 17 10:43:01 2003 Subject: am I wrong? about build romimage of k7sem mb. In-Reply-To: <001301c31c69$66b09c20$2a00a8c0@ben> Message-ID: andrew can you send bendany your config file for this board and see what happens? ron From rminnich at lanl.gov Sat May 17 10:49:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat May 17 10:49:01 2003 Subject: PIRQ problem (Please try using pci=biosirq) In-Reply-To: <20030517153652.47B714FFD2@bom6.vsnl.net.in> Message-ID: On Sat, 17 May 2003 dkotian3 at vsnl.net wrote: > Hi, > > I am using 256kb BIOS flashrom, etherboot, and kernel image > on compact flash IDE . I need to know if CONFIG_COMPRESS is set to 0, I am guessing not. Can you please check? ron From dkotian3 at vsnl.net Sat May 17 13:29:00 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Sat May 17 13:29:00 2003 Subject: PIRQ problem (Please try using pci=biosirq) References: Message-ID: <001f01c31c9f$2020bca0$243e41db@vsnl.net> I do not have acces to my system now, so cannot tell for sure but what it the signifigance of this paramater CONFIG_COMPRESS = 0 or 1 I have seen this in couple of other responses as well which talks about this one. Can on please elaborate on this please and how this paramerter would lead to this error. Regards Deepak ----- Original Message ----- From: "ron minnich" To: Cc: Sent: Saturday, May 17, 2003 8:51 PM Subject: Re: PIRQ problem (Please try using pci=biosirq) > On Sat, 17 May 2003 dkotian3 at vsnl.net wrote: > > > Hi, > > > > I am using 256kb BIOS flashrom, etherboot, and kernel image > > on compact flash IDE . > > I need to know if CONFIG_COMPRESS is set to 0, I am guessing not. Can you > please check? > > ron > From ts1 at tsn.or.jp Sat May 17 13:31:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sat May 17 13:31:01 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: References: <20030516100322.GB4283@cma.co.jp> Message-ID: <20030517180920.GA813@tsn.or.jp> On Fri, May 16, 2003 at 08:40:14AM -0600, ron minnich wrote: > The symptoms you are describing sound almost certainly like RAM problems. I think I solved the problem now! Now my code automatically detects DIMM presence, size, and MA mapping type correctly for my 3 different types of DIMMs, in whichever slot, or any combination of these DIMMs. I'll do some cleanups and extensive test using memtest86, then post the patch. -- Takeshi From ebiederman at lnxi.com Sat May 17 13:47:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat May 17 13:47:01 2003 Subject: PIRQ problem (Please try using pci=biosirq) In-Reply-To: <001f01c31c9f$2020bca0$243e41db@vsnl.net> References: <001f01c31c9f$2020bca0$243e41db@vsnl.net> Message-ID: "Deepak Kotian" writes: > I do not have acces to my system now, so cannot tell for sure but what > it the signifigance of this paramater CONFIG_COMPRESS = 0 or 1 > I have seen this in couple of other responses as well which talks about this > one. > > Can on please elaborate on this please and how this paramerter would lead > to this error. LinuxBIOS is naturally split into 2 components. The part that runs after ram is believed to be working. And the part that is used to initialize ram. During ram initialization the code must run out of the ROM chip. After that however the code can live in RAM. And we take advantage of that fact by compressing that code in the ROM chip. Currently the PIRQ tables are just copied from the LinuxBIOS image in the ROM chip into RAM. Around 0xf0000 - 0xfffff. If ``shadow'' ram has not been enabled there the copy fails. However if LinuxBIOS is not compressed in the ROM chip, the uncompressed table can still be found in the last 64K before 1M. And so the pirq table can still be found that way. The real fix is to enable shadow RAM. Disabling compression is an effective short term work around. Eric From ebiederman at lnxi.com Sat May 17 13:53:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat May 17 13:53:00 2003 Subject: Map of the memory In-Reply-To: <3EC65E9C.3020805@telepolis.es> References: <3EC65E9C.3020805@telepolis.es> Message-ID: Xavier Pegenaute writes: > Hi, > > i was trying to make a memory map in the eeprom but i have some > questions when i saw linuxbios_c.map and linuxbios.map ... > > > We "compile" linuxbios_c with c_start.o and linuxbios.a until generate > linuxbios_payload and linuxbios_c.map. > > We "compile" crt0.S and we make the crt0.o. > > After we "compile" crt0.o with linuxbios_payload generating linuxbios > binary and linuxbios.map > > If we see inside the map files, i can see that there are labels at the > same position in the both map files for example: > > linuxbios_c.map : > 00004000 A _RAMBASE > 00080000 A _ROMBASE > > linuxbios.map: > 00004000 A _RAMBASE > 00080000 A _ROMBASE At that point those are just hard coded symbols, that set of symbols lives nowhere. > How is it possible ? when in theory al linuxbios_c is in the payload of > linuxbios? Only when they are symbols that refer to actual code or data is it a problem. A constant address is not. > linuxbios.map: > 000805a0 D _payload > 00085e5d D _epayload > > also i saw in some file (.ld) in the tree of freebios a picture of memory: > > Memory map: > > 0x00000 (4*4096 bytes) : stack > 0x04000 (4096 bytes) : private data > 0x05000 : data space > 0x90000 : kernel stack > 0xf0000 (64 Kbyte) : EPROM > > Is it right ? No. At one point it was correct but the comment is now out of date. > i think that i'm confusing the memory in RAM and the > memory in EPROM. But i don't know how build a correct idea. Please also note the differences in the physical addresses and the virtual addresses that sometimes show up in the code. Roughly the 64KB of the ROM lives at either: 0xf0000 - 0xfffff or 0xffff0000 - 0xfffffffff And linuxbios_c lives in the first 640K I would have to look to be more precise. Eric From aip at cwlinux.com Sat May 17 21:47:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sat May 17 21:47:00 2003 Subject: am I wrong? about build romimage of k7sem mb. In-Reply-To: ; from ron minnich on Sat, May 17, 2003 at 09:19:38AM -0600 References: <001301c31c69$66b09c20$2a00a8c0@ben> Message-ID: <20030518102516.A7386@mail.cwlinux.com> Here is the config file for 810 which should be very similar to k7sem. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- # # LinuxBIOS config file for: PCCHIPS m8310lmr, Socket 7 (K7/Duron) # target /opt/cwlinux/buildrom/8310-etherboot # pcchips 8310 mainboard pcchips/m810lmr # Enable MII support (required for new 810/8310 mainboard) option ENABLE_MII=1 # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # Use 256KB Standard Flash as Normal BIOS option USE_GENERIC_ROM=1 option STD_FLASH=1 option ZKERNEL_START=0xfffc0000 # payload size = 192KB option PAYLOAD_SIZE=196608 # Rom image size = 63KB option ROM_IMAGE_SIZE=64512 # We reuse docipl from DoC docipl northsouthbridge/sis/730/ipl.S # Use the internal VGA frame buffer device option HAVE_FRAMEBUFFER=1 # use ELF Loader to load Etherboot option USE_ELF_BOOT=1 # Use Etherboot as our payload payload /opt/cwlinux/etherboot/src/bin32/sis900.ebi # Add our own special make rules to handle 256KB flash with docipl makerule romimage: linuxbios.rom payload.block docipl ; addaction romimage cat payload.block linuxbios.rom docipl.bin > romimage makerule docipl: ipl.o ; addaction docipl objcopy -O binary -R .note -R .comment -S ipl.o docipl addaction docipl dd if=docipl skip=126 of=docipl.bin makerule linuxbios.rom: linuxbios.strip ; addaction linuxbios.rom dd if=linuxbios.strip of=linuxbios.rom bs=$(ROM_IMAGE_SIZE) conv=sync # Kernel command line parameters # commandline root=/dev/hda1 console=ttyS0,115200 console=tty0 video=sisfb:1024x768-32 at 85,font:VGA8x16 From dkotian3 at vsnl.net Sun May 18 01:17:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Sun May 18 01:17:01 2003 Subject: PIRQ problem (Please try using pci=biosirq) References: <001f01c31c9f$2020bca0$243e41db@vsnl.net> Message-ID: <000d01c31d01$b51c2800$a12041db@vsnl.net> Thanks, this is a good one. One more question. How does one enable Shadow Ram. Regards Deepak ----- Original Message ----- From: "Eric W. Biederman" To: "Deepak Kotian" Cc: "ron minnich" ; Sent: Sunday, May 18, 2003 12:01 AM Subject: Re: PIRQ problem (Please try using pci=biosirq) > "Deepak Kotian" writes: > > > I do not have acces to my system now, so cannot tell for sure but what > > it the signifigance of this paramater CONFIG_COMPRESS = 0 or 1 > > I have seen this in couple of other responses as well which talks about this > > one. > > > > Can on please elaborate on this please and how this paramerter would lead > > to this error. > > LinuxBIOS is naturally split into 2 components. > The part that runs after ram is believed to be working. > And the part that is used to initialize ram. > > During ram initialization the code must run out of > the ROM chip. After that however the code can live > in RAM. And we take advantage of that fact by compressing > that code in the ROM chip. > > Currently the PIRQ tables are just copied from the LinuxBIOS > image in the ROM chip into RAM. Around 0xf0000 - 0xfffff. > If ``shadow'' ram has not been enabled there the copy fails. > > However if LinuxBIOS is not compressed in the ROM chip, the > uncompressed table can still be found in the last 64K before 1M. > And so the pirq table can still be found that way. > > The real fix is to enable shadow RAM. Disabling compression > is an effective short term work around. > > Eric > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From ts1 at cma.co.jp Mon May 19 03:30:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Mon May 19 03:30:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 Message-ID: <20030519080903.GA11352@cma.co.jp> Hi, This patch adds automatic detection of installed RAM presence, size, and MA mapping type for VIA VT8601 northbridge. I tested this with VIA EPIA 5000 and 3 different type DIMMs. A. 64MB single sided (borrowed from my server :) B. 256MB double sided (borrowed from my desktop :) C. 256MB single sided (bought for EPIA) Timing was set to PC100 CL=3. (it's configurable at build time) EPIA has 2 DIMM slots, and 'empty' is possible in addition to 3 DIMMs, so there are 12 (=4*3) possible installation patterns. All patterns are tested with memtest86 3.0 as payload, to at least Test #2, and no error was found. Additionally DIMM B+C (512MB total) with PC133 CL=2 configuration was tested and all tests of memtest86's Std Test found no error. -- Takeshi -------------- next part -------------- Index: src/northbridge/via/vt8601/northbridge.c =================================================================== RCS file: /cvsroot/freebios/freebios/src/northbridge/via/vt8601/northbridge.c,v retrieving revision 1.13 diff -u -r1.13 northbridge.c --- src/northbridge/via/vt8601/northbridge.c 13 May 2003 13:13:51 -0000 1.13 +++ src/northbridge/via/vt8601/northbridge.c 18 May 2003 18:36:09 -0000 @@ -4,22 +4,164 @@ #include #include +/* + * Automatic memory configuration by SONE Takeshi , 05/19/03 + */ + +static unsigned long find_size(unsigned long addr, unsigned long minimum) +{ + unsigned long i; + unsigned long maximum; + volatile long *p; + + /* First, see if there is any RAM. */ + p = (long *) (addr + minimum); + *p = 0x12345678; + p = (long *) (addr + minimum + 8); + *p = 0x87654321; + p = (long *) (addr + minimum); + if (*p != 0x12345678) + return 0; /* No memory */ + + maximum = (0xffUL << 23) - addr; + + /* Write to addresses with only one address bit on, + * in increasing order, from address 8 (assuming 64-bit bus), + * then read address zero to see if it gets wrap-around. + * This way we can detect missing address bit due to incorrect + * MA mapping, or the size of bank when MA mapping is correct. */ + + for (i = 8; i < maximum; i <<= 1) { + if (i < minimum) + continue; + p = (long *) (addr + i); + *p = 0x89abcdef; + p = (long *) addr; + if (*p == 0x89abcdef) + return i; + } + return maximum; +} + +static void set_ma_mapping(struct pci_dev *pcidev, int bank, int type) +{ + unsigned char reg, val; + int shift; + + reg = 0x58 + bank/4; + if (bank%4 >= 2) + shift = 0; + else + shift = 4; + + pci_read_config_byte(pcidev, reg, &val); + val &= ~(0xf << shift); + val |= type << shift; + pci_write_config_byte(pcidev, reg, val); +} + +static int get_ma_mapping(struct pci_dev *pcidev, int bank) +{ + unsigned char reg, val; + int shift; + + reg = 0x58 + bank/4; + if (bank%4 >= 2) + shift = 0; + else + shift = 4; + + pci_read_config_byte(pcidev, reg, &val); + return (val >> shift) & 0xf; +} static unsigned long __sizeram(void) { - unsigned long totalmem; - unsigned char bank, mem, prevmem; - u8 sma_status, sma_size, sma_size_bits; - // fixed so tha banks 56 & 57 are looked at as well. - unsigned long firstbank = 0x5a, lastbank = 0x61; - + u8 sma_status, sma_size_bits; struct pci_dev *pcidev; + unsigned long memtop, highest, size, sma_size; + int bank, i; + static const unsigned char ma_table[] = {0, 8, 0xe}; + unsigned char ma_tmp, val; + extern void cache_enable(void), cache_disable(void); pcidev = pci_find_slot(0, PCI_DEVFN(0,0)); if (! pcidev) return 0; - + + /* In assembly part, we have initialized all RAM chips, + * brought the first equipped RAM bank to address zero, + * and set correct MA mapping type of that bank. + * Now, we have to detect the size of the first bank, + * then configure rest of banks. */ + + /* Cache must be disabled to detect the RAM. */ + cache_disable(); + + /* Find the first bank configured by assembly part. */ + for (bank = 0; bank < 6; bank++) { + pci_read_config_byte(pcidev, 0x5a + bank, &val); + if (val != 0) + break; + } + + memtop = find_size(0, 1024*1024); + memtop &= ~0x7fffff; /* Unit of 8MB */ + + printk_info("Bank%d %dMB (MA type 0x%x)\n", bank, + memtop>>20, get_ma_mapping(pcidev, bank)); + + pci_write_config_byte(pcidev, 0x5a + bank, memtop>>23); + + for (bank++; bank < 6; bank++) { + if (bank & 1) { + /* We don't change MA mapping of this bank + * since it is shared with the previous bank. + * Most possibly this is the other side of a + * double-sided DIMM. */ + size = find_size(memtop, 0); + size &= ~0x7fffff; + if (size) { + printk_info("Bank%d %dMB\n", bank, size>>20); + memtop += size; + } + } else { + /* Try MA mapping types and find the one which gives + * highest address without wrap-around. + * It should be the correct mapping for the DIMM, + * and the returned address is the size of the DIMM. */ + highest = 0; + ma_tmp = 0; + for (i = 0; i < sizeof(ma_table)/sizeof(ma_table[0]); i++) { + set_ma_mapping(pcidev, bank, ma_table[i]); + size = find_size(memtop, 0); + printk_debug("bank %d MA 0x%x: %d bytes\n", + bank, ma_table[i], size); + if (size > highest) { + highest = size; + ma_tmp = ma_table[i]; + } + } + highest &= ~0x7fffff; + if (highest) { + printk_info("Bank%d %dMB (MA type 0x%x)\n", + bank, highest>>20, ma_tmp); + memtop += highest; + } + set_ma_mapping(pcidev, bank, ma_tmp); + } + pci_write_config_byte(pcidev, 0x5a + bank, memtop>>23); + } + /* As well as 6 bank registers above, it seems we have to fill + * these 2 registers. */ + pci_write_config_byte(pcidev, 0x56, memtop>>23); + pci_write_config_byte(pcidev, 0x57, memtop>>23); + + cache_enable(); + + /* Frame buffer size */ + // Documentation on VT8601 - Pg 51 Rev 1.3 Sept 1999 says // Device 0 Offset FB - Frame buffer control // bit @@ -35,41 +177,31 @@ pci_read_config_byte(pcidev, 0xfb, &sma_status); sma_size_bits = (sma_status >> 4) & 0x03; if (sma_size_bits > 0) - sma_size = 0x01 << sma_size_bits; + sma_size = (1024*1024) << sma_size_bits; else sma_size = 0; - for(totalmem = mem = prevmem = 0, bank = firstbank; - bank <= lastbank; bank++) { - // last 2 banks are in regs before first bank so - // wrap round if > 0x5f - unsigned long rbank = (bank > 0x5f) ? bank - 10 : bank; - - pci_read_config_byte(pcidev, rbank, &mem); - - // sanity check. If the mem value is < prevmem, - // that is an error, so skip this step. - if (mem < prevmem) { - printk_err("ERROR: bank 0x%x, mem 0x%x TOO SMALL\n", - rbank, prevmem); - printk_err("Should be >= 0x%x\n", prevmem); - } else - totalmem += (mem - prevmem) * 8; - prevmem = mem; - } - - totalmem -= sma_size; - totalmem *= 1024; + printk_info("Total %dMB + frame buffer %dMB\n", + (memtop - sma_size)>>20, sma_size>>20); + + /* Turn on shadow DRAM at 0xC0000-0xFFFFF so we can write + * PIRQ table, VGA BIOS, Bochs BIOS, etc. */ + printk_debug("Enabling shadow DRAM at 0xC0000-0xFFFFF: "); + pci_write_config_byte(pcidev, 0x61, 0xff); + pci_write_config_byte(pcidev, 0x62, 0xff); + pci_write_config_byte(pcidev, 0x63, 0xf0); + printk_debug("done\n"); - return totalmem; + return (memtop - sma_size) >> 10; // return in kilo bytes } struct mem_range *sizeram(void) { static struct mem_range mem[3]; + mem[0].basek = 0; mem[0].sizek = 640; - mem[1].basek = 1024; + mem[1].basek = 768; mem[1].sizek = __sizeram(); mem[2].basek = 0; mem[2].sizek = 0; @@ -77,19 +209,27 @@ mem[1].sizek = 64*1024; } mem[1].sizek -= mem[1].basek; - return &mem; + return mem; } #ifdef HAVE_FRAMEBUFFER void framebuffer_on() { +#if 0 /* This code has not been working (always reads 0xffff) + * and I still can bring up VGA (with original VGA BIOS under ADLO) + * after disabling this. -- ts1 */ unsigned long devfn; u16 command; devfn = PCI_DEVFN(0, 1); pcibios_read_config_word(0, devfn, 0x3e, &command); - command |= 0x08; + //command |= 0x08; + command |= 0x0c; pcibios_write_config_word(0, devfn, 0x3e, command); + printk_debug("wrote %02x\n", command); + pcibios_read_config_word(0, devfn, 0x3e, &command); + printk_debug("readback %02x\n", command); +#endif } #endif Index: src/northbridge/via/vt8601/raminit.inc =================================================================== RCS file: /cvsroot/freebios/freebios/src/northbridge/via/vt8601/raminit.inc,v retrieving revision 1.2 diff -u -r1.2 raminit.inc --- src/northbridge/via/vt8601/raminit.inc 10 Nov 2002 06:27:47 -0000 1.2 +++ src/northbridge/via/vt8601/raminit.inc 18 May 2003 18:36:09 -0000 @@ -25,52 +25,92 @@ * correctly - at least on my VIA epia motherboard. 64MB DIMM in slot 0. */ -#define loop200 $0x5000 -#define loop100 $0x2500 +/* Added automatic detection of first equipped bank and its MA mapping type. + * (Rest of configuration is done in C) + * 5/19/03 by SONE Takeshi + */ + +// Set to 1 if your DIMMs are PC133 +// Note that I'm assuming CPU's FSB frequency is 133MHz. If your CPU runs +// at another bus speed, you might need to change some of register values. +#ifndef DIMM_PC133 +#define DIMM_PC133 0 +#endif + +// Set to 1 if your DIMMs are CL=2 +#ifndef DIMM_CL2 +#define DIMM_CL2 0 +#endif + + +/* Stable ~1 usec delay by hitting unused ISA port. */ +#define UDELAY(x) movl $x,%ecx; 9: outb %al,$0x81; loop 9b + +#define DIMMS_READ(x) \ + movl 0x00000000+x, %eax; \ + movl 0x10000000+x, %eax; \ + movl 0x20000000+x, %eax; \ + movl 0x30000000+x, %eax; \ + movl 0x40000000+x, %eax; \ + movl 0x50000000+x, %eax + +#define DIMMS_WRITE(x) \ + movl %eax, 0x00000000+x; \ + movl %eax, 0x10000000+x; \ + movl %eax, 0x20000000+x; \ + movl %eax, 0x30000000+x; \ + movl %eax, 0x40000000+x; \ + movl %eax, 0x50000000+x raminit: intel_chip_post_macro(0x35) -/*; new code... pulled from via stuff.*/ -/* initialize registers */ // memory clk enable. We are not using ECC CS_WRITE($0x78, $0x01) // dram control, see the book. - CS_WRITE($0x68, $0x42) +#if DIMM_PC133 + CS_WRITE($0x68, $0x52) +#else + CS_WRITE($0x68, $0x42) +#endif // dram control, see the book. - CS_WRITE($0x6B, $0x0d) - // 64/128 MB dram - CS_WRITE($0x58, $0x80) - // 64/128 MB dram - CS_WRITE($0x59, $0x00) - // bank 0 ends at 64 MB - CS_WRITE($0x5A, $0x08) - // bank 1 ends at 64 MB - CS_WRITE($0x5B, $0x08) - // bank 2 ends at 64 MB - CS_WRITE($0x5C, $0x08) - // bank 2 ends at 64 MB - CS_WRITE($0x5D, $0x08) - // bank 2 ends at 64 MB - CS_WRITE($0x5E, $0x08) - // bank 2 ends at 64 MB - CS_WRITE($0x5F, $0x08) + CS_WRITE($0x6B, $0x0c) + // Initial setting, 256MB in each bank, will be rewritten later. + CS_WRITE($0x5A, $0x20) + CS_WRITE($0x5B, $0x40) + CS_WRITE($0x5C, $0x60) + CS_WRITE($0x5D, $0x80) + CS_WRITE($0x5E, $0xA0) + CS_WRITE($0x5F, $0xC0) + // It seems we have to take care of these 2 registers as if + // they are bank 6 and 7. + CS_WRITE($0x56, $0xC0) + CS_WRITE($0x57, $0xC0) // SDRAM in all banks CS_WRITE($0x60, $0x3F) // DRAM timing. I'm suspicious of this // This is for all banks, 64 is 0,1. 65 is 2,3. 66 is 4,5. - // ras precharge 4T, RAS pulse 5T, CAS 2T - // as per the note below, we change to cas 3 2000/8/31 + // ras precharge 4T, RAS pulse 5T // cas2 is 0xd6, cas3 is 0xe6 // we're also backing off write pulse width to 2T, so result is 0xee - CS_WRITE($0x64, $0xe6) - CS_WRITE($0x65, $0x95) - CS_WRITE($0x66, $0x95) - - // dram frequency select. We set 66/66. - // no 256 m, enable 4K pages for 64M dram. - CS_WRITE($0x69, $0xac) +#if DIMM_CL2 + CS_WRITE($0x64, $0xd4) + CS_WRITE($0x65, $0xd4) + CS_WRITE($0x66, $0xd4) +#else // CL=3 + CS_WRITE($0x64, $0xe4) + CS_WRITE($0x65, $0xe4) + CS_WRITE($0x66, $0xe4) +#endif + + // dram frequency select. + // enable 4K pages for 64M dram. +#if DIMM_PC133 + CS_WRITE($0x69, $0x3c) +#else + CS_WRITE($0x69, $0xac) +#endif // refresh counter, disabled. CS_WRITE($0x6A, $0x00) // clkenable configuration. kevinh FIXME - add precharge @@ -80,102 +120,188 @@ // As per Cindy Lee, set to 0x37, not 0x57 CS_WRITE($0x6D, $0x7f) + /* Initialize all banks at once */ + /* begin to initialize*/ // I forget why we need this, but we do mov $0xa55a5aa5, %eax - mov %eax, 0 - mov %eax, 0x4000000 + DIMMS_WRITE(0) /* set NOP*/ CS_WRITE($0x6C, $0x01) - /* wait 200us*/ // You need to do the memory reference. That causes the nop cycle. - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop200) - + DIMMS_READ(0) + UDELAY(400) /* set precharge */ CS_WRITE($0x6C, $0x02) /* dummy reads*/ - mov 0x0, %eax - mov 0x4000000, %eax + DIMMS_READ(0) + UDELAY(200) /* set CBR*/ CS_WRITE($0x6C, $0x04) -/* do 8 reads and wait 100us between each - from via*/ - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) - mov 0x0, %eax - mov 0x4000000, %eax - DELAY(loop100) +/* do 8 reads and wait >100us between each - from via*/ + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) + DIMMS_READ(0) + UDELAY(200) /* set MRS*/ - // 0x150 is cas2. We are now using 0x1d0, which is cas3 CS_WRITE($0x6c, $0x03) - movl $0x1d0, %ecx - movl (%ecx), %eax - movl $0x40001d0, %ecx - movl (%ecx), %eax +#if DIMM_CL2 + DIMMS_READ(0x150) +#else // CL=3 + DIMMS_READ(0x1d0) +#endif + UDELAY(200) /* set to normal mode */ CS_WRITE($0x6C, $0x08) movl $0x55aa55aa, %eax - mov %eax, 0x0 - mov 0x0, %eax + DIMMS_WRITE(0) + DIMMS_READ(0) + UDELAY(200) // Set the refresh rate. +#if DIMM_PC133 + CS_WRITE($0x6A, $0x86) +#else CS_WRITE($0x6A, $0x65) +#endif // enable multi-page open - CS_WRITE($0x6B, $0x01) + CS_WRITE($0x6B, $0x0d) - -/* From Mike Fan: - Hi all: - If you are porting PM133, then you have to set DRAM Row Ending Address. - You did not set Rx56 and Rx57 in intel_pm133ram.S. - That register setting is like Rx5A~Rx5F. - Maybe could fix the mem wrapping issue. - (from Ron Minnich) - My manual says these are non-cacheable region registers. - (Turns out the manual is wrong. However, this did not help. - 2000/8/31 8:49 am I am setting all dram to cas3, and if that fails, - I'll be trying some of Cindy's other recommendations. - DRAM is currently CAS2. Symptom is an explosion in free_all_bootmem_core, - In the loop where it is freeing bootmem alloc pages from low mem. - 2000/8/31: 10:57 No change, Linux still crashes. We'll try Cindy Lee's recommendation - RE Register 0x6d, set it to 0x37. All our other settings conform to her - other recommendations. We also need to see whether we should be setting - Fixed MTRRs, but that seems unlikely. - 2000/8/31: 5:56 PM. No significant change. We're going to try to use 1 cycle writes - instead of 2. None of this feels like it is the real problem. Fixed MTRRs - helped a tiny bit. We can get to schedule() before we crash, but only - if we set a breakpoint after the first loop in free_all_bootmem_core - */ - CS_WRITE($0x56, $0x10) - CS_WRITE($0x57, $0x10) + /* Begin auto-detection + * Find the first bank with DIMM equipped. */ + + /* Maximum possible memory in bank 0, none in other banks. + * Starting from bank 0, we's fill 0 in these registers + * until memory is found. */ + CS_WRITE($0x5A, $0xff) + CS_WRITE($0x5B, $0xff) + CS_WRITE($0x5C, $0xff) + CS_WRITE($0x5D, $0xff) + CS_WRITE($0x5E, $0xff) + CS_WRITE($0x5F, $0xff) + CS_WRITE($0x56, $0xff) + CS_WRITE($0x57, $0xff) + + movl $0x5A, %ebx // first bank +1: + /* Write different values to 0 and 8, then read from 0. + * If values of address 0 match, we have something there. */ + movl $0x12345678, %eax + movl %eax, 0 + movl $0x87654321, %edx + movl %edx, 8 + movl 0, %edx + cmpl %eax, %edx + je 2f + /* No memory in this bank. Tell it to the bridge. */ + movl %ebx, %eax + xorl %edx, %edx + PCI_WRITE_CONFIG_BYTE + incl %ebx + cmpl $0x60, %ebx + jne 1b + /* No memory at all! */ + CONSOLE_EMERG_TX_STRING($msg_nomem) +1: + hlt + jmp 1b +2: + + /* Detect MA mapping type of the first bank. */ + + jmp raminit_ma +raminit_ma_reg_table: + /* Values for MA type register to try */ + .word 0x0000, 0x8088, 0xe0ee + .word 0xffff // end mark + +raminit_ma: + xorl %esi, %esi // highest address + movl $raminit_ma_reg_table, %ebx +1: + movw (%ebx), %cx + cmpw $0xffff, %cx + je raminit_ma_done + movl $0x58, %eax + PCI_WRITE_CONFIG_WORD + + xorl %eax, %eax + movl %eax, (%eax) + + // Write to addresses with only one address bit on, + // from 0x80000000 to 0x00000008 (lower 3 bits are ignored, assuming + // 64-bit bus). + // Then what is read at address 0 is the value written to the lowest + // address where it gets wrap-around. That address is either the size + // of the bank, or a missing bit due to incorrect MA mapping. + movl $0x80000000, %eax +2: + movl %eax, (%eax) + shrl $1, %eax + cmpl $4, %eax + jne 2b + + movl 0, %eax + cmpl %eax, %esi + jnc 3f + + // This is the current best MA mapping. + // Save the address and its MA mapping value. + movl %eax, %esi + movl %ecx, %edi +3: + incl %ebx + incl %ebx + jmp 1b + + +raminit_ma_done: + // Set the best (hopefully correct) MA mapping type. + movl $0x58, %eax + movl %edi, %ecx + PCI_WRITE_CONFIG_WORD + + CONSOLE_DEBUG_TX_STRING($msg_enabled) + CONSOLE_DEBUG_TX_HEX32(%esi) + CONSOLE_DEBUG_TX_STRING($msg_bytes) + + /* + * We have the size of first bank in %esi, but throwing it away. + * Sizing will again be done in C, because we'll configure the rest + * of banks in there anyway. + */ + + //CALLSP(dumpnorth) intel_chip_post_macro(0x36) + + + .section ".rom.data" +msg_nomem: + .asciz "No memory\r\n" +msg_enabled: + .asciz "Enabled first bank of RAM: 0x" +msg_bytes: + .asciz " bytes\r\n" + .previous From NEWBELL7 at magicn.com Mon May 19 08:33:01 2003 From: NEWBELL7 at magicn.com (NEWBELL7 at magicn.com) Date: Mon May 19 08:33:01 2003 Subject: [Bochs] Do I need Bochs necessarily ? Message-ID: <65c9801c31e08$2ff653f0$82cda8c0@magicn.net> Hello!! I adapt Takeshi's patch to my EPIA. Thanks for your help very much. So, It works great. But I want to know what Bochs does . I think that we need Bochs for VGA and HDD(LILO). Is that right ? Who can explain what Bochs does ? Please. regards newbie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Mon May 19 09:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 19 09:15:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 In-Reply-To: <20030519080903.GA11352@cma.co.jp> Message-ID: I have committed your patches. Please check them for correctness. Thanks for fixing this. I could never figure it out. ron From rsmith at bitworks.com Mon May 19 09:39:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 19 09:39:00 2003 Subject: [Bochs] Do I need Bochs necessarily ? In-Reply-To: <65c9801c31e08$2ff653f0$82cda8c0@magicn.net> References: <65c9801c31e08$2ff653f0$82cda8c0@magicn.net> Message-ID: <3EC8E775.7080502@bitworks.com> NEWBELL7 at magicn.com wrote: > But I want to know what Bochs does . I think that we need Bochs for VGA > and HDD(LILO). Is that right ? > > Who can explain what Bochs does ? Please. Hopefully this helps. What is ADLO? See the following url: http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml But basically its the glue which bonds LinuxBIOS to the PC BIOS of the Bochs project. It allows you to boot some OS's that depend on legacy BIOS services. What bios services does ADLO provide and when would I need them. The full gory details are at: http://www.missl.cs.umd.edu/Projects/sebos/winint/index2.html -- Richard A. Smith rsmith at bitworks.com From joep at frog.nl Mon May 19 11:06:01 2003 From: joep at frog.nl (Joep Jansen) Date: Mon May 19 11:06:01 2003 Subject: Newbie questions: Linuxbios on Geode GX1 Message-ID: <3EC8FBE8.ECE59CF5@frog.nl> Hi, I am new to this list, and I have a couple of questions. I have an embedded CPU module (Kontron ETX-MGX with a Geode GX1), and I am looking into the possibility of putting linuxbios on it. The board contains: * a Geode GX1 CPU * CS5530A I/O companion south bridge * 64 MB RAM * AM29F040B 512 KB flash ROM with Phoenix BIOS * Compact Flash slot on IDE1 master The flash chip is soldered on the board, so replacing the BIOS chip is no option. My main question is: How can I safely flash a new BIOS? I have a BIOS ROM image file, and the Phoenix Phlash utility which allows to restore and update the BIOS. I understand the flash has a boot block which is able to restore a corrupted BIOS. I don't know whether the boot block is protected from erasing and / or reprogramming. I do know that it needs a specialy wired "key" in the serial port to enable reprogramming. My idea would be to use this utility to put linuxbios in the flash ROM. I would leave the boot block in place so that I am able to restore the original BIOS if things go wrong, or to put in a new version of linuxbios. Does anyone have experience with this? What would I need to do to convince Phlash to flash the linuxbios? Do I need to make changes to linuxbios to accomodate this scheme? Another question: How do I configure linuxbios to boot a linux kernel from the Compact Flash card? Do I need a specific "payload" program in addition to linuxbios? Any help is greatly appreciated! Joep Jansen -- Frog Navigation Systems B.V. mail to: joep at frog.nl Krommewetering 21 URL: http://www.frog.nl 3543AP UTRECHT Tel: (+31) 30 2 440 550 Nederland / the Netherlands Fax: (+31) 30 2 440 700 From rminnich at lanl.gov Mon May 19 11:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 19 11:15:01 2003 Subject: Newbie questions: Linuxbios on Geode GX1 In-Reply-To: <3EC8FBE8.ECE59CF5@frog.nl> Message-ID: On Mon, 19 May 2003, Joep Jansen wrote: > Does anyone have experience with this? we have experience with similar situations. You have to convert the linuxbios romimage into a phoenix romimage. I don't think that is too hard but it does require detective work. Have a look at the old PHLASH stuff for the l440gx. > Do I need to make changes to linuxbios to accomodate this scheme? no > How do I configure linuxbios to boot a linux kernel from the Compact > Flash card? on thing at a time. Let's get the build working at all. This second part is easy. ron From ebiederman at lnxi.com Mon May 19 12:14:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon May 19 12:14:01 2003 Subject: [Xavier Pegenaute ] Re: Map of the memory Message-ID: Don't just send questions to me. Thank you. Eric -------------- next part -------------- An embedded message was scrubbed... From: Xavier Pegenaute Subject: Re: Map of the memory Date: Mon, 19 May 2003 14:02:21 +0200 Size: 4324 URL: From ebiederman at lnxi.com Mon May 19 12:15:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon May 19 12:15:00 2003 Subject: PIRQ problem (Please try using pci=biosirq) In-Reply-To: <000d01c31d01$b51c2800$a12041db@vsnl.net> References: <001f01c31c9f$2020bca0$243e41db@vsnl.net> <000d01c31d01$b51c2800$a12041db@vsnl.net> Message-ID: Deepak Kotian writes: > Thanks, this is a good one. > One more question. How does one enable Shadow Ram. It is chipset and cpu specific. I would look it up in the documentation. Eric From ts1 at tsn.or.jp Mon May 19 15:27:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Mon May 19 15:27:00 2003 Subject: [PATCH] Automatic RAM detection for VT8601 In-Reply-To: References: <20030519080903.GA11352@cma.co.jp> Message-ID: <20030519200523.GA15694@tsn.or.jp> On Mon, May 19, 2003 at 07:51:40AM -0600, ron minnich wrote: > I have committed your patches. Please check them for correctness. Thanks. I confirmed that the current cvs builds and works correctly. -- Takeshi From rsmith at bitworks.com Mon May 19 19:49:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon May 19 19:49:01 2003 Subject: Newbie questions: Linuxbios on Geode GX1 In-Reply-To: <3EC8FBE8.ECE59CF5@frog.nl> References: <3EC8FBE8.ECE59CF5@frog.nl> Message-ID: <3EC96D02.6030604@bitworks.com> Joep Jansen wrote: > How can I safely flash a new BIOS? > I have a BIOS ROM image file, and the Phoenix Phlash utility which > allows to restore and update the BIOS. I understand the flash has a boot > block which is able to restore a corrupted BIOS. I don't know whether > the boot block is protected from erasing and / or reprogramming. I do > know that it needs a specialy wired "key" in the serial port to enable > reprogramming. The AMF040B does not have any special board level access to protection of sectors. It does allow protection/unprotection of any of the 8 64k sectors present but you have to raise A9 and the other control pins up to Vid which is a minimum of 10.5 volts. Seems doubtfull they would have some setup to do hardware protection/unprotection but if they set up some sort of protected boot block then they would have to protect the whole 64k in the address boot range. Which would make it kind of difficult to update things. Where does a geode GX1 boot from? Is it x86 compatible? The data sheet for the AMF040b are available on the web if you google for them. The info in there should help you figure out what (if any) sectors have be hardware locked. > Another question: > How do I configure linuxbios to boot a linux kernel from the Compact > Flash card? > Do I need a specific "payload" program in addition to linuxbios? When you get linuxbios loading from phoenix let me know and I'll send you my FAQ/HOWTO which should get you started this. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Mon May 19 22:09:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon May 19 22:09:01 2003 Subject: config language Message-ID: Eric has pointed out to me that we need a tree to properly describe the new complex systems such as K8. The current config language is not sufficient to do the job. I've been thinking about mods to the language that preserve the current simplicity for the vast majority of motherboards out there, while at the same time allowing a complex hierarchy to be described. I think I have an idea. Currently we say things like this: southbridge vendor/model ... superio vendor/model ... This syntax is actually sufficient for something like 95% of the motherboards we need to support. But what if we have southbridge vendor/model ... southbridge vendor/model ... superio vendor/model ... which southbridge is the superio on? Here is my proposed change southbridge vendor/model[=] [parent=] ... superio vendor/model[=] [parent=] ... (note this syntax applies to all the types of parts) Consider the simple case. The one southbridge is given a default tag of southbridge, with the default parent of northbridge. The superio is given the default tag of superio, with the default parent of southbridge. It all works. Consider the hard case. southbridge intel/xyz=sb1 ... southbridge intel/xyz=sb2 ... superio NSC/abs parent=sb1 ... If there is more than one northbridge, then we can set the parent tag for the southbridge. This syntax allows arbitrary trees to be described; it is as simple in the base case as the current one; and it should be fairly straightforward to implement. Computing the path to a given part is then easy. Some flexibility in the tags should be possible. The tag could allude to an actual tag, or a part type (southbridge), or a part vendor/manufacturer pair (intel/xyz). As long as the tag specifies something unique, it should be acceptable. Another way to do it is this: southbridge [tag=] [parent=] any preference for syntax? Comments? ron From gwatson at lanl.gov Mon May 19 23:52:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Mon May 19 23:52:00 2003 Subject: config language In-Reply-To: References: Message-ID: Phew! What a can of worms you've just opened up! Some comments: Your proposed syntax seems a bit inconsistent, in that you use 'name=' in some places, but not in others. If you go this way then I would suggest using this syntax for all arguments. Also, if 'parent' is optional then what does it mean to leave it out? Attached to the root? Defining the tree from bottom-up is somewhat non-intuitive and potentially confusing. It seems more natural to define the tree structure top-down as follows: mainboard vendor/model cpu p5 southbridge vendor/model end southbridge vendor/model2 superio vendor/model ...config... end end end This provides a much more readable description of the hierarchy, and also avoids the need to define arbitrary tags just to define the tree. Parsing is simple: a keyword ('mainboard', etc.) starts a tree node. The 'end' keyword ends the current node. Some keywords may be terminal so they don't need 'end', eg 'cpu'. Configuration options no longer need to be supplied as arguments to a keyword, they can be terminal keywords in a node. This works nicely for the PPC as follows: mainboard motorola/sandpoint pmc altimus/mpc7500 northbridge motorola/mpc107 end southbridge windbond/w83c553 superio NSC/pc97307 com1={1} com2={1} floppy=0 lpt=1 keyboard=1 hwmonitor=1 end end nvram flash end I think this also provides a nice way of conceptualizing the architecture. Regards, Greg At 8:06 PM -0600 19/5/03, ron minnich wrote: >Eric has pointed out to me that we need a tree to properly describe the >new complex systems such as K8. The current config language is not >sufficient to do the job. > >I've been thinking about mods to the language that preserve the current >simplicity for the vast majority of motherboards out there, while at the >same time allowing a complex hierarchy to be described. I think I have an >idea. > > >Currently we say things like this: > >southbridge vendor/model ... > >superio vendor/model ... > >This syntax is actually sufficient for something like 95% of the >motherboards we need to support. But what if we have > >southbridge vendor/model ... >southbridge vendor/model ... > >superio vendor/model ... > >which southbridge is the superio on? > >Here is my proposed change > >southbridge vendor/model[=] [parent=] ... > >superio vendor/model[=] [parent=] ... > >(note this syntax applies to all the types of parts) > >Consider the simple case. The one southbridge is given a default tag of >southbridge, with the default parent of northbridge. The superio is given >the default tag of superio, with the default parent of southbridge. It all >works. > >Consider the hard case. > >southbridge intel/xyz=sb1 ... >southbridge intel/xyz=sb2 ... > >superio NSC/abs parent=sb1 ... > >If there is more than one northbridge, then we can set the parent tag for >the southbridge. > >This syntax allows arbitrary trees to be described; it is as simple in the >base case as the current one; and it should be fairly straightforward to >implement. Computing the path to a given part is then easy. > >Some flexibility in the tags should be possible. The tag could allude to >an actual tag, or a part type (southbridge), or a part vendor/manufacturer >pair (intel/xyz). As long as the tag specifies something unique, it should >be acceptable. > >Another way to do it is this: > >southbridge [tag=] [parent=] > >any preference for syntax? > >Comments? > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From NEWBELL7 at magicn.com Tue May 20 01:16:01 2003 From: NEWBELL7 at magicn.com (NEWBELL7 at magicn.com) Date: Tue May 20 01:16:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 Message-ID: <450d01c31e8e$d093c3c0$82cda8c0@magicn.net> Hi !!!! I have a question about ADLO. My LinuxBIOS + etherboot + ADLO go through to ADLO, but stop at " sti " instruction before jumping to Bochs BIOS. I look up "sti" from Intel IA32 Instruction set Volume 2. I read that "sti" is "protected mode virtual interrupt enable". I removed "sti" from ADLO because it is real mode. Does It affect badly to my EPIA operation ? ps.> If I reset my system with LinuxBIOS after booting it with PC BIOS, it works great. As result , What makes it works ? Need your help... Thanks. regards newbie -------------- next part -------------- An HTML attachment was scrubbed... URL: From horen at mail.iucc.ac.il Tue May 20 03:42:01 2003 From: horen at mail.iucc.ac.il (Jonathan B. Horen) Date: Tue May 20 03:42:01 2003 Subject: Flashing Intel (L440GX) BIOS Message-ID: <3EC9DC32.2060304@mail.iucc.ac.il> Shalom! With lots of assistance from Ron Minnich, I've been able to patch a 2.4.20 kernel with the LinuxBIOS extensions and successfully compile and boot from it. I've also succeeded in compiling a romimage for the Intel L440GX. I've downloaded Intel's latest System Update Package -- lsup2_0.exe -- for the L440GX motherboard. My question is about what to do with what I've now got. That is, how do I get this romimage onto my motherboard(s)? Running lsup2_0.exe on a Windows system gives me, among other things, a BIOS directory. This directory contains BAT files, README and RELNOTES, BIOS files, and their IFLASH.EXE utility. The 1.BAT file invokes: IFLASH.EXE /P P14-0133.BIO /R in which I assume /P gives the file to load (or the first file in a group of files to load), and /R reboots afterward... or not ;-) Since I don't want to install Intel's newer BIOS, but do want to install the LinuxBIOS I compiled, what do I do, from here? Any pointers to previous threads about flashing L440GX BIOS? -- JONATHAN B. HOREN UNIX SYSTEMS ADMINISTRATOR E: horen at mail.iucc.ac.il Inter-University Computation Center T: +972-(0)3-640-5203 Tel-Aviv University F: +972-(0)3-640-9118 Ramat-Aviv 69978 Israel From ts1 at cma.co.jp Tue May 20 04:30:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Tue May 20 04:30:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 In-Reply-To: <450d01c31e8e$d093c3c0$82cda8c0@magicn.net> References: <450d01c31e8e$d093c3c0$82cda8c0@magicn.net> Message-ID: <20030520082905.GA4460@cma.co.jp> On Tue, May 20, 2003 at 02:15:23PM +0900, NEWBELL7 at magicn.com wrote: > I have a question about ADLO. My LinuxBIOS + etherboot + ADLO go through > to ADLO, but stop at " sti " instruction before jumping to Bochs BIOS. > I look up "sti" from Intel IA32 Instruction set Volume 2. I read that > "sti" is "protected mode virtual interrupt enable". > > I removed "sti" from ADLO because it is real mode. > Does It affect badly to my EPIA operation ? sti should also work in real mode. > ps.> If I reset my system with LinuxBIOS after booting it with PC BIOS, > it works great. Linux's reboot code sometimes doesn't work for some reason. (I think it resets only CPU) I wrote a small program to directly hit the power management device found in EPIA to reset the system, not only CPU. It works for me. Changing 0x29 to 0x28 makes it power off instead of reboot. See southbridge manual for detail. (0x4000 is PM base) -- Takeshi #include main() { iopl(3); outb(0xff, 0x4001); printf("01=%x\n", inb(0x4001)); outb(0x20, 0x4005); printf("05=%x\n", inb(0x4005)); outw(0xff, 0x4020); printf("20=%x\n", inw(0x4020)); outb(0x29, 0x4005); // while ((inb(0x4001) & 1) == 0) // sleep(2); } From xpegenaute at telepolis.es Tue May 20 04:30:55 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Tue May 20 04:30:55 2003 Subject: ADLO Message-ID: <3EC9F3F8.6080502@telepolis.es> Hi, i want to try with ADLO, but at the moment i can't find MS7308E, i think that may be i can find this motherboard MS7308ET, but use a different chipset SIS630ET any one tryed with this one ? Thanks. Xavi. From mwilkinson at ndirect.co.uk Tue May 20 04:42:01 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Tue May 20 04:42:01 2003 Subject: config language In-Reply-To: Message-ID: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> Hi Greg, Ron Just to chip in my $0.02. Greg, what you've suggested looks to lend itself towards an XML type markup. How about something like this for your example :- p5 It's just a suggestion, but with a properly defined schema, the config file could be verified/edited easily. Regards Mark Wilkinson. > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Greg Watson > Sent: 20 May 2003 04:51 > To: linuxbios at clustermatic.org > Subject: Re: config language > > > Phew! What a can of worms you've just opened up! > > Some comments: > > Your proposed syntax seems a bit inconsistent, in that you use > 'name=' in some places, but not in others. If you go this way > then I would suggest using this syntax for all arguments. Also, if > 'parent' is optional then what does it mean to leave it out? Attached > to the root? > > Defining the tree from bottom-up is somewhat non-intuitive and > potentially confusing. It seems more natural to define the tree > structure top-down as follows: > > mainboard vendor/model > cpu p5 > southbridge vendor/model > end > southbridge vendor/model2 > superio vendor/model > ...config... > end > end > end > > This provides a much more readable description of the hierarchy, and > also avoids the need to define arbitrary tags just to define the tree. > > Parsing is simple: a keyword ('mainboard', etc.) starts a tree node. > The 'end' keyword ends the current node. Some keywords may be > terminal so they don't need 'end', eg 'cpu'. Configuration options no > longer need to be supplied as arguments to a keyword, they can be > terminal keywords in a node. > > This works nicely for the PPC as follows: > > mainboard motorola/sandpoint > pmc altimus/mpc7500 > northbridge motorola/mpc107 > end > southbridge windbond/w83c553 > superio NSC/pc97307 > com1={1} > com2={1} > floppy=0 > lpt=1 > keyboard=1 > hwmonitor=1 > end > end > nvram > flash > end > > I think this also provides a nice way of conceptualizing the > architecture. > > Regards, > > Greg > > At 8:06 PM -0600 19/5/03, ron minnich wrote: > >Eric has pointed out to me that we need a tree to properly > describe the > >new complex systems such as K8. The current config language is not > >sufficient to do the job. > > > >I've been thinking about mods to the language that preserve > the current > >simplicity for the vast majority of motherboards out there, while at > >the same time allowing a complex hierarchy to be described. > I think I > >have an idea. > > > > > >Currently we say things like this: > > > >southbridge vendor/model ... > > > >superio vendor/model ... > > > >This syntax is actually sufficient for something like 95% of the > >motherboards we need to support. But what if we have > > > >southbridge vendor/model ... > >southbridge vendor/model ... > > > >superio vendor/model ... > > > >which southbridge is the superio on? > > > >Here is my proposed change > > > >southbridge vendor/model[=] [parent=] ... > > > >superio vendor/model[=] [parent=] ... > > > >(note this syntax applies to all the types of parts) > > > >Consider the simple case. The one southbridge is given a > default tag of > >southbridge, with the default parent of northbridge. The superio is > >given the default tag of superio, with the default parent of > >southbridge. It all works. > > > >Consider the hard case. > > > >southbridge intel/xyz=sb1 ... > >southbridge intel/xyz=sb2 ... > > > >superio NSC/abs parent=sb1 ... > > > >If there is more than one northbridge, then we can set the > parent tag > >for the southbridge. > > > >This syntax allows arbitrary trees to be described; it is as > simple in > >the base case as the current one; and it should be fairly > >straightforward to implement. Computing the path to a given part is > >then easy. > > > >Some flexibility in the tags should be possible. The tag > could allude > >to an actual tag, or a part type (southbridge), or a part > >vendor/manufacturer pair (intel/xyz). As long as the tag specifies > >something unique, it should be acceptable. > > > >Another way to do it is this: > > > >southbridge [tag=] [parent=] > > > >any preference for syntax? > > > >Comments? > > > >ron > > > >_______________________________________________ > >Linuxbios mailing list > >Linuxbios at clustermatic.org > >http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/l> inuxbios > From dkotian3 at vsnl.net Tue May 20 05:10:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Tue May 20 05:10:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? Message-ID: <20030520094250.AD72C4FE47@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From hcyun at etri.re.kr Tue May 20 05:12:01 2003 From: hcyun at etri.re.kr (hcyun at etri.re.kr) Date: Tue May 20 05:12:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A9CD74E@cms3> As for reset, you may can do it by asserting "Software PCI reset" on configuration space of PCI-to-ISA bridge. Heechul > -----Original Message----- > From: SONE Takeshi [mailto:ts1 at cma.co.jp] > Sent: Tuesday, May 20, 2003 5:29 PM > To: NEWBELL7 at magicn.com > Cc: linuxbios at clustermatic.org > Subject: Re: [PATCH] Automatic RAM detection for VT8601 > > > On Tue, May 20, 2003 at 02:15:23PM +0900, NEWBELL7 at magicn.com wrote: > > I have a question about ADLO. My LinuxBIOS + etherboot + > ADLO go through > > to ADLO, but stop at " sti " instruction before jumping to > Bochs BIOS. > > I look up "sti" from Intel IA32 Instruction set Volume 2. > I read that > > "sti" is "protected mode virtual interrupt enable". > > > > I removed "sti" from ADLO because it is real mode. > > Does It affect badly to my EPIA operation ? > > sti should also work in real mode. > > > ps.> If I reset my system with LinuxBIOS after booting it > with PC BIOS, > > it works great. > > Linux's reboot code sometimes doesn't work for some reason. > (I think it resets only CPU) > > I wrote a small program to directly hit the power management device > found in EPIA to reset the system, not only CPU. > It works for me. > Changing 0x29 to 0x28 makes it power off instead of reboot. > See southbridge manual for detail. (0x4000 is PM base) > -- > Takeshi > > > > #include > > main() > { > iopl(3); > outb(0xff, 0x4001); > printf("01=%x\n", inb(0x4001)); > outb(0x20, 0x4005); > printf("05=%x\n", inb(0x4005)); > outw(0xff, 0x4020); > printf("20=%x\n", inw(0x4020)); > outb(0x29, 0x4005); > // while ((inb(0x4001) & 1) == 0) > // sleep(2); > } > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noshel at idis.co.kr Tue May 20 05:15:01 2003 From: noshel at idis.co.kr (Edward J. Lee) Date: Tue May 20 05:15:01 2003 Subject: [linuxBios] HDD init problem Message-ID: <3ECA708D.1050205@idis.co.kr> Hi. Does anyone have problems using ide_init()? While using it on IBM 123G HDDs, ide_init() sometimes seems to run forever, (stuck in the numerous busy-waitings, i guess) and my H/W watchdog eventually reboots the system. Of course, in most occasions everything goes just fine. Is there a better way of initializing HDDs? Ed. From ts1 at cma.co.jp Tue May 20 05:34:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Tue May 20 05:34:00 2003 Subject: Reverse engineering Message-ID: <20030520093316.GA7672@cma.co.jp> Is it legal to disassemble the proprietary VGA BIOS to learn how to enable a particular VGA chip? Of course, he (who?) will not copy any bits from the copyrighted code, he'll just pick up register addresses and values, and its order. If he would eventually write a code to enable VGA this way, can we share the resulting code? -- Takeshi From karl at kalle.csb.ki.se Tue May 20 05:54:01 2003 From: karl at kalle.csb.ki.se (Karl Hammar) Date: Tue May 20 05:54:01 2003 Subject: Reverse engineering In-Reply-To: Message from SONE Takeshi of "Tue, 20 May 2003 18:33:16 +0900." <20030520093316.GA7672@cma.co.jp> References: <20030520093316.GA7672@cma.co.jp> Message-ID: <200305200953.h4K9qvqL008192@md4690f24.utfors.se> > Is it legal to disassemble the proprietary VGA BIOS to learn how to > enable a particular VGA chip? > Of course, he (who?) will not copy any bits from the copyrighted code, > he'll just pick up register addresses and values, and its order. > If he would eventually write a code to enable VGA this way, > can we share the resulting code? > > -- > Takeshi A FreeBSD developer said that in the EU there is a law that says that you have the right to get the interface specifications. I don't know if he was right or wrong. Even if he is right, there could be conditions that makes it out of the reach anyhow. Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Asp? Data karl at kalle.csb.ki.se Lilla Asp? 2340 Networks S-742 94 ?sthammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting ----------------------------------------------------------------------- From sxpert at esitcom.org Tue May 20 06:47:00 2003 From: sxpert at esitcom.org (Amaury Jacquot) Date: Tue May 20 06:47:00 2003 Subject: Reverse engineering In-Reply-To: <20030520093316.GA7672@cma.co.jp> References: <20030520093316.GA7672@cma.co.jp> Message-ID: <1053427504.9913.33.camel@fali> On Tue, 2003-05-20 at 11:33, SONE Takeshi wrote: > Is it legal to disassemble the proprietary VGA BIOS to learn how to > enable a particular VGA chip? > Of course, he (who?) will not copy any bits from the copyrighted code, > he'll just pick up register addresses and values, and its order. > If he would eventually write a code to enable VGA this way, > can we share the resulting code? It is legal in France if the goal is to assure systems compatibility. Clearly, this case would be legal... Amaury > -- > Takeshi > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From pyro at linuxlabs.com Tue May 20 07:16:01 2003 From: pyro at linuxlabs.com (steven james) Date: Tue May 20 07:16:01 2003 Subject: ADLO In-Reply-To: <3EC9F3F8.6080502@telepolis.es> Message-ID: Greetings, For the most part, the 630ET chipset is compatible with the 630. The big difference I have seen is that the builtin sis900 ethernet gets it's MAC address from CMOS rather than a seperate EEPROM. The following code fragment demonstrates: i = read_config_byte(0x80000848); write_config_byte(0x80000848, 0x50); printf("CMOS eth0 hwaddr"); for(i=9; i<15; i++) { outb(i,0x70); cache = inb(0x71); printf(":%02x", cache); } write_config_byte(0x80000848, 0x10); G'day, sjames On Tue, 20 May 2003, Xavier Pegenaute wrote: > Hi, > > i want to try with ADLO, but at the moment i can't find MS7308E, i think > that may be i can find this motherboard MS7308ET, but use a different > chipset SIS630ET any one tryed with this one ? > > Thanks. > Xavi. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From prl-linuxbios at sychron.com Tue May 20 07:17:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Tue May 20 07:17:00 2003 Subject: config language In-Reply-To: Your message of "Mon, 19 May 2003 21:50:53 MDT." Message-ID: Over on etherboot-developers, there has been discussion about encoding a description of the available NICs in the DHCP request so that an appropriate image can be chained. This encodes the PCI IDs (and, IIRC some ISA card names). It would be great to have a more general parseable hardware inventory available via DHCP (which can neatly encapsulate options for this kind of thing). So, whatever kind of structure you end up with, consider how a more general purpose tree fits in and how it can be flattened into DHCP encapsulated options. From debian at ahrcas.net Tue May 20 07:31:01 2003 From: debian at ahrcas.net (Rene Caspari) Date: Tue May 20 07:31:01 2003 Subject: VIA Eden BIOS interchangeable? Message-ID: <20030520113101.GA4922@localhost> Hi, i want to buy a VIA Epia V5000 Motherboard. Do you know wether i can use this board to install another BIOS-Chip and finally install Linuxbios? Thx, rene -- /* Ich hab mein Leben lang gehorcht. (Stengel ?ber Mielke) */ /* http://www.reca.ahrcas.net */ /* remove 'spam': reca@'spam'ahrcas.net */ From bob at drzyzgula.org Tue May 20 07:34:01 2003 From: bob at drzyzgula.org (Bob Drzyzgula) Date: Tue May 20 07:34:01 2003 Subject: config language In-Reply-To: References: Message-ID: <20030520073301.E21569@www2> On Tue, May 20, 2003 at 12:16:16PM +0100, prl-linuxbios at sychron.com wrote: > > Over on etherboot-developers, there has been discussion about encoding a > description of the available NICs in the DHCP request so that an > appropriate image can be chained. This encodes the PCI IDs (and, IIRC > some ISA card names). > > It would be great to have a more general parseable hardware inventory > available via DHCP (which can neatly encapsulate options for this kind > of thing). So, whatever kind of structure you end up with, consider how > a more general purpose tree fits in and how it can be flattened into > DHCP encapsulated options. The great thing about using XML in this kind of situation is the relative ease with which XML-based data can be parsed and transformed into nearly any other format. Were the config language encoded in XML, your application -- to the extent that the data in the config file were truely useful here -- would most likely be codable in a relatively simple script in XSL or Python, etc. --Bob From rminnich at lanl.gov Tue May 20 08:40:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:40:01 2003 Subject: config language In-Reply-To: Message-ID: On Mon, 19 May 2003, Greg Watson wrote: > Defining the tree from bottom-up is somewhat non-intuitive and > potentially confusing. It seems more natural to define the tree > structure top-down as follows: > > mainboard vendor/model > cpu p5 > southbridge vendor/model > end > southbridge vendor/model2 > superio vendor/model > ...config... > end > end > end OH, ok, you win. I had thought of this but hate the idea of writing a parser ... string handling in C is like walking on broken glass. > mainboard motorola/sandpoint > pmc altimus/mpc7500 > northbridge motorola/mpc107 > end > southbridge windbond/w83c553 > superio NSC/pc97307 > com1={1} > com2={1} > floppy=0 > lpt=1 > keyboard=1 > hwmonitor=1 > end > end > nvram > flash > end agreed, it's pretty. But NOBODY is allowed to suggest lexical scoping from indentation. That's not allowed :-) Greg, parser in the usual lex/yacc/C mode or .... I'll see if anybody's got parsers written in python. ron From rminnich at lanl.gov Tue May 20 08:47:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:47:00 2003 Subject: Flashing Intel (L440GX) BIOS In-Reply-To: <3EC9DC32.2060304@mail.iucc.ac.il> Message-ID: On Tue, 20 May 2003, Jonathan B. Horen wrote: > Running lsup2_0.exe on a Windows system gives me, among other things, a > BIOS directory. This directory contains BAT files, README and RELNOTES, > BIOS files, and their IFLASH.EXE utility. have you tried first installing the bios on that floppy so you know what it is like? I'm not kidding. Do it once or twice so you know when it is working and what the floppy sounds are. The recovery flash on those boards is a full BIOS -- except for display -- so the floppy actually boots to DOS and runs autoexec.bat. You need to learn how it sounds. > The 1.BAT file invokes: > > IFLASH.EXE /P P14-0133.BIO /R > > in which I assume /P gives the file to load (or the first file in a > group of files to load), and /R reboots afterward... or not ;-) First file in a group of files, you got it. You really need to find the ancient scripts that take a linuxbios romimage, slice and dice it, and turn it into the sequence of files that iflash.exe understands. ron From rminnich at lanl.gov Tue May 20 08:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:50:01 2003 Subject: [PATCH] Automatic RAM detection for VT8601 In-Reply-To: <20030520082905.GA4460@cma.co.jp> Message-ID: On Tue, 20 May 2003, SONE Takeshi wrote: > Linux's reboot code sometimes doesn't work for some reason. > (I think it resets only CPU) the linux reboot code is very strange and I determined a few years ago that most of it doesn't work; rebooting seems to happen mostly through the triple fault scenario. > I wrote a small program to directly hit the power management device > found in EPIA to reset the system, not only CPU. that's far and away the best way to reset a system. The most acceptable way (nowadays) to integrate that into the kernel is as part of watchdog timer support. However it might be worth integrating into the power off/reset patches in freebios source tree. ron From rminnich at lanl.gov Tue May 20 08:52:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:52:00 2003 Subject: config language In-Reply-To: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> Message-ID: On Tue, 20 May 2003, Mark Wilkinson wrote: > Greg, what you've suggested looks to lend itself towards an XML type > markup. Thanks for the suggestions and looking at the idea, but we're not going XML. Sorry, but we've got a real bias here against using text markup languages for other purposes. Besides, Greg language is pretty, and the xml example is in my opionion kind of ugly ... Other than that, however, sounds like you think Greg's idea is ok? ron From rminnich at lanl.gov Tue May 20 08:57:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:57:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? In-Reply-To: <20030520094250.AD72C4FE47@bom6.vsnl.net.in> Message-ID: getpir just reads the $PIR table in memory as set by the bios. I am wondering if the bios on your board is one of the defective BIOSes that doesn't have the $PIR entries for all devices. There are many of these. If so, you are going to have to hand-edit that .c file and add the entries yourself. in the case of defective $PIR tables what the BIOS writers do is just set the IRQ line by hand in the pci device. ron From rminnich at lanl.gov Tue May 20 08:58:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:58:01 2003 Subject: [linuxBios] HDD init problem In-Reply-To: <3ECA708D.1050205@idis.co.kr> Message-ID: I think Greg Watson is porting a decent IDE driver to LinuxBIOS from Etherboot. The one in LinuxBIOS is not quite right. ron From rminnich at lanl.gov Tue May 20 08:59:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 08:59:01 2003 Subject: Reverse engineering In-Reply-To: <20030520093316.GA7672@cma.co.jp> Message-ID: On Tue, 20 May 2003, SONE Takeshi wrote: > Is it legal to disassemble the proprietary VGA BIOS to learn how to > enable a particular VGA chip? depends on what country you are in. I have no idea of the rules in Japan. We have avoided doing this type of thing in the US, because we have so many lawyers here looking for lawsuits to file. Even if it is legal we felt it was a bad idea. ron From rminnich at lanl.gov Tue May 20 09:02:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:02:01 2003 Subject: config language In-Reply-To: Message-ID: On Tue, 20 May 2003 prl-linuxbios at sychron.com wrote: > It would be great to have a more general parseable hardware inventory > available via DHCP (which can neatly encapsulate options for this kind > of thing). So, whatever kind of structure you end up with, consider how > a more general purpose tree fits in and how it can be flattened into > DHCP encapsulated options. > great idea. Looks like we're going to a real parser anyway. We'll keep that in mind, and if we don't, tell us :-) ron From mwilkinson at ndirect.co.uk Tue May 20 09:04:00 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Tue May 20 09:04:00 2003 Subject: config language In-Reply-To: Message-ID: <001601c31ed0$2fe232d0$ce40a8c0@2pmtech.com> Hi Ron, Greg, > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of ron minnich > Sent: 20 May 2003 13:49 > To: Mark Wilkinson > Cc: 'Greg Watson'; linuxbios at clustermatic.org > Subject: RE: config language > > > On Tue, 20 May 2003, Mark Wilkinson wrote: > > > Greg, what you've suggested looks to lend itself towards an > XML type > > markup. > > Thanks for the suggestions and looking at the idea, but we're > not going XML. Sorry, but we've got a real bias here against > using text markup languages for other purposes. > > Besides, Greg language is pretty, and the xml example is in > my opionion > kind of ugly ... > > Other than that, however, sounds like you think Greg's idea is ok? Yep, all for Greg's idea ! > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/l> inuxbios > Regards Mark From rminnich at lanl.gov Tue May 20 09:05:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:05:00 2003 Subject: config language In-Reply-To: <20030520073301.E21569@www2> Message-ID: XML parsers I have seen are not trivial. S-expressions are far better for this type of thing. For a simple, low-cost, embeddable S-expression parsing library see: http://sexpr.sourceforge.net/ ron From aip at cwlinux.com Tue May 20 09:17:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue May 20 09:17:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? In-Reply-To: ; from ron minnich on Tue, May 20, 2003 at 06:54:04AM -0600 References: <20030520094250.AD72C4FE47@bom6.vsnl.net.in> Message-ID: <20030520211654.B5960@mail.cwlinux.com> > getpir just reads the $PIR table in memory as set by the bios. > I am wondering if the bios on your board is one of the defective BIOSes > that doesn't have the $PIR entries for all devices. There are many of > these. If so, you are going to have to hand-edit that .c file and add the > entries yourself. > in the case of defective $PIR tables what the BIOS writers do is just set > the IRQ line by hand in the pci device. Sometimes you can just trust the value from stock PIRQ table. Some boards come with faulty table. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Tue May 20 09:18:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:18:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? In-Reply-To: <20030520211654.B5960@mail.cwlinux.com> Message-ID: On Tue, 20 May 2003, Andrew Ip wrote: > Sometimes you can just trust the value from stock PIRQ table. Some > boards come with faulty table. yes. Deepak, are the two ethernet devices built into the motherboard? ron From rminnich at lanl.gov Tue May 20 09:22:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:22:00 2003 Subject: new config tool Message-ID: I'm looking at a parser generator called YAPPS, more when I know how it will go. ron From bob at drzyzgula.org Tue May 20 09:25:00 2003 From: bob at drzyzgula.org (Bob Drzyzgula) Date: Tue May 20 09:25:00 2003 Subject: config language In-Reply-To: References: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> Message-ID: <20030520092435.G21569@www2> On Tue, May 20, 2003 at 06:49:15AM -0600, ron minnich wrote: > > On Tue, 20 May 2003, Mark Wilkinson wrote: > > > Greg, what you've suggested looks to lend itself towards an XML type > > markup. > > Thanks for the suggestions and looking at the idea, but we're not going > XML. Sorry, but we've got a real bias here against using text markup > languages for other purposes. > > Besides, Greg language is pretty, and the xml example is in my opionion > kind of ugly ... > > Other than that, however, sounds like you think Greg's idea is ok? > > ron Ron, Given that you just bemoaned the work neccessary to build a C-based parser for a new language, one would think that you would be interested in a solution wherein the parser comes pretty much for free. With an XML-based config file, you can have a correct, validating parser implemented in an afternoon. With some thought put into defaults, the translation of the existing config files into XML could be automated with a small amount of effort, and config file editors that do not allow the creation of invalid config files could easily be constructed. PyRXP will vacuum up an XML document into a native Python data structure, and validate the document against a DTD if you have one: http://www.reportlab.com/xml/pyrxp.html It's fast, GPL'd, and brain-dead easy to use. --Bob From rminnich at lanl.gov Tue May 20 09:38:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:38:00 2003 Subject: config language In-Reply-To: <20030520092435.G21569@www2> Message-ID: On Tue, 20 May 2003, Bob Drzyzgula wrote: > Given that you just bemoaned the work neccessary to build > a C-based parser for a new language, one would think that yeah, I'm a whiner :-) I'll start with yapps first and talk to greg and sung later today. They're the compiler dudes. ron From gwatson at lanl.gov Tue May 20 09:39:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Tue May 20 09:39:01 2003 Subject: [linuxBios] HDD init problem In-Reply-To: References: Message-ID: Ron is right, I'm in the process of retrofitting the etherboot-5.1.8 IDE driver into LB. I can't get the standard IDE driver to even recognize my controller. Greg At 6:55 AM -0600 20/5/03, ron minnich wrote: >I think Greg Watson is porting a decent IDE driver to LinuxBIOS from >Etherboot. The one in LinuxBIOS is not quite right. > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From jarcher at pobox.com Tue May 20 09:49:01 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Tue May 20 09:49:01 2003 Subject: config language Message-ID: <5.2.1.1.2.20030520063748.027cea00@wheresmymailserver.com> I may be going to far here, but what about the ability to define new devices? Or composite devices. define warpdisk cpu p3 # Warp disk controller include vendor/warpdisk_driver.inc end mainboard vendor/model cpu p5 warpdisk ...config... end Also I don't know if the current structure allows options. superio vendor/model IDE2=0 # For setting #defines for this included device. warpdisk ID=0 MAXDISK=3 warpdisk ID=1 MAXDISK=2 Jordan >On Mon, 19 May 2003, Greg Watson wrote: > > > Defining the tree from bottom-up is somewhat non-intuitive and > > potentially confusing. It seems more natural to define the tree > > structure top-down as follows: > > > > mainboard vendor/model > > cpu p5 > > southbridge vendor/model > > end > > southbridge vendor/model2 > > superio vendor/model > > ...config... > > end > > end > > end > >OH, ok, you win. I had thought of this but hate the idea of writing a >parser ... string handling in C is like walking on broken glass. > > > > mainboard motorola/sandpoint > > pmc altimus/mpc7500 > > northbridge motorola/mpc107 > > end > > southbridge windbond/w83c553 > > superio NSC/pc97307 > > com1={1} > > com2={1} > > floppy=0 > > lpt=1 > > keyboard=1 > > hwmonitor=1 > > end > > end > > nvram > > flash > > end > >agreed, it's pretty. But NOBODY is allowed to suggest lexical scoping from >indentation. That's not allowed :-) > >Greg, parser in the usual lex/yacc/C mode or .... I'll see if anybody's >got parsers written in python. > >ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerxxmaillist at san.rr.com Tue May 20 09:51:01 2003 From: rogerxxmaillist at san.rr.com (roger) Date: Tue May 20 09:51:01 2003 Subject: config language In-Reply-To: References: Message-ID: <1053438409.2242.26.camel@localhost3.localdomain> On Tue, 2003-05-20 at 05:49, ron minnich wrote: > Besides, Greg language is pretty, and the xml example is in my opionion > kind of ugly ... eh. i don't program much but i've seen one or two xml config files (of which the authors boost of their ease of understanding)...and i must laugh because the html markup made it a pain to read. -- Roger http://www.eskimo.com/~roger/index.html From rminnich at lanl.gov Tue May 20 09:57:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 09:57:00 2003 Subject: config language In-Reply-To: <5.2.1.1.2.20030520063748.027cea00@wheresmymailserver.com> Message-ID: On Tue, 20 May 2003 jarcher at pobox.com wrote: > I may be going to far here, but what about the ability to define new > devices? Or composite devices. > > define warpdisk > cpu p3 # Warp disk controller > include vendor/warpdisk_driver.inc > end > > mainboard vendor/model > cpu p5 > warpdisk > ...config... > end > > Also I don't know if the current structure allows options. > > superio vendor/model IDE2=0 # For setting #defines for this > included device. > warpdisk ID=0 MAXDISK=3 > warpdisk ID=1 MAXDISK=2 > > Jordan well, at what point are we going overboard? but we'll look at it. It's an interesting idea. There was a reason I made the original language so dumb ... :=) Once you make it a real language too many things are possible :-) ron From gwatson at lanl.gov Tue May 20 09:57:08 2003 From: gwatson at lanl.gov (Greg Watson) Date: Tue May 20 09:57:08 2003 Subject: config language In-Reply-To: <20030520092435.G21569@www2> References: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> <20030520092435.G21569@www2> Message-ID: Hi Bob, The config language does lend itself to XML, (and it was my first thought when Ron suggested a new languge) but I would recommend against it for a couple of reasons. The first is that the language needs to serve the dual purpose of specifying *and documenting* a particular configuration. XML is great for the former, but is almost impossible to read easily, particularly for people not used to working with it. Sure, you could then add something that converts the XML into a more readable document, but then what is a simple idea is now becoming very complicated. Secondly, and more importantly, is that it would mean that LB relies on the existence of an extremely complex external component, that is out of the control of the LB community (be it pyRXP, libXML, or whatever). Arguably this is already the case, since the configuration process uses python, but if we adopt a new configuration language then the parser can be included as part of the distribution - making it effectively self-contained. So in my view the limitations of using XML outweigh any advantages that might be obtained. Regards, Greg At 9:24 AM -0400 20/5/03, Bob Drzyzgula wrote: >On Tue, May 20, 2003 at 06:49:15AM -0600, ron minnich wrote: >> >> On Tue, 20 May 2003, Mark Wilkinson wrote: >> >> > Greg, what you've suggested looks to lend itself towards an XML type >> > markup. >> >> Thanks for the suggestions and looking at the idea, but we're not going >> XML. Sorry, but we've got a real bias here against using text markup >> languages for other purposes. >> >> Besides, Greg language is pretty, and the xml example is in my opionion >> kind of ugly ... >> >> Other than that, however, sounds like you think Greg's idea is ok? >> >> ron > >Ron, > >Given that you just bemoaned the work neccessary to build >a C-based parser for a new language, one would think that >you would be interested in a solution wherein the parser >comes pretty much for free. With an XML-based config file, >you can have a correct, validating parser implemented in >an afternoon. With some thought put into defaults, the >translation of the existing config files into XML could be >automated with a small amount of effort, and config file >editors that do not allow the creation of invalid config >files could easily be constructed. > >PyRXP will vacuum up an XML document into a native Python >data structure, and validate the document against a DTD >if you have one: http://www.reportlab.com/xml/pyrxp.html >It's fast, GPL'd, and brain-dead easy to use. > >--Bob >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From peter at trusteddebian.org Tue May 20 10:29:00 2003 From: peter at trusteddebian.org (Peter Busser) Date: Tue May 20 10:29:00 2003 Subject: config language In-Reply-To: References: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> Message-ID: <20030520142355.GA2391@trusteddebian.org> Hi! > > Greg, what you've suggested looks to lend itself towards an XML type > > markup. > Thanks for the suggestions and looking at the idea, but we're not going > XML. Sorry, but we've got a real bias here against using text markup > languages for other purposes. XML is not a text markup language. It is a markup language which describes data where data can be almost anything. You would be using it here for the kind of things it was designed for. > Besides, Greg language is pretty, and the xml example is in my opionion > kind of ugly ... That is a matter of taste. Besides, XML is not meant to be read/edited by humans, even though it is perfectly possible. The biggest drawback is the complexity of XML parsing and (therefore) the size of XML parsers. > Other than that, however, sounds like you think Greg's idea is ok? Groetjes, Peter Busser From jarcher at pobox.com Tue May 20 10:30:00 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Tue May 20 10:30:00 2003 Subject: config language and 2.0 In-Reply-To: References: <5.2.1.1.2.20030520063748.027cea00@wheresmymailserver.com> Message-ID: <5.2.1.1.2.20030520072130.02dd7e48@cybermorph.com> Yeah, I agree it's hard to not go too far. But coming from a compiler company you begin to look at everything as a language. Honestly, having gone through my first port/debug this weekend, I would say another feature would be a index listing file of the include files, paths, and the generated options would be nice. I spent a lot of time figuring out just which include file was being used. A second point is on items for 2.0. I had to track down three places where the serial port got its baud rate reset. I kept loosing debug messages. How about some flags to test if a device is already initialized? Jordan At 07:54 AM 5/20/2003 -0600, ron minnich wrote: >On Tue, 20 May 2003 jarcher at pobox.com wrote: > > > I may be going to far here, but what about the ability to define new > > devices? Or composite devices. > > > > define warpdisk > > cpu p3 # Warp disk controller > > include vendor/warpdisk_driver.inc > > end > > > > mainboard vendor/model > > cpu p5 > > warpdisk > > ...config... > > end > > > > Also I don't know if the current structure allows options. > > > > superio vendor/model IDE2=0 # For setting #defines for this > > included device. > > warpdisk ID=0 MAXDISK=3 > > warpdisk ID=1 MAXDISK=2 > > > > Jordan > >well, at what point are we going overboard? but we'll look at it. It's an >interesting idea. > >There was a reason I made the original language so dumb ... :=) Once you >make it a real language too many things are possible :-) > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From joep at frog.nl Tue May 20 10:31:00 2003 From: joep at frog.nl (Joep Jansen) Date: Tue May 20 10:31:00 2003 Subject: Newbie questions: Linuxbios on Geode GX1 References: Message-ID: <3ECA3BFF.88DEDB95@frog.nl> ron minnich wrote: > we have experience with similar situations. You have to convert the > linuxbios romimage into a phoenix romimage. I don't think that is too hard > but it does require detective work. > > Have a look at the old PHLASH stuff for the l440gx Thanks Ron! I had a look, but I don't understand what these strange*.bi? files are and where they come from? I guess they must be on some Intel Phlash disk. I don't have that. I have a Phoenix Phlash disk; it contains: * phlash.exe * bios.rom * platform.bin * minidos.sys * crisdisk.bat * makeboot.exe * wincris.exe * wincris.hlp The BIOS.ROM is a generic bios; I replaced it with the specific BIOS for my ETX Geode board. The "crisdisk.bat" command creates a standalone recovery floppy. So I think I need to replace the Phoenix BIOS.ROM file by a linuxbios.rom and use the PHLASH program to burn that. But I guess the PHLASH program will check somehow whether the BIOS.ROM is a genuine Phoenix BIOS ROM image, and will refuse to burn something else. Am I correct? How can I convince the PHLASH program that it should flash LinuxBios? Any suggestions are welcome! Regards, Joep -- Frog Navigation Systems B.V. mail to: joep at frog.nl Krommewetering 21 URL: http://www.frog.nl 3543AP UTRECHT Tel: (+31) 30 2 440 550 Nederland / the Netherlands Fax: (+31) 30 2 440 700 From rminnich at lanl.gov Tue May 20 10:34:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 10:34:00 2003 Subject: config language and 2.0 In-Reply-To: <5.2.1.1.2.20030520072130.02dd7e48@cybermorph.com> Message-ID: On Tue, 20 May 2003 jarcher at pobox.com wrote: > the serial port got its baud rate reset. I kept loosing debug > messages. How about some flags to test if a device is already initialized? that's a good one. It's not so much that it is initialized that you want to say "leave it alone". I'm working on that. ron From rminnich at lanl.gov Tue May 20 10:35:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 10:35:01 2003 Subject: Newbie questions: Linuxbios on Geode GX1 In-Reply-To: <3ECA3BFF.88DEDB95@frog.nl> Message-ID: On Tue, 20 May 2003, Joep Jansen wrote: > But I guess the PHLASH program will check somehow whether the BIOS.ROM is a > genuine Phoenix BIOS ROM image, and will refuse to burn something else. yes. You need to dump the header (usually 32 bytes) and see what it has that makes it magic. How many bytes long is BIOS.ROM ron From bob at drzyzgula.org Tue May 20 10:46:01 2003 From: bob at drzyzgula.org (Bob Drzyzgula) Date: Tue May 20 10:46:01 2003 Subject: config language In-Reply-To: References: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> <20030520092435.G21569@www2> Message-ID: <20030520104553.H21569@www2> On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote: > > Hi Bob, > > The config language does lend itself to XML, (and it was my first > thought when Ron suggested a new languge) but I would recommend > against it for a couple of reasons. The first is that the language > needs to serve the dual purpose of specifying *and documenting* a > particular configuration. XML is great for the former, but is almost > impossible to read easily, particularly for people not used to > working with it. Sure, you could then add something that converts the > XML into a more readable document, but then what is a simple idea is > now becoming very complicated. Secondly, and more importantly, is > that it would mean that LB relies on the existence of an extremely > complex external component, that is out of the control of the LB > community (be it pyRXP, libXML, or whatever). Arguably this is > already the case, since the configuration process uses python, but if > we adopt a new configuration language then the parser can be included > as part of the distribution - making it effectively self-contained. > So in my view the limitations of using XML outweigh any advantages > that might be obtained. > > Regards, > > Greg Greg, Y'know, it's *OK* to say "I just don't like it". :-) I know if Ron & y'all don't *want* to do it it won't get done, which is, again, *OK*. :-) But understanding that I don't seriously expect this to happen in LB, I do sort of want to respin a couple of your points... It's interesting what you say about documentation, because one of the oft-cited primary advantages of XML is that it is self-documenting. Perhaps it takes some getting used to but in the end the meaning of: has got to be at least as clear as pmc altimus/mpc7500 even if it is a bit more longer. Beyond this, the formal specification for an XML document is in the DTD (or schema): an overt, external data file that all code can reference. With a config file of the sort that LB has had thus far, the real specification is embedded in the parser source code, perhaps supplemented by usage notes. Thus it is fairly easy for disconnects to occur not only between the implmentation and the user's understanding thereof, but between the written, external documentation and the implementation. The reliance on an external library is, I would think, something of a red herring. As you point out, there are myriad external libraries that are being relied upon. A yacc/lex implementation relies on the implementation of yacc & lex and all the lexical arcania that come with them. Ron suggested YAPP, which relies on the YAPP project. In the case of PyRXP, that whole thing is GPL'd, so if the project wanted, a version of PyRXP could be frozen into the LB CVS tree. Granted, that could mean fixing it if it turns out to be broken, but that's a separate issue from the one you cited, and is probably not a significantly greater a risk than exists with many other parser generators that could be chosen. The one other thing I'll add is that, while existing LB developers may not be well-versed in XML, the fact is that, industry-wide, XML literacy is growing if not exploding. In the long term, finding people who understand and can work with XML will be no harder, and probably easier, than finding people who can program in C. A custom configuration language, and the code to implement it, will be novel to everyone who encounters it, now and forever. Just my $0.02. --Bob From rminnich at lanl.gov Tue May 20 11:34:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 11:34:00 2003 Subject: config language In-Reply-To: <20030520104553.H21569@www2> Message-ID: ok, Bob, let's do this: send me a pointer to a simple (!) XML parser. Send me if you can a simple example of a simple thing that uses a simple parser. we'll take a look. thanks ron From steve at nexpath.com Tue May 20 11:50:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue May 20 11:50:01 2003 Subject: Reverse engineering In-Reply-To: References: Message-ID: <3ECA4B54.4060000@nexpath.com> ron minnich wrote: > On Tue, 20 May 2003, SONE Takeshi wrote: >>Is it legal to disassemble the proprietary VGA BIOS to learn how to >>enable a particular VGA chip? > > depends on what country you are in. I have no idea of the rules in Japan. > We have avoided doing this type of thing in the US, because we have so > many lawyers here looking for lawsuits to file. Even if it is legal we > felt it was a bad idea. > In America of course, anyone can sue anyone. But it is my understanding most lawyers agree reverse engineering is protected by the fair use doctrine of Title 17, limited by Chap. 12 which is the DMCA. In other words, if it is encrypted, you have to be careful. But I have never seen anyone claim object code was "encrypted". Anyway, I reverse engineer all the time. Highly recommend IDA from www.datarescue.com for disassembly. (Note IANAL). The legal issue that came up in Sony vs. Connectix was the fact that in order to reverse engineer the Sony Playstation BIOS, Connectix had to copy the BIOS repeatedly to a variety of computers. The question was, was this unlawful copying of a copyrighted work. Ultimately the court found that the copying was "fair use" as long as it was "necessary" to create a non-infringing work. The functional aspects of source/object code are not protected by copyright (that is the patent law area), only the specific expression. This is all American law, of course. And, one should note, that even though Connectix won, they went out of business due to legal expenses (as far as I recall). I think that is called being "dead right". -Steve From jarcher at pobox.com Tue May 20 11:54:00 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Tue May 20 11:54:00 2003 Subject: config language Message-ID: <5.2.1.1.2.20030520085333.02de50f8@cybermorph.com> The meaning may be just as clear. But I would argue that it's not as easy for the eye to read. And "altimus/mpc7500" is closer to the environment you are actually trying to debug. It's an include file at the path altimus/mpc7500. Jordan At 10:45 AM 5/20/2003 -0400, Bob Drzyzgula wrote: >On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote: > > > > Hi Bob, > > > > The config language does lend itself to XML, (and it was my first > > thought when Ron suggested a new languge) but I would recommend > > against it for a couple of reasons. The first is that the language > > needs to serve the dual purpose of specifying *and documenting* a > > particular configuration. XML is great for the former, but is almost > > impossible to read easily, particularly for people not used to > > working with it. Sure, you could then add something that converts the > > XML into a more readable document, but then what is a simple idea is > > now becoming very complicated. Secondly, and more importantly, is > > that it would mean that LB relies on the existence of an extremely > > complex external component, that is out of the control of the LB > > community (be it pyRXP, libXML, or whatever). Arguably this is > > already the case, since the configuration process uses python, but if > > we adopt a new configuration language then the parser can be included > > as part of the distribution - making it effectively self-contained. > > So in my view the limitations of using XML outweigh any advantages > > that might be obtained. > > > > Regards, > > > > Greg > >Greg, > >Y'know, it's *OK* to say "I just don't like it". :-) >I know if Ron & y'all don't *want* to do it it won't >get done, which is, again, *OK*. :-) > >But understanding that I don't seriously expect this >to happen in LB, I do sort of want to respin a >couple of your points... > >It's interesting what you say about documentation, because >one of the oft-cited primary advantages of XML is that >it is self-documenting. Perhaps it takes some getting used >to but in the end the meaning of: > > > >has got to be at least as clear as > > pmc altimus/mpc7500 > >even if it is a bit more longer. > >Beyond this, the formal specification for an XML document >is in the DTD (or schema): an overt, external data file >that all code can reference. With a config file of the >sort that LB has had thus far, the real specification is >embedded in the parser source code, perhaps supplemented >by usage notes. Thus it is fairly easy for disconnects to >occur not only between the implmentation and the user's >understanding thereof, but between the written, external >documentation and the implementation. > >The reliance on an external library is, I would think, >something of a red herring. As you point out, there are >myriad external libraries that are being relied upon. A >yacc/lex implementation relies on the implementation of >yacc & lex and all the lexical arcania that come with >them. Ron suggested YAPP, which relies on the YAPP >project. In the case of PyRXP, that whole thing is GPL'd, >so if the project wanted, a version of PyRXP could be >frozen into the LB CVS tree. Granted, that could mean >fixing it if it turns out to be broken, but that's a >separate issue from the one you cited, and is probably not >a significantly greater a risk than exists with many >other parser generators that could be chosen. > >The one other thing I'll add is that, while existing LB >developers may not be well-versed in XML, the fact is that, >industry-wide, XML literacy is growing if not exploding. In >the long term, finding people who understand and can work >with XML will be no harder, and probably easier, than >finding people who can program in C. A custom configuration >language, and the code to implement it, will be novel to >everyone who encounters it, now and forever. > >Just my $0.02. > >--Bob >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Tue May 20 13:02:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 20 13:02:01 2003 Subject: config language In-Reply-To: References: Message-ID: ron minnich writes: > Eric has pointed out to me that we need a tree to properly describe the > new complex systems such as K8. The current config language is not > sufficient to do the job. Several points. 1) Any system with a pci-pci bridge needs this. The more bridges you have the more this shows through. 2) The device config tree will be grafted together with the discovered device tree during device initialization. Which means that a complete inventory of the hardware will be available only after the 2 are merged. The truly cute case will be when we have configuration for devices that are not present. Many boards have things like a scsi option etc. Eric From rminnich at lanl.gov Tue May 20 13:17:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 13:17:01 2003 Subject: config language In-Reply-To: Message-ID: On 20 May 2003, Eric W. Biederman wrote: > 2) The device config tree will be grafted together with > the discovered device tree during device initialization. > Which means that a complete inventory of the hardware will be > available only after the 2 are merged. yes. > The truly cute case will be when we have configuration for devices > that are not present. Many boards have things like a scsi option > etc. Greg thought of that, it's going in there. ron From ebiederman at lnxi.com Tue May 20 13:22:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 20 13:22:00 2003 Subject: config language In-Reply-To: References: Message-ID: prl-linuxbios at sychron.com writes: > Over on etherboot-developers, there has been discussion about encoding a > description of the available NICs in the DHCP request so that an > appropriate image can be chained. This encodes the PCI IDs (and, IIRC > some ISA card names). > > It would be great to have a more general parseable hardware inventory > available via DHCP (which can neatly encapsulate options for this kind > of thing). So, whatever kind of structure you end up with, consider how > a more general purpose tree fits in and how it can be flattened into > DHCP encapsulated options. This is functionality we need in the LinuxBIOS table especially for devices that cannot be detected by the OS. Like temperature sensors. This should be easy to add in the 1.1 development tree. This is information we cannot transmit via DHCP. A DHCP packet is to small. In DHCP we just need enough information to bootstrap. On the same vein I am very tempted after those tables have been implemented to write a version of mkelfImage that will generate a pirq and an mptable from the LinuxBIOS table. Then we can remove that cruft from the LinuxBIOS. Eric From peter at trusteddebian.org Tue May 20 13:27:01 2003 From: peter at trusteddebian.org (Peter Busser) Date: Tue May 20 13:27:01 2003 Subject: How to get technical information? Message-ID: <20030520172157.GA3106@trusteddebian.org> Hi! I'm sorry if this is a FAQ... How does one get technical information from chipset manufacturers? I have searched the SiS and VIA web sites and found no documentation or pointers to documentation whatsoever. Or am I simply not looking well enough? Groetjes, Peter Busser From dkotian3 at vsnl.net Tue May 20 13:28:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Tue May 20 13:28:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? References: Message-ID: <001f01c31ef4$fb9c8be0$313e41db@vsnl.net> Yes, there are 2 of them built into it. One more question, if we the HAVE_PIRQ option is enabled, I have seen some kernel patches to be applied in this case. Could someone explain the significance of it. Regards Deepak ----- Original Message ----- From: "ron minnich" To: "Andrew Ip" Cc: ; Sent: Tuesday, May 20, 2003 6:45 PM Subject: Re: getpir utility for creation of irq tables.c doubt ? > On Tue, 20 May 2003, Andrew Ip wrote: > > > Sometimes you can just trust the value from stock PIRQ table. Some > > boards come with faulty table. > > yes. Deepak, are the two ethernet devices built into the motherboard? > > ron > From rminnich at lanl.gov Tue May 20 13:30:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 13:30:01 2003 Subject: config language In-Reply-To: Message-ID: On 20 May 2003, Eric W. Biederman wrote: > On the same vein I am very tempted after those tables have > been implemented to write a version of mkelfImage that will generate > a pirq and an mptable from the LinuxBIOS table. Then we can > remove that cruft from the LinuxBIOS. yes, and also eliminate error-prone $PIR tables. I am really sick of getting $PIR tables from broken BIOSes. ron From rminnich at lanl.gov Tue May 20 13:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 13:39:00 2003 Subject: How to get technical information? In-Reply-To: <20030520172157.GA3106@trusteddebian.org> Message-ID: On Tue, 20 May 2003, Peter Busser wrote: > How does one get technical information from chipset manufacturers? I have > searched the SiS and VIA web sites and found no documentation or pointers to > documentation whatsoever. Or am I simply not looking well enough? depends. developer.intel.com is a good site. You get about 98% of what you need to do a bios on there, which is about 98% more than many vendors give you. Some examples: Best vendors we've seen on this list: micron. You ask for docs, you get Mbytes of pdf and other info. AMD for the K8 Next best (i.e. you don't get 100 % but if you ask you might) Intel (they've been very good in the last year) SiS (helped write good) VIA (sometimes good, but where is m-epia?) Chipset vendors who have made it clear they have no plans to cooperate, either in written or spoken communications: serverworks Nvidia ron From rminnich at lanl.gov Tue May 20 13:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue May 20 13:41:01 2003 Subject: getpir utility for creation of irq tables.c doubt ? In-Reply-To: <001f01c31ef4$fb9c8be0$313e41db@vsnl.net> Message-ID: On Tue, 20 May 2003, Deepak Kotian wrote: > Yes, there are 2 of them built into it. ok, here's an option. In the mainboard.c file, just the the IRQ line register to the correct value. ron From rsmith at bitworks.com Tue May 20 14:48:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Tue May 20 14:48:01 2003 Subject: How to get technical information? In-Reply-To: <20030520172157.GA3106@trusteddebian.org> References: <20030520172157.GA3106@trusteddebian.org> Message-ID: <3ECA7819.4070603@bitworks.com> Peter Busser wrote: > I'm sorry if this is a FAQ... > > How does one get technical information from chipset manufacturers? I have > searched the SiS and VIA web sites and found no documentation or pointers to > documentation whatsoever. Or am I simply not looking well enough? > Its not. But its a good one to add. If the info isn't available on the web then it probally only accessable by an NDA agreement with the manufacturers. You need to find what sales organization reps the Mfg and then contact them. They can get you in touch with people who can get you the data. While a big PITA an NDA dosn't necessarlly prohibit you from doing LB work with that chipset. Some mfgs allow you to release your source GPL and only hold you to keep an NDA on the documents you used to generate your source code. Some of course don't and require that you can only release binaries which would make them incompatible with LB. I whine to mfg reps about this type stuff all the time. "Why do you guys keep your register docs under NDA and make it so difficult on us to get?" The most common response other than "Well thats just the way we do it." is that if the full register level documentation for a particular chip is aviailable publically then its pretty easy for me to make an exact knockoff of that chip that will be drop in compatible. Sounds like a lot of work but when you are talking big volumes of parts the ammount of $$ at stake are quite large. So if you can make a pin compatible version of say an Intel northbridge and then go hit up Intel customers with a lower price you will probally get a lot of buisness especially if you shave couple dollars off the cost. Placing the register descriptions under NDA makes that much harder and gives them a legal path to stop it should it occur. It sucks and I don't fully agree but I can see the logic. -- Richard A. Smith rsmith at bitworks.com From rsmith at bitworks.com Tue May 20 14:57:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Tue May 20 14:57:01 2003 Subject: How to get technical information? In-Reply-To: References: Message-ID: <3ECA7A28.10408@bitworks.com> ron minnich wrote: > Best vendors we've seen on this list: > micron. You ask for docs, you get Mbytes of pdf and other info. > AMD for the K8 > > Next best (i.e. you don't get 100 % but if you ask you might) > Intel (they've been very good in the last year) Intel is a hit and miss. Like Ron says you just have to ask.. We looked at trying to use the 440MX chipset to replace our 44BX based board and was told that even though Bitworks already has an NDA in place with Arrow (Arrow is our Intel vendor) we were going to have to sigh a extra Double-dog secret NDA for 440MX info. (The 'red' cover agreement rather than the 'yellow' cover agreemnet) and it was very doubtful that any of that stuff would be releaseable under GPL code. So we had to bail and stick with the 440bx which has almost all the info available on the website. -- Richard A. Smith rsmith at bitworks.com From ebiederman at lnxi.com Tue May 20 15:10:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 20 15:10:01 2003 Subject: How to get technical information? In-Reply-To: <3ECA7A28.10408@bitworks.com> References: <3ECA7A28.10408@bitworks.com> Message-ID: Richard Smith writes: > ron minnich wrote: > > > Best vendors we've seen on this list: > > micron. You ask for docs, you get Mbytes of pdf and other info. AMD > > for the K8 > > Next best (i.e. you don't get 100 % but if you ask you might) > > Intel (they've been very good in the last year) > > Intel is a hit and miss. Like Ron says you just have to ask.. We > looked at trying to use the 440MX chipset to replace our 44BX based > board and was told that even though Bitworks already has an NDA in > place with Arrow (Arrow is our Intel vendor) we were going to have to > sigh a extra Double-dog secret NDA for 440MX info. (The 'red' cover > agreement rather than the 'yellow' cover agreemnet) and it was very > doubtful that any of that stuff would be releaseable under GPL code. > So we had to bail and stick with the 440bx which has almost all the > info available on the website. Just to underscore this Intel routinely does not put a couple of registers in their public docs. For which reverse engineering may actually be easier than getting Intels Double-Dog secret NDAs. But actually knowing what is going on always helps. Eric From bari at onelabs.com Tue May 20 20:09:00 2003 From: bari at onelabs.com (Bari Ari) Date: Tue May 20 20:09:00 2003 Subject: Geode Video Xfree86 and VSA Message-ID: <3ECAC3D0.3070808@onelabs.com> Anyone know the current status of running XFree86 on the Geodes? I'm currently looking at working on getting the VSA running on the Geodes as a BLOB. Anyone else started on this yet? --Bari From ollie at sis.com.tw Tue May 20 21:53:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Tue May 20 21:53:01 2003 Subject: Reverse engineering In-Reply-To: <3ECA4B54.4060000@nexpath.com> References: <3ECA4B54.4060000@nexpath.com> Message-ID: <1053481317.1978.3.camel@ollie> On Tue, 2003-05-20 at 23:35, Steve Gehlbach wrote: > ron minnich wrote: > > On Tue, 20 May 2003, SONE Takeshi wrote: > >>Is it legal to disassemble the proprietary VGA BIOS to learn how to > >>enable a particular VGA chip? > > > > depends on what country you are in. I have no idea of the rules in Japan. > > We have avoided doing this type of thing in the US, because we have so > > many lawyers here looking for lawsuits to file. Even if it is legal we > > felt it was a bad idea. > > > > In America of course, anyone can sue anyone. But it is my understanding > most lawyers agree reverse engineering is protected by the fair use > doctrine of Title 17, limited by Chap. 12 which is the DMCA. In other > words, if it is encrypted, you have to be careful. But I have never > seen anyone claim object code was "encrypted". Anyway, I reverse > engineer all the time. Highly recommend IDA from www.datarescue.com for > disassembly. > If you are tracing the code with some kind of debugger rather than disassembly the binary image, does it matter if the image is encrypted ? > > This is all American law, of course. And, one should note, that even > though Connectix won, they went out of business due to legal expenses > (as far as I recall). I think that is called being "dead right". > If Connetix won, why can it ask Sony for the legal expense ? With some additional "punishment" ? -- ollie lho From ollie at sis.com.tw Tue May 20 22:26:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Tue May 20 22:26:00 2003 Subject: debugger In-Reply-To: References: Message-ID: <1053483460.1978.17.camel@ollie> On Fri, 2003-05-16 at 22:27, ron minnich wrote: > On Thu, 15 May 2003, jarcher wrote: > > > It might be helpful in debugging the stuff that get loaded after the core > > BIOS runs. > > I mostly saw it as a useful learning tool for people trying to follow the > code. Can we make the gdb stub reuseable as linuxbios_table or ELF loader stuff ? In this way, both LinuxBIOS and the payload (BLOB ?) can be debugged. -- ollie lho From agnew at cs.umd.edu Tue May 20 22:51:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue May 20 22:51:00 2003 Subject: Reverse engineering In-Reply-To: <1053481317.1978.3.camel@ollie> Message-ID: <20030520225020.J70129-100000@www.missl.cs.umd.edu> On 21 May 2003, ollie lho wrote: > > If you are tracing the code with some kind of debugger rather than > disassembly the binary image, does it matter if the image is encrypted ? > Interesting question. You didn't subvert the encryption, the program decrypted itself! But in the US, i think this would be debatable and would probably boil down too how much you can spend on lawyers... Speaking of such things, has anyone ever seen a license on VGA Roms? More specific than just a copyright i mean? I was considering how one could get past the problem of making commercial solutions when we don't know much about the video chipset. The solution in my mind is to sell the commercial appliance with the linux distro and the default commercial BIOS. On first boot up by the customer, the linux distro extracts the VGA ROM from memory and installs it along with linuxBIOS. Subsequent reboots then would use that VGA blob. This way, the company selling the appliance didn't copy the VGA ROM, it was done by the user. And I would think the user is alright under fair use? Is my logic faulty? > > > > > This is all American law, of course. And, one should note, that even > > though Connectix won, they went out of business due to legal expenses > > (as far as I recall). I think that is called being "dead right". > > > > If Connetix won, why can it ask Sony for the legal expense ? With > some additional "punishment" ? > Don't lose any sleep worrying about what happened to Connectix. http://www.connectix.com/about/acquisition_win.html ------------------ Adam Agnew Independent Contractor www.adamagnew.com From bari at onelabs.com Tue May 20 23:03:00 2003 From: bari at onelabs.com (Bari Ari) Date: Tue May 20 23:03:00 2003 Subject: Reverse engineering References: <20030520225020.J70129-100000@www.missl.cs.umd.edu> Message-ID: <3ECAEC97.7060306@onelabs.com> Adam Agnew wrote: >Speaking of such things, has anyone ever seen a license on VGA Roms? More >specific than just a copyright i mean? > > > If you're buying the VGA controller the vendor gives the OEM a VGA BIOS along with the silicon. If you're an end user they generally don't want to spend any time supporting you. --Bari From ebiederman at lnxi.com Tue May 20 23:56:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue May 20 23:56:01 2003 Subject: Reverse engineering In-Reply-To: References: Message-ID: ron minnich writes: > On Tue, 20 May 2003, SONE Takeshi wrote: > > > Is it legal to disassemble the proprietary VGA BIOS to learn how to > > enable a particular VGA chip? > > depends on what country you are in. I have no idea of the rules in Japan. > We have avoided doing this type of thing in the US, because we have so > many lawyers here looking for lawsuits to file. Even if it is legal we > felt it was a bad idea. Also it is much more productive (in general) to just look at the registers and see how they get set. And extrapolate the meaning of the registers from there. On the same scale you can usually capture the same information with some kind of ICE so you do not need to disassemble the code. Eric From bari at onelabs.com Wed May 21 00:23:00 2003 From: bari at onelabs.com (Bari Ari) Date: Wed May 21 00:23:00 2003 Subject: Geode Video Xfree86 and VSA References: <3ECAC3D0.3070808@onelabs.com> Message-ID: <3ECAFF5D.1040202@onelabs.com> Bari Ari wrote: > Anyone know the current status of running XFree86 on the Geodes? Just to clarify. I meant under ADLO or using LinuxBIOS. > > I'm currently looking at working on getting the VSA running on the > Geodes as a BLOB. Anyone else started on this yet? > > --Bari > From ts1 at tsn.or.jp Wed May 21 01:03:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Wed May 21 01:03:00 2003 Subject: VIA Eden BIOS interchangeable? In-Reply-To: <20030520113101.GA4922@localhost> References: <20030520113101.GA4922@localhost> Message-ID: <20030521050210.GA21228@tsn.or.jp> On Tue, May 20, 2003 at 01:31:01PM +0200, Rene Caspari wrote: > i want to buy a VIA Epia V5000 Motherboard. > > Do you know wether i can use this board to install another BIOS-Chip > and finally install Linuxbios? I have EPIA 5000 (not V series) and its BIOS is socketed so it can be replaced. I think V5000 is same but I'm not sure. I use BIOS Savior (RD1-PL) and highly recommend it. -- Takeshi From ts1 at tsn.or.jp Wed May 21 01:08:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Wed May 21 01:08:01 2003 Subject: EPIA + CONFIG_VGABIOS works Message-ID: <20030521050800.GB21228@tsn.or.jp> Today I tried CONFIG_VGABIOS. After a little bit of config hassle and fix to compile error, it just worked. Now I don't have to use ADLO. I put VGA BIOS in flash rather than enablnig PCI option ROM (it was just 0xFF 0xFF..). I like this code, it is great development. I should have tried this one first. -- Takeshi From steve at nexpath.com Wed May 21 01:33:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed May 21 01:33:01 2003 Subject: Reverse engineering In-Reply-To: <1053481317.1978.3.camel@ollie> References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> Message-ID: <3ECB133A.1000801@nexpath.com> ollie lho wrote: > > If you are tracing the code with some kind of debugger rather than > disassembly the binary image, does it matter if the image is encrypted ? I guess it depends on why it is encrypted, and why you are tracing it. Encryption for copy protection, and access protection (ie movies and e-books), is covered by the DMCA. The language of the law is "circumvention", which basically means getting around the protection mechanism, and I don't think it matters how you do that, tracing, decrypting, whatever. There is an exception for reverse engineering for the purpose of developing interoperable software. For the case of a BIOS, one is developing interoperable software so it seems to be an exception, if the BIOS is encrypted (as in the Xbox). But of course, IANAL. -Steve From steve at nexpath.com Wed May 21 01:36:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed May 21 01:36:00 2003 Subject: Reverse engineering In-Reply-To: <20030520225020.J70129-100000@www.missl.cs.umd.edu> References: <20030520225020.J70129-100000@www.missl.cs.umd.edu> Message-ID: <3ECB1418.7090001@nexpath.com> Adam Agnew wrote: > Don't lose any sleep worrying about what happened to Connectix. > http://www.connectix.com/about/acquisition_win.html > Sounds like the reports of Connectix' demise were greatly exaggerated. I guess my info or memory was incorrect. -Steve From peter at trusteddebian.org Wed May 21 03:12:01 2003 From: peter at trusteddebian.org (Peter Busser) Date: Wed May 21 03:12:01 2003 Subject: Reverse engineering In-Reply-To: <3ECB133A.1000801@nexpath.com> References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> <3ECB133A.1000801@nexpath.com> Message-ID: <20030521070620.GA6835@trusteddebian.org> Hi! > >If you are tracing the code with some kind of debugger rather than > >disassembly the binary image, does it matter if the image is encrypted ? > I guess it depends on why it is encrypted, and why you are tracing it. > Encryption for copy protection, and access protection (ie movies and > e-books), is covered by the DMCA. While talking about the DMCA. If you violate the DMCA outside the US and this violation for whatever reason hurts the US interests, you can be prosecuted in the US whenever you enter US teritory. And it is a criminal offense too. So you might end up in jail when you are prosecuted. Groetjes, Peter Busser From peter at trusteddebian.org Wed May 21 03:14:01 2003 From: peter at trusteddebian.org (Peter Busser) Date: Wed May 21 03:14:01 2003 Subject: Reverse engineering In-Reply-To: References: Message-ID: <20030521070916.GB6835@trusteddebian.org> Hi! > Also it is much more productive (in general) to just look at the > registers and see how they get set. And extrapolate the meaning of > the registers from there. > > On the same scale you can usually capture the same information > with some kind of ICE so you do not need to disassemble the code. An in-circuit emulator is expensive, right? Is it also possible to do this using something like Bochs? Groetjes, Peter Busser From ollie at sis.com.tw Wed May 21 03:23:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed May 21 03:23:00 2003 Subject: Reverse engineering In-Reply-To: <3ECB133A.1000801@nexpath.com> References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> <3ECB133A.1000801@nexpath.com> Message-ID: <1053501145.1978.20.camel@ollie> On Wed, 2003-05-21 at 13:48, Steve Gehlbach wrote: > ollie lho wrote: > > > > > If you are tracing the code with some kind of debugger rather than > > disassembly the binary image, does it matter if the image is encrypted ? > > I guess it depends on why it is encrypted, and why you are tracing it. > Encryption for copy protection, and access protection (ie movies and > e-books), is covered by the DMCA. The language of the law is > "circumvention", which basically means getting around the protection > mechanism, and I don't think it matters how you do that, tracing, > decrypting, whatever. There is an exception for reverse engineering for > the purpose of developing interoperable software. For the case of a > BIOS, one is developing interoperable software so it seems to be an > exception, if the BIOS is encrypted (as in the Xbox). > Then why a DVD player with DeCSS not a "interoperatable" software ? -- ollie lho From ollie at sis.com.tw Wed May 21 03:48:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed May 21 03:48:01 2003 Subject: Reverse engineering In-Reply-To: <20030521070916.GB6835@trusteddebian.org> References: <20030521070916.GB6835@trusteddebian.org> Message-ID: <1053502350.1978.26.camel@ollie> On Wed, 2003-05-21 at 15:09, Peter Busser wrote: > Hi! > > > Also it is much more productive (in general) to just look at the > > registers and see how they get set. And extrapolate the meaning of > > the registers from there. > > > > On the same scale you can usually capture the same information > > with some kind of ICE so you do not need to disassemble the code. > > An in-circuit emulator is expensive, right? Is it also possible to do this > using something like Bochs? > If you are only interested in those IO ports, an logic analyzer is probably better and easier to use. Modern LA can be programmed to log/filter various IO scenario. -- ollie lho From peter at trusteddebian.org Wed May 21 04:17:01 2003 From: peter at trusteddebian.org (Peter Busser) Date: Wed May 21 04:17:01 2003 Subject: Reverse engineering In-Reply-To: <1053502350.1978.26.camel@ollie> References: <20030521070916.GB6835@trusteddebian.org> <1053502350.1978.26.camel@ollie> Message-ID: <20030521081210.GA6934@trusteddebian.org> Hi! > If you are only interested in those IO ports, an logic analyzer is > probably better and easier to use. Modern LA can be programmed to > log/filter various IO scenario. It's probably a bit expensive to buy an LA or ICE or any other specialised hardware just to get a board going. So I thought it might be possible to use Bochs to do the job instead. But maybe I'm mistaken. Groetjes, Peter Busser From aip at cwlinux.com Wed May 21 04:35:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed May 21 04:35:00 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: <20030521050800.GB21228@tsn.or.jp>; from SONE Takeshi on Wed, May 21, 2003 at 02:08:00PM +0900 References: <20030521050800.GB21228@tsn.or.jp> Message-ID: <20030521163431.A16891@mail.cwlinux.com> Takeshi, > Today I tried CONFIG_VGABIOS. > After a little bit of config hassle and fix to compile error, > it just worked. > Now I don't have to use ADLO. > I put VGA BIOS in flash rather than enablnig PCI option ROM > (it was just 0xFF 0xFF..). Cool. May I have your config and patch? I would like to try. Thanks. GOOD JOB!!! -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From xpegenaute at telepolis.es Wed May 21 04:56:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Wed May 21 04:56:01 2003 Subject: brun_mtd Message-ID: <3ECB4C50.4030402@telepolis.es> Hello, In the script of src/util/mtd/burn_mtd there are these lines .. - dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block With this we if exist we don't trunc and fix the size of vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until this size. - dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block The same but with 63k. - dd conv=notrunc if=docipl of=/dev/mtd0 We write without trunc /dev/mtd0 with the source of docipl. - dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 The same but this time we skip 1 block of "bs" (i supose that we can remind the value of bs in the last line, then sizeof(docipl) ). - dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 Without trunc we write linuxbios.block to mtd, skipping 2 times the last size (sizeof(docipl) ). - dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 Now without trunc write vmlinux skipping 128 times the size of linuxbios.block. My questions, are: Why we write two times docipl ? And why we skip 128 times the size of linuxbios.block ? (i supose that i'm wrong, any one can help me with these) Thanks a lot for your patience. Xavi. From christer at weinigel.se Wed May 21 05:01:01 2003 From: christer at weinigel.se (Christer Weinigel) Date: Wed May 21 05:01:01 2003 Subject: Geode Video Xfree86 and VSA In-Reply-To: <3ECAC3D0.3070808@onelabs.com> References: <3ECAC3D0.3070808@onelabs.com> Message-ID: Bari Ari writes: > Anyone know the current status of running XFree86 on the Geodes? I did get XFree86 3.something running fine on a GX1 + CS5530 with Linxbios using the Geode Framebuffer driver to set up the display and then just using the unaccelerated XF86_FBDev. On the SC2200 XFree86 did not work, but that's because XFree86 tries to mess with the keyboard controller directly and then hangs in a loop waiting for the keyboard controller to stop being busy. Fix that problem in XFree86 and it should be no problem. I haven't tried the accelerated geode drivers. > I'm currently looking at working on getting the VSA running on the > Geodes as a BLOB. Anyone else started on this yet? I've just looked briefly at it, but if I remember correctly, what's needed is to copy the VSA BIOS to ram somewhere below 640k (since it should be started in real mode) and then jumped into. The BIOS has to provide a few INT 15h functions to report the current memory size. There might be some additional restraints such as only certain base addresses working (since only XpressROM/Insyde use this) or that the VSA code relies on a certain layout of the rest of the BIOS in ROM. Famous last words: how hard can it be :) /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel http://www.weinigel.se From noshel at idis.co.kr Wed May 21 06:40:00 2003 From: noshel at idis.co.kr (=?ks_c_5601-1987?B?RWR3YXJkIExlZSBcKMDMwOW/+Fwp?=) Date: Wed May 21 06:40:00 2003 Subject: [linuxBios] HDD init problem References: Message-ID: <002501c31f85$3393edf0$525deecb@noshel> gee, are you mentioning disk_init() in pcbios.S ? I just took a look at it, and I had to close the file because it was in asm! (I'm really scared of asm, you see..) When your done, I hope I could get a copy, badly :) good luck! Ed ----- Original Message ----- From: "Greg Watson" To: Sent: Tuesday, May 20, 2003 10:38 PM Subject: Re: [linuxBios] HDD init problem > Ron is right, I'm in the process of retrofitting the etherboot-5.1.8 > IDE driver into LB. I can't get the standard IDE driver to even > recognize my controller. > > Greg > > At 6:55 AM -0600 20/5/03, ron minnich wrote: > >I think Greg Watson is porting a decent IDE driver to LinuxBIOS from > >Etherboot. The one in LinuxBIOS is not quite right. > > > >ron > > > >_______________________________________________ > >Linuxbios mailing list > >Linuxbios at clustermatic.org > >http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From adam at cfar.umd.edu Wed May 21 08:56:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Wed May 21 08:56:00 2003 Subject: Reverse engineering In-Reply-To: <20030521081210.GA6934@trusteddebian.org> Message-ID: <20030521090305.B70670-100000@www.missl.cs.umd.edu> > > If you are only interested in those IO ports, an logic analyzer is > > probably better and easier to use. Modern LA can be programmed to > > log/filter various IO scenario. > > It's probably a bit expensive to buy an LA or ICE or any other specialised > hardware just to get a board going. So I thought it might be possible to use > Bochs to do the job instead. But maybe I'm mistaken. The problem with bochs is that it is not just "any hardware" but they attempt to emulate Intel 440LX (IIRC). So if you put here an standard bios I would expect it to complain a lot. Of course it is still better than nothing and I believe there are people on the list which went this track before. Actualy it was other way around with getting LinuxBIOS bios to run under BOCHS IIRC. While I myself hadn't used BOCHS to this purpose I have used Wine on regular basic, and I was able to *easily* track IO ports for communication between ChipWriter software and the ChipWriter hardware itself. Just my two bits. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From pyro at linuxlabs.com Wed May 21 09:32:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed May 21 09:32:01 2003 Subject: brun_mtd In-Reply-To: <3ECB4C50.4030402@telepolis.es> Message-ID: Greetings, The DoC has hardware support for a 512B boot plock. On powerup, it loads the first block into a block that 'just happens' to map the end of the block at 0xf000:0xfff0. If the first block has an ECC error, the second block is copied instead (so two copies of docipl). IIRC, the seek=128 is used so that two copies of LinuxBIOS can be stored, one as a fallback image though full support for that never got implemented in the older boards. G'day, sjames On Wed, 21 May 2003, Xavier Pegenaute wrote: > Hello, > > In the script of src/util/mtd/burn_mtd there are these lines .. > > - dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block > With this we if exist we don't trunc and fix the size of > vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until > this size. > > - dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block > The same but with 63k. > > - dd conv=notrunc if=docipl of=/dev/mtd0 > We write without trunc /dev/mtd0 with the source of docipl. > > - dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 > The same but this time we skip 1 block of "bs" (i supose that we can > remind the value of bs in the last line, then sizeof(docipl) ). > > - dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 > Without trunc we write linuxbios.block to mtd, skipping 2 times the last > size (sizeof(docipl) ). > > - dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 > Now without trunc write vmlinux skipping 128 times the size of > linuxbios.block. > > > My questions, are: > > Why we write two times docipl ? > And why we skip 128 times the size of linuxbios.block ? (i supose that > i'm wrong, any one can help me with these) > > > Thanks a lot for your patience. > Xavi. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bob at drzyzgula.org Wed May 21 09:51:01 2003 From: bob at drzyzgula.org (Bob Drzyzgula) Date: Wed May 21 09:51:01 2003 Subject: config language In-Reply-To: References: <20030520104553.H21569@www2> Message-ID: <20030521095102.A6357@www2> I'll be tied up with some other stuff for a day or two, but I'll get back to you with something. Warning, though: If you really want it in XSD, it's less "simple" pretty much by definition. :-) --Bob On Tue, May 20, 2003 at 09:31:53AM -0600, ron minnich wrote: > > ok, Bob, let's do this: > > send me a pointer to a simple (!) XML parser. > > Send me if you can a simple example of a simple thing that uses a simple > parser. > > we'll take a look. > > thanks > > ron From jarcher at pobox.com Wed May 21 10:03:01 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Wed May 21 10:03:01 2003 Subject: debugger Message-ID: <5.2.1.1.2.20030521070250.02faa5c0@cybermorph.com> I'm going to look at doing that over the next week or so. Jordan At 10:17 AM 5/21/2003 +0800, ollie lho wrote: >On Fri, 2003-05-16 at 22:27, ron minnich wrote: > > On Thu, 15 May 2003, jarcher wrote: > > > > > It might be helpful in debugging the stuff that get loaded after the > core > > > BIOS runs. > > > > I mostly saw it as a useful learning tool for people trying to follow the > > code. > >Can we make the gdb stub reuseable as linuxbios_table or ELF loader >stuff ? In this way, both LinuxBIOS and the payload (BLOB ?) can be >debugged. > >-- >ollie lho From bari at onelabs.com Wed May 21 10:14:00 2003 From: bari at onelabs.com (Bari Ari) Date: Wed May 21 10:14:00 2003 Subject: Geode Video Xfree86 and VSA References: <3ECAC3D0.3070808@onelabs.com> Message-ID: <3ECB89CF.3080601@onelabs.com> Christer Weinigel wrote: >I've just looked briefly at it, but if I remember correctly, what's >needed is to copy the VSA BIOS to ram somewhere below 640k (since it >should be started in real mode) and then jumped into. The BIOS has to >provide a few INT 15h functions to report the current memory size. >There might be some additional restraints such as only certain base >addresses working (since only XpressROM/Insyde use this) or that the >VSA code relies on a certain layout of the rest of the BIOS in ROM. > > > That's why I was looking at possibly getting BOCHS to work with VSA for the INT 15 functions. Having full graphics and the audio up on the SCx2xx for embedded apps would be nice. --Bari From prl-linuxbios at sychron.com Wed May 21 11:04:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Wed May 21 11:04:00 2003 Subject: config language In-Reply-To: Your message of "20 May 2003 11:27:53 MDT." Message-ID: > This is functionality we need in the LinuxBIOS table especially > for devices that cannot be detected by the OS. Like temperature > sensors. This should be easy to add in the 1.1 development tree. > > This is information we cannot transmit via DHCP. A DHCP packet > is to small. In DHCP we just need enough information to bootstrap. I was not suggesting that the tables must of necessity all be munged into a DHCP packet, though I observe that with a reasonable encoding, most descriptions probably *would* fit in a single DHCP options field of 312 bytes. In practise I agree that one would use only those parts which were relevant to (network) booting in a real DHCP packet. But... reading through the recent discussions about XML, it took me some time to release that people were talking about parsing IN LinuxBIOS, as opposed using XML as an input file to a build or config process. XML or similar in LinuxBIOS itself seems like overkill to me. Please consider using DHCP encapsulated option format as an internal format for LinuxBIOS in the first instance, even if DHCP (the protocol) is not used. I see several reasons... - Compatibility with the DHCP protocol OK, I understand that not everything wants to use DHCP for network configuration, but even the most ardent boot-from-the-bare-metal embedded fan must appreciate that many do use DHCP, even if only for testing code via DHCP / TFTP before a final product is burned in. Or, put another way, why would you make a *point* of being different? - Code exists DHCP option parsing code exists in Etherboot (so Etherboot-on-LinuxBIOS users have it anyway). As I say, a hardware description has been discussed (and I *think* implemented) in Etherboot in the particular case of PCI nics. - Compact parser and encoding DHCP hardware descriptions (i.e. individual chipsets) should be encoded numerically. There are reasons why existing DHCP options and SNMP MIBs do it this way - 32 bits encodes a HELL of a lot of possible hardware types in only 4 bytes. Doubtless someone will tell me that DHCP isn't the most efficient method or that they have a *really* neat parser for their favourite format. Big deal - refer to "Code exists". - Do the hard stuff outside LinuxBIOS Register the encodings centrally held table (like other DHCP options or an SNMP MIB), so that when building, tables can be built as appropriate from XML definitions. A DHCP server or a small amount of perl in the build process can translate raw numbers to and from human readable form using boilerplate derived from the central table. Where possible (e.g. PCI IDs), use an existing registry anyway. From xpegenaute at telepolis.es Wed May 21 11:17:00 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Wed May 21 11:17:00 2003 Subject: ADLO In-Reply-To: References: Message-ID: <3ECBA59A.5070909@telepolis.es> steven james wrote: >For the most part, the 630ET chipset is compatible with the 630. The big >difference I have seen is that the builtin sis900 ethernet gets it's MAC >address from CMOS rather than a seperate EEPROM. The following code >fragment demonstrates: > > Do you know if there is some patch for this ? Thanks. Xavi. From aip at cwlinux.com Wed May 21 11:18:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed May 21 11:18:00 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030517180920.GA813@tsn.or.jp>; from SONE Takeshi on Sun, May 18, 2003 at 03:09:20AM +0900 References: <20030516100322.GB4283@cma.co.jp> <20030517180920.GA813@tsn.or.jp> Message-ID: <20030521231809.A20957@mail.cwlinux.com> Takeshi, > I think I solved the problem now! > Now my code automatically detects DIMM presence, size, and MA mapping > type correctly for my 3 different types of DIMMs, in whichever slot, > or any combination of these DIMMs. > I'll do some cleanups and extensive test using memtest86, > then post the patch. I'm just testing your latest code here with LinuxBIOS + ADLO. It is able to start VGA and grub sometimes, but not all the time. FYI, I'm running EPIA with IDE to CF adapter. It maybe related to memory again. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From steve at nexpath.com Wed May 21 11:27:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed May 21 11:27:01 2003 Subject: Reverse engineering In-Reply-To: <1053501145.1978.20.camel@ollie> References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> <3ECB133A.1000801@nexpath.com> <1053501145.1978.20.camel@ollie> Message-ID: <3ECB9BC5.9070204@nexpath.com> ollie lho wrote: > Then why a DVD player with DeCSS not a "interoperatable" software ? > Ah, yes, a very good question. This was answered by Judge Kaplan in the DeCSS decision (Universal City v. Reimerdes, US District Court, So. District of NY). The reason is that the US legislature (apparently) only intended the reverse engineering exception to apply to interoperating with _software_, not movies. So it only applies to software (at least in the Judge's opinion, which counts in NY and probably everywhere else until a higher court says differently). Which, among a whole bunch of other reasons, is why Eric Corley lost the case. The prosecution of Jon Johansen still goes on today AFAIK in Norway. -Steve From xpegenaute at telepolis.es Wed May 21 11:58:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Wed May 21 11:58:01 2003 Subject: brun_mtd In-Reply-To: References: Message-ID: <3ECBAF32.9040405@telepolis.es> steven james wrote: >The DoC has hardware support for a 512B boot plock. On powerup, it loads >the first block into a block that 'just happens' to map the end of the >block at 0xf000:0xfff0. If the first block has an ECC error, the second >block is copied instead (so two copies of docipl). >IIRC, the seek=128 is used so that two copies of LinuxBIOS can be stored, >one as a fallback image though full support for that never got implemented >in the older boards. > > Ok, then if i want make a memory map of a eeprom, it will be like this: 0-511 (0x0 - 0x1FF) docipl 512 Bytes 512-1023 (0x200 - 0x3FF) docipl (security copy) 512 Bytes 1024-65535 (0x400 - 0xFFFF) linuxbios.block 64512 Bytes 65536-8323071 (0x10000 - 0x7EFFFF) Free Space 8257536 Bytes = 128x64512 8323072-9109503 (0x7F0000 - 0x8AFFFF) vmlinux.bin.gz.block 786432 Bytes Then also if im'not wrong, when we make the reset EEPROM 0x0 - 0xFFFF is mapped to the top of memory addres space 0xFFFF0000 - 0xFFFFFFFF, and then the start point 0xFFFFFFF0 is visible in linuxbios.block. If this is right, sorry but i didn't find the jump into the code of docipl, i suposed that the initial label is "sis630spd_start:" in ipl.S., any one know where is the jump ? Regards. Xavi. >>Hello, >> >>In the script of src/util/mtd/burn_mtd there are these lines .. >> >>- dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block >>With this we if exist we don't trunc and fix the size of >>vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until >>this size. >> >>- dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block >>The same but with 63k. >> >>- dd conv=notrunc if=docipl of=/dev/mtd0 >>We write without trunc /dev/mtd0 with the source of docipl. >> >>- dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 >>The same but this time we skip 1 block of "bs" (i supose that we can >>remind the value of bs in the last line, then sizeof(docipl) ). >> >>- dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 >>Without trunc we write linuxbios.block to mtd, skipping 2 times the last >>size (sizeof(docipl) ). >> >>- dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 >>Now without trunc write vmlinux skipping 128 times the size of >>linuxbios.block. >> >> >>My questions, are: >> >>Why we write two times docipl ? >>And why we skip 128 times the size of linuxbios.block ? (i supose that >>i'm wrong, any one can help me with these) >> >> >> From stepan at suse.de Wed May 21 12:27:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed May 21 12:27:00 2003 Subject: AMD Sledge Hammer In-Reply-To: References: <20030516165915.A18037@mail.cwlinux.com> Message-ID: <20030521162654.GC23052@suse.de> * Eric W. Biederman [030516 22:45]: > Andrew Ip writes: > > > Does anyone know what is the statue of AMD Hammer? I have seen > > it in freebios2, but would like to know how far it is from being > > stable? Thanks. > > The code works, for a subset of cases but it has a way to go before > it is production grade code. > > I believe there is an AMD sponsored port going on at SuSe. But I they > guys I was working with have grown mysteriously silent. SuSE (note spelling ;-) is working on LinuxBIOS for AMD Opteron. We have a number of sponsors for the work. We have had early access to the AMD documentation (even before it was public) and were allowed to use it because we had to deal with similar confidentiality issues when we did the 64-bit Linux port. Currently you haven't heard much from us since we're facing some severe problems with IOAPIC and local APIC initialization as well as booting SMP machines and like to get this working first. > As for me I am busy working on it, which means there will be a solid > port eventually. Eric did a really great job and without him the freebios2 port would be nowhere close to where it is now. I'm positive that I can provide the missing pieces shortly. Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From steve at nexpath.com Wed May 21 12:29:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed May 21 12:29:00 2003 Subject: Reverse engineering In-Reply-To: <3ECB9BC5.9070204@nexpath.com> References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> <3ECB133A.1000801@nexpath.com> <1053501145.1978.20.camel@ollie> <3ECB9BC5.9070204@nexpath.com> Message-ID: <3ECBAAA1.5020107@nexpath.com> Steve Gehlbach wrote: > ollie lho wrote: > >> Then why a DVD player with DeCSS not a "interoperatable" software ? >> > > The reason is that the US legislature (apparently) > only intended the reverse engineering exception to apply to > interoperating with _software_, not movies. I was working from memory here, and it has been pointed out to me that the final DeCSS decision does not state this. I don't recall where I read this, maybe it was an interim opinion, maybe I have it completely wrong. So to be very accurate, you should read the final DeCSS opinion yourself: http://news.findlaw.com/hdocs/docs/dvd/dvdopinion.pdf. -Steve From pyro at linuxlabs.com Wed May 21 12:48:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed May 21 12:48:01 2003 Subject: brun_mtd In-Reply-To: <3ECBAF32.9040405@telepolis.es> Message-ID: Greetings, At the end of ipl.S, reset_vector: .byte 0xea .word 0x0000, DOC_WIN_SEG is the jmp instruction hand assembled. G'day, sjames On Wed, 21 May 2003, Xavier Pegenaute wrote: > steven james wrote: > > >The DoC has hardware support for a 512B boot plock. On powerup, it loads > >the first block into a block that 'just happens' to map the end of the > >block at 0xf000:0xfff0. If the first block has an ECC error, the second > >block is copied instead (so two copies of docipl). > >IIRC, the seek=128 is used so that two copies of LinuxBIOS can be stored, > >one as a fallback image though full support for that never got implemented > >in the older boards. > > > > > Ok, then if i want make a memory map of a eeprom, it will be like this: > 0-511 (0x0 - 0x1FF) docipl 512 Bytes > 512-1023 (0x200 - 0x3FF) docipl (security copy) 512 Bytes > 1024-65535 (0x400 - 0xFFFF) linuxbios.block 64512 Bytes > 65536-8323071 (0x10000 - 0x7EFFFF) Free Space 8257536 Bytes = 128x64512 > 8323072-9109503 (0x7F0000 - 0x8AFFFF) vmlinux.bin.gz.block 786432 Bytes > > Then also if im'not wrong, when we make the reset EEPROM 0x0 - 0xFFFF is > mapped to the top of memory addres space 0xFFFF0000 - 0xFFFFFFFF, and > then the start point 0xFFFFFFF0 is visible in linuxbios.block. > > If this is right, sorry but i didn't find the jump into the code of > docipl, i suposed that the initial label is "sis630spd_start:" in > ipl.S., any one know where is the jump ? > > Regards. > Xavi. > > >>Hello, > >> > >>In the script of src/util/mtd/burn_mtd there are these lines .. > >> > >>- dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block > >>With this we if exist we don't trunc and fix the size of > >>vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until > >>this size. > >> > >>- dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block > >>The same but with 63k. > >> > >>- dd conv=notrunc if=docipl of=/dev/mtd0 > >>We write without trunc /dev/mtd0 with the source of docipl. > >> > >>- dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 > >>The same but this time we skip 1 block of "bs" (i supose that we can > >>remind the value of bs in the last line, then sizeof(docipl) ). > >> > >>- dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 > >>Without trunc we write linuxbios.block to mtd, skipping 2 times the last > >>size (sizeof(docipl) ). > >> > >>- dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 > >>Now without trunc write vmlinux skipping 128 times the size of > >>linuxbios.block. > >> > >> > >>My questions, are: > >> > >>Why we write two times docipl ? > >>And why we skip 128 times the size of linuxbios.block ? (i supose that > >>i'm wrong, any one can help me with these) > >> > >> > >> > > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bari at onelabs.com Wed May 21 12:50:01 2003 From: bari at onelabs.com (Bari Ari) Date: Wed May 21 12:50:01 2003 Subject: Reverse engineering References: <3ECA4B54.4060000@nexpath.com> <1053481317.1978.3.camel@ollie> <3ECB133A.1000801@nexpath.com> <1053501145.1978.20.camel@ollie> <3ECB9BC5.9070204@nexpath.com> <3ECBAAA1.5020107@nexpath.com> Message-ID: <3ECBAE6F.3090407@onelabs.com> Steve Gehlbach wrote: > Steve Gehlbach wrote: > >> ollie lho wrote: >> >>> Then why a DVD player with DeCSS not a "interoperatable" software ? >>> >> >> The reason is that the US legislature (apparently) >> only intended the reverse engineering exception to apply to >> interoperating with _software_, not movies. > > > I was working from memory here, and it has been pointed out to me that > the final DeCSS decision does not state this. I don't recall where I > read this, maybe it was an interim opinion, maybe I have it completely > wrong. So to be very accurate, you should read the final DeCSS > opinion yourself: http://news.findlaw.com/hdocs/docs/dvd/dvdopinion.pdf. This has moved up to the Supreme Court. Lots of links are here: http://news.com.com/2100-1023-978985.html?tag=fd_top -Bari From rminnich at lanl.gov Wed May 21 16:42:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 21 16:42:00 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: <20030521050800.GB21228@tsn.or.jp> Message-ID: On Wed, 21 May 2003, SONE Takeshi wrote: > I like this code, it is great development. > I should have tried this one first. well, you made my day ... we grabbed that from x11 and then fixed the errors in the emulator. Can you please write up a HOWTO for epi and vgabios? thanks ron From ollie at sis.com.tw Thu May 22 00:54:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Thu May 22 00:54:01 2003 Subject: config language In-Reply-To: References: Message-ID: <1053577043.1978.38.camel@ollie> On Wed, 2003-05-21 at 23:03, prl-linuxbios at sychron.com wrote: > > But... reading through the recent discussions about XML, it took me some > time to release that people were talking about parsing IN LinuxBIOS, as > opposed using XML as an input file to a build or config process. XML or > similar in LinuxBIOS itself seems like overkill to me. > Maybe I can not read English. Are we really talking about parsing XML in LinuxBIOS rather than "config" tool ? -- ollie lho From ollie at sis.com.tw Thu May 22 01:01:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Thu May 22 01:01:01 2003 Subject: brun_mtd In-Reply-To: References: Message-ID: <1053576732.1978.35.camel@ollie> On Wed, 2003-05-21 at 21:31, steven james wrote: > Greetings, > > The DoC has hardware support for a 512B boot plock. On powerup, it loads > the first block into a block that 'just happens' to map the end of the > block at 0xf000:0xfff0. If the first block has an ECC error, the second > block is copied instead (so two copies of docipl). > > > On Wed, 21 May 2003, Xavier Pegenaute wrote: > > > Hello, > > > > In the script of src/util/mtd/burn_mtd there are these lines .. > > > > - dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block > > With this we if exist we don't trunc and fix the size of > > vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until > > this size. > > > > - dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block > > The same but with 63k. > > > > - dd conv=notrunc if=docipl of=/dev/mtd0 > > We write without trunc /dev/mtd0 with the source of docipl. > > > > - dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 > > The same but this time we skip 1 block of "bs" (i supose that we can > > remind the value of bs in the last line, then sizeof(docipl) ). > > > > - dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 > > Without trunc we write linuxbios.block to mtd, skipping 2 times the last > > size (sizeof(docipl) ). > > > > - dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 > > Now without trunc write vmlinux skipping 128 times the size of > > linuxbios.block. > > > > > > My questions, are: > > > > Why we write two times docipl ? First of all, you are way wrong with what seek=# means. It skips # of (output) blocks of the output device. It has nothing to do with sizeof(some image). Please man dd for detail. There are two copies for IPL one at offset 0 the other at offset 512B (seek=1). > > And why we skip 128 times the size of linuxbios.block ? (i supose that > > i'm wrong, any one can help me with these) > > The size of linuxbios.block is 63kB plus the 2 copies of IPL == 64kB == 128 blocks. -- ollie lho From ts1 at cma.co.jp Thu May 22 03:41:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 22 03:41:00 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: <20030521163431.A16891@mail.cwlinux.com> References: <20030521050800.GB21228@tsn.or.jp> <20030521163431.A16891@mail.cwlinux.com> Message-ID: <20030522074024.GA1760@cma.co.jp> On Wed, May 21, 2003 at 04:34:31PM +0800, Andrew Ip wrote: > Cool. May I have your config and patch? I would like to try. > Thanks. GOOD JOB!!! Here you are. In addition to it you need my vgainit.inc from previous patch. Ron, please look at the fix to pcibios.c. I'm not very sure it is correct. Note that I'm booting linux with BOOT_IDE, which is believed to be unstable. For me, I could never get it past the verify code in elfboot.c. It should be problem in either binutils or IDE driver, but for now I just commented out the verify code and it's working fine for me. Maybe I can have Etherboot+VGABIOS as payload, but I just don't know how to do it in the config file. -- Takeshi From ts1 at cma.co.jp Thu May 22 03:43:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 22 03:43:00 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: <20030521163431.A16891@mail.cwlinux.com> References: <20030521050800.GB21228@tsn.or.jp> <20030521163431.A16891@mail.cwlinux.com> Message-ID: <20030522074318.GB1760@cma.co.jp> Sorry, forgot to attach the files! -- Takeshi -------------- next part -------------- diff -urN freebios-cvs/src/arch/i386/lib/vgabios.c freebios-vgabios/src/arch/i386/lib/vgabios.c --- freebios-cvs/src/arch/i386/lib/vgabios.c 2002-03-30 08:11:05.000000000 +0900 +++ freebios-vgabios/src/arch/i386/lib/vgabios.c 2003-05-21 19:06:04.000000000 +0900 @@ -160,12 +160,19 @@ printk_debug("NO VGA FOUND\n"); return; } - printk_debug("found VGA: vid=%ux, did=%ux\n", dev->vendor, dev->device); + printk_debug("found VGA: vid=%x, did=%x\n", dev->vendor, dev->device); + +#ifdef VGABIOS_START + // Use VGA BIOS blob at specified address + rom = VGABIOS_START; +#else + // Use the ROM with the VGA card pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom); // paranoia rom = 0xf0000000; pci_write_config_dword(dev, PCI_ROM_ADDRESS, rom|1); printk_debug("rom base, size: %x\n", rom); +#endif buf = (unsigned char *) rom; if ((buf[0] == 0x55) && (buf[1] = 0xaa)) { memcpy((void *) 0xc0000, buf, size); @@ -176,7 +183,9 @@ real_mode_switch_call_vga(); } else printk_debug("BAD SIGNATURE 0x%x 0x%x\n", buf[0], buf[1]); +#ifndef VGABIOS_START pci_write_config_dword(dev, PCI_ROM_ADDRESS, 0); +#endif } #endif // (CONFIG_VGABIOS == 1) diff -urN freebios-cvs/src/bioscall/pcibios.c freebios-vgabios/src/bioscall/pcibios.c --- freebios-cvs/src/bioscall/pcibios.c 2002-03-31 15:25:56.000000000 +0900 +++ freebios-vgabios/src/bioscall/pcibios.c 2003-05-21 19:05:44.000000000 +0900 @@ -76,7 +76,7 @@ *peax = 0; // busnum is an unsigned char; // devfn is an int, so we mask it off. - busdevfn = dev->bus->number | (dev->devfn & 0xff); + busdevfn = dev->bus->secondary | (dev->devfn & 0xff); printk_debug("0x%x: return 0x%x\n", func, busdevfn); *pebx = busdevfn; retval = 0; -------------- next part -------------- # # LinuxBIOS config file for: VIA epia mini-itx # target epia-vgabios # via epia mainboard via/epia # Enable Serial Console for debugging option SERIAL_CONSOLE=1 option TTYS0_BAUD=115200 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option DEBUG=1 option SERIAL_POST=1 # Use 256KB Standard Flash as Normal BIOS option RAMTEST=1 option STD_FLASH=1 option ZKERNEL_START=0xfffc0000 option ROM_SIZE=262144 # payload size option PAYLOAD_SIZE=196608 # use ELF Loader option USE_ELF_BOOT=1 # Boot ELF kernel in IDE hard disk partition option BOOT_IDE=1 #option IDE_BOOT_DRIVE=0 #option ONE_TRACK=63 option CONFIG_UDELAY_TSC=1 # Boot payload in ROM #option USE_GENERIC_ROM=1 # our payload #payload /home/ts1/memtest86-3.0/memtest #payload /home/ts1/freebios/util/ADLO/payload payload /home/ts1/freebios/util/ADLO/video.bios.bin # Enable video option HAVE_FRAMEBUFFER=1 # Frame buffer (shared memory) size in Megs #option SMA_SIZE=8 #option CONFIG_COMPRESS=0 # DIMM type #option DIMM_PC133=1 #option DIMM_CL2=1 # Run VGA BIOS option CONFIG_VGABIOS=1 option CONFIG_REALMODE_IDT=1 option CONFIG_PCIBIOS=1 dir src/bioscall # Have VGA BIOS blob in ROM (note the payload line) option VGABIOS_START=0xfffc0000 From ts1 at cma.co.jp Thu May 22 04:10:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 22 04:10:00 2003 Subject: Passes RAM test, but hangs at jumping to RAM In-Reply-To: <20030521231809.A20957@mail.cwlinux.com> References: <20030516100322.GB4283@cma.co.jp> <20030517180920.GA813@tsn.or.jp> <20030521231809.A20957@mail.cwlinux.com> Message-ID: <20030522080958.GC1760@cma.co.jp> On Wed, May 21, 2003 at 11:18:09PM +0800, Andrew Ip wrote: > I'm just testing your latest code here with LinuxBIOS + ADLO. It is > able to start VGA and grub sometimes, but not all the time. FYI, I'm > running EPIA with IDE to CF adapter. It maybe related to memory > again. Could you send me a lspci -xxx -s0:0.0 of Award BIOS and serial output of LinuxBIOS? If I found something interesting there, maybe I can help. Otherwise, it's difficult for me to cope with it since the only one EPIA board I have access to is working quite happily with current code. I think you don't have to be asked to do basic things to track it down (like memtest86, replacing DIMMs, disabling framebuffer/VGABIOS, etc.) Only possible solution comes to mind is to introduce more "Aword compatible" register values. I tried many of them, then dropped most of them once it began to work, to keep it minimum. I didn't like to have things I can't explain. -- Takeshi From xpegenaute at telepolis.es Thu May 22 04:41:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Thu May 22 04:41:01 2003 Subject: brun_mtd In-Reply-To: <1053576732.1978.35.camel@ollie> References: <1053576732.1978.35.camel@ollie> Message-ID: <3ECC9A1E.1000608@telepolis.es> ollie lho wrote: >>>In the script of src/util/mtd/burn_mtd there are these lines .. >>> >>>- dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block >>>With this we if exist we don't trunc and fix the size of >>>vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until >>>this size. >>> >>>- dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block >>>The same but with 63k. >>> >>>- dd conv=notrunc if=docipl of=/dev/mtd0 >>>We write without trunc /dev/mtd0 with the source of docipl. >>> >>>- dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 >>>The same but this time we skip 1 block of "bs" (i supose that we can >>>remind the value of bs in the last line, then sizeof(docipl) ). >>> >>>- dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 >>>Without trunc we write linuxbios.block to mtd, skipping 2 times the last >>>size (sizeof(docipl) ). >>> >>>- dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 >>>Now without trunc write vmlinux skipping 128 times the size of >>>linuxbios.block. >>> >>> >>>My questions, are: >>> >>>Why we write two times docipl ? >>> >>> > >First of all, you are way wrong with what seek=# means. It skips # of >(output) blocks of the output device. It has nothing to do with >sizeof(some image). Please man dd for detail. > >There are two copies for IPL one at offset 0 the other at offset 512B >(seek=1). > >And why we skip 128 times the size of linuxbios.block ? (i supose that >i'm wrong, any one can help me with these) > >The size of linuxbios.block is 63kB plus the 2 copies of IPL == 64kB == >128 blocks. > Ok, then the default block size (bs) for input and output is 512 Bytes, thank you. Then finally the map of eeprom is this: 0-511 (0x0 - 0x1FF) docipl 512 Bytes 512-1023 (0x200 - 0x3FF) docipl (security copy) 512 Bytes 1024-65535 (0x400 - 0xFFFF) linuxbios.block 64512 Bytes 65536-851967 (0x10000 - 0xCFFFF) vmlinux.bin.gz.block 786432 Bytes Thanks a lot. Xavi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts1 at cma.co.jp Thu May 22 05:39:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 22 05:39:01 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: References: <20030521050800.GB21228@tsn.or.jp> Message-ID: <20030522093855.GA6753@cma.co.jp> On Wed, May 21, 2003 at 02:42:08PM -0600, ron minnich wrote: > Can you please write up a HOWTO for epi and vgabios? It seems some more work is needed before that, to get it work for Andrew so he commits the necessory patches. I'm not a good writer in English, as you see, so my HOWTO would be low quality in some aspect. -- Takeshi From xpegenaute at telepolis.es Thu May 22 07:08:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Thu May 22 07:08:01 2003 Subject: Entrance point (ipl and linuxbios) Message-ID: <3ECCBCC1.8090708@telepolis.es> Hi, i have some doubt about the real entrance point in the eeprom and ipl with LinuxBios. if the map of eeprom is right (following burn_mtd sript): 0-511 (0x0 - 0x1FF) docipl 512 Bytes 512-1023 (0x200 - 0x3FF) docipl (security copy) 512 Bytes 1024-65535 (0x400 - 0xFFFF) linuxbios.block 64512 Bytes 65536-851967 (0x10000 - 0xCFFFF) vmlinux.bin.gz.block 786432 Bytes In theory we have mapped the completly EPROM into the top of memory (4Gb for 32 bits) (Vol. 3 Cap. 9.10 of IA-32 ...), how we have the CS.BASE = 0xFFFF0000 and EIP = 0x0000FFF0 with the special memory config we start in 0xFFFFFFF0. We only can see a range of 0x0000 - 0xFFFF (the last 64Kbytes?) until we turn to protected mode. Then we start the init of EPROM with the last 16 bytes below the top of memory, that is the last 16 bytes below of vmlinux.bin.gz, of course impossible, any one can help me in this ? Also, in ipl.S, we can find this code: ----------------------------------------------------------------------- #ifdef STD_FLASH .org 0xfff0 reset_vector: .byte 0xea # jmp to f000:fc00, where IPL .word 0xfc00, 0xf000 # starts in Standard Flash #else /* !STD_FLASH i.e. DoC Mil */ ----------------------------------------------------------------------- Here if we have a standard flash eeprom we jump to the code of initialitzacion "sis630spd_start:" in ipl.S and we execute until "sis630ipl_end:" that there is a jump to SPL vector. What about ".org 0xfff0" ? ----------------------------------------------------------------------- #if (USE_DOC_MIL == 1) .org 0x1f0 ----------------------------------------------------------------------- If we have DOC_MIL ".org 0x1f0". ----------------------------------------------------------------------- #elif USE_DOC_2000_TSOP == 1) || (USE_DOC_MIL_PLUS == 1) .org 0x3f0 ----------------------------------------------------------------------- and here we put the ".org 0x3f0" ----------------------------------------------------------------------- #endif reset_vector: .byte 0xea # jmp to fe00:0000, where IPL .word 0x0000, DOC_WIN_SEG # starts in DoC #endif /* STD_FLASH */ ----------------------------------------------------------------------- If it is not a DOC_MIL and bla, bla, bla ... we make a jmp to 0xfe00:000, what is there in this direction ? ----------------------------------------------------------------------- spl_vector: .byte 0xea # jmp to 8000:0000, where SPL .word 0x0000, SPL_RAM_SEG # (LinuxBIOS) starts in RAM ----------------------------------------------------------------------- And finally if it was a standard flash or DOC_MIL we jump to LinuxBios in the segment 0x8000. In theory LinuxBios ?. My questions: - May be the mapped EEPROM in memory address space is mapped in reverse order (to find linuxbios in the firs 64Kb) ? 0x0 of EEPROM -> 0xFFFFFFFF. - Who is executed first ipl.S, or crt0.S ? My confusion are the ".org 0xfff0" in ipl.S but in the same time in src/cpu/i386/reset["16","32"].inc i found some reference to reset_vector but i don't know how it works , also by the other hand who turn the memory in protected memory is crt0.S, then this has to be the first. Thanks by patience. Sorry by the extension of the mail. Xavi. From aip at cwlinux.com Thu May 22 09:06:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu May 22 09:06:01 2003 Subject: [COMMIT] VGABIOS support for EPIA Message-ID: <20030522210538.A1826@mail.cwlinux.com> Hi, Thanks for Takeshi. We now have better ram detection and vgabios support. I also applied hcyun's serial debug patch and epia support for ADLO. src/northbridge/via/vt8601/vgainit.inc src/arch/i386/lib/vgabios.c src/bioscall/pcibios.c src/mainboard/via/epia/Config util/ADLO/bochs/bios/rombios.c util/ADLO/Makefile This update should be very limited to epia. Takeshi, would you mind to verify the tree. Since I still have problem, I might have missed something. However, it still looks much beter than before. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From jerj at coplanar.net Thu May 22 10:05:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Thu May 22 10:05:01 2003 Subject: Reverse engineering References: <20030521090305.B70670-100000@www.missl.cs.umd.edu> Message-ID: <024401c3206b$74d93f90$7e07a8c0@bridge> I have speculated that the XFree86 int10 code that (re)posts the card using I believe vm86 syscalls, would be a suitable test harness for this. So, boot off a second video card, then XFree86 will post the card in question in the DOS box when doing multihead or just running on the card that wasn't initialized at boot. If you were to modify the flags passed to vm86, not to allow IO, you just need a trap handler that logs the access then continues. For MMIO, page table permissions could also be used to generate traps, which log the access then continue, for the PCI IO region. Jeremy ----- Original Message ----- From: "Adam Sulmicki" To: "Peter Busser" Cc: Sent: Wednesday, May 21, 2003 9:07 AM Subject: Re: Reverse engineering > > > If you are only interested in those IO ports, an logic analyzer is > > > probably better and easier to use. Modern LA can be programmed to > > > log/filter various IO scenario. > > > > It's probably a bit expensive to buy an LA or ICE or any other specialised > > hardware just to get a board going. So I thought it might be possible to use > > Bochs to do the job instead. But maybe I'm mistaken. > > The problem with bochs is that it is not just "any hardware" but they > attempt to emulate Intel 440LX (IIRC). So if you put here an standard bios > I would expect it to complain a lot. > > Of course it is still better than nothing and I believe there are people > on the list which went this track before. Actualy it was other way around > with getting LinuxBIOS bios to run under BOCHS IIRC. > > While I myself hadn't used BOCHS to this purpose I have used Wine on > regular basic, and I was able to *easily* track IO ports for communication > between ChipWriter software and the ChipWriter hardware itself. > > Just my two bits. > > -- > Adam Sulmicki > http://www.eax.com The Supreme Headquarters of the 32 bit registers > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From shitse at web.de Thu May 22 10:42:01 2003 From: shitse at web.de (Jonas Meyer) Date: Thu May 22 10:42:01 2003 Subject: Via MVP4 Message-ID: <20030522164217.1bc0a2d9.shitse@web.de> Hi I've got this K6-2 that i haven'T used in months and would like to put linuxbios on. Chipset seems to be a MVP4 (vt8501) which i found some files for in the linuxbios source directory. But i'm still not sure if it is worth trying to replace the BIOS. I'd rather want to change the BIOS of my dual-P3 on a 440BX board, but as this is my primary machine i want to first do it on another. all the other Boards i have are intel FX Boards, which seem absolutely unsupported. I'd appreciate any help you can give. Thanks in advance Jonas Meyer From rsmith at bitworks.com Thu May 22 13:56:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu May 22 13:56:00 2003 Subject: EPIA + CONFIG_VGABIOS works In-Reply-To: <20030522093855.GA6753@cma.co.jp> References: <20030521050800.GB21228@tsn.or.jp> <20030522093855.GA6753@cma.co.jp> Message-ID: <3ECD0F18.4090309@bitworks.com> SONE Takeshi wrote: > I'm not a good writer in English, as you see, so my HOWTO > would be low quality in some aspect. If you can just get something rough I'll be happy to rework it in more native english and then include it in my document. -- Richard A. Smith rsmith at bitworks.com From dkotian3 at vsnl.net Thu May 22 14:37:01 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Thu May 22 14:37:01 2003 Subject: A problem, a machine stalls after usage of the PCI board.(seems IRQs) References: <20030522164217.1bc0a2d9.shitse@web.de> Message-ID: <017b01c32090$a2eb1280$293e41db@vsnl.net> Hi, The LinuxBIOS with etherboot boots Linux properly, and gets on the network with both the internet interface up and seems to asigns the IRQ correctly in LinuxBIOS. ping.etc is OK. But, when I use the Multimedia card(encoder)card on this on a PCI slot and start encoding. The machine just comes to a halt and network is also out and there is no Output on the Serial console. I have assigned IRQ 12 to this PCI slot. Would it matter with different IRQ numbers, if IRQ 5 is assigned, the results are a bit different. But still does remain come network later once the encoding starts. I doubt whether the IRQ still has a problem with this. Could someone give any suggestions on this one. Also, if there is a good methodolgy/literature of this whole IRQ business with LinuxBIOS and would like to share. It would be great as well. Regards Deepak From dkotian3 at vsnl.net Thu May 22 14:37:22 2003 From: dkotian3 at vsnl.net (Deepak Kotian) Date: Thu May 22 14:37:22 2003 Subject: I cannot control my GPIO LEDS from the application Message-ID: <018101c32090$cf1d76e0$293e41db@vsnl.net> Hi, After booting from LinuxBIOS, I try to access the GPIOs connected to 7-Segmen LEDS, it does not do anything. Is there a way or something needs to be done in LinuxBIOS to enable it . If there are any experiences/suggestion, please let me know. Regards Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From klemens.mantzos at dynatools.com Thu May 22 17:07:01 2003 From: klemens.mantzos at dynatools.com (Klemens Mantzos) Date: Thu May 22 17:07:01 2003 Subject: Laptops? Message-ID: I read an articel about the Linux BIOS Project in the Linux-Magazin (German)----It's great!!!!!!!!!!!! What i want to know is: "Does anybody think about using in Workstations/Laptops?????". CU ------------------------------------- Klemens Mantzos Dynatools Communication Services GmbH Schopenhauerstrasse 36 1180 Wien Tel: +43-1-4031600 Fax: +43-1-4031600-34 mailto:klemens.mantzos at dynatools.com ? http://www.dynatools.com http://www.projectmaker.at http://www.dynaweb.at ------------------------------------- From skosmider at liza.umcs.lublin.pl Thu May 22 17:08:08 2003 From: skosmider at liza.umcs.lublin.pl (Kosmider Slawomir) Date: Thu May 22 17:08:08 2003 Subject: linuxbios for soltek Message-ID: <64161.212.182.58.98.1053004121.squirrel@liza.umcs.lublin.pl> Hello. I found yours linuxbios project very interesting and I'm wonder if I could build it for my soltek SL-75KAV mainboard with via apollo chipset. Curently I havent fount it in the status page of this project but maybe few small changes in the source code would be enough. From sklavo at pobox.com Thu May 22 17:08:14 2003 From: sklavo at pobox.com (sklavo) Date: Thu May 22 17:08:14 2003 Subject: debugger In-Reply-To: <20030515160001.10755.38094.Mailman@nwn.definitive.org> Message-ID: <5.2.1.1.2.20030515101005.02ca24d8@cybermorph.com> To add to Ron's message. It varies a lot with your experience and how dirty you want to get. A simple POST card and a lot of creative POST code bread crumbs is the cheap and dirty way to go, until you get the serial port debugger up and running. But it requires you to be really creative in crawling through the code. And takes a lot of time. But you can move up the a logic analyzer looking at bus cycles or an ICE (in circuit emulator) looking at CPU activity These two are expensive (lots of $10K), but you can often rent them. Setup is usually the time burner here. But with a LA you can take selective pictures of events chained together in time. I don't know if SIS has an ICE for their SOC products. Jordan PS: Has anyone done a USB interface low level debugger? Early BIOS or at least just prior to payload decompress. At 12:00 PM 5/15/2003 -0400, you wrote: >Message: 10 >Date: Thu, 15 May 2003 08:50:44 -0700 (PDT) >From: Frank >Subject: Re: debugger >To: ron minnich >Cc: linuxbios at clustermatic.org > >sis55x SOC x86 based >--- ron minnich wrote: > > On Thu, 15 May 2003, Frank wrote: > > > > > Can anyone recommend a debugger for bringing up LinuxBios on > > an > > > x86 system... > > > > what kind of chip? and how much money can you spend? > > > > ron From sklavo at pobox.com Thu May 22 17:08:19 2003 From: sklavo at pobox.com (sklavo) Date: Thu May 22 17:08:19 2003 Subject: debugger In-Reply-To: <1053050152.20104.188.camel@ollie> References: <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> <5.2.1.1.2.20030515102329.02ca3880@cybermorph.com> Message-ID: <5.2.1.1.2.20030515191246.02be4ae0@cybermorph.com> I was curious about that one also. Jordan At 09:55 AM 5/16/2003 +0800, ollie lho wrote: >On Fri, 2003-05-16 at 01:23, jarcher wrote: > > To add to Ron's message. > > > > It varies a lot with your experience and how dirty you want to get. > > > > A simple POST card and a lot of creative POST code bread crumbs is the > > cheap and dirty way to go, until you get the serial port debugger up and > > running. But it requires you to be really creative in crawling through > the > > code. And takes a lot of time. > > > > But you can move up the a logic analyzer looking at bus cycles or an ICE > > (in circuit emulator) looking at CPU activity These two are expensive > > (lots of $10K), but you can often rent them. Setup is usually the time > > burner here. But with a LA you can take selective pictures of events > > chained together in time. I don't know if SIS has an ICE for their SOC > > products. > > > > Jordan > > > > PS: Has anyone done a USB interface low level debugger? Early BIOS or at > > least just prior to payload decompress. > > > >BTW, why didn't we come up with a GDB stub in LinuxBIOS ?? > >-- >ollie lho From vova7dima at yahoo.com Thu May 22 17:08:26 2003 From: vova7dima at yahoo.com (Vladimir Viktorov) Date: Thu May 22 17:08:26 2003 Subject: LinuxBios on Sis630 (Nova-7896) Message-ID: <20030516153833.9822.qmail@web40109.mail.yahoo.com> Hello! My name is Vova! I from Russia! I want to put on the computer (with chipset SiS630, motherbord iei NOVA-7896) so-called fast loading Linux Slackware 9 using your LinuxBios program. I have downloaded (as is written in the instruction) freebios-20010708.tar.gz and mtd-20000704.tar.gz. For me a question on STEP 2: *************************************** ************************** - go to www.kernel.org and get linux-2.4.0-test12 o Once you have pulled this file down and untar'ed it, apply the proper patch from the freebios/src/kernel_patches directory. The patch is: *************************************** ********************************* For me Linux Slackware 9.0 with a nucleus 2.4.20. In the instruction ask to download a nucleus 2.4.0!!! What to me to do(make)? With what nucleus to work that ????? to place(install) LINUXBIOS!!! Help please! Yours faithfully Vova. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From kron-os at web.de Thu May 22 17:08:32 2003 From: kron-os at web.de (Peter Kling) Date: Thu May 22 17:08:32 2003 Subject: K7S5A (SiS735) Message-ID: <3EC54637.5010105@web.de> Hi, I would like to use linuxbios with my PC, but I'm not sure if my mainboard is supported or not. I've already read some articles about this mainboard and the chipset. Something about problems with using DoC. And SiS735 is "unstable" as I've seen on the status page. So, can somebody tell me which features exactly are suported with this mainboard? Perhaps somebody who has already tried to ise linuxbios with this mainboard. Or is there realy no support at all for my mainboard? Thx for any information, ciao, Peter From sklavo at cybermorph.com Thu May 22 17:08:37 2003 From: sklavo at cybermorph.com (sklavo at cybermorph.com) Date: Thu May 22 17:08:37 2003 Subject: config language In-Reply-To: <20030520104553.H21569@www2> References: <000d01c31eab$a0b1e5c0$ce40a8c0@2pmtech.com> <20030520092435.G21569@www2> Message-ID: <5.2.1.1.2.20030520084928.027ab878@cybermorph.com> The meaning may be just as clear. But I would argue that it's not as easy for the eye to read. And "altimus/mpc7500" is closer to the environment you are actually trying to debug. It's an include file at the path altimus/mpc7500. Jordan At 10:45 AM 5/20/2003 -0400, Bob Drzyzgula wrote: >On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote: > > > > Hi Bob, > > > > The config language does lend itself to XML, (and it was my first > > thought when Ron suggested a new languge) but I would recommend > > against it for a couple of reasons. The first is that the language > > needs to serve the dual purpose of specifying *and documenting* a > > particular configuration. XML is great for the former, but is almost > > impossible to read easily, particularly for people not used to > > working with it. Sure, you could then add something that converts the > > XML into a more readable document, but then what is a simple idea is > > now becoming very complicated. Secondly, and more importantly, is > > that it would mean that LB relies on the existence of an extremely > > complex external component, that is out of the control of the LB > > community (be it pyRXP, libXML, or whatever). Arguably this is > > already the case, since the configuration process uses python, but if > > we adopt a new configuration language then the parser can be included > > as part of the distribution - making it effectively self-contained. > > So in my view the limitations of using XML outweigh any advantages > > that might be obtained. > > > > Regards, > > > > Greg > >Greg, > >Y'know, it's *OK* to say "I just don't like it". :-) >I know if Ron & y'all don't *want* to do it it won't >get done, which is, again, *OK*. :-) > >But understanding that I don't seriously expect this >to happen in LB, I do sort of want to respin a >couple of your points... > >It's interesting what you say about documentation, because >one of the oft-cited primary advantages of XML is that >it is self-documenting. Perhaps it takes some getting used >to but in the end the meaning of: > > > >has got to be at least as clear as > > pmc altimus/mpc7500 > >even if it is a bit more longer. > >Beyond this, the formal specification for an XML document >is in the DTD (or schema): an overt, external data file >that all code can reference. With a config file of the >sort that LB has had thus far, the real specification is >embedded in the parser source code, perhaps supplemented >by usage notes. Thus it is fairly easy for disconnects to >occur not only between the implmentation and the user's >understanding thereof, but between the written, external >documentation and the implementation. > >The reliance on an external library is, I would think, >something of a red herring. As you point out, there are >myriad external libraries that are being relied upon. A >yacc/lex implementation relies on the implementation of >yacc & lex and all the lexical arcania that come with >them. Ron suggested YAPP, which relies on the YAPP >project. In the case of PyRXP, that whole thing is GPL'd, >so if the project wanted, a version of PyRXP could be >frozen into the LB CVS tree. Granted, that could mean >fixing it if it turns out to be broken, but that's a >separate issue from the one you cited, and is probably not >a significantly greater a risk than exists with many >other parser generators that could be chosen. > >The one other thing I'll add is that, while existing LB >developers may not be well-versed in XML, the fact is that, >industry-wide, XML literacy is growing if not exploding. In >the long term, finding people who understand and can work >with XML will be no harder, and probably easier, than >finding people who can program in C. A custom configuration >language, and the code to implement it, will be novel to >everyone who encounters it, now and forever. > >Just my $0.02. > >--Bob >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From sklavo at cybermorph.com Thu May 22 17:08:43 2003 From: sklavo at cybermorph.com (sklavo at cybermorph.com) Date: Thu May 22 17:08:43 2003 Subject: debugger In-Reply-To: <1053483460.1978.17.camel@ollie> References: Message-ID: <5.2.1.1.2.20030521065256.02f7b860@cybermorph.com> I'm going to look at doing that over the next week or so. Jordan At 10:17 AM 5/21/2003 +0800, ollie lho wrote: >On Fri, 2003-05-16 at 22:27, ron minnich wrote: > > On Thu, 15 May 2003, jarcher wrote: > > > > > It might be helpful in debugging the stuff that get loaded after the > core > > > BIOS runs. > > > > I mostly saw it as a useful learning tool for people trying to follow the > > code. > >Can we make the gdb stub reuseable as linuxbios_table or ELF loader >stuff ? In this way, both LinuxBIOS and the payload (BLOB ?) can be >debugged. > >-- >ollie lho From rminnich at lanl.gov Thu May 22 17:13:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 22 17:13:01 2003 Subject: Laptops? In-Reply-To: Message-ID: On Thu, 8 May 2003, Klemens Mantzos wrote: > What i want to know is: "Does anybody think about using in > Workstations/Laptops?????". we've been trying to find a good laptop for a few years for this purpose. One possibility is the $700 lindows laptop, which does use a supported chipset. ron From ts1 at tsn.or.jp Thu May 22 17:55:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Thu May 22 17:55:00 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030522210538.A1826@mail.cwlinux.com> References: <20030522210538.A1826@mail.cwlinux.com> Message-ID: <20030522215420.GA2621@tsn.or.jp> On Thu, May 22, 2003 at 09:05:38PM +0800, Andrew Ip wrote: > Thanks for Takeshi. We now have better ram detection and vgabios support. Thank you for committing. > I also applied hcyun's serial debug patch and epia support for ADLO. It doesn't contain any of my work to ADLO. It's just serial patch. EPIA runs just fine anyway. > Takeshi, would you mind to verify the tree. Since I still have problem, > I might have missed something. However, it still looks much beter than > before. You missed an important line. Attached vgabios.patch fixes it. To build ADLO with "make epia" you introduced, pirq table blob is needed, but you didn't add it to the tree. Also, you need to modify some part of loader.s. My working example is attached adlo-epia.patch. Without it, ADLO screws some part of PCI controller registers. You might also want to change memory size in loader.s. With above changes, my EPIA runs fine with VGABIOS+memtest86 payload (memtest86 runs on VGA screen), and ADLO which boots to GRUB->Linux. (BOOT_IDE didn't work this morning...) -- Takeshi -------------- next part -------------- Index: src/arch/i386/lib/vgabios.c =================================================================== RCS file: /cvsroot/freebios/freebios/src/arch/i386/lib/vgabios.c,v retrieving revision 1.7 diff -u -r1.7 vgabios.c --- src/arch/i386/lib/vgabios.c 22 May 2003 12:59:58 -0000 1.7 +++ src/arch/i386/lib/vgabios.c 22 May 2003 21:31:17 -0000 @@ -164,7 +164,7 @@ #ifdef VGABIOS_START // Use VGA BIOS blob at specified address - // rom = VGABIOS_START; + rom = VGABIOS_START; #else pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom); // paranoia -------------- next part -------------- Index: util/ADLO/loader.s =================================================================== RCS file: /cvsroot/freebios/freebios/util/ADLO/loader.s,v retrieving revision 1.1 diff -u -r1.1 loader.s --- util/ADLO/loader.s 25 Nov 2002 02:07:53 -0000 1.1 +++ util/ADLO/loader.s 22 May 2003 21:31:18 -0000 @@ -50,13 +50,13 @@ ;***************************************************** ; B) shadow - ON (enable/read/write) -mov eax, #0x80000070 -mov dx, #0x0cf8 -out dx, eax - -mov eax, #0xFFFFFFFF -mov dx, #0x0cfc -out dx, eax +;mov eax, #0x80000070 +;mov dx, #0x0cf8 +;out dx, eax +; +;mov eax, #0xFFFFFFFF +;mov dx, #0x0cfc +;out dx, eax ;***************************************************** nop @@ -166,14 +166,14 @@ ;***************************************************** ; E) shadow - OFF (write) -mov eax, #0x80000070 -mov dx, #0x0cf8 -out dx, eax +;mov eax, #0x80000070 +;mov dx, #0x0cf8 +;out dx, eax ;mov eax, #0xFFFFFFFF -mov eax, #0x0000FFFF -mov dx, #0x0cfc -out dx, eax +;mov eax, #0x0000FFFF +;mov dx, #0x0cfc +;out dx, eax ;***************************************************** nop From adam at cfar.umd.edu Thu May 22 20:43:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Thu May 22 20:43:00 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030522215420.GA2621@tsn.or.jp> Message-ID: <20030522205411.T79444-100000@www.missl.cs.umd.edu> Of course if you commit this ADLO patch for EPIA you will break ADLO on SIS630. No point to 'fix' one architecture to break another. On Fri, 23 May 2003, SONE Takeshi wrote: > On Thu, May 22, 2003 at 09:05:38PM +0800, Andrew Ip wrote: > > Thanks for Takeshi. We now have better ram detection and vgabios support. > > Thank you for committing. > > > I also applied hcyun's serial debug patch and epia support for ADLO. > > It doesn't contain any of my work to ADLO. It's just serial patch. > EPIA runs just fine anyway. > > > Takeshi, would you mind to verify the tree. Since I still have problem, > > I might have missed something. However, it still looks much beter than > > before. > > You missed an important line. > Attached vgabios.patch fixes it. > > To build ADLO with "make epia" you introduced, pirq table blob is > needed, but you didn't add it to the tree. > > Also, you need to modify some part of loader.s. > My working example is attached adlo-epia.patch. > Without it, ADLO screws some part of PCI controller registers. > You might also want to change memory size in loader.s. > > With above changes, my EPIA runs fine with VGABIOS+memtest86 payload > (memtest86 runs on VGA screen), and ADLO which boots to GRUB->Linux. > (BOOT_IDE didn't work this morning...) > > -- > Takeshi > -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From aip at cwlinux.com Thu May 22 20:53:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu May 22 20:53:01 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030522215420.GA2621@tsn.or.jp>; from SONE Takeshi on Fri, May 23, 2003 at 06:54:20AM +0900 References: <20030522210538.A1826@mail.cwlinux.com> <20030522215420.GA2621@tsn.or.jp> Message-ID: <20030523085316.A8460@mail.cwlinux.com> > It doesn't contain any of my work to ADLO. It's just serial patch. > EPIA runs just fine anyway. If it is not necessary, I probably skip this patch, since it may affect other mb. > You missed an important line. > Attached vgabios.patch fixes it. Fixed > To build ADLO with "make epia" you introduced, pirq table blob is > needed, but you didn't add it to the tree. Done. > Also, you need to modify some part of loader.s. > My working example is attached adlo-epia.patch. > Without it, ADLO screws some part of PCI controller registers. > You might also want to change memory size in loader.s. I'll try. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Thu May 22 21:07:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu May 22 21:07:01 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030522205411.T79444-100000@www.missl.cs.umd.edu> Message-ID: On Thu, 22 May 2003, Adam Sulmicki wrote: > > Of course if you commit this ADLO patch for EPIA you will break ADLO on > SIS630. the, clearly, please don't commit. ron From aip at cwlinux.com Fri May 23 02:35:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri May 23 02:35:00 2003 Subject: K7S5A (SiS735) In-Reply-To: <3EC54637.5010105@web.de>; from Peter Kling on Fri, May 16, 2003 at 10:12:39PM +0200 References: <3EC54637.5010105@web.de> Message-ID: <20030523143439.A12431@mail.cwlinux.com> Peter, > I would like to use linuxbios with my PC, but I'm not sure if my > mainboard is supported or not. I've already read some articles about > this mainboard and the chipset. Something about problems with using DoC. > And SiS735 is "unstable" as I've seen on the status page. 735 doesn't work with DOC. But it works with etherboot. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From ts1 at cma.co.jp Fri May 23 04:38:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri May 23 04:38:00 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: References: <20030522205411.T79444-100000@www.missl.cs.umd.edu> Message-ID: <20030523083757.GA886@cma.co.jp> On Thu, May 22, 2003 at 07:06:38PM -0600, ron minnich wrote: > On Thu, 22 May 2003, Adam Sulmicki wrote: > > > > > Of course if you commit this ADLO patch for EPIA you will break ADLO on > > SIS630. > > the, clearly, please don't commit. How about applying that patch but disabling it by default by setting DEBUG_SERIAL to 0. -- Takeshi From frannk_m1 at yahoo.com Fri May 23 10:36:00 2003 From: frannk_m1 at yahoo.com (Frank) Date: Fri May 23 10:36:00 2003 Subject: support for SIS55x Message-ID: <20030523143630.58759.qmail@web13806.mail.yahoo.com> Any support for the SIS55x family based mother boards... __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com From shitse at web.de Fri May 23 10:59:01 2003 From: shitse at web.de (Jonas Meyer) Date: Fri May 23 10:59:01 2003 Subject: Via MVP4 In-Reply-To: <20030522164217.1bc0a2d9.shitse@web.de> References: <20030522164217.1bc0a2d9.shitse@web.de> Message-ID: <20030523165914.28636f63.shitse@web.de> On Thu, 22 May 2003 16:42:17 +0200 Jonas Meyer wrote: > > Hi > I've got this K6-2 that i haven'T used in months and would like to put linuxbios on. Chipset seems to be a MVP4 (vt8501) which i found some files for in the linuxbios source directory. But i'm still not sure if it is worth trying to replace the BIOS. > I'd rather want to change the BIOS of my dual-P3 on a 440BX board, but as this is my primary machine i want to first do it on another. all the other Boards i have are intel FX Boards, which seem absolutely unsupported. > I'd appreciate any help you can give. > Thanks in advance > Jonas Meyer This board hasn't got a bios anyways. Needed the chip some time ago. So i wouldn't care if it worked bad, but i really would love to give it a try if any of you said there are chances that i at least get an output on the serial line. So what do you say, is there any chance the current linuxbios will do anything on this board? i'd want to run etherboot if it is possible, but don't want to try something that never had a chance to work. Jonas From gwatson at lanl.gov Fri May 23 11:16:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Fri May 23 11:16:01 2003 Subject: [linuxBios] HDD init problem In-Reply-To: <002501c31f85$3393edf0$525deecb@noshel> References: <002501c31f85$3393edf0$525deecb@noshel> Message-ID: No, I'm just working on pc80/ide/ide.c in the linuxbios tree. I need this for the PPC port, so x86 asm code won't be of much help. Cheers, Greg >gee, are you mentioning disk_init() in pcbios.S ? >I just took a look at it, and I had to close the file >because it was in asm! (I'm really scared of asm, you see..) >When your done, I hope I could get a copy, badly :) >good luck! > >Ed > >----- Original Message ----- >From: "Greg Watson" >To: >Sent: Tuesday, May 20, 2003 10:38 PM >Subject: Re: [linuxBios] HDD init problem > > >> Ron is right, I'm in the process of retrofitting the etherboot-5.1.8 >> IDE driver into LB. I can't get the standard IDE driver to even >> recognize my controller. >> >> Greg >> >> At 6:55 AM -0600 20/5/03, ron minnich wrote: >> >I think Greg Watson is porting a decent IDE driver to LinuxBIOS from >> >Etherboot. The one in LinuxBIOS is not quite right. >> > >> >ron >> > >> >_______________________________________________ >> >Linuxbios mailing list >> >Linuxbios at clustermatic.org >> >http://www.clustermatic.org/mailman/listinfo/linuxbios >> >> _______________________________________________ >> Linuxbios mailing list >> Linuxbios at clustermatic.org >> http://www.clustermatic.org/mailman/listinfo/linuxbios >> >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From tkl at tobbynet.de Fri May 23 11:33:00 2003 From: tkl at tobbynet.de (Tobias Kloss) Date: Fri May 23 11:33:00 2003 Subject: no docipl after make Message-ID: <3ECE3F2E.9030805@tobbynet.de> Hi, i have an old gigabyte board with the 430TX chipset on it. For configuration i used the example from src/mainborads/digitallogic/smartcore-p5/config.example, because it uses the 430tx as northbridge and the piix4 as southbridge as my board does. After running the python program, i started to make a romimage. But i don't get the docipl file after make finshed. What can i do? Thanks, Tobias Kloss This is my lspci output: 00:00.0 Host bridge: Intel Corp. 430TX - 82439TX MTXC (rev 01) 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:08.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] 00:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) From aip at cwlinux.com Fri May 23 12:10:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri May 23 12:10:01 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030523083757.GA886@cma.co.jp>; from SONE Takeshi on Fri, May 23, 2003 at 05:37:57PM +0900 References: <20030522205411.T79444-100000@www.missl.cs.umd.edu> <20030523083757.GA886@cma.co.jp> Message-ID: <20030524001037.B18491@mail.cwlinux.com> Takeshi, > How about applying that patch but disabling it by default > by setting DEBUG_SERIAL to 0. Tried. It only works with DEBUG_SERIAL=1 and DEBUG_ATA=1. BTW, memtest passes. Next, I'll compare the values between LinuxBIOS and regualar. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Fri May 23 13:33:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 23 13:33:01 2003 Subject: Laptops? In-Reply-To: <1053648071.976.95.camel@jcenote> Message-ID: can you send an lspci? ron From bob at drzyzgula.org Fri May 23 13:46:00 2003 From: bob at drzyzgula.org (Bob Drzyzgula) Date: Fri May 23 13:46:00 2003 Subject: config language In-Reply-To: References: <20030520104553.H21569@www2> Message-ID: <20030523134611.C17200@www2> Ron, FYI, I'm back and starting to mess with this. I'm digging through some stuff and tinkering with some candidate tools that will hopefully come close to your requirements ("simple" + "schema-based"). The bulk of my XML experience, what there is of it, has been DTD-based, so this takes a small bit of getting up to speed. Validating, XSDL-aware, Python-based, simple-to-use parsers are (perhaps you knew this :) about as scarce as hen's teeth. The main Python XSDL processsor appears to be XSV , but I haven't yet made an assesment of the "simple" criteria. However, in digging around I find that recent builds of 4Suite provide some support for RELAX NG (see ) which in fact may be superior for this application because of its extensive support for flexible content ordering. More later. --Bob On Tue, May 20, 2003 at 09:31:53AM -0600, ron minnich wrote: > > ok, Bob, let's do this: > > send me a pointer to a simple (!) XML parser. > > Send me if you can a simple example of a simple thing that uses a simple > parser. > > we'll take a look. > > thanks > > ron From jeff.carr at eng.nciaccess.com Fri May 23 14:10:00 2003 From: jeff.carr at eng.nciaccess.com (Jeff Carr) Date: Fri May 23 14:10:00 2003 Subject: Laptops? In-Reply-To: References: Message-ID: <1053713191.988.125.camel@jcenote> :) As soon as I hit send I thought, "oh crap..." On Fri, 2003-05-23 at 12:33, ron minnich wrote: > can you send an lspci? > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -------------- next part -------------- 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 42) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) Subsystem: Unknown device 161f:2025 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 00:0b.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00ce (rev 01) (prog-if 10 [OHCI]) Subsystem: Unknown device 161f:2025 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4 From ts1 at tsn.or.jp Fri May 23 16:17:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Fri May 23 16:17:00 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <20030524001037.B18491@mail.cwlinux.com> References: <20030522205411.T79444-100000@www.missl.cs.umd.edu> <20030523083757.GA886@cma.co.jp> <20030524001037.B18491@mail.cwlinux.com> Message-ID: <20030523201655.GA27026@tsn.or.jp> On Sat, May 24, 2003 at 12:10:37AM +0800, Andrew Ip wrote: > How about applying that patch but disabling it by default > > by setting DEBUG_SERIAL to 0. > Tried. It only works with DEBUG_SERIAL=1 and DEBUG_ATA=1. BTW, Well, I recommended that to commit to cvs, so that that patch doesn't break other boards any more. Not for you to try with EPIA. Sorry for bad English. Good news: if you add a dummy function, vga_hardware_fixup(), VIDEO_CONSOLE just works. Can we state so at the status page of web? :) -- Takeshi From NEWBELL7 at magicn.com Sun May 25 14:09:00 2003 From: NEWBELL7 at magicn.com (NEWBELL7 at magicn.com) Date: Sun May 25 14:09:00 2003 Subject: [COMMIT] VGABIOS support for EPIA Message-ID: <4c5ab01c321d0$f17d49e0$81cda8c0@magicn.net> Hello!! Takeshi I get latest cvs today. Then I configure and compile it for my EPIA. But ..it looks like that it doesn't work. I input my elf kernel like this. dd if=kernel.elf of=/dev/hda1 ( Because Maybe ... from debug message ... It looks like to find any elf image from sector 63 .. ) Is it right ?? When I use BOOT_IDE option, What does "payload command" do originally ? Anyway, I applause for your work. regards newbie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts1 at cma.co.jp Mon May 26 02:32:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Mon May 26 02:32:00 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: <4c5ab01c321d0$f17d49e0$81cda8c0@magicn.net> References: <4c5ab01c321d0$f17d49e0$81cda8c0@magicn.net> Message-ID: <20030526063302.GA7333@cma.co.jp> On Sat, May 24, 2003 at 05:46:18PM +0900, NEWBELL7 at magicn.com wrote: > I get latest cvs today. Then I configure and compile it for my EPIA. > But ..it looks like that it doesn't work. > I input my elf kernel like this. > dd if=kernel.elf of=/dev/hda1 > ( Because Maybe ... from debug message ... It looks like to find any elf > image from sector 63 .. ) > Is it right ?? > > When I use BOOT_IDE option, What does "payload command" do originally ? Generally, with BOOT_IDE, payload does nothing but fill the flash part. However, with my CONFIG_VGABIOS configuration, we use payload command to store the VGABIOS binary in the flash. As I said before, BOOT_IDE is unstable and does not always work. You can make VGABIOS+Etherboot payload, to load VGABIOS *and* boot Etherboot. If your VGABIOS is 64K, cat video.bios.bin ide_disk.zelf >vgabios+etherboot.bin this command puts VGABIOS at beginning and Etherboot at +64K of the output file. Then, config like this will let LinuxBIOS boot the Etherboot: payload vgabios+etherboot.bin option VGABIOS_START=0xfffc0000 option ZKERNEL_START=0xfffd0000 To autmate the 'cat' step we need some hack to config file but I haven't figured it out. -- Takeshi From karl at kalle.csb.ki.se Mon May 26 11:39:01 2003 From: karl at kalle.csb.ki.se (Karl Hammar) Date: Mon May 26 11:39:01 2003 Subject: [COMMIT] VGABIOS support for EPIA In-Reply-To: Message from SONE Takeshi of "Mon, 26 May 2003 15:33:02 +0900." <20030526063302.GA7333@cma.co.jp> References: <4c5ab01c321d0$f17d49e0$81cda8c0@magicn.net> <20030526063302.GA7333@cma.co.jp> Message-ID: <200305261538.h4QFcrfF000565@opal.aspo.lcl> ... > You can make VGABIOS+Etherboot payload, to load VGABIOS *and* > boot Etherboot. > If your VGABIOS is 64K, > > cat video.bios.bin ide_disk.zelf >vgabios+etherboot.bin > > this command puts VGABIOS at beginning and Etherboot at +64K > of the output file. > Then, config like this will let LinuxBIOS boot the Etherboot: > > payload vgabios+etherboot.bin > option VGABIOS_START=0xfffc0000 > option ZKERNEL_START=0xfffd0000 > > To autmate the 'cat' step we need some hack to config file > but I haven't figured it out. > > -- > Takeshi Maybe something like: $ cat lb #!/bin/sh base=FFFC0000 # bc need it to be upcase out="vgabios+etherboot.bin" files="video.bios.bin ide_disk.zelf" ls -l $files : > config : > $out echo payload $out > config for i in $files do cat $i | dd bs=64k conv=sync 2>/dev/null >> $out # pad the files to 64k size=`stat -L -c %s $out` # filesize in bytes (decimal) hsz=`echo "obase=16; $size" | bc` # filesize in bytes (hex) SSZ=`echo "obase=16; ibase=16; $base+$hsz" | bc` # add it to $base echo option ${i}_START=0x$SSZ >> config done ls -l $out echo Config file: cat config Using faked input files just for testing: $ ./lb -rw-r--r-- 1 karl users 5291 May 26 16:50 ide_disk.zelf -rw-r--r-- 1 karl users 17470 May 26 16:50 video.bios.bin -rw-r--r-- 1 karl users 131072 May 26 17:23 vgabios+etherboot.bin Config file: payload vgabios+etherboot.bin option video.bios.bin_START=0xFFFD0000 option ide_disk.zelf_START=0xFFFE0000 Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Asp? Data karl at kalle.csb.ki.se Lilla Asp? 2340 Networks S-742 94 ?sthammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting ----------------------------------------------------------------------- From kevin at koconnor.net Mon May 26 15:24:00 2003 From: kevin at koconnor.net (Kevin O'Connor) Date: Mon May 26 15:24:00 2003 Subject: What is the status of EPIA-M? Message-ID: <20030526192500.GA2631@arizona.localdomain> Hi, A couple of weeks ago, there was a message about EPIA-M support being checked in. Then later a brief message about possible NDA issues. Does anyone know what the status is now? Thanks, -Kevin -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ From aip at cwlinux.com Mon May 26 20:19:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon May 26 20:19:00 2003 Subject: What is the status of EPIA-M? In-Reply-To: <20030526192500.GA2631@arizona.localdomain>; from Kevin O'Connor on Mon, May 26, 2003 at 03:25:00PM -0400 References: <20030526192500.GA2631@arizona.localdomain> Message-ID: <20030527082013.A24982@mail.cwlinux.com> Kevin, > A couple of weeks ago, there was a message about EPIA-M support being > checked in. Then later a brief message about possible NDA issues. Does > anyone know what the status is now? I have got permission from VIA. I will check it in soon. Thanks. -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From ollie at sis.com.tw Tue May 27 00:20:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Tue May 27 00:20:01 2003 Subject: Entrance point (ipl and linuxbios) In-Reply-To: <3ECCBCC1.8090708@telepolis.es> References: <3ECCBCC1.8090708@telepolis.es> Message-ID: <1054008646.1978.70.camel@ollie> On Thu, 2003-05-22 at 20:04, Xavier Pegenaute wrote: > > In theory we have mapped the completly EPROM into the top of memory (4Gb > for 32 bits) (Vol. 3 Cap. 9.10 of IA-32 ...), how we have the CS.BASE = > 0xFFFF0000 and EIP = 0x0000FFF0 with the special memory config we start > in 0xFFFFFFF0. We only can see a range of 0x0000 - 0xFFFF (the last > 64Kbytes?) until we turn to protected mode. > Then we start the init of EPROM with the last 16 bytes below the top of > memory, that is the last 16 bytes below of vmlinux.bin.gz, of course > impossible, any one can help me in this ? > The cases for DoC and normal flash are different. Your image map is for DoC. The DoC is very special that it will map the IPL to the top and bottom of its addressable window. The addressable window is mapped multiple times to 64KB below 4GB and 1MB by HW. In this way, the memory map for the image has nothing to do with what CPU see in its address space. > Also, in ipl.S, we can find this code: > > ----------------------------------------------------------------------- > #ifdef STD_FLASH > .org 0xfff0 > reset_vector: > .byte 0xea # jmp to f000:fc00, where IPL > .word 0xfc00, 0xf000 # starts in Standard Flash > #else /* !STD_FLASH i.e. DoC Mil */ > ----------------------------------------------------------------------- > Here if we have a standard flash eeprom we jump to the code of > initialitzacion "sis630spd_start:" in ipl.S and we execute until > "sis630ipl_end:" that there is a > jump to SPL vector. > What about ".org 0xfff0" ? For IPL for normal flash, we deliberated to make the IPL 64kB although it is only 512B and overlap the first 63kB with linuxbios.bin. The .org 0xfff0 directive makes the reset_vector at the last 16B of the 64kB image. > ----------------------------------------------------------------------- > #if (USE_DOC_MIL == 1) > .org 0x1f0 > ----------------------------------------------------------------------- > If we have DOC_MIL ".org 0x1f0". We address the reset vector to the last 16B of 512B. > ----------------------------------------------------------------------- > #elif USE_DOC_2000_TSOP == 1) || (USE_DOC_MIL_PLUS == 1) > .org 0x3f0 > ----------------------------------------------------------------------- > and here we put the ".org 0x3f0" > ----------------------------------------------------------------------- The size of IPL area is 1kB instead of 512kB for newer DoC Mil and DoC Mil Plus. So we have to make the reset_vector at the last 16B of 1kB. > #endif > reset_vector: > .byte 0xea # jmp to fe00:0000, where IPL > .word 0x0000, DOC_WIN_SEG # starts in DoC > #endif /* STD_FLASH */ > ----------------------------------------------------------------------- > If it is not a DOC_MIL and bla, bla, bla ... we make a jmp to > 0xfe00:000, what is there in this direction ? > ----------------------------------------------------------------------- As I mentioned before, the DoC area is mapped multiple times at the top and bottom 2kB of the 8kB window. The 8kB window is than mapped by HW to 0xC0000-0xFFFF and 0xFFFC0000-0xFFFFFFFF. When jumping to fe00:0000, it jumps to one alias of the IPL area. > spl_vector: > .byte 0xea # jmp to 8000:0000, where SPL > .word 0x0000, SPL_RAM_SEG # (LinuxBIOS) starts in RAM > ----------------------------------------------------------------------- > And finally if it was a standard flash or DOC_MIL we jump to LinuxBios > in the segment 0x8000. In theory LinuxBios ?. > > My questions: > - May be the mapped EEPROM in memory address space is mapped in reverse > order (to find linuxbios in the firs 64Kb) ? 0x0 of EEPROM -> 0xFFFFFFFF. No, it is not. > - Who is executed first ipl.S, or crt0.S ? > My confusion are the ".org 0xfff0" in ipl.S but in the same time in > src/cpu/i386/reset["16","32"].inc i found some reference to reset_vector > but i don't know how it works , also by the other hand who turn the > memory in protected memory is crt0.S, then this has to be the first. > For SiS chipsets, the memory init is done in ipl.S instead of crt0.S so IPL is executed first. -- ollie lho From shubhangi.jadhav at patni.com Wed May 28 09:30:01 2003 From: shubhangi.jadhav at patni.com (Shubhangi Jadhav) Date: Wed May 28 09:30:01 2003 Subject: IRQ Problem !!! Message-ID: Hi, I got my motherboard to successfully boot with LinuxBIOS. It gets on the network with both the internet interface up and seems to asign the IRQ correctly in LinuxBIOS. ping is OK.However when I start a video streaming application which uses a Multimedia card(encoder)card on a PCI slot, the network goes out. This encoder card uses a fast interrupt and I have read that in such a case interrupt handlers run with all other interrupts disabled. Was wondering whether this is what is happening in my case. Is it that the ethernet interrupts get disabled whenever a fast interrupt comes up and then it is never enabled again? Any suggestions on what could be the possible solution? Regards, Shubhangi From rminnich at lanl.gov Wed May 28 10:25:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 28 10:25:00 2003 Subject: IRQ Problem !!! In-Reply-To: Message-ID: On Wed, 28 May 2003, Shubhangi Jadhav wrote: > I got my motherboard to successfully boot with LinuxBIOS. It gets > on the network with both the internet interface up and seems to asign > the IRQ correctly in LinuxBIOS. ping is OK.However when I start a video > streaming application which uses a Multimedia card(encoder)card on a PCI > slot, the network goes out. It is very important that you tell us what the motherboard is. ron From dinesh at shahmicro.com Wed May 28 10:30:01 2003 From: dinesh at shahmicro.com (Dinesh Shah) Date: Wed May 28 10:30:01 2003 Subject: HELP: VIA/EPIA Linux BIOS In-Reply-To: <20030526143915.C15751@mail.cwlinux.com> References: <20030523174855.GA2734@shahmicro.com> <20030526143915.C15751@mail.cwlinux.com> Message-ID: <20030528142641.GC1584@shahmicro.com> Hi Andrew and others, 1st thx Andrew for your reply. However, I have few doubts and questions as bellow. What I got - VIA EPIA MoBo with 800 MHz CPU and 2 MB Flash. What I want - Replace existing BIOS with LinuxBIOS. Put Linux Kernel on Flash. Put initrd image on flash. Make self contained minimal system on flash. What I know - How to compile my own kernel (2.4.x and 2.5.x) How to make initrd (uClibc and BusyBox) What I did in past - Made a boot floppy (1.44 MB) with BusyBox, ModUtils, IPTables, thttpd, ssh, uClibc and udhcp (kernel+initrd) What I think - BIOS+PIX+VidBIOS =< 384 KB (Within upper mem? from 640K to 1M Limits?) Have 1024 - 384 = 1664KB mem in Flash? The doubts are - Can I use that 1664 KB Flash to put Kernel+InitRD to make system self content? Can I put LinuxBIOS on BIOS and ask it to load my kernel and InitRD from Flash? Do I have to retain VidBIOS? Some of my apps need X Server? I need to retain VidBIOS for VESA 2.0 and VESA FB? The idea is to make the system self contained and not to depend on network for booting. Whenever I want the system to boot of the network I can use in-built PIX. I can also upgrade my Flash to 4 MB if every thing can not be put on 2 MB. Also I need to backup my existing BIOS+PIX+VidBIOS and restore if something goes wrong. I don't have access to DOS oe Win. What are my options? I know these are lots of questions. Thx in advance for your time and answers and pointers. With warm regards, On Mon, May 26, 2003 at 02:39:15PM +0800, Andrew Ip wrote: > Hi Dinesh, > > > While looking @ LinuxBIOS project web site I come across your name in > > status page. > > I need whatever help/pointer u can give about VIA/EPIA Flash BIOS. I > > need some how-to for puting Linux on 2/4 MB Flash which comes with MoBo. > > Any help/pinters will be greatly appreciated. > There is a README file under freebios/src/mainboard/via/epia for > describing how-to enable and write flash. IIRC, the latest > version of flash_rom (in src/utils/flash_and_burn) supports EPIA. > You can just use flash_rom to flash rom under Linux. > > -Andrew -- --Dinesh Shah :-) Dinesh at ShahMicro.com +91-98213-11906 +91-22-56919423 From rminnich at lanl.gov Wed May 28 10:44:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed May 28 10:44:00 2003 Subject: HELP: VIA/EPIA Linux BIOS In-Reply-To: <20030528142641.GC1584@shahmicro.com> Message-ID: On Wed, 28 May 2003, Dinesh Shah wrote: > Hi Andrew and others, > > 1st thx Andrew for your reply. > > However, I have few doubts and questions as bellow. > > What I got - > > VIA EPIA MoBo with 800 MHz CPU and 2 MB Flash. 2 Mbits, not 2 Mbytes. You can't put a kernel in there. If you want to do this, you have to get a compact-flash->ide adapter or similar and go that route. ron From ts1 at cma.co.jp Thu May 29 03:06:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu May 29 03:06:00 2003 Subject: HELP: VIA/EPIA Linux BIOS In-Reply-To: <20030528142641.GC1584@shahmicro.com> References: <20030523174855.GA2734@shahmicro.com> <20030526143915.C15751@mail.cwlinux.com> <20030528142641.GC1584@shahmicro.com> Message-ID: <20030529070627.GB4837@cma.co.jp> On Wed, May 28, 2003 at 07:56:41PM +0530, Dinesh Shah wrote: > The doubts are - > > Can I use that 1664 KB Flash to put Kernel+InitRD to make system > self content? > Can I put LinuxBIOS on BIOS and ask it to load my kernel and > InitRD from Flash? > Do I have to retain VidBIOS? Some of my apps need X Server? I > need to retain VidBIOS for VESA 2.0 and VESA FB? Currently VGA BIOS is needed to enable video of EPIA. I can boot my EPIA from LinuxBIOS with VGA BIOS into Linux then use tridentfb or XFree86. vesafb maybe needs some hack since it has real mode part to switch video mode and obtain information from BIOS, and ELF boot of LinuxBIOS doesn't execute real mode part of kernel (if I understand it correctly). Perhaps it works unmodified with ADLO? Kernel and initrd can be loaded from normal hard disk or CompactFlash on IDE. > The idea is to make the system self contained and not to depend on > network for booting. Whenever I want the system to boot of the network I > can use in-built PIX. What is PIX? We use Etherboot with LinuxBIOS to boot from network. > Also I need to backup my existing BIOS+PIX+VidBIOS and restore if > something goes wrong. I don't have access to DOS oe Win. What are my > options? I and some of us are using BIOS Savior (google for it if doubt) to backup BIOS. -- Takeshi From ebiederman at lnxi.com Thu May 29 08:14:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu May 29 08:14:00 2003 Subject: [linuxBios] HDD init problem In-Reply-To: <002501c31f85$3393edf0$525deecb@noshel> References: <002501c31f85$3393edf0$525deecb@noshel> Message-ID: =?ks_c_5601-1987?B?RWR3YXJkIExlZSBcKMDMwOW/+Fwp?= writes: > gee, are you mentioning disk_init() in pcbios.S ? > I just took a look at it, and I had to close the file > because it was in asm! (I'm really scared of asm, you see..) > When your done, I hope I could get a copy, badly :) > good luck! disk_init() is the old driver, that uses BIOS calls. The fact it is in pcbios.S should be a pretty good clue it isn't what you want. Under a normal LinuxBIOS configuration it is not even compiled in. Eric From ebiederman at lnxi.com Thu May 29 08:23:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu May 29 08:23:00 2003 Subject: [linuxBios] HDD init problem In-Reply-To: References: <002501c31f85$3393edf0$525deecb@noshel> Message-ID: Greg Watson writes: > No, I'm just working on pc80/ide/ide.c in the linuxbios tree. I need this for > the PPC port, so x86 asm code won't be of much help. Please look at src/drivers/disk/ide_disk.c in a etherboot-5.1 tree. It is a simpler and more correct driver. In some sense it is a derivative of pc80/ide/ide.c, as much as a complete rewrite can be derivative code. And there is no x86 asm. The important thing is the etherboot driver gets the ide spin up case correct. And it seems to handle a wider range of drives. Porting the etherboot driver back into LinuxBIOS is one of the todo list items. If you are brave a port of etherboot to the ppc would not be rejected. The only big problem is that etherboot currently does not run on any big endian architectures so there may be some endian problems in the etherboot code. Of course for most cases a little endian architecture is more likely to show problems so there should not be too many problems. The alignment problems should already be handled by the Itanium port. The cute thing of course would be to get openbios or some other implementation of open firmware running on top of LinuxBIOS. Giving linuxbios backwards compatibility on both Macs and PCs. Eric From spirit at reactor.ru Fri May 30 05:17:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Fri May 30 05:17:00 2003 Subject: SiS630 Watchdog driver Message-ID: <176866459412.20030530131747@reactor.ru> Hello guys! Coming back to the old topic of the SiS630 watchdog driver, I must say that I found a ready one. Available as a patch here: http://www.linuxlabs.com/LinuxBIOS/patches/sis630-wd-2.4.x.patch The driver is kind of 'risky' as it doesn't check for the presence of the SiS630 chipset but, in case if we're cautious, it may be working and useful. It would be nice if someone tested it as I don't have the board right now. With best regards, Alexander mailto:spirit at reactor.ru From bonboncat at sina.com Fri May 30 05:51:01 2003 From: bonboncat at sina.com (bonboncat8888) Date: Fri May 30 05:51:01 2003 Subject: help: serial port and keyboard not work Message-ID: <20030530095237.17681.qmail@sina.com> Hi, My mainboard is GX1+5530A+97317. After boot from linuxbios+linux-2.4.20, eth0 and USB work fine but keyboard not work and linux seems can't receive data from serial port(I can see output from SERIAL_CONSOLE). Please help me. Thanks! /////////////////////////////////////////////// LinuxBIOS-1.0.0 Fri May 30 17:07:05 CST 2003 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 1 DIMM size: 04000000 Probing for DIMM1 Memory sizing done, MC_BANK_CFG = 0x00701420 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Fri May 30 17:07:05 CST 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 [1078/0001] PCI: 00:0f.0 [10ec/8139] PCI: 00:12.0 [1078/0100] PCI: 00:12.1 [1078/0101] PCI: 00:12.2 [1078/0102] PCI: 00:12.3 [1078/0103] PCI: 00:12.4 [1078/0104] PCI: 00:13.0 [0e11/a0f8] PCI: pci_scan_bus returning with max=00 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:0f.0 10 <- [0x00001000 - 0x000010ff] io PCI: 00:0f.0 14 <- [0xfebfd000 - 0xfebfd0ff] mem PCI: 00:12.1 10 <- [0xfebfe000 - 0xfebfe0ff] mem PCI: 00:12.2 20 <- [0x00001400 - 0x0000147f] io PCI: 00:12.3 10 <- [0xfebff000 - 0xfebff07f] mem PCI: 00:12.4 10 <- [0xfebfb000 - 0xfebfbfff] mem PCI: 00:13.0 10 <- [0xfebfc000 - 0xfebfcfff] mem ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07 PCI: 00:0f.0 cmd <- 03 PCI: 00:12.0 cmd <- 0f PCI: 00:12.1 cmd <- 02 PCI: 00:12.2 cmd <- 01 PCI: 00:12.3 cmd <- 02 PCI: 00:12.4 cmd <- 03 PCI: 00:13.0 cmd <- 02 done. Initializing PCI devices... PCI devices initialized DIMM0: 64MB (4kB page size, 4 component banks, 1 module banks) DIMM1: empty Reserving 4096kB for video memory BC_DRAM_TOP = 0x03bfffff MC_GBASE_ADD = 0x00000078 totalram: 60M Initializing CPU #0 Enabling cache...done. Max cpuid index : 2 Vendor ID : Geode by NSC Processor Type : 0x00 Processor Family : 0x05 Processor Model : 0x04 Processor Mask : 0x00 Processor Stepping : 0x00 Feature flags : 0x00808131 Cache/TLB descriptor values: 1 reads required Desc 0x70 : UNKNOWN Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x80 : UNKNOWN Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null done. CPU #0 Initialized Enable FLASH Set F0/0x52 to 0xee cs5530: Enabling Primary IDE Controller cs5530: Enabling Secondary IDE Controller Set F0/0x5b to |= 1 << 5(0x38) Final southbridge fixup F0/5c: 0x0000 cs5530: PCI INTA=15, INTB=9, INTC=9, INTD=9 F0/5c: 0x999f 4d0: 0x00 4d1: 0x00 4d0: 0x00 4d1: 0x82 F0/5b = 0x38 cs5530: Enabling Primary IDE Controller F0/5b = 0x38 cs5530: USB is on INTA, IRQ 15 Final mainboard fixup nano: Setting eth0 IRQ to 9 Wrote linuxbios table at: 00000500 - 00000698 checksum 8bc9 Jumping to linuxbiosmain()... Welcome to start32, the open sourced starter. This space will eventually hold more diagnostic information. January 2000, James Hendricks, Dale Webster, and Ron Minnich. Version 0.1 Trying polled ide Waiting for ide disks to spin up This is a hard coded delay and longer than necessary. .clocks_per_usec: 264 . offset=00000200 I am now initializing the ide system UQNAUT MIFERABLLcl1t 050  init_drive: sectors_per_track=[63], num_heads=[15], num_cylinders=[10585] IDE0 15/10585/63 cap: 0f00 init_drive: sectors_per_track=[0], num_heads=[0], num_cylinders=[0] Controller 1: detect FAILED (1) Gunzip setup gunzip_setup output data is 0x00100000 Gunzipping boot code ................ <1023> command line - [vga=785 root=/dev/hda2 console=tty0 console=ttyS0,9600n8] Jumping to boot code Linux version 2.4.20 () (gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)) #6 Tue May 27 18:14:43 CST 2003 BIOS-provided physical RAM map: BIOS-e801: 0000000000000000 - 000000000009f000 (usable) BIOS-e801: 0000000000100000 - 0000000003b00000 (usable) 59MB LOWMEM available. On node 0 totalpages: 15104 zone(0): 4096 pages. zone(1): 11008 pages. zone(2): 0 pages. Kernel command line: vga=785 root=/dev/hda2 console=tty0 console=ttyS0,9600n8 Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs. Detected 200.455 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 399.76 BogoMIPS Memory: 57172k/60416k available (1323k kernel code, 2856k reserved, 333k data, 256k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Working around Cyrix MediaGX virtual DMA bugs. CPU: NSC Geode(TM) Integrated Processor by National Semi stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10) Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS not found. Starting kswapd Journalled Block Device driver loaded pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CS5530: IDE controller on PCI bus 00 dev 92 CS5530: detected chipset, but driver not compiled in! CS5530: chipset revision 0 CS5530: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1408-0x140f, BIOS settings: hdc:pio, hdd:pio hda: C/H/S=0/0/0 from BIOS ignored hda: QUANTUM FIREBALLlct10 05, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 blk: queue c0308544, I/O limit 4095Mb (mask 0xffffffff) hda: 10002825 sectors (5121 MB) w/418KiB Cache, CHS=10585/15/63, (U)DMA Partition check: hda: [PTBL] [622/255/63] hda1 hda2 hda3 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize loop: loaded (max 8 devices) 8139cp: 10/100 PCI Ethernet driver v0.3.0 (Sep 29, 2002) 8139cp: pci dev 00:0f.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip 8139cp: Try the "8139too" driver instead. 8139too Fast Ethernet driver 0.9.26 eth0: RealTek RTL8139 Fast Ethernet at 0xc4800000, 00:e0:4c:26:c6:fa, IRQ 9 SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.275 $ time 10:12:59 May 15 2003 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: v1.275:USB Universal Host Controller Interface driver usb-ohci.c: USB OHCI at membase 0xc4802000, IRQ 15 usb-ohci.c: usb-00:13.0, Compaq Computer Corporation ZFMicro Chipset USB usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 256k freed INIT: version 2.78 booting kernel loading successed. Checking flash file system... EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended Flash file system OK! INIT: Entering runlevel: 2 Loading network interface...eth0: Setting half-duplex based on auto-negotiated partner ability 0000. eth0: Too much work at interrupt, IntrStatus=0x0001. V1.0.1 command line interface version 1.0.127 login: ______________________________________ =================================================================== From rminnich at lanl.gov Fri May 30 09:19:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 30 09:19:00 2003 Subject: SiS630 Watchdog driver In-Reply-To: <176866459412.20030530131747@reactor.ru> Message-ID: On Fri, 30 May 2003, Alexander Amelkin wrote: > The driver is kind of 'risky' as it doesn't check for the presence > of the SiS630 chipset but, in case if we're cautious, it may be > working and useful. my standard patches in the kernel tree do check for the chipset, so you might want to look at them too. ron From rminnich at lanl.gov Fri May 30 19:21:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri May 30 19:21:00 2003 Subject: [9fans] 4-node plan9 cluster (fwd) Message-ID: just FYI, linuxbios + plan9 cluster. ron ---------- Forwarded message ---------- Date: Fri, 30 May 2003 13:31:32 -0600 (MDT) From: andrey mirtchovski Reply-To: 9fans at cse.psu.edu To: 9fans at cse.psu.edu Subject: [9fans] 4-node plan9 cluster this is the cluster Ron will show on usenix: http://pages.cpsc.ucalgary.ca/~mirtchov/p9/cluster/ andrey From adam at cfar.umd.edu Fri May 30 20:27:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri May 30 20:27:01 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: Message-ID: <20030530202317.M14739-100000@www.missl.cs.umd.edu> > just FYI, linuxbios + plan9 cluster. > > this is the cluster Ron will show on usenix: > > http://pages.cpsc.ucalgary.ca/~mirtchov/p9/cluster/ Whoa. pretty nice! For that matter, I'm curious who else from LinuxBIOS list will be at USENIX. I know that as far as ADLO goes all 4 authors will be around. That is me (Adam Sulmicki), Ron Minnich, Adam Agnew and Bill Arbaugh. Adam Agnew will have honors to present our paper on Open Source Stackable BIOS (Freenix track, Friday). Everyone is welcome to our presentation and I hope to meet people from the list in person :-) Adam, on the Internet you never know if you are talking to someone else or just smart script :-P -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From hansolofalcon at worldnet.att.net Fri May 30 20:52:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Fri May 30 20:52:00 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: <20030530202317.M14739-100000@www.missl.cs.umd.edu> Message-ID: <001901c3270f$390f42c0$0100a8c0@who5> Hello again from Gregg C Levine Well, I saw the photos, on the web site. I'm impressed. I do wish I could attend this years, conference. However, will this cluster, be visiting next year's LWE here, in Manhattan? Oh and Adam, I already know that the both of you, are real people. And Ron. Along with Eric. But, I believe any six of the names on the list, are actually AIs at work. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Adam Sulmicki > Sent: Friday, May 30, 2003 8:29 PM > To: ron minnich > Cc: linuxbios at clustermatic.org > Subject: Re: [9fans] 4-node plan9 cluster (fwd) > > > > just FYI, linuxbios + plan9 cluster. > > > > this is the cluster Ron will show on usenix: > > > http://pages.cpsc.ucalgary.ca/~mirtchov/p9/cluster/ > > Whoa. pretty nice! > > For that matter, I'm curious who else from LinuxBIOS list will be at > USENIX. > > I know that as far as ADLO goes all 4 authors will be around. That is me > (Adam Sulmicki), Ron Minnich, Adam Agnew and Bill Arbaugh. Adam Agnew will > have honors to present our paper on Open Source Stackable BIOS (Freenix > track, Friday). > > Everyone is welcome to our presentation and I hope to meet people from the > list in person :-) > > Adam, > on the Internet you never know if you are talking to someone else or just > smart script :-P > > > -- > Adam Sulmicki > http://www.eax.com The Supreme Headquarters of the 32 bit registers > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From aip at cwlinux.com Fri May 30 22:02:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri May 30 22:02:00 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: <20030530202317.M14739-100000@www.missl.cs.umd.edu>; from Adam Sulmicki on Fri, May 30, 2003 at 08:29:26PM -0400 References: <20030530202317.M14739-100000@www.missl.cs.umd.edu> Message-ID: <20030531100332.A18884@mail.cwlinux.com> > Everyone is welcome to our presentation and I hope to meet people from the > list in person :-) Well, I would like to, but it is too far for me. :) Do you have the presentation on web? -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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From adam at cfar.umd.edu Fri May 30 22:09:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Fri May 30 22:09:01 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: <20030531100332.A18884@mail.cwlinux.com> Message-ID: <20030530221130.O14972-100000@www.missl.cs.umd.edu> On Sat, 31 May 2003, Andrew Ip wrote: > > Everyone is welcome to our presentation and I hope to meet people from the > > list in person :-) > Well, I would like to, but it is too far for me. :) Do you have the > presentation on web? We should have our paper on-line sometime after the conference. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ts1 at tsn.or.jp Sat May 31 11:11:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sat May 31 11:11:01 2003 Subject: [PATCH] XIP for low address (0xf0000) support Message-ID: <20030531151300.GA16585@tsn.or.jp> Ron, please apply this patch. It should not break anything, and significantly speeds up booting of certain boards like EPIA. This patch does two things: - Add write-through cache for 0xf0000-0xfffff before uncompressing linuxbios_c, if option XIP_LOW is defined. - Changes existing XIP (execute in place) code to use write-through cache instead of write-protect cache. (as Eric suggested) -- Takeshi Index: earlymtrr.inc =================================================================== RCS file: /cvsroot/freebios/freebios/src/cpu/p6/earlymtrr.inc,v retrieving revision 1.4 diff -u -r1.4 earlymtrr.inc --- earlymtrr.inc 8 Aug 2001 02:45:09 -0000 1.4 +++ earlymtrr.inc 31 May 2003 14:59:56 -0000 @@ -35,6 +35,22 @@ movl $0x06060606, %edx movl $0x06060606, %eax wrmsr + +#ifdef XIP_LOW + /* enable write through cache for 0xf0000-0xfffff*/ + movl $MTRRfix4K_F0000_MSR, %ecx + rdmsr + movl $0x04040404, %edx + movl $0x04040404, %eax + wrmsr + + movl $MTRRfix4K_F8000_MSR, %ecx + rdmsr + movl $0x04040404, %edx + movl $0x04040404, %eax + wrmsr +#endif /* XIP_LOW */ + #endif /* MEMORY_HOLE */ set_var_mtrr: @@ -56,12 +72,12 @@ wrmsr #if defined(XIP_ROM_SIZE) && defined(XIP_ROM_BASE) - /* enable write protect caching so we can do execute in place + /* enable write through caching so we can do execute in place * on the flash rom. */ movl $0x202, %ecx xorl %edx, %edx - movl $(XIP_ROM_BASE | 0x005), %eax + movl $(XIP_ROM_BASE | 0x004), %eax wrmsr movl $0x203, %ecx From rminnich at lanl.gov Sat May 31 15:26:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat May 31 15:26:01 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: <20030530202317.M14739-100000@www.missl.cs.umd.edu> Message-ID: linuxbios bof, anyone? ron From agnew at cs.umd.edu Sat May 31 15:37:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Sat May 31 15:37:00 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: Message-ID: <20030531153328.B19659-100000@www.missl.cs.umd.edu> A fine idea. On Sat, 31 May 2003, ron minnich wrote: > linuxbios bof, anyone? > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From adam at cfar.umd.edu Sat May 31 15:42:15 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Sat May 31 15:42:15 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: Message-ID: <20030531153730.R19825-100000@www.missl.cs.umd.edu> > linuxbios bof, anyone? count me in. I think that's cool idea :) -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From hansolofalcon at worldnet.att.net Sat May 31 16:37:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Sat May 31 16:37:01 2003 Subject: [9fans] 4-node plan9 cluster (fwd) In-Reply-To: <20030531153328.B19659-100000@www.missl.cs.umd.edu> Message-ID: <000101c327b4$c3378ca0$0100a8c0@who5> Hello again from Gregg C Levine Oh yes. A very good idea. But we need to select a time. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."? Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: linuxbios-admin at clustermatic.org [mailto:linuxbios- > admin at clustermatic.org] On Behalf Of Adam Agnew > Sent: Saturday, May 31, 2003 3:40 PM > To: ron minnich > Cc: waa at cs.umd.edu; Adam Sulmicki; linuxbios at clustermatic.org > Subject: Re: [9fans] 4-node plan9 cluster (fwd) > > A fine idea. > > On Sat, 31 May 2003, ron minnich wrote: > > > linuxbios bof, anyone? > > > > ron > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios