From niki.waibel at newlogic.com Mon Sep 1 11:11:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Sep 1 11:11:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte Message-ID: <200309011529.h81FT4ZS013565@enterprise2.newlogic.at> i am still trying to get this running: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte it took quite long until all parts arrived. anyway. the current problem is that if i plug the dip2plcc adapter into the bios savior socket epia-m does not boot anymore... (of course i've written the bios to the bios savior plcc chip before). that's very strange -- i am going to check the pins of the adapter. i've 2 adapters. both refuse to work with the board. maybe this is a high frequency electrical problem... does someone know in which "speed" the bios is accessed? niki From ebiederman at lnxi.com Mon Sep 1 19:05:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 1 19:05:01 2003 Subject: [COMMIT] Infrastructure update 1 Message-ID: Giant monolithic changes are dangerous and hard to track down so I am updating the infrastructure in small steps where everything should continue to work. If there are problems it becomes easier to track things down. This first change is the set of changes that gets the new configuration working for me. Until we starting doing something better with the development branch I bumping the version number and tagging each chunk of changes. So linuxbios_1_1_0 is tagged just before I started doing anything. And this set of changes is tagged linuxbios_1_1_1 Eric - Updates to config.g so that it works more reliably and has initial support for paths - Renamed some configuration variables SMP -> CONFIG_SMP MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS - Removed some dead configuration variables MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS SMP -> CONFIG_SMP FINAL_MAINBOARD_FIXUP SIO_BASE SIO_SYSTEM_CLK_INPUT NO_KEYBOARD USE_NORMAL_IMAGE SERIAL_CONSOLE USE_ELF_BOOT ENABLE_FIXED_AND_VARIABLE_MTRRS START_CPU_SEG DISABLE_WATCHDOG ENABLE_IOMMU AMD8111_DEV - Removed some assembly files that are no longer needed killed src/southbridge/amd/amd8111/smbus.inc killed src/southbrideg/amd/amd8111/cmos_boot_failover.inc killed src/ram/ramtest.inc - Updates to config.g so that it works more reliably and has initial support for paths - Renamed some configuration variables SMP -> CONFIG_SMP MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS - Removed some dead configuration variables MAX_CPUS -> CONFIG_MAX_CPUS MAX_PHYSICAL_CPUS -> CONFIG_MAX_PHYSICAL_CPUS SMP -> CONFIG_SMP FINAL_MAINBOARD_FIXUP SIO_BASE SIO_SYSTEM_CLK_INPUT NO_KEYBOARD USE_NORMAL_IMAGE SERIAL_CONSOLE USE_ELF_BOOT ENABLE_FIXED_AND_VARIABLE_MTRRS START_CPU_SEG DISABLE_WATCHDOG ENABLE_IOMMU AMD8111_DEV - Removed some assembly files that are no longer needed killed src/southbridge/amd/amd8111/smbus.inc killed src/southbrideg/amd/amd8111/cmos_boot_failover.inc killed src/ram/ramtest.inc killed src/sdram/generic_dump_spd.inc killed src/sdram/generic_dump_spd.inc - Updated the arima/hdama to build with the new configuration system - Updated config.g to list all of the variables with make echo CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS documentation/RFC/config.tex src/arch/i386/boot/tables.c CVS: src/arch/i386/config/make.base CVS: src/arch/i386/include/arch/smp/mpspec.h CVS: src/arch/i386/lib/c_start.S src/arch/i386/smp/mpspec.c CVS: src/arch/i386/smp/secondary.S src/arch/i386/smp/start_stop.c CVS: src/arch/ppc/config/make.base src/boot/hardwaremain.c CVS: src/config/Config src/config/Options.lb CVS: src/config/linuxbios_c.ld src/include/device/device.h CVS: src/mainboard/amd/quartet/Config CVS: src/mainboard/amd/quartet/Config.lb CVS: src/mainboard/amd/quartet/auto.c CVS: src/mainboard/amd/quartet/example-fallback.config CVS: src/mainboard/amd/quartet/example-normal.config CVS: src/mainboard/amd/quartet/mainboard.c CVS: src/mainboard/amd/solo/Config src/mainboard/amd/solo/Config.lb CVS: src/mainboard/amd/solo/example-fallback.config CVS: src/mainboard/amd/solo/example-normal.config CVS: src/mainboard/amd/solo/mainboard.c CVS: src/mainboard/arima/hdama/Config CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/auto.c CVS: src/mainboard/arima/hdama/example-fallback.config CVS: src/mainboard/arima/hdama/example-normal.config CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/motorola/sandpoint/Config CVS: src/mainboard/motorola/sandpoint/example-altimus.config CVS: src/mainboard/motorola/sandpoint/hardwaremain.c CVS: src/mainboard/newisys/khepri/Config.lb CVS: src/mainboard/newisys/khepri/auto.c CVS: src/mainboard/newisys/khepri/mainboard.c CVS: src/mainboard/tyan/s2880/Config CVS: src/mainboard/tyan/s2880/Config.lb CVS: src/mainboard/tyan/s2880/mainboard.c CVS: src/mainboard/tyan/s2880/tyan-fallback.config CVS: src/mainboard/tyan/s2880/tyan-normal.config CVS: src/mainboard/tyan/s2882/Config CVS: src/mainboard/tyan/s2882/Config.lb CVS: src/mainboard/tyan/s2882/mainboard.c CVS: src/mainboard/tyan/s2882/tyan-fallback.config CVS: src/mainboard/tyan/s2882/tyan-normal.config CVS: src/mainboard/tyan/s2885/Config CVS: src/mainboard/tyan/s2885/Config.lb CVS: src/mainboard/tyan/s2885/mainboard.c CVS: src/mainboard/tyan/s2885/tyan-fallback.config CVS: src/mainboard/tyan/s2885/tyan-normal.config CVS: src/northbridge/amd/amdk8/coherent_ht.c CVS: src/northbridge/amd/amdk8/raminit.c CVS: targets/arima/hdama/Config.lb CVS: targets/embeddedplanet/ep405pc/Config.lb CVS: targets/motorola/sandpoint/Config.lb CVS: targets/tyan/s2880/Config.lb targets/tyan/s2882/Config.lb CVS: targets/tyan/s2885/Config.lb util/config/NLBConfig.py CVS: util/newconfig/config.g CVS: Removed Files: CVS: src/ram/ramtest.inc src/sdram/generic_dump_spd.inc CVS: src/southbridge/amd/amd8111/cmos_boot_failover.inc CVS: src/southbridge/amd/amd8111/smbus.inc CVS: ---------------------------------------------------------------------- From ebiederman at lnxi.com Mon Sep 1 19:39:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 1 19:39:00 2003 Subject: [COMMIT] Infrastructure Update 2 Message-ID: - 1.1.2 Add back in the hard_reset method from freebios1 this allows generic code to reset the box. Update the hypertransport setup code to automatically optimize hypertransport link widths and frequencies, and to call hard_reset if necessary for the changes to go into effect. From rminnich at lanl.gov Mon Sep 1 21:18:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 1 21:18:00 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: <200309011529.h81FT4ZS013565@enterprise2.newlogic.at> Message-ID: On Mon, 1 Sep 2003, Niki Waibel wrote: > i am still trying to get this running: > epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte that won't work with the normal bios. You will also have trouble getting it working with linuxbios, due to the chipset issues. If there is a huge demand for this we can open up that issue again and try it again. ron From rminnich at lanl.gov Mon Sep 1 21:37:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 1 21:37:00 2003 Subject: [COMMIT] Infrastructure update 1 In-Reply-To: Message-ID: On 1 Sep 2003, Eric W. Biederman wrote: > > Giant monolithic changes are dangerous and hard to track > down so I am updating the infrastructure in small steps where > everything should continue to work. If there are problems > it becomes easier to track things down. This first change is > the set of changes that gets the new configuration working for me. I'll test tomorrow. thanks, I took a look and it's reasonable. ron From ebiederman at lnxi.com Mon Sep 1 23:21:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 1 23:21:01 2003 Subject: [COMMIT] Infrastructure Updates 3 Message-ID: At this point all of the major infrastructure changes. The next group of changes will start taking advantage of them to handle hypertransport more cleanly and dynamically. - Major update of the dynamic device tree so it can handle * subtractive resources * merging with the static device tree * more device types than just pci - The piece to watch out for is the new enable_resources method that was needed in all of the drivers Eric CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS src/arch/i386/lib/pci_ops.c src/arch/ppc/lib/pci_ops.c CVS: src/boot/hardwaremain.c src/config/Config CVS: src/config/Options.lb src/devices/Config.lb src/devices/chip.c CVS: src/devices/device.c src/devices/device_util.c CVS: src/devices/pci_device.c src/include/device/chip.h CVS: src/include/device/device.h src/include/device/pci.h CVS: src/include/device/resource.h CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/tyan/s2880/adaptec_scsi.c CVS: src/mainboard/tyan/s2880/intel_nic.c CVS: src/mainboard/tyan/s2880/promise_sata.c CVS: src/mainboard/tyan/s2882/adaptec_scsi.c CVS: src/mainboard/tyan/s2882/intel_nic.c CVS: src/mainboard/tyan/s2882/si_sata.c CVS: src/mainboard/tyan/s2885/adaptec_scsi.c CVS: src/mainboard/tyan/s2885/broadcom_nic.c CVS: src/mainboard/tyan/s2885/intel_nic.c CVS: src/mainboard/tyan/s2885/si_sata.c CVS: src/mainboard/tyan/s2885/ti_firewire.c CVS: src/southbridge/amd/amd8111/amd8111_acpi.c CVS: src/southbridge/amd/amd8111/amd8111_ide.c CVS: src/southbridge/amd/amd8111/amd8111_lpc.c CVS: src/southbridge/amd/amd8111/amd8111_usb.c CVS: src/southbridge/amd/amd8111/amd8111_usb2.c CVS: src/southbridge/amd/amd8131/amd8131_bridge.c CVS: src/southbridge/amd/amd8151/amd8151_agp3.c CVS: CVS: Committing in . CVS: CVS: Added Files: CVS: src/devices/root_device.c src/include/device/path.h CVS: ---------------------------------------------------------------------- From niki.waibel at newlogic.com Tue Sep 2 03:39:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 2 03:39:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: Message-ID: <200309020756.h827ucZS007043@enterprise2.newlogic.at> >> i am still trying to get this running: >> epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte > > that won't work with the normal bios. that's clear. but right now i have epia-m + bios savior + dip2plcc adapter (without doc millennium 8mbyte). bios savior is switched to its internal bios chip (which works (burned the orig bios) if there is only epia-m + bios savior). but if i plug the dip2plcc adapter (without touching the switch on bios savior) then the system does not boot anymore. that is very strange, isn't it? > You will also have trouble getting > it working with linuxbios, due to the chipset issues. that is what i expect. > If there is a huge demand for this we can open up that issue again and try > it again. so someone should start digging into this :) From leon.woestenberg at gmx.net Tue Sep 2 04:57:00 2003 From: leon.woestenberg at gmx.net (Leon Woestenberg) Date: Tue Sep 2 04:57:00 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte References: Message-ID: <006a01c37132$a89caed0$0100a8c0@campus.tue.nl> > > epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte > > that won't work with the normal bios. You will also have trouble getting > it working with linuxbios, due to the chipset issues. > > If there is a huge demand for this we can open up that issue again and try > it again. > In general, I think EPIA-M support would be great for lots of people. EPIA-{EM6000|M9000|M10000} to be precise. I will continue to see why the EM6000 has a wrong baudrate setting on the serial port, booting LinuxBIOS. Regards, Leon. From niki.waibel at newlogic.com Tue Sep 2 06:24:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 2 06:24:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte Message-ID: <200309021041.h82AfwZS028790@enterprise2.newlogic.at> i checked the dip2plcc adapter -- everything is fine. all pins are connected properly. is it possible that this does not work because the wires are too long (bios savior + dip2plcc adapter)? would it help to reduce the clockrate of the epia-m? does someone know how that could be done? it is okay if i boot without dip2plcc converter and then plug it on top of the bios savior. i am going to try booting linux and then place only dip2plcc conv + doc mill. see if the mtd is detected. niki From rminnich at lanl.gov Tue Sep 2 09:02:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 09:02:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: <200309020756.h827ucZS007043@enterprise2.newlogic.at> Message-ID: On Tue, 2 Sep 2003, Niki Waibel wrote: > but right now i have > epia-m + bios savior + dip2plcc adapter > (without doc millennium 8mbyte). bios savior is switched to its internal bios chip > (which works (burned the orig bios) if there is only epia-m + bios savior). but if > i plug the dip2plcc adapter (without touching the switch on bios savior) then the > system does not boot anymore. anybody remember what part is on the savior? ron From rminnich at lanl.gov Tue Sep 2 09:03:02 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 09:03:02 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: <200309021041.h82AfwZS028790@enterprise2.newlogic.at> Message-ID: On Tue, 2 Sep 2003, Niki Waibel wrote: > is it possible that this does not work because the wires are > too long (bios savior + dip2plcc adapter)? it is asynch. logic last time I checked. It could still be a timing issue however. > it is okay if i boot without dip2plcc converter and > then plug it on top of the bios savior. > i am going to try booting linux and then place only > dip2plcc conv + doc mill. > see if the mtd is detected. good idea. ron From niki.waibel at newlogic.com Tue Sep 2 09:59:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 2 09:59:00 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: Message-ID: <200309021417.h82EH1ZS026695@enterprise2.newlogic.at> >> but right now i have >> epia-m + bios savior + dip2plcc adapter >> (without doc millennium 8mbyte). bios savior is switched to its internal bios chip >> (which works (burned the orig bios) if there is only epia-m + bios savior). but if >> i plug the dip2plcc adapter (without touching the switch on bios savior) then the >> system does not boot anymore. > > anybody remember what part is on the savior? had a tricky look behind the sticker: winbond w29c020cp90b in the PL version of bios savior. niki From niki.waibel at newlogic.com Tue Sep 2 10:10:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 2 10:10:00 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: Message-ID: <200309021427.h82ERcZS028004@enterprise2.newlogic.at> >> is it possible that this does not work because the wires are >> too long (bios savior + dip2plcc adapter)? > > it is asynch. logic last time I checked. > > It could still be a timing issue however. > >> it is okay if i boot without dip2plcc converter and >> then plug it on top of the bios savior. >> i am going to try booting linux and then place only >> dip2plcc conv + doc mill. >> see if the mtd is detected. > > good idea. hmmm -- modprobe docprobe doc_config_location=0xFFFFe000 (is this the right way to check it?) reports: 0E: bios savior with orig rom (i010010f.bin) without dip2plcc (switched to internal rom) OE: bios savior with orig rom (i010010f.bin) + dip2plcc + doc (switched to internal rom) 00: bios savior with orig rom (i010010f.bin) + dip2plcc + doc (switched to external rom) FF: nothing in the bios socket 00: dip2plcc + doc in the bios socket hmm -- 00 ... seems to be ok in both cases... or should it be sthg else? is doc_config_location=0xFFFFe000 corect? niki From niki.waibel at newlogic.com Tue Sep 2 10:25:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 2 10:25:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: <200309021427.h82ERcZS028004@enterprise2.newlogic.at> Message-ID: <200309021443.h82EhCZS029924@enterprise2.newlogic.at> >>> is it possible that this does not work because the wires are >>> too long (bios savior + dip2plcc adapter)? >> >> it is asynch. logic last time I checked. >> >> It could still be a timing issue however. >> >>> it is okay if i boot without dip2plcc converter and >>> then plug it on top of the bios savior. >>> i am going to try booting linux and then place only >>> dip2plcc conv + doc mill. >>> see if the mtd is detected. >> >> good idea. > > hmmm -- > modprobe docprobe doc_config_location=0xFFFFe000 > (is this the right way to check it?) > reports: > 0E: bios savior with orig rom (i010010f.bin) without dip2plcc (switched to internal rom) > OE: bios savior with orig rom (i010010f.bin) + dip2plcc + doc (switched to internal rom) > 00: bios savior with orig rom (i010010f.bin) + dip2plcc + doc (switched to external rom) > FF: nothing in the bios socket > 00: dip2plcc + doc in the bios socket > hmm -- 00 ... seems to be ok in both cases... > or should it be sthg else? > is doc_config_location=0xFFFFe000 corect? maybe this has sthg to do with the reset state of the doc mill... maybe that confuses the bios savior... no. not possible, because then it would work with bios savior +dip2plcc -doc... all this is very strange to me. niki From rminnich at lanl.gov Tue Sep 2 11:19:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 11:19:00 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: <200309021417.h82EH1ZS026695@enterprise2.newlogic.at> Message-ID: I think the 90 refers to speed, and I note that in my EPIA the part is a -70. This may be part of the problem. ron From YhLu at tyan.com Tue Sep 2 12:02:01 2003 From: YhLu at tyan.com (YhLu) Date: Tue Sep 2 12:02:01 2003 Subject: Unified setup... Message-ID: <3174569B9743D511922F00A0C9431423031889B0@TYANWEB> Then, the setup scripts tool should include that support and should have support for auto.c too. YH -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?8?29? 4:48 ???: YhLu ??: linuxbios at clustermatic.org ??: Re: Unified setup... * YhLu [030828 23:36]: > PS: > - PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000, > + PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000, > [..] > - PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000, > + PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000, > > should be there. It defines the bus number behind the links. It will be used > when enumerating the non-coherent devices. I agree. But maybe we find a nicer way of describing this. Are these "hard coded" in hardware? The motherboard configuration should then probably contain a busnumber value for each ht bridge that implements a pci bus southbridge amd/amd8131 "amd8131" register "bus0" = "5" end southbridge amd/amd8151 "amd8151" register "bus0" = "3" end Or should this be handled distinct from the bridges with options like option BUS1=99 option BUS2=5 ? Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Tue Sep 2 12:39:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 2 12:39:01 2003 Subject: Unified setup... In-Reply-To: <3174569B9743D511922F00A0C9431423031889B0@TYANWEB> References: <3174569B9743D511922F00A0C9431423031889B0@TYANWEB> Message-ID: <20030902165505.GA9977@suse.de> * YhLu [030902 18:18]: > Then, the setup scripts tool should include that support and should have > support for auto.c too. > > YH > > southbridge amd/amd8131 "amd8131" > register "bus0" = "5" > end > > southbridge amd/amd8151 "amd8151" > register "bus0" = "3" > end currently the code that is generated (static.c) consists all of global structs that are not directly usable with romcc code. looking at the needs of auto.c it might be worth it adding a new writeromccstructs definition that dumps into the right files and is only called "on architectures that have romcc support" ;) When i.e. generating hypertransport routing tables it would be nice to have those directly generated in config.g. but then again, this adds up a lot of cpu dependent magic to the config tool. What about having part specific configuration output in src////config.py i.e. have the opteron northbridge specific code that creates ht tables and writes auto.c's mem_controller struct in src/northbridge/amd/amdk8/Config.py. That would keep the configuration utility reasonably small and enhancable while have the actual config file creator for each of the components at the same place as the other code parts belonging to that component. Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Tue Sep 2 13:03:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 13:03:00 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: OK. With this update I start taking advantage of the infrastructure changes I have been making with the merged trees to dynamically allocate superio device resources, and to enumerate hypertranport devices. The code is still rough around the edges but the basic ideas are there. If you want all of your hypertransport devices to be on bus 0, that is feasible but it will take a little more work. Right now each hypertranport chain get's it's own bus. Mostly I have updated the arima/hdama the rest of the boards I have only modified enough that they still function. OK Now I'm off to bug fix land for a few days. - 1.1.4 Major restructuring of hypertransport handling. Major rewerite of superio/NSC/pc87360 as a proof of concept for handling superio resources dynamically Updates to hard_reset handling when resetting because of the need to change hypertransport link speeds and widths. (a) No longer assume the boot is good just because we get to a hard reset point. (b) Set a flag to indicate that the BIOS triggered the reset so we don't decrement the boot counter. Updates to arima/hdama mptable so it tracks the new bus numbers Eric CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS src/config/Config src/config/Options.lb CVS: src/devices/Config.lb src/devices/pci_device.c CVS: src/include/device/device.h CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/arima/hdama/mptable.c CVS: src/mainboard/arima/hdama/reset.c CVS: src/northbridge/amd/amdk8/Config.lb CVS: src/northbridge/amd/amdk8/northbridge.c CVS: src/northbridge/amd/amdk8/reset_test.c CVS: src/superio/NSC/pc87360/superio.c CVS: Added Files: CVS: src/devices/hypertransport.c CVS: src/include/device/hypertransport.h CVS: src/northbridge/amd/amdk8/chip.h CVS: src/northbridge/amd/amdk8/misc_control.c CVS: src/northbridge/amd/amdk8/northbridge.h CVS: ---------------------------------------------------------------------- From ebiederman at lnxi.com Tue Sep 2 15:11:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 15:11:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030902204711.A26490@suse.de> References: <20030902204711.A26490@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030902 19:28]: > > If you want all of your hypertransport devices to be on bus 0, that is > > feasible but it will take a little more work. Right now each > > hypertranport chain get's it's own bus. > > What is missing to achieve this? Just a little code. Merging busses into bus 0 is an interesting logicistics feat, but the current infrastructure will allow it. > Can this cause trouble with current board implementations? Not it is software only. > In the Tyan update code, some hardcoded bus numbers were changed. We should be able to complete remove that. Right now each Hypertransport chains appears to be it's own bus and all of that information is dynamically calculated. The busses that are Hypertranpsort chains are enumerated just like other busses. The way to look at the code is that: - device.c has the logic to enumerate and assign resources to devices and busses. - pci_device.c has the methods for doing that on pci devices. - hypertransport.c has the methods for doing that with hypertranport devices. - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge. In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes. I have committed the code not in a final perfect state. But in a state where it works well enough to be useful. And whatever details we encounter are minor things. Passing information to the dynamic device tree from the static device tree is currently a weak area. But we are building one tree from the other so it is just a matter of a small amount of refactoring if we want to do something better. Basically what remains is to dive into the code see what it is doing, and tweak it a little if is not doing quite the right thing. But usually all that needs to happen is to improve a method of a device so that it operates better. Eric From rminnich at lanl.gov Tue Sep 2 15:14:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 15:14:01 2003 Subject: coding Message-ID: anybody object to anonymous enums? I've gotten used to them in Plan 9 and like them. Instead of this: #define FLOPPY_DEVICE 0 #define PARALLEL_DEVICE 1 #define COM2_DEVICE 2 #define COM1_DEVICE 3 #define SWC_DEVICE 4 #define MOUSE_DEVICE 5 #define KBC_DEVICE 6 #define GPIO_DEVICE 7 #define ACB_DEVICE 8 #define FSCM_DEVICE 9 #define WDT_DEVICE 10 you get this: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE }; The advantages I see - somewhat less prone to error - looks nicer - the big one: enums are first-class objects to the compiler, and #defines are pertty much ripped out by the compiler and disappear into constant numbers. comments? ron From rminnich at lanl.gov Tue Sep 2 15:18:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 15:18:01 2003 Subject: coding In-Reply-To: Message-ID: On Tue, 2 Sep 2003, ron minnich wrote: > The advantages I see > - somewhat less prone to error > - looks nicer > - the big one: enums are first-class objects to the compiler, and > #defines are pertty much ripped out by the compiler and disappear --------------------------->PRE-PROCESSOR > into constant numbers. error, sorry. ron From ebiederman at lnxi.com Tue Sep 2 15:25:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 15:25:01 2003 Subject: coding In-Reply-To: References: Message-ID: ron minnich writes: > anybody object to anonymous enums? I've gotten used to them in Plan 9 and > like them. Instead of this: > > #define FLOPPY_DEVICE 0 > #define PARALLEL_DEVICE 1 > #define COM2_DEVICE 2 > #define COM1_DEVICE 3 > #define SWC_DEVICE 4 > #define MOUSE_DEVICE 5 > #define KBC_DEVICE 6 > #define GPIO_DEVICE 7 > #define ACB_DEVICE 8 > #define FSCM_DEVICE 9 > #define WDT_DEVICE 10 > > you get this: > enum { > FLOPPY_DEVICE=0, > PARALLEL_DEVICE, > COM2_DEVICE, > COM1_DEVICE, > SWC_DEVICE, > MOUSE_DEVICE, > KBC_DEVICE, > GPIO_DEVICE, > ACB_DEVICE, > FSCM_DEVICE, > WDT_DEVICE > }; > > The advantages I see > - somewhat less prone to error > - looks nicer > - the big one: enums are first-class objects to the compiler, and > #defines are pertty much ripped out by the compiler and disappear > into constant numbers. I have no strong preference, but I am used to using defines. In this case as these numbers are magic constants not an enumeration, so I think an enumeration is much more likely to be error prone. Those are the logical device numbers on the superio chip, and they cannot. Beyond which before I start using enums very much I want to get them implemented in romcc. Those and constant pointers are some of the last missing features, that can reasonably be added. After that I could look at compiling static.c with romcc.... The one thing I do get grumpy about are less then 8 space indents, so I would get: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE }; It's pretty much a case of if you are going to use whitespace you might as well use enough of it that you can see. For this case though I am pretty certain that enums are more error prone as the encourage the myth that you can change the value. Eric From rjwalsh at durables.org Tue Sep 2 15:38:01 2003 From: rjwalsh at durables.org (Robert Walsh) Date: Tue Sep 2 15:38:01 2003 Subject: coding In-Reply-To: References: Message-ID: <1062532579.9879.1.camel@hematite> > enum { > FLOPPY_DEVICE=0, > PARALLEL_DEVICE, > COM2_DEVICE, > COM1_DEVICE, > SWC_DEVICE, > MOUSE_DEVICE, > KBC_DEVICE, > GPIO_DEVICE, > ACB_DEVICE, > FSCM_DEVICE, > WDT_DEVICE > }; If you're going to stick with an enum, why not put a comma after the last entry, so diffs look cleaner later on: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE, }; Regards, Robert. From gwatson at lanl.gov Tue Sep 2 15:40:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Tue Sep 2 15:40:01 2003 Subject: coding In-Reply-To: References: Message-ID: At 1:32 PM -0600 2/9/03, ron minnich wrote: >anybody object to anonymous enums? I've gotten used to them in Plan 9 and >like them. Instead of this: > >#define FLOPPY_DEVICE 0 >#define PARALLEL_DEVICE 1 >#define COM2_DEVICE 2 >#define COM1_DEVICE 3 >#define SWC_DEVICE 4 >#define MOUSE_DEVICE 5 >#define KBC_DEVICE 6 >#define GPIO_DEVICE 7 >#define ACB_DEVICE 8 >#define FSCM_DEVICE 9 >#define WDT_DEVICE 10 > >you get this: >enum { > FLOPPY_DEVICE=0, > PARALLEL_DEVICE, > COM2_DEVICE, > COM1_DEVICE, > SWC_DEVICE, > MOUSE_DEVICE, > KBC_DEVICE, > GPIO_DEVICE, > ACB_DEVICE, > FSCM_DEVICE, > WDT_DEVICE >}; > >The advantages I see >- somewhat less prone to error >- looks nicer >- the big one: enums are first-class objects to the compiler, and > #defines are pertty much ripped out by the compiler and disappear > into constant numbers. > > >comments? > >ron I think they work well when you have a sequence of numbers like this, but I would rather see each enum explicitly given it's value as in: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE=1, COM2_DEVICE=2, COM1_DEVICE=3, SWC_DEVICE=4, MOUSE_DEVICE=5, KBC_DEVICE=6, GPIO_DEVICE=7, ACB_DEVICE=8, FSCM_DEVICE=9, WDT_DEVICE=10 }; Otherwise you're forever trying to work out what the actual value is. Where it doesn't work is when you have a bunch of random defines with unrelated values, or values that jump about all over the place. Greg From bos at serpentine.com Tue Sep 2 15:55:00 2003 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Sep 2 15:55:00 2003 Subject: coding In-Reply-To: References: Message-ID: <1062533577.21269.12.camel@serpentine.internal.keyresearch.com> On Tue, 2003-09-02 at 12:57, Greg Watson wrote: > I think they work well when you have a sequence of numbers like this, > but I would rather see each enum explicitly given it's value as in: > > enum { > FLOPPY_DEVICE=0, > PARALLEL_DEVICE=1, > COM2_DEVICE=2, > COM1_DEVICE=3, > SWC_DEVICE=4, > MOUSE_DEVICE=5, > KBC_DEVICE=6, > GPIO_DEVICE=7, > ACB_DEVICE=8, > FSCM_DEVICE=9, > WDT_DEVICE=10 > }; > > Otherwise you're forever trying to work out what the actual value is. More importantly, this style reduces the likelihood of screwing up the ABI by adding an enum member somewhere other than the end of the list. Eric, Could you explain the Config.lb about northbridge and southbridge PCI numbering info? Regards YH -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?9?2? 12:37 ???: Stefan Reinauer ??: LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 Stefan Reinauer writes: > * Eric W. Biederman [030902 19:28]: > > If you want all of your hypertransport devices to be on bus 0, that is > > feasible but it will take a little more work. Right now each > > hypertranport chain get's it's own bus. > > What is missing to achieve this? Just a little code. Merging busses into bus 0 is an interesting logicistics feat, but the current infrastructure will allow it. > Can this cause trouble with current board implementations? Not it is software only. > In the Tyan update code, some hardcoded bus numbers were changed. We should be able to complete remove that. Right now each Hypertransport chains appears to be it's own bus and all of that information is dynamically calculated. The busses that are Hypertranpsort chains are enumerated just like other busses. The way to look at the code is that: - device.c has the logic to enumerate and assign resources to devices and busses. - pci_device.c has the methods for doing that on pci devices. - hypertransport.c has the methods for doing that with hypertranport devices. - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge. In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes. I have committed the code not in a final perfect state. But in a state where it works well enough to be useful. And whatever details we encounter are minor things. Passing information to the dynamic device tree from the static device tree is currently a weak area. But we are building one tree from the other so it is just a matter of a small amount of refactoring if we want to do something better. Basically what remains is to dive into the code see what it is doing, and tweak it a little if is not doing quite the right thing. But usually all that needs to happen is to improve a method of a device so that it operates better. Eric _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Tue Sep 2 16:29:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 16:29:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188A1F@TYANWEB> References: <3174569B9743D511922F00A0C943142303188A1F@TYANWEB> Message-ID: YhLu writes: > Eric, > > Could you explain the Config.lb about northbridge and southbridge PCI > numbering info? The Hypertransport chains are numbered exactly like pci busses. The static information from Config.lb is used just to find the appropriate methods. The only change needed to take advantage of this is to update mainboard.c Eric From rminnich at lanl.gov Tue Sep 2 19:26:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 19:26:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: Message-ID: OK, this commit works for me. Not completely, but well enough to say it's good enough. The only problem is the usual PIRQ fun. I'm going to try to work out a reasonable solution given time. ron From jeff at planetfall.com Tue Sep 2 19:50:00 2003 From: jeff at planetfall.com (Jeff Noxon) Date: Tue Sep 2 19:50:00 2003 Subject: Which board? Message-ID: <20030903000836.GA17535@planetfall.com> I'm about to put some 1U servers together at the office. I want to use LinuxBIOS because they will be operated offsite, and it makes management easier. So I want Linux in Flash. Which Xeon boards are recommended at this point in time? Thanks Jeff From rminnich at lanl.gov Tue Sep 2 20:30:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 20:30:01 2003 Subject: Which board? In-Reply-To: <20030903000836.GA17535@planetfall.com> Message-ID: On Tue, 2 Sep 2003, Jeff Noxon wrote: > Which Xeon boards are recommended at this point in time? Adam Agnew has had good luck with the Tyan 7501-based boards. Supermicro is causing us trouble with the 7501 chipset in getting the port working. Adam is probably one of the right guys to ask, as are Steve James and the crew at Linux Labs; Atipa also ships 7501-based systems. You can start with those guys I would guess. ron From ebiederman at lnxi.com Tue Sep 2 20:33:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 20:33:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: Message-ID: ron minnich writes: > OK, this commit works for me. Not completely, but well enough to say it's > good enough. > > The only problem is the usual PIRQ fun. I'm going to try to work out a > reasonable solution given time. Cool that sounds about right. There is a very real chance I might reverse the order of the devices on the hypertransport chain. So I can allocate from the top of the unitid space instead of from the bottom. With that it will be easier to cram all of the hypertransport chains into bus 0 cleanly. So we really need to find a way to move irq information to the static to the dynamic device tree. That is one of the harder remaining problems. It is not a show stopper but something we need to do before we are done. Eric From agnew at cs.umd.edu Tue Sep 2 20:52:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 2 20:52:00 2003 Subject: Which board? In-Reply-To: Message-ID: <20030902211404.R43782-100000@www.missl.cs.umd.edu> If you do go with i7501 boards, I have an i7501 HOWTO in the works, and patches so you can use the Rage XL that comes on many of them as a framebuffer (for 2.6, i'll have a 2.4 patch finished tomorrow). That should solve the issue of vga support. - Adam Agnew On Tue, 2 Sep 2003, ron minnich wrote: > On Tue, 2 Sep 2003, Jeff Noxon wrote: > > > Which Xeon boards are recommended at this point in time? > > Adam Agnew has had good luck with the Tyan 7501-based boards. Supermicro > is causing us trouble with the 7501 chipset in getting the port working. > > Adam is probably one of the right guys to ask, as are Steve James and the > crew at Linux Labs; Atipa also ships 7501-based systems. You can start > with those guys I would guess. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Tue Sep 2 21:36:01 2003 From: YhLu at tyan.com (YhLu) Date: Tue Sep 2 21:36:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188A81@TYANWEB> S2880 and S2882 is OK now. S2885 has some problems. I will try it more.. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?9?2? 17:58 ???: ron minnich ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 ron minnich writes: > OK, this commit works for me. Not completely, but well enough to say it's > good enough. > > The only problem is the usual PIRQ fun. I'm going to try to work out a > reasonable solution given time. Cool that sounds about right. There is a very real chance I might reverse the order of the devices on the hypertransport chain. So I can allocate from the top of the unitid space instead of from the bottom. With that it will be easier to cram all of the hypertransport chains into bus 0 cleanly. So we really need to find a way to move irq information to the static to the dynamic device tree. That is one of the harder remaining problems. It is not a show stopper but something we need to do before we are done. Eric _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Tue Sep 2 21:58:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 2 21:58:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188A81@TYANWEB> References: <3174569B9743D511922F00A0C943142303188A81@TYANWEB> Message-ID: YhLu writes: > S2880 and S2882 is OK now. > > S2885 has some problems. I will try it more.. Sounds good. The code should work for multiple hypertransport chains, but for some fairly obvious reasons I didn't try it out. Eric From rminnich at lanl.gov Tue Sep 2 23:12:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 2 23:12:01 2003 Subject: via-rhine driver on 2.4.19 on EPIA M-800 Message-ID: via-rhine on 2.4.19 is working very poorly for us. We can plug a tulip board into the PCI slot and the board works quite well, but if we use the via-rhine we get errors and poor performance. Is the via-rhine driver any better on 2.4.19+1, 2, or more? thanks ron From niki.waibel at newlogic.com Wed Sep 3 03:35:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 3 03:35:00 2003 Subject: via-rhine driver on 2.4.19 on EPIA M-800 In-Reply-To: Message-ID: <200309030753.h837r8ZS027702@enterprise2.newlogic.at> On 03-Sep-2003 ron minnich wrote: > via-rhine on 2.4.19 is working very poorly for us. We can plug a tulip > board into the PCI slot and the board works quite well, but if we use the > via-rhine we get errors and poor performance. Is the via-rhine driver any > better on 2.4.19+1, 2, or more? i always use the latest kernel (2.4.22 or 2.6.0-test4). i remember that i had troubles with ethernet on epia-m 600, but with the new kernels that seems to be solved. niki From niki.waibel at newlogic.com Wed Sep 3 06:05:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 3 06:05:01 2003 Subject: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte In-Reply-To: Message-ID: <200309031023.h83AN4ZS016430@enterprise2.newlogic.at> On 02-Sep-2003 ron minnich wrote: > I think the 90 refers to speed, and I note that in my EPIA the part is a > -70. This may be part of the problem. that is not actually the problem. it was never the plan to use bios savior in the production system. i have no problem to remove bios savior and replace it with dip2plcc conv + doc during operation. (the bios savior socket makes removing of the plcc easy). we should focus on detecting/programming the doc. i have a md-2802-d08. an md-2202-d128 is about to arrive. how can i do that with the epia-m? niki From ebiederman at lnxi.com Wed Sep 3 09:56:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 09:56:00 2003 Subject: Which board? In-Reply-To: <20030902211404.R43782-100000@www.missl.cs.umd.edu> References: <20030902211404.R43782-100000@www.missl.cs.umd.edu> Message-ID: Adam Agnew writes: > If you do go with i7501 boards, I have an i7501 HOWTO in the works, and > patches so you can use the Rage XL that comes on many of them as a > framebuffer (for 2.6, i'll have a 2.4 patch finished tomorrow). That > should solve the issue of vga support. Cool. That should solve the server video problem. Adam I could probably use some nagging to get my last port to the supermicro x5dpr (and E7501 board) pushed into the tree. That has a lot of generic bug fixes that are not in the main tree yet. Eric From niki.waibel at newlogic.com Wed Sep 3 10:23:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 3 10:23:00 2003 Subject: description of DoC control registers Message-ID: <200309031441.h83EfcZS019078@enterprise2.newlogic.at> is there a written documentation about the DoC control registers? (2000, millennium) or do i have to find out from the linux kernel drivers? niki From stepan at suse.de Wed Sep 3 10:33:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 3 10:33:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: <20030902204711.A26490@suse.de> Message-ID: <20030903145132.GB6532@suse.de> > The way to look at the code is that: > - device.c has the logic to enumerate and assign resources to devices and busses. > - pci_device.c has the methods for doing that on pci devices. > - hypertransport.c has the methods for doing that with hypertranport devices. > - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific > northbridge. > > In short dynamic resource assignment should now be pretty simple and should > remove the need for most of the hard codes. Ok, thanks for the clarification. The config file for the hdama looks like follows: northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 pci 0:1.1 pci 0:1.2 pci 0:1.3 pci 0:1.5 pci 0:1.6 superio NSC/pc87360 [..] end end end northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end cpu k8 "cpu0" register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end cpu k8 "cpu1" end What's the meaning of the "pci" command? why are some mentioned multiple times? (0:18.0, 0:19.0) I started digging through the code, but I am not completely there yet. It seems to me it would make sense to move the register "up" information from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since its information associated with the used southbridges. There is currently no information on how the amd8131 and 8151 are actually linked. Does it look like this? : 8111 | 8131 | CPU0 -- CPU1 In this case it could be needed to describe to which link of the 8131 the 8111 is connected?! Would the link speed between 8131 and 8111 be set correctly with the current code? Same thing applies for the 8151 that is used in the tyan and solo boards. The link speed is currently written by src/southbridge/amd/amd8151/amd8151_agp3.c If the code is already covered by the new ht code it could be removed from the 8151 code. If this constellation is not possible, amd8151_agp3.c should read the link values from static.c - What is the better solution? Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Wed Sep 3 10:46:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 3 10:46:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030903145132.GB6532@suse.de> Message-ID: On Wed, 3 Sep 2003, Stefan Reinauer wrote: > pci 0:18.0 one thing I'd still like to see as long as we are declaring these pci slots: why not have the IRQ routing in there? pci 0:18.o A=B, B=C, C=D, D=A that way, we'd have info to build PIRQ. any reason not to do this? ron From ebiederman at lnxi.com Wed Sep 3 11:13:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 11:13:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: Message-ID: ron minnich writes: > On Wed, 3 Sep 2003, Stefan Reinauer wrote: > > > pci 0:18.0 > > one thing I'd still like to see as long as we are declaring these pci > slots: why not have the IRQ routing in there? > > pci 0:18.o A=B, B=C, C=D, D=A > > that way, we'd have info to build PIRQ. > > any reason not to do this? Nope. The only reason it is not done is that no one has gotten there yet. There are a few practical issues with not specifying the interrupt controller an irq goes to though... Eric From pyro at linuxlabs.com Wed Sep 3 11:14:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed Sep 3 11:14:01 2003 Subject: coding In-Reply-To: Message-ID: Greetings, It seems to me that working out the integer value of an enum is actually abuse of the type. The closest one should get to that is ++ or -- to step through enumerated objects. Of course, nobody ever takes liberties with that, especially me :-) If the value itself is significant, it should probably be a define. If it's only significant for ABI compatibility, best practice is to only add to the end of the list and retain deprecated enums until an ABI breaking version change happens. A comma after the last enum value is a pretty decent invitation to do the right thing. G'day, sjames On Tue, 2 Sep 2003, Greg Watson wrote: > At 1:32 PM -0600 2/9/03, ron minnich wrote: > >anybody object to anonymous enums? I've gotten used to them in Plan 9 and > >like them. Instead of this: > > > >#define FLOPPY_DEVICE 0 > >#define PARALLEL_DEVICE 1 > >#define COM2_DEVICE 2 > >#define COM1_DEVICE 3 > >#define SWC_DEVICE 4 > >#define MOUSE_DEVICE 5 > >#define KBC_DEVICE 6 > >#define GPIO_DEVICE 7 > >#define ACB_DEVICE 8 > >#define FSCM_DEVICE 9 > >#define WDT_DEVICE 10 > > > >you get this: > >enum { > > FLOPPY_DEVICE=0, > > PARALLEL_DEVICE, > > COM2_DEVICE, > > COM1_DEVICE, > > SWC_DEVICE, > > MOUSE_DEVICE, > > KBC_DEVICE, > > GPIO_DEVICE, > > ACB_DEVICE, > > FSCM_DEVICE, > > WDT_DEVICE > >}; > > > >The advantages I see > >- somewhat less prone to error > >- looks nicer > >- the big one: enums are first-class objects to the compiler, and > > #defines are pertty much ripped out by the compiler and disappear > > into constant numbers. > > > > > >comments? > > > >ron > > I think they work well when you have a sequence of numbers like this, > but I would rather see each enum explicitly given it's value as in: > > enum { > FLOPPY_DEVICE=0, > PARALLEL_DEVICE=1, > COM2_DEVICE=2, > COM1_DEVICE=3, > SWC_DEVICE=4, > MOUSE_DEVICE=5, > KBC_DEVICE=6, > GPIO_DEVICE=7, > ACB_DEVICE=8, > FSCM_DEVICE=9, > WDT_DEVICE=10 > }; > > Otherwise you're forever trying to work out what the actual value is. > > Where it doesn't work is when you have a bunch of random defines with > unrelated values, or values that jump about all over the place. > > Greg > > _______________________________________________ > 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 steve at nexpath.com Wed Sep 3 11:17:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Sep 3 11:17:00 2003 Subject: via-rhine driver on 2.4.19 on EPIA M-800 In-Reply-To: References: Message-ID: <3F560C51.7090908@nexpath.com> ron minnich wrote: > via-rhine on 2.4.19 is working very poorly for us. We can plug a tulip > board into the PCI slot and the board works quite well, but if we use the > via-rhine we get errors and poor performance. Is the via-rhine driver any > better on 2.4.19+1, 2, or more? > There have been many changes to the via-rhine driver AFAIK. I can't remember where it started working right, but sometime around 2.4.20 I think. I don't have 2.4.19 unpacked, but at 2.4.18, the driver version is 1.1.13. In 2.4.21, the driver version is 1.1.17, so that is 4 versions later, and based on the comments in the driver, lots of changes. -Steve From ebiederman at lnxi.com Wed Sep 3 11:22:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 11:22:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030903145132.GB6532@suse.de> References: <20030902204711.A26490@suse.de> <20030903145132.GB6532@suse.de> Message-ID: Stefan Reinauer writes: > > The way to look at the code is that: > > - device.c has the logic to enumerate and assign resources to devices and > busses. > > > - pci_device.c has the methods for doing that on pci devices. > > - hypertransport.c has the methods for doing that with hypertranport devices. > > - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific > > northbridge. > > > > In short dynamic resource assignment should now be pretty simple and should > > remove the need for most of the hard codes. > > Ok, thanks for the clarification. > > The config file for the hdama looks like follows: > northbridge amd/amdk8 "mc0" > pci 0:18.0 > pci 0:18.0 > pci 0:18.0 > pci 0:18.1 > pci 0:18.2 > pci 0:18.3 > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > end > southbridge amd/amd8111 "amd8111" > pci 0:0.0 > pci 0:1.0 > pci 0:1.1 > pci 0:1.2 > pci 0:1.3 > pci 0:1.5 > pci 0:1.6 > superio NSC/pc87360 > [..] > end > end > end > > northbridge amd/amdk8 "mc1" > pci 0:19.0 > pci 0:19.0 > pci 0:19.0 > pci 0:19.1 > pci 0:19.2 > pci 0:19.3 > end > > cpu k8 "cpu0" > register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" > end > > cpu k8 "cpu1" > end > > What's the meaning of the "pci" command? why are some mentioned > multiple times? (0:18.0, 0:19.0) First the most basic result I have is that I need to know what all of the logical devices that come out of a chip are. So off of each logical device I have one or more channels. The only way I could think of to describe multiple channels is to repeat the logical device in the configuration file. All of the logical device paths are relative to the device they are hanging off of (it just looks like the bus number). So to say the amd/amd8131 was hanging off of the second hypertransport link I would change it's logical devices to: southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 end I am not saying that is the best way to go, but it currently works. > I started digging through the code, but I am not completely there yet. > It seems to me it would make sense to move the register "up" information > from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since > its information associated with the used southbridges. The register "up" is something that has not been used at all yet. Personally I am not comfortable with the fact that we have both cpu and northbridge instances for the cpus.. > There is currently no information on how the amd8131 and 8151 are > actually linked. Yes there is, but it is mostly implicit. > Does it look like this? : > > 8111 > | > 8131 > | > CPU0 -- CPU1 Yes. The order of the device structures is significant. > In this case it could be needed to describe to which link of the 8131 > the 8111 is connected?! Would the link speed between 8131 and 8111 be > set correctly with the current code? Yes. Except I don't yet have a way to automatically down clock it from 800Mhz which it claims it can do but cannot. > Same thing applies for the 8151 that is used in the tyan and solo > boards. The link speed is currently written by > src/southbridge/amd/amd8151/amd8151_agp3.c > > If the code is already covered by the new ht code it could be removed > from the 8151 code. Sounds good. > If this constellation is not possible, > amd8151_agp3.c should read the link values from static.c - What is the > better solution? Since it is already covered and it can be done automatically I would go there. Eric From stepan at suse.de Wed Sep 3 11:54:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 3 11:54:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: <20030902204711.A26490@suse.de> <20030903145132.GB6532@suse.de> Message-ID: <20030903161236.GB6849@suse.de> * Eric W. Biederman [030903 17:47]: > First the most basic result I have is that I need to know what all of the > logical devices that come out of a chip are. > So off of each logical device I have one or more channels. The only > way I could think of to describe multiple channels is to repeat > the logical device in the configuration file. > > All of the logical device paths are relative to the device they are hanging > off of (it just looks like the bus number). So to say the amd/amd8131 was > hanging off of the second hypertransport link I would change it's logical > devices to: > > southbridge amd/amd8131 "amd8131" > pci 1:0.0 > pci 1:0.1 > pci 1:1.0 > pci 1:1.1 > end > > I am not saying that is the best way to go, but it currently works. Ah. this is fine and allows porting linuxbios easily to new opteron mainboards. I see some drawbacks: * the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ? * The device description itself and the link (channel?) information is intermixed (preventing above config change from happening) * link information is duplicate. This might be a feature though when devices happen that connect to more than one link. (Is this theoretically possible, i.e. to raise bandwidth?) > The register "up" is something that has not been used at all yet. Personally > I am not comfortable with the fact that we have both cpu and northbridge > instances for the cpus.. This looks weird for the opteron case, true. But most architectures still don't come with an on-cpu northbridge, so keeping that seperated might be a good idea (in case a certain northbridge can cope with several cpu types) > > Does it look like this? : > > > > 8111 > > | > > 8131 > > | > > CPU0 -- CPU1 > > Yes. The order of the device structures is significant. should this: southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] end not rather look like this then: ? southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end > Yes. Except I don't yet have a way to automatically down clock it from 800Mhz > which it claims it can do but cannot. this seems only like a matter of the information not being parsed from an appropriate place in the config file yet. > > Same thing applies for the 8151 that is used in the tyan and solo > > boards. The link speed is currently written by > > src/southbridge/amd/amd8151/amd8151_agp3.c > > > > If the code is already covered by the new ht code it could be removed > > from the 8151 code. > > Sounds good. YhLu? Can you confirm that link speeds to AGP are ok without that code? Does anyone have an appropriate method of testing the actual link speed and/or width between any pair of devices? Stefan -- Architecture Team SuSE Linux AG From YhLu at tyan.com Wed Sep 3 12:19:00 2003 From: YhLu at tyan.com (YhLu) Date: Wed Sep 3 12:19:00 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188AA9@TYANWEB> Eric, For s2885 8151 | (link0) CPU0 -- CPU1 | (link2) 8131 | 8111 So the Config.lb should include northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8151 "amd8151" pci 5:0.0 pci 5:1.0 end southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 pci 1:1.1 pci 1:1.2 pci 1:1.3 pci 1:1.5 pci 1:1.6 end end end northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end cpu k8 "cpu0" register "up" = "{ .chip = &amd8151, .ht_width=16, .ht_speed=600 }" register "down" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end cpu k8 "cpu1" end Is that right? Regards YH. _ From YhLu at tyan.com Wed Sep 3 12:26:00 2003 From: YhLu at tyan.com (YhLu) Date: Wed Sep 3 12:26:00 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188AAB@TYANWEB> I have tried in s2880. southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end will not work. In this case amd8111 will be considered as children to amd8131. Before that 8111 is next node to amd8131. For the Frequency and Width, I have add two print_regs in mainboard.c and print all regs values. Of'course, if LDTSTOP# or reset# is not asserted, the regs has no meanings. YH -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?3? 9:13 ???: Eric W. Biederman ??: LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 * Eric W. Biederman [030903 17:47]: > First the most basic result I have is that I need to know what all of the > logical devices that come out of a chip are. > So off of each logical device I have one or more channels. The only > way I could think of to describe multiple channels is to repeat > the logical device in the configuration file. > > All of the logical device paths are relative to the device they are hanging > off of (it just looks like the bus number). So to say the amd/amd8131 was > hanging off of the second hypertransport link I would change it's logical > devices to: > > southbridge amd/amd8131 "amd8131" > pci 1:0.0 > pci 1:0.1 > pci 1:1.0 > pci 1:1.1 > end > > I am not saying that is the best way to go, but it currently works. Ah. this is fine and allows porting linuxbios easily to new opteron mainboards. I see some drawbacks: * the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ? * The device description itself and the link (channel?) information is intermixed (preventing above config change from happening) * link information is duplicate. This might be a feature though when devices happen that connect to more than one link. (Is this theoretically possible, i.e. to raise bandwidth?) > The register "up" is something that has not been used at all yet. Personally > I am not comfortable with the fact that we have both cpu and northbridge > instances for the cpus.. This looks weird for the opteron case, true. But most architectures still don't come with an on-cpu northbridge, so keeping that seperated might be a good idea (in case a certain northbridge can cope with several cpu types) > > Does it look like this? : > > > > 8111 > > | > > 8131 > > | > > CPU0 -- CPU1 > > Yes. The order of the device structures is significant. should this: southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] end not rather look like this then: ? southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end > Yes. Except I don't yet have a way to automatically down clock it from 800Mhz > which it claims it can do but cannot. this seems only like a matter of the information not being parsed from an appropriate place in the config file yet. > > Same thing applies for the 8151 that is used in the tyan and solo > > boards. The link speed is currently written by > > src/southbridge/amd/amd8151/amd8151_agp3.c > > > > If the code is already covered by the new ht code it could be removed > > from the 8151 code. > > Sounds good. YhLu? Can you confirm that link speeds to AGP are ok without that code? Does anyone have an appropriate method of testing the actual link speed and/or width between any pair of devices? Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Wed Sep 3 12:41:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 12:41:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188AA9@TYANWEB> References: <3174569B9743D511922F00A0C943142303188AA9@TYANWEB> Message-ID: YhLu writes: > Eric, > > For s2885 > > 8151 > | (link0) > CPU0 -- CPU1 > | (link2) > 8131 > | > 8111 > > > So the Config.lb should include With the current code the configuration should say: northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8151 "amd8151" pci 2:0.0 pci 2:1.0 end southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 pci 0:1.1 pci 0:1.2 pci 0:1.3 pci 0:1.5 pci 0:1.6 end end northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end cpu k8 "cpu0" end cpu k8 "cpu1" end Eric From ebiederman at lnxi.com Wed Sep 3 12:51:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 12:51:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030903161236.GB6849@suse.de> References: <20030902204711.A26490@suse.de> <20030903145132.GB6532@suse.de> <20030903161236.GB6849@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030903 17:47]: > > First the most basic result I have is that I need to know what all of the > > logical devices that come out of a chip are. > > > So off of each logical device I have one or more channels. The only > > way I could think of to describe multiple channels is to repeat > > the logical device in the configuration file. > > > > All of the logical device paths are relative to the device they are hanging > > off of (it just looks like the bus number). So to say the amd/amd8131 was > > hanging off of the second hypertransport link I would change it's logical > > devices to: > > > > southbridge amd/amd8131 "amd8131" > > pci 1:0.0 > > pci 1:0.1 > > pci 1:1.0 > > pci 1:1.1 > > end > > > > I am not saying that is the best way to go, but it currently works. > > Ah. this is fine and allows porting linuxbios easily to new opteron > mainboards. > I see some drawbacks: > > * the logical devices of the amd8131 pci-x bridge has to be described in > the mainboard configuration file. This means a lot of duplicate config > "code" spread over the mainboard directory. Can this somehow go to the > Config.lb file in southbridge/amd/amd8131/ ? Yes. But at the same time everything there is explicit and up front. Which is not necessarily a bad thing. It is very hard to see what is going on if you introduce a level of indirection here to be more sparse. I have tried for the most part to ensure that if you don't mention a logical device it still turns up. It is just that you can not feed it any static configuration if it is not mentioned. > * The device description itself and the link (channel?) information is > intermixed (preventing above config change from happening) I introduced channel because that is a concept that is purely in the configuration. How that maps to hardware capabilities can vary. Think a pci bridge chip with 8 pci busses hanging off of it, for the kinds of problem I was trying to solve. > * link information is duplicate. This might be a feature though when > devices happen that connect to more than one link. (Is this > theoretically possible, i.e. to raise bandwidth?) A little. > > The register "up" is something that has not been used at all yet. Personally > > I am not comfortable with the fact that we have both cpu and northbridge > > instances for the cpus.. > > This looks weird for the opteron case, true. But most architectures > still don't come with an on-cpu northbridge, so keeping that seperated > might be a good idea (in case a certain northbridge can cope with > several cpu types) Right. Which is why I have not messed with it yet. I have just stared with a rough draft that works. I don't have problems with changing it, so long as all of the requirements are met. > > > Does it look like this? : > > > > > > 8111 > > > | > > > 8131 > > > | > > > CPU0 -- CPU1 > > > > Yes. The order of the device structures is significant. > > should this: > > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > end > southbridge amd/amd8111 "amd8111" > pci 0:0.0 > pci 0:1.0 > [..] > end > > not rather look like this then: ? > > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > southbridge amd/amd8111 "amd8111" > pci 1:0.0 > pci 1:1.0 > [..] > end > end Quite possibly. A hypertransport chain is a weird case. For the moment I am treating it like a weird pci bus, and that seems to work... But further nesting might not be bad with the right set of changes. > > Yes. Except I don't yet have a way to automatically down clock it from 800Mhz > > which it claims it can do but cannot. > > this seems only like a matter of the information not being parsed from > an appropriate place in the config file yet. Yep, pretty much. Although for bug fixes I would like it if the configuration file didn't have to be involved. Just the driver for the 8131 saying that it can't do 800Mhz which is a slightly different thing. Eric From ebiederman at lnxi.com Wed Sep 3 12:53:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 12:53:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188AAB@TYANWEB> References: <3174569B9743D511922F00A0C943142303188AAB@TYANWEB> Message-ID: YhLu writes: > I have tried in s2880. > > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > southbridge amd/amd8111 "amd8111" > pci 1:0.0 > pci 1:1.0 > [..] > end > end > > will not work. Correct. There is a good argument for changing the code so this works but it does not currently. > In this case amd8111 will be considered as children to amd8131. > > Before that 8111 is next node to amd8131. > > For the Frequency and Width, I have add two print_regs in mainboard.c and > print all regs values. Of'course, if LDTSTOP# or reset# is not asserted, the > regs has no meanings. Right. If you define a hard_reset routine and set HAVE_HARD_RESET to 1, the reset will be asserted. Eric From niki.waibel at newlogic.com Wed Sep 3 13:59:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 3 13:59:00 2003 Subject: epia-m + bios savior + dip2plcc + doc (md2802-d08) Message-ID: <200309031817.h83IHkZS014916@enterprise2.newlogic.at> okay -- it seems that things are working (a little bit). on http://www.rootshell.be/~nwaibel/docprobe.txt you can find the output of a modified version of docprobe. you can see the plain mem map of the md2802-d08 there. it is different to the md2800-d08!!! 0x0000: 512byte IPL -- is someone able to rev eng this? 0x01ff 0x0200: 512byte mirror of IPL 0x03ff 0x0400: 512byte mirror of IPL 0x05ff 0x0600: 512byte mirror of IPL 0x07ff 0x0800: 512byte IPL -- this seems to be the first 512byte of page 0 of the 8mbyte flash memory 0x09ff 0x0a00: 512byte -- not sure but could be 2nd part of page 0 of the 8mbyte 0x0bff 0x0c00: 512byte failsave IPL? -- not sure but could be 3rd part of page 0 of the 8mbyte 0x0dff 0x0e00: 512byte -- not sure but could be 4th part of page 0 of the 8mbyte 0x0fff 0x1000: the doc 2000 and doc millennium (2001) control registers are here. but it seems that this is not true for the md2802-d08 chip! everything is set to 0x00 -> docprobe does *NOT* recognize this chip as 0x11ff DoC Millennium!!! 0x1200: hmmm -- control registers? very strange. it is like IPL but (almost) all even bytes are set to 0x00 (not all!) maybe the even bytes are the control regs? 0x13ff 0x1400: no idea -- 512 empty bytes 0x15ff 0x1600: like 0x1200, but first 3 bytes are different! control registers? 0x17ff 0x1800: expected 512byte mirror of IPL here -- but it is a mirror of 0x1200! 0x19ff 0x1a00: 512byte mirror of IPL 0x1bff 0x1c00: expected 512byte mirror of IPL here -- but it is a mirror of 0x1200! 0x1dff 0x1e00: 512byte mirror of IPL 0x1fff any ideas or more info about this md2802-d08? niki BTW: the epia-m does not boot with epia-m + bios savior + dip2plcc + doc (md2802-d08). even not if bios savior is switched to the normal flash containing the bios. even not if there is only epia-m + bios savior + dip2plcc. so i booted with epia-m + bios savior and then (when linux was running) i placed the dip2plcc + doc (md2802-d08) into bios savior and changed the switch. From agnew at cs.umd.edu Wed Sep 3 15:26:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Wed Sep 3 15:26:00 2003 Subject: Which board? In-Reply-To: Message-ID: <20030903154914.M47326-100000@www.missl.cs.umd.edu> > Cool. That should solve the server video problem. > > Adam I could probably use some nagging to get my last port to the > supermicro x5dpr (and E7501 board) pushed into the tree. That has > a lot of generic bug fixes that are not in the main tree yet. > Alright. How about this: I'll trade you my rage xl initialization patches for both 2.6 and 2.4 for you committing your x5dpr changes? :) - Adam Agnew From YhLu at tyan.com Wed Sep 3 16:51:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Sep 3 16:51:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188B11@TYANWEB> Eric, Please check function hypertransport_scan_chain definition and calling parameters. It seems the .h and .c is not consistent. Regards YH From gwatson at lanl.gov Wed Sep 3 17:13:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Wed Sep 3 17:13:00 2003 Subject: init_timer() Message-ID: K8 developers: I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok. Greg From ollie at sis.com.tw Wed Sep 3 21:27:01 2003 From: ollie at sis.com.tw (???) Date: Wed Sep 3 21:27:01 2003 Subject: description of DoC control registers References: <200309031441.h83EfcZS019078@enterprise2.newlogic.at> Message-ID: <00f501c37286$20c56f60$0201a8c0@ollie> The Linux MTD maintainer David Woodhouse has a copy of the register spec. He has made some deal with M-System about the redistribution of the spec. You should ask him for detail. Ollie ----- Original Message ----- From: "Niki Waibel" To: Sent: Wednesday, September 03, 2003 10:41 PM Subject: description of DoC control registers is there a written documentation about the DoC control registers? (2000, millennium) or do i have to find out from the linux kernel drivers? niki _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Wed Sep 3 21:46:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 3 21:46:00 2003 Subject: coding In-Reply-To: Message-ID: On Wed, 3 Sep 2003, steven james wrote: > It seems to me that working out the integer value of an enum is actually > abuse of the type. The closest one should get to that is ++ or -- to step > through enumerated objects. yeah but The Man Himself, Rob Pike, came up with this idea, and Ken and Dennis bless it. I figure if anybody can bless such a use of enum, the guy who invented the language is probably the one :-) I'll try to get some Plan 9 excerpts for reference. ron From rminnich at lanl.gov Wed Sep 3 22:21:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 3 22:21:01 2003 Subject: init_timer() In-Reply-To: Message-ID: On Wed, 3 Sep 2003, Greg Watson wrote: > K8 developers: > > I've moved init_timer() from hardwaremain.c to the static > initialization code in cpu/k8/cpufixup.c as it prevents PPC code from > building. Please check that everything still works ok. yes, and there is a bigger issue. putting init_timer() in hardwaremain as an explicit call breaks machines that have no timer. These do exist. Thanks, Greg. ron From ebiederman at lnxi.com Wed Sep 3 22:43:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 3 22:43:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188B11@TYANWEB> References: <3174569B9743D511922F00A0C943142303188B11@TYANWEB> Message-ID: YhLu writes: > Eric, > > Please check function hypertransport_scan_chain definition and calling > parameters. > > It seems the .h and .c is not consistent. You are right. I have removed the middle parameter (something I was playing with) from northbridge.c and hypertransport.h. Some one shoot me for forgetting to include hypertransport.h in hypertransport.c And committed that. This should be the reason why the bus numbers don't automatically work on the s2885. Eric From rminnich at lanl.gov Thu Sep 4 09:57:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 09:57:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: Message-ID: On 3 Sep 2003, Eric W. Biederman wrote: > > I started digging through the code, but I am not completely there yet. > > It seems to me it would make sense to move the register "up" information > > from cpu k8 "cpu0" to the northbridge amd/amdk8 "mc0" definition since > > its information associated with the used southbridges. > > The register "up" is something that has not been used at all yet. Personally > I am not comfortable with the fact that we have both cpu and northbridge > instances for the cpus.. yes, this is the eternal question. For the earlier version I put in northsouthbridge as a type because of stuff like the sis 630. Now, I always wondered if we should not have just kept southbridge/sis/630 and northbridge/sis/630, but acknowledging that they were in fact one chip seemed the way to go. For the k8, we have a cpu and a northbridge. We could have a part called cpunorthbridge (ACK) but where does this end? It seems ugly. Is it better to just have a northbridge.c in the cpu/k8 directory and remove northbridge/amdk8? > > There is currently no information on how the amd8131 and 8151 are > > actually linked. > > Yes there is, but it is mostly implicit. The issue is that we designed the config file hierarchy as parent/child. That is not enough of a topology description to allow the more complex topologies possible on the K8 systems. Thus you have to extend the topology with the per-chip "register" declarations. Since every other system we have can be satisfied with the parent/child relationship, I think we ought to leave this be. ron From rminnich at lanl.gov Thu Sep 4 10:00:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 10:00:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030903161236.GB6849@suse.de> Message-ID: On Wed, 3 Sep 2003, Stefan Reinauer wrote: > > > Does it look like this? : > > > > > > 8111 > > > | > > > 8131 > > > | > > > CPU0 -- CPU1 > > > > Yes. The order of the device structures is significant. > > should this: > > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > end > southbridge amd/amd8111 "amd8111" > pci 0:0.0 > pci 0:1.0 > [..] > end > > not rather look like this then: ? > > southbridge amd/amd8131 "amd8131" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > southbridge amd/amd8111 "amd8111" > pci 1:0.0 > pci 1:1.0 > [..] > end > end > that's how greg intended it to be used when he came up with that part of the language. So your second example is right. ron From rminnich at lanl.gov Thu Sep 4 10:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 10:04:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: Message-ID: On 3 Sep 2003, Eric W. Biederman wrote: > > > > * the logical devices of the amd8131 pci-x bridge has to be described in > > the mainboard configuration file. This means a lot of duplicate config > > "code" spread over the mainboard directory. Can this somehow go to the > > Config.lb file in southbridge/amd/amd8131/ ? > > Yes. But at the same time everything there is explicit and up front. > Which is not necessarily a bad thing. It is very hard to see what is going > on if you introduce a level of indirection here to be more sparse. One of the goals of the new tool was to bring everything up to the top level. People were getting lost in the maze of include files and option settings. The disadvantage, as you point out, is some duplicated code, but the advantages have so far outweighed that disadvantage. In this case duplicated code is actually not too bad, as the hardware that the code describes will not change for a given board. > Quite possibly. A hypertransport> > southbridge amd/amd8131 "amd8131" > > pci 0:0.0 > > pci 0:0.1 > > pci 0:1.0 > > pci 0:1.1 > > southbridge amd/amd8111 "amd8111" > > pci 1:0.0 > > pci 1:1.0 > > [..] > > end > > end > > chain is a weird case. For the > moment I am treating it like a weird pci bus, and that seems to > work... But further nesting might not be bad with the right set of > changes. Ah, this is a chain and not a true parent/child case? I'm still getting the hang of HT, obviously. ron From stepan at suse.de Thu Sep 4 10:10:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 4 10:10:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: Message-ID: <20030904142833.GB22287@suse.de> * ron minnich [030904 16:22]: > One of the goals of the new tool was to bring everything up to the top > level. People were getting lost in the maze of include files and option > settings. The disadvantage, as you point out, is some duplicated code, but > the advantages have so far outweighed that disadvantage. > > In this case duplicated code is actually not too bad, as the hardware that > the code describes will not change for a given board. I agree.. but right now there are still Config.lb files in the mainboard and in the targets directory. And at least last time I checked both were used. Stefan -- Architecture Team SuSE Linux AG From rodmur at maybe.org Thu Sep 4 10:58:00 2003 From: rodmur at maybe.org (Dale Harris) Date: Thu Sep 4 10:58:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS Message-ID: <20030904151613.GR7092@maybe.org> This isn't exactly on topic, but I thought it was interesting nonetheless. So with a mobo that would support this BIOS, could we still pop out the Phoenix BIOS and pop in a LinuxBIOS or FreeBIOS? http://www.extremetech.com/article2/0,3973,1237519,00.asp BIOS maker Phoenix Technologies said it is currently shopping a digital-rights-enabled BIOS system to top PC OEMs, the most aggressive use of DRM technology to date. Phoenix executives said Wednesday that they've developed a prototype version of its Core Management Environment (cME) using DRM technology in conjunction with Orbid Corp., a DRM technology provider. The software was designed to assist content providers to authenticate and track software moving from PC to PC. -- Dale Harris rodmur at maybe.org /.-) From vincent at ulyssis.org Thu Sep 4 11:23:01 2003 From: vincent at ulyssis.org (Vincent Touquet) Date: Thu Sep 4 11:23:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <20030904151613.GR7092@maybe.org> References: <20030904151613.GR7092@maybe.org> Message-ID: <20030904154147.GH28986@lea.ulyssis.org> On Thu, Sep 04, 2003 at 08:16:13AM -0700, Dale Harris wrote: >This isn't exactly on topic, but I thought it was interesting >nonetheless. So with a mobo that would support this BIOS, could we >still pop out the Phoenix BIOS and pop in a LinuxBIOS or FreeBIOS? >http://www.extremetech.com/article2/0,3973,1237519,00.asp (cut) Not a chance in hell I guess. I was lucky to be able to join a talk about the upcoming new and improved secure windows with an extra vertical separation between left and right, where right is the old kernel space, with on top the old user space. Basicly they stop trusting kernel space. basic services | old user ------------------------------------- NEXUS | old kernel The nexus would be some micro kernel with supposedly code that is open to peer review (no word about the license). All circuits on board would be encrypted, all the way to the graphics card (eg. to securely display sensitive information, no word about attacks which use the radiation of the screen as the basis though :) The BIOS will check the Nexus and its signature and then load it, the nexus then fires the operating system (only windows up till now I guess). MS was having active connections with mobo manufacturers, but of course they need time for anything like this (imagine the changes required to the hardware ...). My guess is that this is one of the prime reasons for the delay of Longhorn to 2005. It will be presented as the saviour of the content industry. I wouldn't be surprised if lobbying towards people only being allowed to use trusted PCs would start at around the same time. This is all speculation though. Not sure if the Phoenix DRM BIOS fits into this picture. v From rminnich at lanl.gov Thu Sep 4 11:31:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 11:31:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030904142833.GB22287@suse.de> Message-ID: On Thu, 4 Sep 2003, Stefan Reinauer wrote: > I agree.. but right now there are still Config.lb files in the mainboard > and in the targets directory. And at least last time I checked both were > used. possibly I am missing your point. What bits did you want to see in mainboard/Config.lb that are in the target? ron From steve at nexpath.com Thu Sep 4 11:53:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Sep 4 11:53:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <20030904154147.GH28986@lea.ulyssis.org> References: <20030904151613.GR7092@maybe.org> <20030904154147.GH28986@lea.ulyssis.org> Message-ID: <3F576637.509@nexpath.com> Vincent Touquet wrote: > Not sure if the Phoenix DRM BIOS fits into this picture. I suspect the Xbox is your clue... MS has had plenty of practice on encrypting the bios and locking out foreign app sw, and the xboxlinux group has been the test foil (although in the short run they are on top right now). -Steve From ebiederman at lnxi.com Thu Sep 4 12:49:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 4 12:49:01 2003 Subject: init_timer() In-Reply-To: References: Message-ID: ron minnich writes: > On Wed, 3 Sep 2003, Greg Watson wrote: > > > K8 developers: > > > > I've moved init_timer() from hardwaremain.c to the static > > initialization code in cpu/k8/cpufixup.c as it prevents PPC code from > > building. Please check that everything still works ok. > > yes, and there is a bigger issue. putting init_timer() in hardwaremain as > an explicit call breaks machines that have no timer. These do exist. Here is the issue. In various places we need functions that wait a certain amount of time. And the code that needs it is not directly tied to the platform. Things like the IDE driver require it. So we need to a source of delays, and that source potentially needs initialization. How to do that I don't know. Putting that initialization in hardwaremain.c is obviously not perfect but we need to do something and we need not to brush the issue under the rug. Except that everything on the k8 is in the cpu it really does not belong in cpufixup.c At least not on a general basis. Eric From ebiederman at lnxi.com Thu Sep 4 12:59:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 4 12:59:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <3F576637.509@nexpath.com> References: <20030904151613.GR7092@maybe.org> <20030904154147.GH28986@lea.ulyssis.org> <3F576637.509@nexpath.com> Message-ID: Steve Gehlbach writes: > Vincent Touquet wrote: > > > Not sure if the Phoenix DRM BIOS fits into this picture. > > I suspect the Xbox is your clue... MS has had plenty of practice on encrypting > the bios and locking out foreign app sw, and the xboxlinux group has been the > test foil (although in the short run they are on top right now). Boards don't sell if people won't buy them. Eric From rminnich at lanl.gov Thu Sep 4 13:00:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 13:00:00 2003 Subject: init_timer() In-Reply-To: Message-ID: On 4 Sep 2003, Eric W. Biederman wrote: > Except that everything on the k8 is in the cpu it really does not belong > in cpufixup.c At least not on a general basis. agreed, the solution is not exactly what we want. I really think there should be a timer device, built into the static tree. For those platforms without timers? The best you'll get is a cpu cycle counter. ron From YhLu at tyan.com Thu Sep 4 13:13:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 4 13:13:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188B96@TYANWEB> I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?9?3? 20:09 ???: YhLu ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 YhLu writes: > Eric, > > Please check function hypertransport_scan_chain definition and calling > parameters. > > It seems the .h and .c is not consistent. You are right. I have removed the middle parameter (something I was playing with) from northbridge.c and hypertransport.h. Some one shoot me for forgetting to include hypertransport.h in hypertransport.c And committed that. This should be the reason why the bus numbers don't automatically work on the s2885. Eric From YhLu at tyan.com Thu Sep 4 13:30:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 4 13:30:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188B9F@TYANWEB> Eric, In the hypertransport_scan_chain, if the hard_reset is needed, it may produce problem. Hard_reset call 8111 LPC (B1, D4, F0) reg 0x47 to trigger Reset. But it is called before pci_scan_bus. At that time the 8111 LPC is still unkown. Regards YH -----????----- ???: YhLu ????: 2003?9?4? 10:30 ???: 'ebiederman at lnxi.com' ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed From mikew at lanl.gov Thu Sep 4 14:25:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Thu Sep 4 14:25:01 2003 Subject: New to list Message-ID: <3F5787D2.6020700@lanl.gov> Hello, everyone here. This LinuxBios stuff sounds interesting. I have a Micron Millenium with a BCM DR737 motherboard sitting around doing nothing in my lab. I know, it's kind of old, but maybe it'll be good enough to provide me a learning experience... Any opinions on whether this MoBo is even worth experimenting with? ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From YhLu at tyan.com Thu Sep 4 15:26:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 4 15:26:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188BC0@TYANWEB> Eric, If I disable the hard_reset, it can enumerate from link2 to link0. And the 8131 on link2 and 8151 on link0 all show out. Maybe you can add MACRO to control reverse scan for AMKK8 northbridge. ( link2 then link0) But it continues to reboot. Regards Yinghai Lu Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 19:17:58 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 [1022/746d] enabled PCI: 01:04.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled PCI: 04:01.0 [1022/7462] enabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 0 Hypertransport scan link done Hyper transport scan link: 0 max: 5 PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004 Hypertransport link capability not foundPCI: pci_scan_bus for bus 5 PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:00.0 No device operations PCI: 05:01.0 [1022/7454] ops PCI: 05:01.0 [1022/7454] enabled PCI: 05:02.0 [1022/7455] bus ops PCI: 05:02.0 [1022/7455] enabled Copying LinuxBIOS to ram. -----????----- ???: YhLu ????: 2003?9?4? 10:48 ???: ebiederman at lnxi.com ??: Stefan Reinauer; LinuxBIOS ??: re: [COMMIT] Infrastructure Updates 4 Eric, In the hypertransport_scan_chain, if the hard_reset is needed, it may produce problem. Hard_reset call 8111 LPC (B1, D4, F0) reg 0x47 to trigger Reset. But it is called before pci_scan_bus. At that time the 8111 LPC is still unkown. Regards YH -----????----- ???: YhLu ????: 2003?9?4? 10:30 ???: 'ebiederman at lnxi.com' ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From hansolofalcon at worldnet.att.net Thu Sep 4 15:29:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu Sep 4 15:29:01 2003 Subject: New to list In-Reply-To: <3F5787D2.6020700@lanl.gov> Message-ID: <000b01c3731d$94d15b20$0100a8c0@who5> Hello from Gregg C Levine Mike, can you provide some information on this beast? What's its chosen processor? Also you'll need to run a "#lspci -v" for us (# mark for shell prompt). Oh, and as a side note, nice to see you here. ------------------- 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 Mike Westfall > Sent: Thursday, September 04, 2003 2:44 PM > To: linuxbios at clustermatic.org > Subject: New to list > > Hello, everyone here. > > This LinuxBios stuff sounds interesting. > > I have a Micron Millenium with a BCM DR737 motherboard sitting around > doing nothing in my lab. I know, it's kind of old, but maybe it'll be > good enough to provide me a learning experience... > > Any opinions on whether this MoBo is even worth experimenting with? > > > ---------------------------------------------------------------------- ------ > Mike Westfall Software/Systems Engineer, > Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, > Email: mikew at lanl.gov Nonproliferation and International Security Division. > Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 > ---------------------------------------------------------------------- ------ > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From steve at nexpath.com Thu Sep 4 15:34:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Sep 4 15:34:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: <20030904151613.GR7092@maybe.org> <20030904154147.GH28986@lea.ulyssis.org> <3F576637.509@nexpath.com> Message-ID: <3F579A1C.2030703@nexpath.com> Eric W. Biederman wrote: > Steve Gehlbach writes: > > >>Vincent Touquet wrote: >> >> >>>Not sure if the Phoenix DRM BIOS fits into this picture. >> >>I suspect the Xbox is your clue... MS has had plenty of practice on encrypting >>the bios and locking out foreign app sw, and the xboxlinux group has been the >>test foil (although in the short run they are on top right now). > > > Boards don't sell if people won't buy them. > > Eric > I think people will buy if them if they are cheap enough. Imagine a mobo that only runs Win2k and sells (in a system) for cost, like the Xbox, where the revenue stream is the license fees for software, shared by the mfr and distributor. The implications for linuxbios is that any reverse engineering to determine chip function is a violation of DMCA (because of the encryption), with stiff penalties. The reverse engineering exception may apply, but this DMCA exeception does not allow public dissemination of the information that is discovered (see Judge Kaplan's opinion in the DeCSS case). Via is already making it hard enough without encryption. My worry is that this is prong two of a two prong aproach to slowing Linux down by MS. The other being the SCO license FUD. -Steve From mikew at lanl.gov Thu Sep 4 15:43:00 2003 From: mikew at lanl.gov (Mike Westfall) Date: Thu Sep 4 15:43:00 2003 Subject: New to list In-Reply-To: <000b01c3731d$94d15b20$0100a8c0@who5> References: <000b01c3731d$94d15b20$0100a8c0@who5> Message-ID: <3F579A21.6040801@lanl.gov> Gregg C Levine wrote: > Hello from Gregg C Levine > Mike, can you provide some information on this beast? What's its > chosen processor? Also you'll need to run a "#lspci -v" for us (# mark > for shell prompt). Oh, and as a side note, nice to see you here. OK, well I haven't actually got linux installed yet. That's the first step. It's got a Pentium II in it, and, I believe, a 440BX chipset. More when I get the thing set up and running.... ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From rminnich at lanl.gov Thu Sep 4 15:53:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 15:53:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <3F579A1C.2030703@nexpath.com> Message-ID: OK, it is true, there is an issue. Consider this, however. There are now several vendors actively supporting LinuxBIOS: AMD, Tyan, ASUS, and a few I can name in another few days. There's money in LinuxBIOS. Market forces are starting to sway our way. So don't worry too much. ron From steve at nexpath.com Thu Sep 4 16:17:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Sep 4 16:17:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: Message-ID: <3F57A43E.3020302@nexpath.com> ron minnich wrote: > OK, it is true, there is an issue. > > Consider this, however. There are now several vendors actively supporting > LinuxBIOS: AMD, Tyan, ASUS, and a few I can name in another few days. > There's money in LinuxBIOS. > > Market forces are starting to sway our way. So don't worry too much. > Cool, love to see the name "Via" in that list someday. -Steve From rminnich at lanl.gov Thu Sep 4 17:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 17:29:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <3F57A43E.3020302@nexpath.com> Message-ID: On Thu, 4 Sep 2003, Steve Gehlbach wrote: > Cool, love to see the name "Via" in that list someday. VIA was extremely helpful with the EIPA issues, from what I understand. We're getting there. Also, be aware that the much of the world is less than happy with the idea of any one vendor controlling their software, much less their PC architecture. Anything that pushes to unity of control (such as DRM in the BIOS) will probably be poorly received. ron From mikew at lanl.gov Thu Sep 4 17:54:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Thu Sep 4 17:54:01 2003 Subject: New to list In-Reply-To: <3F579A21.6040801@lanl.gov> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> Message-ID: <3F57B8DB.1040205@lanl.gov> Mike Westfall wrote: > Gregg C Levine wrote: > >> Hello from Gregg C Levine >> Mike, can you provide some information on this beast? What's its >> chosen processor? Also you'll need to run a "#lspci -v" for us (# mark >> for shell prompt). Oh, and as a side note, nice to see you here. > > > OK, well I haven't actually got linux installed yet. That's the first step. > > It's got a Pentium II in it, and, I believe, a 440BX chipset. > > More when I get the thing set up and running.... OK.. Linux installed. Here's what I have: Script started on Thu 04 Sep 2003 04:01:38 PM MDT [mikew at dirtbag mikew]$ su -lc "lspci -v" Password: 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 02) Flags: bus master, medium devsel, latency 64 Memory at e0000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: e4000000-e5ffffff Prefetchable memory behind bridge: e6000000-e6ffffff 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at f000 [size=16] 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at e000 [size=32] 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) Flags: medium devsel, IRQ 9 00:0d.0 Multimedia audio controller: ESS Technology ES1968 Maestro 2 Subsystem: Micron: Unknown device 0737 Flags: bus master, medium devsel, latency 64, IRQ 9 I/O ports at e400 [size=256] Capabilities: [c0] Power Management version 1 00:13.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at e800 [size=64] Expansion ROM at e7000000 [disabled] [size=64K] 01:00.0 VGA compatible controller: NVidia / SGS Thomson (Joint Venture) Riva128 (rev 22) (prog-if 00 [VGA]) Subsystem: Micron: Unknown device 0737 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at e4000000 (32-bit, non-prefetchable) [size=16M] Memory at e6000000 (32-bit, prefetchable) [size=16M] Expansion ROM at [disabled] [size=4M] Capabilities: [44] AGP version 1.0 [mikew at dirtbag mikew]$ exit Script done on Thu 04 Sep 2003 04:02:03 PM MDT Oh, and thanks for the welcome, and any help y'all can provide. ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From rminnich at lanl.gov Thu Sep 4 18:13:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 18:13:01 2003 Subject: New to list In-Reply-To: <3F57B8DB.1040205@lanl.gov> Message-ID: this will probably work just fine. Hey, looks like you are from LANL, come by and say hello (we're in the ACL) ron From rminnich at lanl.gov Thu Sep 4 22:36:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 22:36:00 2003 Subject: A question on the SC 520 Message-ID: My first shot at a simpler target for V2 is the AMD Elan SC520. It's as different from the K8 as I can get. I can thus test the structure of V2 and see how hard this will be. V2 is good at really complex systems such as the K8 (probably the most complex system we've ever done); how hard is it for really simple systems; how much of a burden is the "complex system" support when writing for a simple system? This is a pretty integrated chip. It can't be said to have a north/southbridge per se. I'm thinking of doing something like this: src/mainboard/jumptech/mops520 src/cpu/amd/sc520 and that would be it. No north or southbridge directories. The code to bring up the 520 is pretty straightforward, and AMD offers it all in source form, which is really helpful. It looks to be about a few tens of lines of C code for the hard-wired DRAM case, which is the first one I will try. Comments welcome. ron From YhLu at tyan.com Thu Sep 4 22:53:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 4 22:53:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188C37@TYANWEB> Eric, The AGP display Adapter shown out too. When enumerating the CPU 0 Link0 for 8151, it first collapse the early non-conherent device 5:0.0 ( 8151) and then assign unit id (1) to him. So the device id is change to 5:1.0. After that on bus5 there is a invalid device 5:0.0 is there.( Child of Bus 5). I wonder that We should remove that invalid device or change unit id back to 0 before calling pci_scan_bus. According to AMD datasheet, the device on bus other bus 0 can use 0 as unit id. Of' course should name it some bigger unit id and after enumerating chain, change it back to 0. It hang out after scan link2 and link0. ??? Regards YH. Jumping to LinuxBIOS. LinuxBIOS-1.1.42.0_Fallback Fri Sep 5 02:45:43 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 [1022/746d] enabled PCI: 01:04.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled PCI: 04:01.0 [1022/7462] enabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 4 Hypertransport scan link done Hyper transport scan link: 0 max: 5 PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004 Hypertransport link capability not foundPCI: pci_scan_bus for bus 5 PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:00.0 No device operations PCI: 05:01.0 [1022/7454] ops PCI: 05:01.0 [1022/7454] enabled PCI: 05:02.0 [1022/7455] bus ops PCI: 05:02.0 [1022/7455] enabled PCI: 05:00.0 No device operations PCI: pci_scan_bus for bus 6 PCI: 06:00.0 [10de/0322] enabled PCI: pci_scan_bus returning with max=06 PCI: pci_scan_bus returning with max=06 Hyper transport scan link: 0 new max: 6 Hypertransport scan link done From steve at nexpath.com Thu Sep 4 23:18:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Sep 4 23:18:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: Message-ID: <3F5804FA.7080209@nexpath.com> ron minnich wrote: > On Thu, 4 Sep 2003, Steve Gehlbach wrote: > >>Cool, love to see the name "Via" in that list someday. > > > VIA was extremely helpful with the EIPA issues, from what I understand. > Well actually, my beef is about not releasing datasheets. AFAIK we still do not have the direct register VGA working for EPIA-800, due to some hidden enable of some kind or another. And in this case, we have the datasheet, so it probably undocumented. But the other EPIAs, with the CLE266, the datasheet is not available to my knowledge. -Steve From rminnich at lanl.gov Thu Sep 4 23:23:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 4 23:23:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <3F5804FA.7080209@nexpath.com> Message-ID: On Thu, 4 Sep 2003, Steve Gehlbach wrote: > Well actually, my beef is about not releasing datasheets. AFAIK we still > do not have the direct register VGA working for EPIA-800, due to some > hidden enable of some kind or another. And in this case, we have the > datasheet, so it probably undocumented. But the other EPIAs, with the > CLE266, the datasheet is not available to my knowledge. as of today, David Hendriks built a BIOS for EPIA with SONE's freebios source tree, and the VGA is working fine. I think there's literally one bit left to find. We are now trying to see why our latest CVS does not work, but we're very close with this. It's going to turn into a diff -r. Hang in there. ron p.s. Next we try to get via-rhine to boot the node in less than 3 minutes ... From ollie at sis.com.tw Thu Sep 4 23:59:00 2003 From: ollie at sis.com.tw (???) Date: Thu Sep 4 23:59:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS References: <20030904151613.GR7092@maybe.org><20030904154147.GH28986@lea.ulyssis.org> <3F576637.509@nexpath.com> Message-ID: <012701c37360$b0440bd0$0201a8c0@ollie> > > > > I suspect the Xbox is your clue... MS has had plenty of practice on encrypting > > the bios and locking out foreign app sw, and the xboxlinux group has been the > > test foil (although in the short run they are on top right now). > > Boards don't sell if people won't buy them. > I am afraid they will buy it when they have no or very few choice. When the majority of the boards on the market are DRM enabled or most of the digital information requires DRM to be accessed, pepole will buy these products. I don't know how it is in the U.S., but here in Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" for its "Trusted Computing" hype. Ollie From steve at nexpath.com Fri Sep 5 00:12:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Fri Sep 5 00:12:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: Message-ID: <3F5811C4.7090907@nexpath.com> ron minnich wrote: > > as of today, David Hendriks built a BIOS for EPIA with SONE's freebios > source tree, and the VGA is working fine. I think there's literally one > bit left to find. I'd love to know which bit; but of course that is typical VGA, one bit off or 100 bits off, same result, black screen. I'll admit I never gave it a really hard effort, I just didn't have the time right now. -Steve From sc at flagen.com Fri Sep 5 02:02:00 2003 From: sc at flagen.com (David Hendricks) Date: Fri Sep 5 02:02:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: <3F5804FA.7080209@nexpath.com> Message-ID: <2015.68.35.24.31.1062746396.squirrel@mail.flagen.com> Yeah, that whole via-rhine (Or via_rhine, more like) issue is somewhat bizarre, but is an issue for another thread :) > On Thu, 4 Sep 2003, Steve Gehlbach wrote: > >> Well actually, my beef is about not releasing datasheets. AFAIK we still >> do not have the direct register VGA working for EPIA-800, due to some >> hidden enable of some kind or another. And in this case, we have the >> datasheet, so it probably undocumented. But the other EPIAs, with the >> CLE266, the datasheet is not available to my knowledge. > > as of today, David Hendriks built a BIOS for EPIA with SONE's freebios > source tree, and the VGA is working fine. I think there's literally one > bit left to find. > > We are now trying to see why our latest CVS does not work, but we're very > close with this. It's going to turn into a diff -r. > > Hang in there. > > ron > p.s. Next we try to get via-rhine to boot the node in less than 3 minutes > ... > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From ts1 at cma.co.jp Fri Sep 5 02:31:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri Sep 5 02:31:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <3F5811C4.7090907@nexpath.com> References: <3F5811C4.7090907@nexpath.com> Message-ID: <20030905065003.GA1518@cma.co.jp> On Thu, Sep 04, 2003 at 09:32:04PM -0700, Steve Gehlbach wrote: > ron minnich wrote: > > >as of today, David Hendriks built a BIOS for EPIA with SONE's freebios > >source tree, and the VGA is working fine. I think there's literally one > >bit left to find. Good to hear that. > I'd love to know which bit; but of course that is typical VGA, one bit > off or 100 bits off, same result, black screen. I'll admit I never gave > it a really hard effort, I just didn't have the time right now. To clarify, what I've done is merely enabling VGA by executing the mfr's proprietary VGABIOS. Perhaps Steve is talking about enabling the device without such binary-only code, but by directly programming the (poorly documented) registers with outb()'s, etc. Of cource I too would like to have such an open sourced code. -- Takeshi From rodmur at maybe.org Fri Sep 5 07:58:02 2003 From: rodmur at maybe.org (Dale Harris) Date: Fri Sep 5 07:58:02 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <012701c37360$b0440bd0$0201a8c0@ollie> References: <3F576637.509@nexpath.com> <012701c37360$b0440bd0$0201a8c0@ollie> Message-ID: <20030905121645.GA29466@maybe.org> On Fri, Sep 05, 2003 at 11:48:39AM +0800, ??? elucidated: > > I am afraid they will buy it when they have no or very few choice. When > the majority of the boards on the market are DRM enabled or most of > the digital information requires DRM to be accessed, pepole will > buy these products. I don't know how it is in the U.S., but here in > Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" > for its "Trusted Computing" hype. > Heh, a virus that is possible because of their crappy software... the irony. Dale From rsmith at bitworks.com Fri Sep 5 10:05:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri Sep 5 10:05:01 2003 Subject: New to list In-Reply-To: <3F57B8DB.1040205@lanl.gov> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> Message-ID: <3F589C63.7080508@bitworks.com> Mike Westfall wrote: > OK.. Linux installed. > Here's what I have: > > 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge You appear to be good to go here. The 440 code in the LB 1 tree should just work. I don't see a superIO in your device listing though. What does your serial ports? > 01:00.0 VGA compatible controller: NVidia / SGS Thomson (Joint Venture) > Riva128 (rev 22) (prog-if 00 [VGA]) Don't know about the status here but you might get it to work under ADLO. -- Richard A. Smith rsmith at bitworks.com From mikew at lanl.gov Fri Sep 5 10:10:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Fri Sep 5 10:10:01 2003 Subject: New to list In-Reply-To: References: Message-ID: <3F589D9F.7010005@lanl.gov> ron minnich wrote: > this will probably work just fine. > > Hey, looks like you are from LANL, come by and say hello (we're in the > ACL) Hey, cool. I'd love to see what you guys are up to. When would be a good time? On another note, the system I have here has its BIOS on a 256 kByte 32-pin PLCC flash device (AM29F002NT). Is this big enough? ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From rminnich at lanl.gov Fri Sep 5 10:47:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 10:47:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <012701c37360$b0440bd0$0201a8c0@ollie> Message-ID: On Fri, 5 Sep 2003, ??? wrote: > I am afraid they will buy it when they have no or very few choice. When > the majority of the boards on the market are DRM enabled or most of > the digital information requires DRM to be accessed, pepole will > buy these products. I don't know how it is in the U.S., but here in > Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" > for its "Trusted Computing" hype. that's quite funny. First, M$ builds insecure software, then pushes DRM as a fix for their own software? hmm. ron From mikew at lanl.gov Fri Sep 5 10:54:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Fri Sep 5 10:54:01 2003 Subject: New to list In-Reply-To: <3F589C63.7080508@bitworks.com> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> <3F589C63.7080508@bitworks.com> Message-ID: <3F58A7E7.3040804@lanl.gov> Richard Smith wrote: > I don't see a superIO in your device listing though. What does your > serial ports? I'm assuming that legacy devices are taken care of by the PIIX4 southbridge (FW82371EB). But I'm probably just blowing smoke, 'cause I don't really know... ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From steve at nexpath.com Fri Sep 5 11:05:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Fri Sep 5 11:05:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <20030905065003.GA1518@cma.co.jp> References: <3F5811C4.7090907@nexpath.com> <20030905065003.GA1518@cma.co.jp> Message-ID: <3F58AC86.1050505@nexpath.com> SONE Takeshi wrote: > To clarify, what I've done is merely enabling VGA by executing the > mfr's proprietary VGABIOS. > Perhaps Steve is talking about enabling the device without > such binary-only code, but by directly programming the > (poorly documented) registers with outb()'s, etc. > Of cource I too would like to have such an open sourced code. > Yes, I am talking about direct register programming. The BIOS approach is very useful, but I want to do it directly. Just a personal thing, like Linus' comment in setup.S, "we don't need no steenking BIOS anyway". I did see one VGA legacy register in the vt8601 datasheet, copied below, that looks a little funny. I thought it defaulted to a useable default state, but maybe not. But this "read 3C6 four times to enable" is the kind of thing where if you do not have the datasheet you are up a creek. -Steve Port 3C6 ? VGA RAMDAC Command........................... RW This register is a non-standard VGA register (?extension register?) located at the same port address as the VGA RAMDAC Pixel Mask register. In order to maintain compatibility with standard VGA operations, access to this register is restricted: access is enabled by performing four successive accesses to the Pixel Mask register at 3C6 (i.e., read 3C6 four times). 7-4 Color Mode Select 0000 Pseudo-Color Mode ................................default 0001 Hi-Color Mode (15-bit direct interface) 0010 Muxed Pseudo-Color Mode (16-bit pixel bus) 0011 XGA Color Mode (16-bit direct interface) 01xx -reserved- 10xx -reserved- 1100 -reserved- 1101 True Color Mode (24-bit direct interface) 111x -reserved- 3 Reserved ......................................... always reads 0 2 DAC Disable 0 DAC On (if SR20[0] = 1) .......................default 1 DAC Off 1 Reserved ......................................... always reads 0 0 RAMDAC Enable 0 Disable (Bypass) RAMDAC ..................default 1 Enable RAMDAC From Antony at Soft-Solutions.co.uk Fri Sep 5 11:07:00 2003 From: Antony at Soft-Solutions.co.uk (Antony Stone) Date: Fri Sep 5 11:07:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: Message-ID: <200309051525.h85FPT503023@onyx.rockstone.co.uk> On Friday 05 September 2003 4:05 pm, ron minnich wrote: > On Fri, 5 Sep 2003, ??? wrote: > > I am afraid they will buy it when they have no or very few choice. When > > the majority of the boards on the market are DRM enabled or most of > > the digital information requires DRM to be accessed, pepole will > > buy these products. I don't know how it is in the U.S., but here in > > Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" > > for its "Trusted Computing" hype. > > that's quite funny. First, M$ builds insecure software, then pushes DRM as > a fix for their own software? Not so new, I think. For years they've been buildig insecure software, then pushing the next version of Windows as "the most reliable and most secure version of Windows ever" (by "ever" of course, they mean "so far"). Antony. -- Abandon hope, all ye who enter here. You'll feel much better about things once you do. From steve at nexpath.com Fri Sep 5 11:12:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Fri Sep 5 11:12:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: References: Message-ID: <3F58AE51.8080201@nexpath.com> ron minnich wrote: > > that's quite funny. First, M$ builds insecure software, then pushes DRM as > a fix for their own software? > Who was it that said, "No one ever went broke underestimating the stupidity of the American public" ? P.T. Barnum I think. -Steve From michel.belleau at malaiwah.com Fri Sep 5 11:42:01 2003 From: michel.belleau at malaiwah.com (Michel Belleau) Date: Fri Sep 5 11:42:01 2003 Subject: Hangs at PCI ressources Message-ID: <1062777912.3f58b438bdc99@www.malaiwah.com> Hi everyone. I just wanted to tell you that I finally received my two spare flash chips for my EPIA800. Considering I couldn't make it work with the Millenium, I'm trying to make it work with a standard flash chip now. At my surprise this morning, IT BOOTED! I saw something on the serial console. It looks like it's trying to allocate PCI ressources but just hangs in here. I see the greeting, it looks like it finds the southbridge but it hangs right after that. I remember seeing that it fails to "config_pci_direct" or something like that.. What did I do wrong? What can I check when I'll be back home tonight? Thanks! -- Michel Belleau From mikew at lanl.gov Fri Sep 5 11:52:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Fri Sep 5 11:52:01 2003 Subject: New to list In-Reply-To: <3F58A7E7.3040804@lanl.gov> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> <3F589C63.7080508@bitworks.com> <3F58A7E7.3040804@lanl.gov> Message-ID: <3F58B5AB.2070903@lanl.gov> Mike Westfall wrote: > Richard Smith wrote: > >> I don't see a superIO in your device listing though. What does your >> serial ports? > > > I'm assuming that legacy devices are taken care of by the PIIX4 > southbridge (FW82371EB). > > But I'm probably just blowing smoke, 'cause I don't really know... Ok, I was blowing smoke. The serial ports (and other stuff) are handled by a Winbond W83977TF chip, which I suppose is connected to the PIIX4E's ISA bus... ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From rsmith at bitworks.com Fri Sep 5 12:38:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri Sep 5 12:38:01 2003 Subject: New to list In-Reply-To: <3F58B5AB.2070903@lanl.gov> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> <3F589C63.7080508@bitworks.com> <3F58A7E7.3040804@lanl.gov> <3F58B5AB.2070903@lanl.gov> Message-ID: <3F58C022.8010806@bitworks.com> Mike Westfall wrote: >>> I don't see a superIO in your device listing though. What does your >>> serial ports? >> > Ok, I was blowing smoke. > > The serial ports (and other stuff) are handled by a Winbond W83977TF > chip, which I suppose is connected to the PIIX4E's ISA bus... Correct. The southbrige will pass all the legacy IO's to the isa buss. mouse and keyboard are usually in that group of superIO functions as well. I looked at the superio tree and there is a W83977ef but not a tf you will need to get the datasheets and look at the difference between the them. Of course you can probally just try the ef and see what happens. If you don't get any serial activity though you will have to fix whatever superio serial port issues there are. I'm really interested in you trying this board so I can see if all my changes to the 440bx tree work for someone else besides me. I don't beleive they have been re-tested by someone else since they were comitted. -- Richard A. Smith rsmith at bitworks.com From ts1 at tsn.or.jp Fri Sep 5 13:13:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Fri Sep 5 13:13:00 2003 Subject: Hangs at PCI ressources In-Reply-To: <1062777912.3f58b438bdc99@www.malaiwah.com> References: <1062777912.3f58b438bdc99@www.malaiwah.com> Message-ID: <20030905173138.GA26471@tsn.or.jp> On Fri, Sep 05, 2003 at 12:05:12PM -0400, Michel Belleau wrote: > It looks like it's trying to allocate PCI ressources but just hangs in here. I > see the greeting, it looks like it finds the southbridge but it hangs right > after that. I remember seeing that it fails to "config_pci_direct" or something > like that.. > > What did I do wrong? What can I check when I'll be back home tonight? Thanks! Maybe we need to see the copy of your serial output. From aip at cwlinux.com Fri Sep 5 13:32:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri Sep 5 13:32:01 2003 Subject: Hangs at PCI ressources In-Reply-To: <1062777912.3f58b438bdc99@www.malaiwah.com>; from Michel Belleau on Fri, Sep 05, 2003 at 12:05:12PM -0400 References: <1062777912.3f58b438bdc99@www.malaiwah.com> Message-ID: <20030906015109.A14376@mail.cwlinux.com> Hi Michel, It is normal, at least for me. :) Your kernel need to skip pci_scan_slot devfn > 0xa8. -Andrew On Fri, Sep 05, 2003 at 12:05:12PM -0400, Michel Belleau wrote: > Hi everyone. > > I just wanted to tell you that I finally received my two spare flash chips for > my EPIA800. Considering I couldn't make it work with the Millenium, I'm trying > to make it work with a standard flash chip now. > > At my surprise this morning, IT BOOTED! I saw something on the serial console. > It looks like it's trying to allocate PCI ressources but just hangs in here. I > see the greeting, it looks like it finds the southbridge but it hangs right > after that. I remember seeing that it fails to "config_pci_direct" or something > like that.. > > What did I do wrong? What can I check when I'll be back home tonight? Thanks! > > -- > Michel Belleau > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From aip at cwlinux.com Fri Sep 5 13:40:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri Sep 5 13:40:00 2003 Subject: Benefit of using ROM Emulator and debugging on VT8623/VT8235 Message-ID: <20030906015825.B14376@mail.cwlinux.com> Hi, I ask those who are using ROM emulator for developing LinuxBIOS. What is the benefit of using it besides flashing romimage? Is it possible to do any code tracing? At the moment, I'm having hard time to trace an interrupt problem on vt8623/vt8235(similar to EPIA-M) where Award'USB works but LinuxBIOS doesn't. However, both has the same IRQ assignments. Furthermore, same code works on EPIA-M with proper IRQ settings. Any suggestion on debugging tools? 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. For public pgp key, please obtain it from http://www.keyserver.net/en. From jeff at planetfall.com Fri Sep 5 14:32:01 2003 From: jeff at planetfall.com (Jeff Noxon) Date: Fri Sep 5 14:32:01 2003 Subject: New to list In-Reply-To: <3F58C022.8010806@bitworks.com> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> <3F589C63.7080508@bitworks.com> <3F58A7E7.3040804@lanl.gov> <3F58B5AB.2070903@lanl.gov> <3F58C022.8010806@bitworks.com> Message-ID: <20030905185034.GA3842@planetfall.com> I have an MSI board with a 440BX (BXmaster), and also a Dell PWS 210. I'm particulary interested in getting the Dell to work. But the Dell boxes are SMP... The MSI uses a Winbond W83977EF-AW, which is supported. Are most of the BX boards really generic enough that they can be made to work easily? Regards, Jeff On Fri, Sep 05, 2003 at 11:56:02AM -0500, Richard Smith wrote: > I'm really interested in you trying this board so I can see if all my > changes to the 440bx tree work for someone else besides me. I don't > beleive they have been re-tested by someone else since they were comitted. From rminnich at lanl.gov Fri Sep 5 14:57:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 14:57:01 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS In-Reply-To: <20030905065003.GA1518@cma.co.jp> Message-ID: On Fri, 5 Sep 2003, SONE Takeshi wrote: > To clarify, what I've done is merely enabling VGA by executing the > mfr's proprietary VGABIOS. > Perhaps Steve is talking about enabling the device without > such binary-only code, but by directly programming the > (poorly documented) registers with outb()'s, etc. > Of cource I too would like to have such an open sourced code. there is some difference. When he built from CVS, it did not work; when he built from your tree, it worked. ron From rsmith at bitworks.com Fri Sep 5 15:14:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri Sep 5 15:14:00 2003 Subject: New to list In-Reply-To: <20030905185034.GA3842@planetfall.com> References: <000b01c3731d$94d15b20$0100a8c0@who5> <3F579A21.6040801@lanl.gov> <3F57B8DB.1040205@lanl.gov> <3F589C63.7080508@bitworks.com> <3F58A7E7.3040804@lanl.gov> <3F58B5AB.2070903@lanl.gov> <3F58C022.8010806@bitworks.com> <20030905185034.GA3842@planetfall.com> Message-ID: <3F58E4BC.3040307@bitworks.com> Jeff Noxon wrote: > I have an MSI board with a 440BX (BXmaster), and also a Dell PWS 210. > I'm particulary interested in getting the Dell to work. But the Dell > boxes are SMP... Hmmm.... Dunno about the SMP. Ron and Eric perhaps can comment on that . I never messed with any of the smp stuff. Assuming the MSI board dosen't have something flaky with the SMbus to gain access to the SPD it should come up and "just work" YMMV of course. > The MSI uses a Winbond W83977EF-AW, which is supported. Are most of > the BX boards really generic enough that they can be made to work easily? Yes. I think so. There are a few bits in the southbridge setup that are hardcoded to match my board. (ie they aren't configurable in the config file) However, I think that these settings are going to be the same on most of the boards. Perhaps some other custom embedded system might have them different but any board set up like a normal desktop PC should work. -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri Sep 5 15:15:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 15:15:00 2003 Subject: Hangs at PCI ressources In-Reply-To: <1062777912.3f58b438bdc99@www.malaiwah.com> Message-ID: On Fri, 5 Sep 2003, Michel Belleau wrote: > At my surprise this morning, IT BOOTED! I saw something on the serial console. this is linux messages you mean? did you configure pci_direct as the ONLY pci access method in Linux? ron From rminnich at lanl.gov Fri Sep 5 15:21:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 15:21:01 2003 Subject: New to list In-Reply-To: <3F58B5AB.2070903@lanl.gov> Message-ID: On Fri, 5 Sep 2003, Mike Westfall wrote: > The serial ports (and other stuff) are handled by a Winbond W83977TF > chip, which I suppose is connected to the PIIX4E's ISA bus... the 83977ef is supported already. ron From rsmith at bitworks.com Fri Sep 5 15:37:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Fri Sep 5 15:37:00 2003 Subject: New to list In-Reply-To: References: Message-ID: <3F58E9E7.7010506@bitworks.com> ron minnich wrote: >>The serial ports (and other stuff) are handled by a Winbond W83977TF >>chip, which I suppose is connected to the PIIX4E's ISA bus... > the 83977ef is supported already. > What's the diff between a TF and EF? -- Richard A. Smith rsmith at bitworks.com From rminnich at lanl.gov Fri Sep 5 15:49:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 15:49:01 2003 Subject: Hangs at PCI ressources In-Reply-To: <20030906015109.A14376@mail.cwlinux.com> Message-ID: On Sat, 6 Sep 2003, Andrew Ip wrote: > It is normal, at least for me. :) Your kernel need to skip > pci_scan_slot devfn > 0xa8. oh, yes, the hardware bug in the 8601. Still there, eh? wow. ron From mikew at lanl.gov Fri Sep 5 16:23:01 2003 From: mikew at lanl.gov (Mike Westfall) Date: Fri Sep 5 16:23:01 2003 Subject: Winbond W83977 TF vs EF (was: New to list) In-Reply-To: <3F58E9E7.7010506@bitworks.com> References: <3F58E9E7.7010506@bitworks.com> Message-ID: <3F58F532.1010906@lanl.gov> Richard Smith wrote: > ron minnich wrote: > >>> The serial ports (and other stuff) are handled by a Winbond W83977TF >>> chip, which I suppose is connected to the PIIX4E's ISA bus... > > >> the 83977ef is supported already. >> > > What's the diff between a TF and EF? > Looking at the data sheets... - The TF suppports 13 IRQs, the EF only 12. - The TF has "23 programmable general purpose I/O ports; 3 dedicate, 20 optional", while the EF has only "14 programmable general purpose I/O ports; 6 dedicate, 8 optional". Oh, and the TF is compliant wih the Microsoft PC97 Hardware Design Guide; the EF with the PC98 version of same. Big Deal. Other than that, they look identical. ---------------------------------------------------------------------------- Mike Westfall Software/Systems Engineer, Phone: 505.665.5256 NIS-4, Space Instrumentation and Systems Engineering, Email: mikew at lanl.gov Nonproliferation and International Security Division. Snail: Mailstop D448, PO Box 1663, Los Alamos National Laboratory, NM 87545 ---------------------------------------------------------------------------- From rminnich at lanl.gov Fri Sep 5 21:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 5 21:29:01 2003 Subject: New to list In-Reply-To: <3F58E4BC.3040307@bitworks.com> Message-ID: On Fri, 5 Sep 2003, Richard Smith wrote: > Hmmm.... Dunno about the SMP. Ron and Eric perhaps can comment on that > . I never messed with any of the smp stuff. Assuming the MSI board > dosen't have something flaky with the SMbus to gain access to the SPD it > should come up and "just work" YMMV of course. smp has been working fine for years, no issue. ron From rimy2000 at hotmail.com Fri Sep 5 21:51:00 2003 From: rimy2000 at hotmail.com (elife elife) Date: Fri Sep 5 21:51:00 2003 Subject: about etherboot and mkelfImage Message-ID: Hi, I am try etherboot in my epia 5000 now. When I used mkelfImage in linuxbios, it reports Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 Loading Etherboot version: 5.2.0 Dropping non PT_LOAD segment New segment addr 0x20000 size 0xf4e0 offset 0xb0 filesize 0x5f1c (cleaned up) New segment addr 0x20000 size 0xf4e0 offset 0xb0 filesize 0x5f1c Loading Segment: addr: 0x0000000003f7f9a8 memsz: 0x000000000000f4e0 filesz: 0x0000000000005f1c Clearing Segment: addr: 0x0000000003f858c4 memsz: 0x00000000000095c4 Jumping to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc 0x00020000 CPU 552 Mhz Etherboot 5.2.0 (GPL) http://etherboot.org Tagged ELF for [VIA 86C100] Relocating _text from: [00020000,000304f0) to [03eefb10,03f00000) Boot from (N)etwork or (Q)uit? ?Probing pci nic... [dlink-530tx]rhine.c v1.0.1 2003-02-06 IO address 1800 Ethernet Address: 00:40:63:CA:E7:EC Analyzing Media type,this will take several seconds........OK Linespeed=100Mbs Fullduplex Searching for server (DHCP)... ..Me: 172.27.4.254, Server: 172.27.4.23, Gateway 172.27.4.23 Loading 172.27.4.23:kernel ...(ELF)... Loading Linux version: ....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done rhine disable Unknown bootloader class! type=0x00000000 data=0x00000000 Firmware type: LinuxBIOS ?and halts. (The kernel(2.4.20) I uses work fine with linuxbios without etherboot) When I use the newest mkelfImage 2.5, mkelfImage said Internal error convert_magic 00000070 != a5a5a5a5 Any hint? By the way, what's the difference between mkelfImage and mkelfImage-1.6 in lb? Thanks! _________________________________________________________________ ?????????????????????????????? MSN Hotmail?? http://www.hotmail.com From YhLu at tyan.com Fri Sep 5 22:40:00 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 5 22:40:00 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188D32@TYANWEB> Eric, Without hard_reset, s2885 is ok now. In the k8/cpufixup.c need compare mmio_basek and 0x3f0000 and then assign that to TOM. Regards YH -----????----- ???: YhLu ????: 2003?9?4? 12:44 ???: ebiederman at lnxi.com ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 Eric, If I disable the hard_reset, it can enumerate from link2 to link0. And the 8131 on link2 and 8151 on link0 all show out. Maybe you can add MACRO to control reverse scan for AMKK8 northbridge. ( link2 then link0) But it continues to reboot. Regards Yinghai Lu Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 19:17:58 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 [1022/746d] enabled PCI: 01:04.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled PCI: 04:01.0 [1022/7462] enabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 0 Hypertransport scan link done Hyper transport scan link: 0 max: 5 PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004 Hypertransport link capability not foundPCI: pci_scan_bus for bus 5 PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:00.0 No device operations PCI: 05:01.0 [1022/7454] ops PCI: 05:01.0 [1022/7454] enabled PCI: 05:02.0 [1022/7455] bus ops PCI: 05:02.0 [1022/7455] enabled Copying LinuxBIOS to ram. -----????----- ???: YhLu ????: 2003?9?4? 10:48 ???: ebiederman at lnxi.com ??: Stefan Reinauer; LinuxBIOS ??: re: [COMMIT] Infrastructure Updates 4 Eric, In the hypertransport_scan_chain, if the hard_reset is needed, it may produce problem. Hard_reset call 8111 LPC (B1, D4, F0) reg 0x47 to trigger Reset. But it is called before pci_scan_bus. At that time the 8111 LPC is still unkown. Regards YH -----????----- ???: YhLu ????: 2003?9?4? 10:30 ???: 'ebiederman at lnxi.com' ??: Stefan Reinauer; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed _______________________________________________ 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 rimy2000 at hotmail.com Fri Sep 5 23:05:00 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Fri Sep 5 23:05:00 2003 Subject: about etherboot and mkelfImage References: Message-ID: After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is Loading 172.27.4.23:vmlinuz.vo ...(ELF)... .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done rhine disable Firmware type: LinuxBIOS but then I received nothing from serial. Any hint? Thanks!? From agnew at cs.umd.edu Fri Sep 5 23:12:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Fri Sep 5 23:12:00 2003 Subject: about etherboot and mkelfImage In-Reply-To: Message-ID: <20030905233728.R53859-100000@www.missl.cs.umd.edu> Did you put this on your command like "console=ttyS0,115200" (change 115200 for the baud you were using linuxbios at)? On Sat, 6 Sep 2003, rimy2000 wrote: > After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is > > Loading 172.27.4.23:vmlinuz.vo ...(ELF)... .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done > > rhine disable > > Firmware type: LinuxBIOS > > but then I received nothing from serial. > > Any hint? > > Thanks!? > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Fri Sep 5 23:17:00 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 5 23:17:00 2003 Subject: about etherboot and mkelfImage Message-ID: <3174569B9743D511922F00A0C943142303188D36@TYANWEB> 1. You need to verify your Kernel is workable under Normal BIOS. 2. when you using mkelfimage, you need add parameters for Console port and baud rate. YH. -----????----- ???: rimy2000 [mailto:rimy2000 at hotmail.com] ????: 2003?9?5? 20:24 ???: linuxbios at clustermatic.org ??: Re: about etherboot and mkelfImage After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is Loading 172.27.4.23:vmlinuz.vo ...(ELF)... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ .......................................................................done rhine disable Firmware type: LinuxBIOS but then I received nothing from serial. Any hint? Thanks!? _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rimy2000 at hotmail.com Fri Sep 5 23:18:01 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Fri Sep 5 23:18:01 2003 Subject: about etherboot and mkelfImage References: <20030905233728.R53859-100000@www.missl.cs.umd.edu> Message-ID: Yes, I put. ./mkelfImage --kernel=/mnt/root/bzImage-17 --output=vmlinuz.vo --command-line="c onsole=/dev/ttyS0,115200n8 root=/dev/hda2" ----- Original Message ----- From: "Adam Agnew" To: "rimy2000" Cc: Sent: Saturday, September 06, 2003 11:38 AM Subject: Re: about etherboot and mkelfImage > > Did you put this on your command like "console=ttyS0,115200" (change > 115200 for the baud you were using linuxbios at)? > > On Sat, 6 Sep 2003, rimy2000 wrote: > > > After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is > > > > Loading 172.27.4.23:vmlinuz.vo ...(ELF)... .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done > > > > rhine disable > > > > Firmware type: LinuxBIOS > > > > but then I received nothing from serial. > > > > Any hint? > > > > Thanks!? > > > > _______________________________________________ > > 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 rimy2000 at hotmail.com Fri Sep 5 23:22:01 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Fri Sep 5 23:22:01 2003 Subject: about etherboot and mkelfImage References: <3174569B9743D511922F00A0C943142303188D36@TYANWEB> Message-ID: Thanks, but 1. My Kernel is workable under Normal BIOS, it is even workable under Linux BIOS without Etherboot. 2. Yes, I have added them: ./mkelfImage --kernel=/mnt/root/bzImage-17 --output=vmlinuz.vo --command-line="c onsole=/dev/ttyS0,115200n8 root=/dev/hda2" ----- Original Message ----- From: "YhLu" To: "rimy2000" ; Sent: Saturday, September 06, 2003 11:35 AM Subject: Re: about etherboot and mkelfImage 1. You need to verify your Kernel is workable under Normal BIOS. 2. when you using mkelfimage, you need add parameters for Console port and baud rate. YH. -----????----- ???: rimy2000 [mailto:rimy2000 at hotmail.com] ????: 2003?9?5? 20:24 ???: linuxbios at clustermatic.org ??: Re: about etherboot and mkelfImage After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is Loading 172.27.4.23:vmlinuz.vo ...(ELF)... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ .......................................................................done rhine disable Firmware type: LinuxBIOS but then I received nothing from serial. Any hint? Thanks!? _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From agnew at cs.umd.edu Fri Sep 5 23:23:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Fri Sep 5 23:23:01 2003 Subject: about etherboot and mkelfImage In-Reply-To: Message-ID: <20030905234737.O53859-100000@www.missl.cs.umd.edu> Nope, not "console=/dev/ttyS0,115200n8" you want "console=ttyS0,115200n8" (or you can leave out the n8). Give that a shot. But first, as the last mail said, test it under a normal bios (with the same command line!). On Sat, 6 Sep 2003, rimy2000 wrote: > Yes, I put. > > ./mkelfImage --kernel=/mnt/root/bzImage-17 --output=vmlinuz.vo --command-line="c > onsole=/dev/ttyS0,115200n8 root=/dev/hda2" > > > ----- Original Message ----- > From: "Adam Agnew" > To: "rimy2000" > Cc: > Sent: Saturday, September 06, 2003 11:38 AM > Subject: Re: about etherboot and mkelfImage > > > > > > Did you put this on your command like "console=ttyS0,115200" (change > > 115200 for the baud you were using linuxbios at)? > > > > On Sat, 6 Sep 2003, rimy2000 wrote: > > > > > After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is > > > > > > Loading 172.27.4.23:vmlinuz.vo ...(ELF)... .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done > > > > > > rhine disable > > > > > > Firmware type: LinuxBIOS > > > > > > but then I received nothing from serial. > > > > > > Any hint? > > > > > > Thanks!? > > > > > > _______________________________________________ > > > 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 Fri Sep 5 23:27:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Fri Sep 5 23:27:00 2003 Subject: about etherboot and mkelfImage In-Reply-To: Message-ID: <20030905235206.E53859-100000@www.missl.cs.umd.edu> You may also want to try mkelfImage-1.6 (in the linuxbios tree). I've found it to work more often. I also experienced an error using the newest mkelfImage where it would load from linuxbios but not etherboot. But that was perhaps my binutils as well. On Sat, 6 Sep 2003, rimy2000 wrote: > Thanks, but > > 1. My Kernel is workable under Normal BIOS, it is even workable under Linux BIOS without Etherboot. > 2. Yes, I have added them: > > ./mkelfImage --kernel=/mnt/root/bzImage-17 --output=vmlinuz.vo --command-line="c > onsole=/dev/ttyS0,115200n8 root=/dev/hda2" > > ----- Original Message ----- > From: "YhLu" > To: "rimy2000" ; > Sent: Saturday, September 06, 2003 11:35 AM > Subject: Re: about etherboot and mkelfImage > > > 1. You need to verify your Kernel is workable under Normal BIOS. > 2. when you using mkelfimage, you need add parameters for Console port and > baud rate. > > YH. > > -----????????????----- > ?????????: rimy2000 [mailto:rimy2000 at hotmail.com] > ????????????: 2003???9???5??? 20:24 > ?????????: linuxbios at clustermatic.org > ??????: Re: about etherboot and mkelfImage > > After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new > output is > > Loading 172.27.4.23:vmlinuz.vo ...(ELF)... > ............................................................................ > ............................................................................ > ............................................................................ > ............................................................................ > ............................................................................ > ............................................................................ > ............................................................................ > ............................................................................ > .......................................................................done > > rhine disable > > Firmware type: LinuxBIOS > > but then I received nothing from serial. > > Any hint? > > Thanks!??? > > _______________________________________________ > 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 rimy2000 at hotmail.com Fri Sep 5 23:40:01 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Fri Sep 5 23:40:01 2003 Subject: about etherboot and mkelfImage References: <20030905234737.O53859-100000@www.missl.cs.umd.edu> Message-ID: Thanks! I am so careless and after I changed console=/dev/ttyS0 to console=ttyS0 it works fine now. ----- Original Message ----- From: "Adam Agnew" To: "rimy2000" Cc: Sent: Saturday, September 06, 2003 11:48 AM Subject: Re: about etherboot and mkelfImage > Nope, not "console=/dev/ttyS0,115200n8" you want "console=ttyS0,115200n8" > (or you can leave out the n8). Give that a shot. But first, as the last > mail said, test it under a normal bios (with the same command line!). > > > On Sat, 6 Sep 2003, rimy2000 wrote: > > > Yes, I put. > > > > ./mkelfImage --kernel=/mnt/root/bzImage-17 --output=vmlinuz.vo --command-line="c > > onsole=/dev/ttyS0,115200n8 root=/dev/hda2" > > > > > > ----- Original Message ----- > > From: "Adam Agnew" > > To: "rimy2000" > > Cc: > > Sent: Saturday, September 06, 2003 11:38 AM > > Subject: Re: about etherboot and mkelfImage > > > > > > > > > > Did you put this on your command like "console=ttyS0,115200" (change > > > 115200 for the baud you were using linuxbios at)? > > > > > > On Sat, 6 Sep 2003, rimy2000 wrote: > > > > > > > After I upgrade binutils to 2.14, mkelfImage 2.5 work find and the new output is > > > > > > > > Loading 172.27.4.23:vmlinuz.vo ...(ELF)... .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done > > > > > > > > rhine disable > > > > > > > > Firmware type: LinuxBIOS > > > > > > > > but then I received nothing from serial. > > > > > > > > Any hint? > > > > > > > > Thanks!? > > > > > > > > _______________________________________________ > > > > 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 ebiederman at lnxi.com Sat Sep 6 00:02:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sat Sep 6 00:02:00 2003 Subject: about etherboot and mkelfImage In-Reply-To: <20030905235206.E53859-100000@www.missl.cs.umd.edu> References: <20030905235206.E53859-100000@www.missl.cs.umd.edu> Message-ID: Adam Agnew writes: > You may also want to try mkelfImage-1.6 (in the linuxbios tree). I've > found it to work more often. I also experienced an error using the newest > mkelfImage where it would load from linuxbios but not etherboot. But that > was perhaps my binutils as well. Hmm. I think that may have been a transient etherboot bug. I know I fixed a very peculiar bug that kept memtest86 from loading with etherboot. As far as I can tell 2.5 is the most stable, although binutils likes to miscompile it. The nicest part with 2.5 is once you get it compiled it has not external dependencies except libc so it works in a lot more strange settings. Eric From rminnich at lanl.gov Sat Sep 6 09:30:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 6 09:30:01 2003 Subject: about etherboot and mkelfImage In-Reply-To: <20030905233728.R53859-100000@www.missl.cs.umd.edu> Message-ID: On Fri, 5 Sep 2003, Adam Agnew wrote: > > Did you put this on your command like "console=ttyS0,115200" (change > 115200 for the baud you were using linuxbios at)? and also make sure that vga is not enabled. ron From rsmith at bitworks.com Sat Sep 6 12:09:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Sat Sep 6 12:09:00 2003 Subject: New to list In-Reply-To: References: Message-ID: <3F5A0ACC.7080509@bitworks.com> ron minnich wrote: >>Hmmm.... Dunno about the SMP. Ron and Eric perhaps can comment on that >>. I never messed with any of the smp stuff. Assuming the MSI board >>dosen't have something flaky with the SMbus to gain access to the SPD it >>should come up and "just work" YMMV of course. > > smp has been working fine for years, no issue. > ron Well what I was trying to say is that I don't know if the 440bx code will do SMP. I don't remember seeing much of anything about smp in the 440bx stuff I looked at. I know that all the code I worked on dosen't have a clue about smp. But it was all SDRAM detection stuff and some mouse/keyboard settings work. Perhaps thats much further on down the init chain and dosen't care about smp? I do remember the serial ouput mentioning finding a CPU 0 so I may have just never needed to look in those areas. In any case sounds like things are good to go for a test. Check out the lb 1 CVS tree and give it a shot. > On another note, the system I have here has its BIOS > on a 256 kByte 32-pin PLCC flash device (AM29F002NT). Is this big enough? Plenty big enough for linuxbios testing. Not big enough to put a kernel in so you will have to use etherboot or ide to load a kernel. But to test all the linuxbios stuff a kernel isn't necessary. What package type do you have and is it soldered on or socketed? That part has a TSOP option as well as PLCC and DIP. -- Richard A. Smith rsmith at bitworks.com From rimy2000 at hotmail.com Sat Sep 6 20:21:01 2003 From: rimy2000 at hotmail.com (elife elife) Date: Sat Sep 6 20:21:01 2003 Subject: about util/vgabios Message-ID: Hi, I am trying util/vgabios but encounter a strange problem: testbios seems fetching wrong instruction [root at linux vgabios]# ./testbios -s 64k -t ~/lb/500video.bios.bin running file /root/lb/500video.bios.bin No base specified. defaulting to 0xc0000 No initial code segment specified. defaulting to 0xc000 No initial instruction pointer specified. defaulting to 0x0003 Switching to single step mode. AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0005 NV UP DI PL NZ NA PO NC c000:0003 eb53 JMP 58 c000:3 - AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=005a NV UP DI PL NZ NA PO NC c000:0058 0000 ADD [BX+SI],AL c000:58 - [root at linux lb]# od -x 500vi* |more 0000000 aa55 eb60 3753 3034 3030 c237 2a8a 522a 0000020 5345 5245 4556 2044 00b1 4f46 2052 4249 0000040 204d 4f43 504d 5441 4249 4c49 5449 2a59 0000060 2a2a a807 0000 1090 3130 302f 2f37 3032 0000100 3230 0000 2e31 3431 3c20 4144 203e 2020 0000120 3156 2033 2020 2020 83e9 075e 6f43 7970 testbios said c000:0058 is 0000 but in file, it's E9835E JMP 5EDE Best Regards! _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From rminnich at lanl.gov Sat Sep 6 23:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 6 23:41:01 2003 Subject: about util/vgabios In-Reply-To: Message-ID: On Sun, 7 Sep 2003, elife elife wrote: > > Hi, > I am trying util/vgabios but encounter a strange problem: testbios seems > fetching wrong instruction > > [root at linux vgabios]# ./testbios -s 64k -t ~/lb/500video.bios.bin > running file /root/lb/500video.bios.bin > No base specified. defaulting to 0xc0000 > No initial code segment specified. defaulting to 0xc000 > No initial instruction pointer specified. defaulting to 0x0003 > Switching to single step mode. > AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 > DI=0000 > DS=0040 ES=0000 SS=0030 CS=c000 IP=0005 NV UP DI PL NZ NA PO > NC > c000:0003 eb53 JMP 58 > c000:3 - > AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 > DI=0000 > DS=0040 ES=0000 SS=0030 CS=c000 IP=005a NV UP DI PL NZ NA PO > NC > c000:0058 0000 ADD [BX+SI],AL > c000:58 - > > [root at linux lb]# od -x 500vi* |more > 0000000 aa55 eb60 3753 3034 3030 c237 2a8a 522a > 0000020 5345 5245 4556 2044 00b1 4f46 2052 4249 > 0000040 204d 4f43 504d 5441 4249 4c49 5449 2a59 > 0000060 2a2a a807 0000 1090 3130 302f 2f37 3032 > 0000100 3230 0000 2e31 3431 3c20 4144 203e 2020 > 0000120 3156 2033 2020 2020 83e9 075e 6f43 7970 > > testbios said c000:0058 is 0000 but in file, it's E9835E JMP > 5EDE > > Best Regards! interesting, I have seen a similar sort of problem but was not sure what it was. I'll try to take a look. ron From dhroepaem at freechal.com Sun Sep 7 12:33:00 2003 From: dhroepaem at freechal.com (dhroepaem at freechal.com) Date: Sun Sep 7 12:33:00 2003 Subject: EPIA-M 10000 etherboot Message-ID: <10670.1062953503528.JavaMail.Administrator@smtp3> hello~ i have been testing linuxbios with epia-m10000 and rom emulator. i made the romimage from /freebios/src/mainboard/via/epia-m/example.config. when loaded it to rom emulator and reset, hyperterminal said "x-x-f" but when loaded it and reset after loading original epia-m 10000 bios and reset, etherboot worked successfully. following is the config file # # linuxbios config file for: via epia-m mini-itx # target /opt/cwlinux/buildrom/epia-m # via epia mainboard via/epia-m # enable serial console for debugging option serial_console=1 # option serial_post=1 option ttys0_baud=115200 # option ttys0_baud=57600 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 /opt/cwlinux/etherboot/src/bin32/via-rhine.ebi # payload /opt/cwlinux/memtest86/memtest plz, give me some hints~ :-) DDR?? ???! ????? ??? 3D??? ?? ?? http://showtime2.freechal.com/index.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at nexpath.com Sun Sep 7 21:46:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sun Sep 7 21:46:01 2003 Subject: epia800 direct vga working In-Reply-To: References: Message-ID: <3F5BE42E.4060506@nexpath.com> I finally got the epia 800 (vt8601 chipset) direct register vga working. The diff is short, so I attached it. A few issues remain. For some reason or other, a warm reset (reboot from Linux) leaves the VGA is a scrambled state. But a hardware reset or cold start is fine. I could not get the current ide to work, so I backed up to the following revisions on ide: $Id: ide.c,v 1.5 2002/11/11 21:30:45 pyro9 Exp $ $Id: ide.h,v 1.3 2002/12/16 17:57:45 rminnich Exp $ (since my config loads from hda1). It sure appears to me that the repository code for ide is broken, but I did not have time to pin it down. The main issues preventing the vga from being done much sooner are basically a bunch of extended registers that Via uses, that do not initialize to a useable condition on power-on. Takes a while to find which ones, there are hundreds. I would not want to do this without a datasheet, so I don't have much hope for the CLE266 unless the VGA is identical or we get a datasheet for it. -Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: epia.diff URL: From rminnich at lanl.gov Mon Sep 8 00:04:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 00:04:01 2003 Subject: epia800 direct vga working In-Reply-To: <3F5BE42E.4060506@nexpath.com> Message-ID: we will test and commit if it all works. I think I'm going to try to get the emulator fixed and long term go with that, but these fixes are needed for the emulator too. ron From jarcher at pobox.com Mon Sep 8 00:15:00 2003 From: jarcher at pobox.com (jarcher at pobox.com) Date: Mon Sep 8 00:15:00 2003 Subject: Starting new port. In-Reply-To: References: <3F5BE42E.4060506@nexpath.com> Message-ID: <5.2.1.1.2.20030907213222.0214a3f8@cybermorph.com> Hey Ron, I'm starting my port to a new processor/NB and south bridge. Which tree should I be using? Thanks, Jordan At 10:22 PM 9/7/2003 -0600, ron minnich wrote: >we will test and commit if it all works. > >I think I'm going to try to get the emulator fixed and long term go with >that, but these fixes are needed for the emulator too. > >ron > > > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Mon Sep 8 08:45:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 08:45:00 2003 Subject: Starting new port. In-Reply-To: <5.2.1.1.2.20030907213222.0214a3f8@cybermorph.com> Message-ID: On Sun, 7 Sep 2003 jarcher at pobox.com wrote: > I'm starting my port to a new processor/NB and south bridge. Which tree > should I be using? Hmm, that's an interesting question :-) I'd recommend the V2 tree. We're trying to get cut over to that as it is such an improvement, and there is basically 0 assembly required. What CPU? ron From rminnich at lanl.gov Mon Sep 8 08:56:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 08:56:01 2003 Subject: EPIA-M 10000 etherboot [PMX:##] In-Reply-To: <10670.1062953503528.JavaMail.Administrator@smtp3> Message-ID: add this line: option MAXIMUM_CONSOLE_LOGLEVEL=9 not very intuitive, but might help. Do you have a POST card? ron From stepan at suse.de Mon Sep 8 09:04:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 09:04:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: <20030904142833.GB22287@suse.de> Message-ID: <20030908132620.GA7054@suse.de> * ron minnich [030904 17:49]: > On Thu, 4 Sep 2003, Stefan Reinauer wrote: > > > I agree.. but right now there are still Config.lb files in the mainboard > > and in the targets directory. And at least last time I checked both were > > used. > > possibly I am missing your point. What bits did you want to see in > mainboard/Config.lb that are in the target? There are some things that are in both Config.lb files. Some of these make sense as a board default that gets overwritten by the image config file, keeping the idea in mind that whoever builds an image for a certain mainboard has to change/create a targets/ Config.lb, but does not have to care about the mainboards/Config.lb. When porting LinuxBIOS to a new board for a known platform, it should be the other way round. Still, I am uncertain what belongs where ... uses XIP_ROM_SIZE uses XIP_ROM_BASE [..] option CONFIG_CHIP_CONFIGURE=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option _RAMBASE=0x00004000 These are currently found in the arima targets-Config.lb but they seem pretty much mainboard specific, not build specific. Left for the targets config file would be: * console loglevels * console output (serial, vga, ..) * rom/ide streaming (is anything but rom streaming still supported?) * fallback/normal image builds: size, payloads * option table Whats the difference between option FALLBACK_SIZE=131072 and the option option ROM_IMAGE_SIZE=0x10000 in the romimage "fallback" group? Both sound like they do similar things. I had trouble getting a build to work with a kernel (800k) in the normal image and etherboot (~20k) in the fallback image. Do the payload image sizes have to be the same for fallback and normal? I'll investigate further.. Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Mon Sep 8 09:28:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 09:28:00 2003 Subject: buildtarget - building config.py automatically Message-ID: <20030908134954.GA7843@suse.de> Hi, I changed the buildtarget script so that it builds the config.py script automatically when it's not there (i.e. fresh checkout). It gets rebuild already if it's there but not current. Anything speaking against committing applied patch? Stefan -- Architecture Team SuSE Linux AG -------------- next part -------------- Index: buildtarget =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/buildtarget,v retrieving revision 1.2 diff -u -r1.2 buildtarget --- buildtarget 23 Jul 2003 21:30:29 -0000 1.2 +++ buildtarget 8 Sep 2003 13:44:35 -0000 @@ -32,8 +32,13 @@ fi if [ ! -f $config_py ]; then - echo "No linuxbios config file found" - exit 1 + echo "No linuxbios config script found. Rebuilding it.." + ( + cd $config_dir + make config.py + ) + echo "done." + # exit 1 fi # make sure config.py is up-to-date From stepan at suse.de Mon Sep 8 09:43:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 09:43:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188D32@TYANWEB> References: <3174569B9743D511922F00A0C943142303188D32@TYANWEB> Message-ID: <20030908140450.GA8055@suse.de> * YhLu [030906 04:58]: > Eric, > > Without hard_reset, s2885 is ok now. Did you have a look at the implementation of hard_reset in reset.c? void hard_reset(void) { set_bios_reset(); pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); } It looks like if the bus numbering for a mainboard is different, the device (southbridge?) has to be changed here as well. Can this device id somehow be moved to the config file, or generated with the already known config parameters? Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Mon Sep 8 10:19:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 10:19:01 2003 Subject: Older Solo motherboards Message-ID: <20030908144113.GA8185@suse.de> Hi, I chose an older solo motherboard for testing, but I can't get the system up, it bails out with "No memory" most of the time. After a coldstart it gets beyond testing the memory, but then it can't jump to the real linuxbios c image. logs attached Any idea? Stefan -- Architecture Team SuSE Linux AG -------------- next part -------------- LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 133Mhz disabling dimm01 RAM: 0x00040000 KB Ram3 Initializing memory: done Ram4 TOP_MEM: 0000000010000000 Testing DRAM : 00000000-10000000 DRAM fill: 00000000-10000000 [..] DRAM filled DRAM verify: 00000000-10000000 [..] DRAM verified Done. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Ciopying LinuxBIOo ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Ciopying LinuxBIOo ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. -------------- next part -------------- boot attempt 1: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 disabling dimm01 133Mhz No memory boot attempt 2: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 133Mhz disabling dimm00 disabling dimm01 No memory From stepan at suse.de Mon Sep 8 10:39:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 10:39:01 2003 Subject: newer solo motherboards Message-ID: <20030908150150.GA8342@suse.de> Testing the newmethod solo image on a newer motherboard I get the following: with 1 dimm module: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 disabling dimm01 disabling dimm01 133Mhz disabling dimm01 RAM: 0x00040000 KB Ram3 Initializing memory: done Ram4 TOP_MEM: 0000000010000000 Testing DRAM : 00000000-10000000 DRAM fill: 00000000-10000000 [..] DRAM filled DRAM verify: 00000000-10000000 [..] DRAM verified Done. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: NSC 87360 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 0 max: 1 PCI: 01:01.0 [1022/7454] enabled next_unitid: 0004 PCI: 01:04.0 [1022/7460] enabled next_unitid: 0008 HyperT reset needed HyperT reset not needed PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7454] ops PCI: 01:01.0 [1022/7454] enabled PCI: 01:02.0 [1022/7455] bus ops PCI: 01:02.0 [1022/7455] enabled PCI: 01:04.0 [1022/7460] enabled PCI: 01:05.0 [1022/7468] bus ops PCI: 01:05.0 [1022/7468] enabled PCI: 01:05.1 [1022/7469] ops PCI: 01:05.1 [1022/7469] enabled PCI: 01:05.2 [1022/746a] enabled PCI: 01:05.3 [1022/746b] ops PCI: 01:05.3 [1022/746b] enabled PCI: 01:05.5 [1022/746d] enabled PCI: 01:05.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:00.0 [1002/5157] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: 03:00.0 [1022/7464] ops PCI: 03:00.0 [1022/7464] enabled PCI: 03:00.1 [1022/7464] ops PCI: 03:00.1 [1022/7464] enabled PCI: 03:00.2 [1022/7463] ops PCI: 03:00.2 [1022/7463] enabled PCI: 03:01.0 [1022/7462] enabled PCI: 03:05.0 [14e4/1645] enabled PCI: pci_scan_bus returning with max=03 Hyper transport scan link: 0 new max: 3 Hypertransport scan link done amdk8_scan_chains max: 3 done PCI: pci_scan_bus returning with max=03 done Allocating resources... ASSIGN RESOURCES, bus 0 PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io PCI: 00:18.0 b8 <- [0xe0000000 - 0xf81fffff] node 0 link 0 mem ASSIGN RESOURCES, bus 1 PCI: 01:01.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 01:02.0 1c <- [0x00001000 - 0x00001fff] bus 2 io PCI: 01:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 2 prefmem PCI: 01:02.0 20 <- [0xf8000000 - 0xf80fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 02:00.0 14 <- [0x00001000 - 0x000010ff] io PCI: 02:00.0 18 <- [0xf8000000 - 0xf800ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:04.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:04.0 24 <- [0xf8200000 - 0xf81fffff] bus 3 prefmem PCI: 01:04.0 20 <- [0xf8100000 - 0xf81fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:00.0 10 <- [0xf8110000 - 0xf8110fff] mem PCI: 03:00.1 10 <- [0xf8111000 - 0xf8111fff] mem PCI: 03:00.2 10 <- [0xf8113000 - 0xf81130ff] mem PCI: 03:00.2 14 <- [0xf8114000 - 0xf811401f] mem PCI: 03:01.0 10 <- [0xf8112000 - 0xf8112fff] mem PCI: 03:05.0 10 <- [0xf8100000 - 0xf810ffff] mem ASSIGNED RESOURCES, bus 3 PCI: 01:05.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:05.0 00 <- [0x00000000 - 0xffffffff] mem PCI: 01:05.1 20 <- [0x000028e0 - 0x000028ef] io PCI: 01:05.2 10 <- [0x000028c0 - 0x000028df] io PCI: 01:05.5 10 <- [0x00002000 - 0x000020ff] io PCI: 01:05.5 14 <- [0x00002880 - 0x000028bf] io PCI: 01:05.6 10 <- [0x00002400 - 0x000024ff] io PCI: 01:05.6 14 <- [0x00002800 - 0x0000287f] io ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. Enabling resourcess... PCI: 00:18.0 cmd <- 00 PCI: 01:01.0 cmd <- 06 PCI: 01:02.0 bridge ctrl <- 003e PCI: 01:02.0 cmd <- 07 PCI: 02:00.0 cmd <- 83 PCI: 01:04.0 bridge ctrl <- 0000 PCI: 01:04.0 cmd <- 07 PCI: 03:00.0 cmd <- 02 PCI: 03:00.1 cmd <- 02 PCI: 03:00.2 cmd <- 02 PCI: 03:01.0 cmd <- 02 PCI: 03:05.0 cmd <- 02 PCI: 01:05.0 cmd <- 0f PCI: 01:05.1 cmd <- 01 PCI: 01:05.2 cmd <- 01 PCI: 01:05.3 cmd <- 00 PCI: 01:05.5 cmd <- 01 PCI: 01:05.6 cmd <- 01 PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 cmd <- 00 done. Initializing devices... PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 01:02.0 init PCI: 01:05.0 init lpc_init PCI: 01:05.1 init ide_init IDE1 IDE0 PCI: 01:05.3 init PCI: 03:00.0 init USB: Setting up controller.. done. PCI: 03:00.1 init USB: Setting up controller.. done. PCI: 03:00.2 init USB: Setting up controller.. done. Devices initialized mmio_base: 3670016KB totalram: 256M Initializing CPU #0 cpufixup RAM: 0x00040000 KB Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-88) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 256MB, type WB Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 rebooting... Finding PCI configuration type. [..] now it repeatedly resets into pci configuration... With 2 ram modules I found another interesting problem: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 133Mhz RAM: 0x00080000 KB Ram3 Initializing memory: done Ram4 TOP_MEM: 0000000020000000 Testing DRAM : 00000000-20000000 DRAM fill: 00000000-20000000 [..] Now the testing of the first 256 MB work fine, but the second 256 MB fail completely: 10000008:0fffffc8 1000000c:0fffffcc 10000010:0fffffd0 10000014:0fffffd4 10000018:0fffffd8 10000020:0fffffe0 10000024:0fffffe4 10000028:0fffffe8 1000002c:0fffffec 10000030:0ffffff0 10000040:10000000 10000044:0fffffc4 10000048:0fffffc8 1000004c:0fffffcc [..] 10000130:0ffffff0 10000134:10000034 10000138:100000b8 10000140:10000000 10000144:0fffffc4 10000148:0fffffc8 1000014c:0fffffcc 10000150:0fffffd0 10000154:0fffffd4 10000160:0fffffe0 So far... Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 8 10:42:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 10:42:01 2003 Subject: buildtarget - building config.py automatically In-Reply-To: <20030908134954.GA7843@suse.de> Message-ID: thanks, I like it :=-) rno From rminnich at lanl.gov Mon Sep 8 10:44:59 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 10:44:59 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030908140450.GA8055@suse.de> Message-ID: On Mon, 8 Sep 2003, Stefan Reinauer wrote: > * YhLu [030906 04:58]: > > Eric, > > > > Without hard_reset, s2885 is ok now. > > Did you have a look at the implementation of hard_reset in reset.c? > void hard_reset(void) > { > set_bios_reset(); > pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); > } the only reset.c I see is in the mainboard-specific code. Nevertheless this code really should do the find_device thing. on the list of fixes. ron From gwatson at lanl.gov Mon Sep 8 11:44:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Mon Sep 8 11:44:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030908132620.GA7054@suse.de> References: <20030904142833.GB22287@suse.de> <20030908132620.GA7054@suse.de> Message-ID: Any inconsistencies you find in the options are most certainly real. :-) Much of the confusion comes from the configuration setup in the old tree which allowed options to be specified and set in any config file. The result was that many options were duplicated because their definition was buried in some device specific directory somewhere. This is the main reason we now use a global options file so that at least everything is in one place. As it stands there is also no way to distinguish between which options should be set in the target config file and which in the mainboard config, except by convention. It would be relatively easy to add a flag to the option to enforce this if it was felt to be desirable. In any case, please feel free to continue to clean up the option situation as it is long overdue. BTW, I use IDE streaming on the PPC boards. Regards, Greg At 3:26 PM +0200 8/9/03, Stefan Reinauer wrote: >* ron minnich [030904 17:49]: >> On Thu, 4 Sep 2003, Stefan Reinauer wrote: >> >> > I agree.. but right now there are still Config.lb files in the mainboard >> > and in the targets directory. And at least last time I checked both were >> > used. >> >> possibly I am missing your point. What bits did you want to see in >> mainboard/Config.lb that are in the target? > >There are some things that are in both Config.lb files. Some of these >make sense as a board default that gets overwritten by the image config >file, keeping the idea in mind that whoever builds an image for a >certain mainboard has to change/create a targets/ Config.lb, but does >not have to care about the mainboards/Config.lb. When porting LinuxBIOS >to a new board for a known platform, it should be the other way round. > >Still, I am uncertain what belongs where ... > >uses XIP_ROM_SIZE >uses XIP_ROM_BASE >[..] >option CONFIG_CHIP_CONFIGURE=1 >option CPU_FIXUP=1 >option CONFIG_UDELAY_TSC=0 >option i686=1 >option i586=1 >option INTEL_PPRO_MTRR=1 >option k7=1 >option k8=1 >option _RAMBASE=0x00004000 > >These are currently found in the arima targets-Config.lb but they seem >pretty much mainboard specific, not build specific. > >Left for the targets config file would be: >* console loglevels >* console output (serial, vga, ..) >* rom/ide streaming (is anything but rom streaming still supported?) >* fallback/normal image builds: size, payloads >* option table > >Whats the difference between >option FALLBACK_SIZE=131072 >and the option > option ROM_IMAGE_SIZE=0x10000 > >in the romimage "fallback" group? Both sound like they do similar >things. > >I had trouble getting a build to work with a kernel (800k) in the normal >image and etherboot (~20k) in the fallback image. Do the payload image sizes >have to be the same for fallback and normal? > >I'll investigate further.. > > Stefan > > >-- >Architecture Team > SuSE Linux AG >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From YhLu at tyan.com Mon Sep 8 12:37:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Sep 8 12:37:01 2003 Subject: newer solo motherboards Message-ID: <3174569B9743D511922F00A0C943142303188D9B@TYANWEB> HyperT reset needed HyperT reset not needed In the scan_hypertranport_chain.c missed one "else" YH. -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?8? 8:02 ???: LinuxBIOS ??: newer solo motherboards Testing the newmethod solo image on a newer motherboard I get the following: with 1 dimm module: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 disabling dimm01 disabling dimm01 133Mhz disabling dimm01 RAM: 0x00040000 KB Ram3 Initializing memory: done Ram4 TOP_MEM: 0000000010000000 Testing DRAM : 00000000-10000000 DRAM fill: 00000000-10000000 [..] DRAM filled DRAM verify: 00000000-10000000 [..] DRAM verified Done. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: NSC 87360 Enumerating buses...PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled amdk8_scan_chains max: 0 starting... Hyper transport scan link: 0 max: 1 PCI: 01:01.0 [1022/7454] enabled next_unitid: 0004 PCI: 01:04.0 [1022/7460] enabled next_unitid: 0008 HyperT reset needed HyperT reset not needed PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7454] ops PCI: 01:01.0 [1022/7454] enabled PCI: 01:02.0 [1022/7455] bus ops PCI: 01:02.0 [1022/7455] enabled PCI: 01:04.0 [1022/7460] enabled PCI: 01:05.0 [1022/7468] bus ops PCI: 01:05.0 [1022/7468] enabled PCI: 01:05.1 [1022/7469] ops PCI: 01:05.1 [1022/7469] enabled PCI: 01:05.2 [1022/746a] enabled PCI: 01:05.3 [1022/746b] ops PCI: 01:05.3 [1022/746b] enabled PCI: 01:05.5 [1022/746d] enabled PCI: 01:05.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:00.0 [1002/5157] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: 03:00.0 [1022/7464] ops PCI: 03:00.0 [1022/7464] enabled PCI: 03:00.1 [1022/7464] ops PCI: 03:00.1 [1022/7464] enabled PCI: 03:00.2 [1022/7463] ops PCI: 03:00.2 [1022/7463] enabled PCI: 03:01.0 [1022/7462] enabled PCI: 03:05.0 [14e4/1645] enabled PCI: pci_scan_bus returning with max=03 Hyper transport scan link: 0 new max: 3 Hypertransport scan link done amdk8_scan_chains max: 3 done PCI: pci_scan_bus returning with max=03 done Allocating resources... ASSIGN RESOURCES, bus 0 PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io PCI: 00:18.0 b8 <- [0xe0000000 - 0xf81fffff] node 0 link 0 mem ASSIGN RESOURCES, bus 1 PCI: 01:01.0 10 <- [0xe0000000 - 0xefffffff] prefmem PCI: 01:02.0 1c <- [0x00001000 - 0x00001fff] bus 2 io PCI: 01:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 2 prefmem PCI: 01:02.0 20 <- [0xf8000000 - 0xf80fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 02:00.0 14 <- [0x00001000 - 0x000010ff] io PCI: 02:00.0 18 <- [0xf8000000 - 0xf800ffff] mem ASSIGNED RESOURCES, bus 2 PCI: 01:04.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:04.0 24 <- [0xf8200000 - 0xf81fffff] bus 3 prefmem PCI: 01:04.0 20 <- [0xf8100000 - 0xf81fffff] bus 3 mem ASSIGN RESOURCES, bus 3 PCI: 03:00.0 10 <- [0xf8110000 - 0xf8110fff] mem PCI: 03:00.1 10 <- [0xf8111000 - 0xf8111fff] mem PCI: 03:00.2 10 <- [0xf8113000 - 0xf81130ff] mem PCI: 03:00.2 14 <- [0xf8114000 - 0xf811401f] mem PCI: 03:01.0 10 <- [0xf8112000 - 0xf8112fff] mem PCI: 03:05.0 10 <- [0xf8100000 - 0xf810ffff] mem ASSIGNED RESOURCES, bus 3 PCI: 01:05.0 00 <- [0x00000000 - 0xffffffff] io PCI: 01:05.0 00 <- [0x00000000 - 0xffffffff] mem PCI: 01:05.1 20 <- [0x000028e0 - 0x000028ef] io PCI: 01:05.2 10 <- [0x000028c0 - 0x000028df] io PCI: 01:05.5 10 <- [0x00002000 - 0x000020ff] io PCI: 01:05.5 14 <- [0x00002880 - 0x000028bf] io PCI: 01:05.6 10 <- [0x00002400 - 0x000024ff] io PCI: 01:05.6 14 <- [0x00002800 - 0x0000287f] io ASSIGNED RESOURCES, bus 1 ASSIGNED RESOURCES, bus 0 Allocating VGA resource done. Enabling resourcess... PCI: 00:18.0 cmd <- 00 PCI: 01:01.0 cmd <- 06 PCI: 01:02.0 bridge ctrl <- 003e PCI: 01:02.0 cmd <- 07 PCI: 02:00.0 cmd <- 83 PCI: 01:04.0 bridge ctrl <- 0000 PCI: 01:04.0 cmd <- 07 PCI: 03:00.0 cmd <- 02 PCI: 03:00.1 cmd <- 02 PCI: 03:00.2 cmd <- 02 PCI: 03:01.0 cmd <- 02 PCI: 03:05.0 cmd <- 02 PCI: 01:05.0 cmd <- 0f PCI: 01:05.1 cmd <- 01 PCI: 01:05.2 cmd <- 01 PCI: 01:05.3 cmd <- 00 PCI: 01:05.5 cmd <- 01 PCI: 01:05.6 cmd <- 01 PCI: 00:18.1 cmd <- 00 PCI: 00:18.2 cmd <- 00 PCI: 00:18.3 cmd <- 00 done. Initializing devices... PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 01:02.0 init PCI: 01:05.0 init lpc_init PCI: 01:05.1 init ide_init IDE1 IDE0 PCI: 01:05.3 init PCI: 03:00.0 init USB: Setting up controller.. done. PCI: 03:00.1 init USB: Setting up controller.. done. PCI: 03:00.2 init USB: Setting up controller.. done. Devices initialized mmio_base: 3670016KB totalram: 256M Initializing CPU #0 cpufixup RAM: 0x00040000 KB Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-88) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 256MB, type WB Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 rebooting... Finding PCI configuration type. [..] now it repeatedly resets into pci configuration... With 2 ram modules I found another interesting problem: LinuxBIOS-1.1.4.0Fallback Mon Sep 8 16:21:32 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling UP settings Disabling read/write/fill probes for UP... done. coherent_ht_finalize done SMBus controller enabled Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 133Mhz RAM: 0x00080000 KB Ram3 Initializing memory: done Ram4 TOP_MEM: 0000000020000000 Testing DRAM : 00000000-20000000 DRAM fill: 00000000-20000000 [..] Now the testing of the first 256 MB work fine, but the second 256 MB fail completely: 10000008:0fffffc8 1000000c:0fffffcc 10000010:0fffffd0 10000014:0fffffd4 10000018:0fffffd8 10000020:0fffffe0 10000024:0fffffe4 10000028:0fffffe8 1000002c:0fffffec 10000030:0ffffff0 10000040:10000000 10000044:0fffffc4 10000048:0fffffc8 1000004c:0fffffcc [..] 10000130:0ffffff0 10000134:10000034 10000138:100000b8 10000140:10000000 10000144:0fffffc4 10000148:0fffffc8 1000014c:0fffffcc 10000150:0fffffd0 10000154:0fffffd4 10000160:0fffffe0 So far... Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From stepan at suse.de Mon Sep 8 14:59:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 8 14:59:00 2003 Subject: newer solo motherboards In-Reply-To: <3174569B9743D511922F00A0C943142303188D9B@TYANWEB>; from YhLu@tyan.com on Mon, Sep 08, 2003 at 09:55:54AM -0700 References: <3174569B9743D511922F00A0C943142303188D9B@TYANWEB> Message-ID: <20030908211808.B27817@suse.de> * YhLu [030908 18:55]: > HyperT reset needed > HyperT reset not needed > > In the scan_hypertranport_chain.c missed one "else" > > YH. ./src/devices/hypertransport.c:hypertransport_scan_chain() should do the right thing, i.e. trigger a reset. And it seems the reset should go to PCIDEV(1,4,0), as on all other hammer boards. But obviously the code does not do a reset, or does it continue at the same PC afterwards? > SMBus controller enabled > Ram1.00 > setting up CPU00 northbridge registers > done. > Ram2.00 How can i verify that the smbus channels LinuxBIOS uses are correct for my board? The old solos only found RAM in the first socket it seems. > Hyper transport scan link: 0 max: 1 > PCI: 01:01.0 [1022/7454] enabled next_unitid: 0004 > PCI: 01:04.0 [1022/7460] enabled next_unitid: 0008 > HyperT reset needed [ LinuxBIOS should restart HERE ] > HyperT reset not needed > PCI: pci_scan_bus for bus 1 > PCI: 01:01.0 [1022/7454] ops [..] Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Mon Sep 8 15:33:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 8 15:33:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188D32@TYANWEB> References: <3174569B9743D511922F00A0C943142303188D32@TYANWEB> Message-ID: YhLu writes: > Eric, > > Without hard_reset, s2885 is ok now. > > In the k8/cpufixup.c need compare mmio_basek and 0x3f0000 and then assign > that to TOM. Hmm. What is special about 0x3f0000? In any event this sounds promising. It looks like the reset needs to move a little farther down in the code until after all of the hypertransport chains have been enumerated. Eric From ebiederman at lnxi.com Mon Sep 8 15:37:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 8 15:37:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030908132620.GA7054@suse.de> References: <20030904142833.GB22287@suse.de> <20030908132620.GA7054@suse.de> Message-ID: Stefan Reinauer writes: > * ron minnich [030904 17:49]: > > On Thu, 4 Sep 2003, Stefan Reinauer wrote: > > > > > I agree.. but right now there are still Config.lb files in the mainboard > > > and in the targets directory. And at least last time I checked both were > > > used. > > > > possibly I am missing your point. What bits did you want to see in > > mainboard/Config.lb that are in the target? > > There are some things that are in both Config.lb files. Some of these > make sense as a board default that gets overwritten by the image config > file, keeping the idea in mind that whoever builds an image for a > certain mainboard has to change/create a targets/ Config.lb, but does > not have to care about the mainboards/Config.lb. When porting LinuxBIOS > to a new board for a known platform, it should be the other way round. > > Still, I am uncertain what belongs where ... > > uses XIP_ROM_SIZE > uses XIP_ROM_BASE > [..] > option CONFIG_CHIP_CONFIGURE=1 > option CPU_FIXUP=1 > option CONFIG_UDELAY_TSC=0 > option i686=1 > option i586=1 > option INTEL_PPRO_MTRR=1 > option k7=1 > option k8=1 > option _RAMBASE=0x00004000 > > These are currently found in the arima targets-Config.lb but they seem > pretty much mainboard specific, not build specific. Correct. It is a little better on the HDAMA. But currently there are some options that don't seem to work properly when I move them in closer. > Left for the targets config file would be: > * console loglevels > * console output (serial, vga, ..) > * rom/ide streaming (is anything but rom streaming still supported?) > * fallback/normal image builds: size, payloads > * option table The option table pretty much should be mainboard specific, I think. > Whats the difference between > option FALLBACK_SIZE=131072 > and the option > option ROM_IMAGE_SIZE=0x10000 > > in the romimage "fallback" group? Both sound like they do similar > things. As I recall FALLBACK_SIZE is the fallback part of the rom image. Both payload and LinuxBIOS. Whereas ROM_IMAGE_SIZE is just the LinuxBIOS part. > I had trouble getting a build to work with a kernel (800k) in the normal > image and etherboot (~20k) in the fallback image. Do the payload image sizes > have to be the same for fallback and normal? No. Although there are some peculiarities in the new configuration tool. make echo works so you should be able to see what the variables are set to. Eric From rminnich at lanl.gov Mon Sep 8 15:47:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 15:47:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: Message-ID: On 8 Sep 2003, Eric W. Biederman wrote: > Correct. It is a little better on the HDAMA. But currently there are > some options that don't seem to work properly when I move them in closer. yes, I've seen this too, not had time to fix it. Clearly, some things should move into the mainboard file. I just don't want to go back to what we had before, with lots of things getting set/reset/changed all over the place. > > > Left for the targets config file would be: > > * console loglevels > > * console output (serial, vga, ..) > > * rom/ide streaming (is anything but rom streaming still supported?) IDE streaming is not going away any time soon, if ever; too useful too often. > > * fallback/normal image builds: size, payloads > > * option table > > The option table pretty much should be mainboard specific, I think. yup. > > > Whats the difference between > > option FALLBACK_SIZE=131072 > > and the option > > option ROM_IMAGE_SIZE=0x10000 > > > > in the romimage "fallback" group? Both sound like they do similar > > things. > > As I recall FALLBACK_SIZE is the fallback part of the rom image. Both > payload and LinuxBIOS. Whereas ROM_IMAGE_SIZE is just the LinuxBIOS part. we need to rename these, these names are far too confusing. > > > I had trouble getting a build to work with a kernel (800k) in the normal > > image and etherboot (~20k) in the fallback image. Do the payload image sizes > > have to be the same for fallback and normal? > > No. Although there are some peculiarities in the new configuration tool. > make echo > works so you should be able to see what the variables are set to. or just cat Makefile.settings, as the perl is gone and these are now almost always just numbers. send me make output if you want, I'll take a look. ron From nathanael at gnat.ca Mon Sep 8 16:10:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Mon Sep 8 16:10:01 2003 Subject: Acquiring Flash Parts Message-ID: <348137D4-E23B-11D7-84C1-0003931B4D6A@gnat.ca> Hello, I have an EPIA 800. I would like to start with linux bios on this machine. Unfortunately, they only sell the flash parts in rails of 30. at 2.70 a piece we're not talking a passive investment. Wondering two things. Can I use a different part. If so, how do I find out, and which ones would work? Are there places I can order in fewer quantities? Does anyone else with an EPIA board have a different flash part then me (SST 39SF020A 70-4C-NH)? What parts are they using etc... How worried should I be, could I just flash it with linux bios? what is the likelyhood that I'd have problems? Thanks, -- 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 Mon Sep 8 16:24:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 16:24:00 2003 Subject: Acquiring Flash Parts In-Reply-To: <348137D4-E23B-11D7-84C1-0003931B4D6A@gnat.ca> Message-ID: never flash the original bios. never. try digikey or jameco for onesy-twosy orders. But the'll end up costing more like $10 overall. ron From jeff at planetfall.com Mon Sep 8 16:27:00 2003 From: jeff at planetfall.com (Jeff Noxon) Date: Mon Sep 8 16:27:00 2003 Subject: Acquiring Flash Parts In-Reply-To: <348137D4-E23B-11D7-84C1-0003931B4D6A@gnat.ca> References: <348137D4-E23B-11D7-84C1-0003931B4D6A@gnat.ca> Message-ID: <20030908204516.GA13498@planetfall.com> Two suggestions: Find out on the SST website who your local distributor is. Ask for free samples (specify the complete part number(s) and quantity you require). They usually take less than a week. You'll probably have to provide a project name, description, completion date, manufacturing quantities, etc. Just make it up. That's what my local SST distributor told me to do ;) I got five 8-mbit LPC chips this way. Whether this practice is ethical or not is a matter for another discussion group. (I'm not going to worry about it myself, since the SST rep was the one who suggested I "make stuff up" in order for the sample request to be approved.) Generally manufacturers only want to give parts away when they can lead to more sales. However, savvy manufacturers provide a way for hobbyists to purchase parts in single quantities at reasonable prices. Many offer free samples overnight with no-questions-asked. You may be asked to pay for shipping. A shipper account number will suffice in those circumstances. You can get a shipper account with just about any carrier by calling them up and giving them a credit card number. Something else you can do is purchase a rail and offer chips for sale to the group. I suspect you'll eventually sell them. ;) Regards, Jeff On Mon, Sep 08, 2003 at 02:29:54PM -0600, Nathanael Noblet wrote: > Hello, > I have an EPIA 800. I would like to start with linux bios on this > machine. Unfortunately, they only sell the flash parts in rails of 30. > at 2.70 a piece we're not talking a passive investment. Wondering two > things. Can I use a different part. If so, how do I find out, and which > ones would work? Are there places I can order in fewer quantities? Does > anyone else with an EPIA board have a different flash part then me (SST > 39SF020A 70-4C-NH)? What parts are they using etc... > > How worried should I be, could I just flash it with linux bios? what is > the likelyhood that I'd have problems? From ebiederman at lnxi.com Mon Sep 8 16:33:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 8 16:33:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <3174569B9743D511922F00A0C943142303188DD6@TYANWEB> References: <3174569B9743D511922F00A0C943142303188DD6@TYANWEB> Message-ID: YhLu writes: > Eric, > > In the k8/cpufixup.c, you have use 0x3f0000 for TOM ( you said leave 64M for > ROM and Device IO). In case that if the device need more MMIO range, it will > produce problems for example AGP. So You need compare mmio_basek with > 0x3f0000 to see if mmio_basek is smaller than 0x3f0000. ( 0xf0000000 in > bytes.) Hmm. The 64M hole was an initial hard code in raminit.c that was just a small arbitrary hole so we could access I/O devices until everything is setup properly. mmio_basek should be the lowest address at which we have devices. So cpufixup.c should be doing the right thing. Although I have a few pieces to update. > I have ever tried to move that hard_reset to mainboard.c, and it still does > not work for s2885. I will try it on s2880 again. Ok. It really depends on how your bus is enumerated. Eric From linuxbios at techfreakz.net Mon Sep 8 17:58:00 2003 From: linuxbios at techfreakz.net (Alex Scarbro) Date: Mon Sep 8 17:58:00 2003 Subject: K7SEM support broken in freebios? In-Reply-To: Message-ID: <200398231517.089426@techfreakz> An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Mon Sep 8 19:02:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 19:02:01 2003 Subject: newest code release for arima/hdama and ... Message-ID: linux is no longer seeing many of the pci devices. I'm going to take a look, didn't see any obvious reason for this, but ... This bit me as the IRQ router is no longer there. ron From michel.belleau at malaiwah.com Mon Sep 8 19:19:01 2003 From: michel.belleau at malaiwah.com (Michel Belleau) Date: Mon Sep 8 19:19:01 2003 Subject: Acquiring Flash Parts In-Reply-To: <20030908215800.22897.10624.Mailman@nwn.definitive.org> References: <20030908215800.22897.10624.Mailman@nwn.definitive.org> Message-ID: <1063064627.3f5d14335c08f@www.malaiwah.com> Selon linuxbios-request at clustermatic.org: > Hello, > I have an EPIA 800. I would like to start with linux bios on this > machine. Unfortunately, they only sell the flash parts in rails of 30. > at 2.70 a piece we're not talking a passive investment. Wondering two > things. Can I use a different part. If so, how do I find out, and which > ones would work? Are there places I can order in fewer quantities? Does > anyone else with an EPIA board have a different flash part then me (SST > 39SF020A 70-4C-NH)? What parts are they using etc... Hi. I have a EPIA 800 too. I don't want to make an ad for them, but www.badflash.com sent me two blank chips by mail for 10$ each. That's fair and I can keep a backup copy of my original BIOS away from my test lab in case something goes terribly wrong. They didn't send me the exact same SST chip, but it works great. -- Michel Belleau From rminnich at lanl.gov Mon Sep 8 19:34:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 8 19:34:01 2003 Subject: arima hdama and bus 1 Message-ID: What happens is that linuxbios properly scans and enables bus 1, but the linux that boots never scans bus 1 at all. So something is not quite set up right. More as I find it. ron From YhLu at tyan.com Mon Sep 8 22:11:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Sep 8 22:11:01 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303188D9A@TYANWEB> For the s2880/2882/2885, Amd8111 LPC is actually the PCI_DEV(1,0x4,0). Regards Yinghai Lu -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?9?8? 8:03 ???: Stefan Reinauer ??: YhLu; ebiederman at lnxi.com; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 On Mon, 8 Sep 2003, Stefan Reinauer wrote: > * YhLu [030906 04:58]: > > Eric, > > > > Without hard_reset, s2885 is ok now. > > Did you have a look at the implementation of hard_reset in reset.c? > void hard_reset(void) > { > set_bios_reset(); > pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); > } the only reset.c I see is in the mainboard-specific code. Nevertheless this code really should do the find_device thing. on the list of fixes. ron From prl-linuxbios at sychron.com Tue Sep 9 05:59:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Tue Sep 9 05:59:00 2003 Subject: Laptop with Sis 650 chipset Message-ID: I'm planning on getting a laptop; there's a likely candidate with a SiS 650 chipset. Out of curiosity, is it likely that this will be LinuxBIOSable in the near future? Obviously, I haven't got the thing yet, so I can't send the output of lspci -vv. :) I'd be motivated to help port, after a couple of years of heckling from the sidelines, especially if the v2 tree holds out the prospect of needing no assembly. This is it, if anyone is interested: http://www.eurosimm.com/sites/eurosimm.nsf/details.jsp?ItemCode=UKPD-5JBBUH From rminnich at lanl.gov Tue Sep 9 09:46:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 09:46:01 2003 Subject: Laptop with Sis 650 chipset In-Reply-To: Message-ID: I would love to see this happen, the only problem will be the lcd control I think. ron From niki.waibel at newlogic.com Tue Sep 9 11:06:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 9 11:06:01 2003 Subject: epia-m -- accessing bios rom Message-ID: <200309091526.h89FQ4ZS017770@enterprise2.newlogic.at> is it necessary to do some unlocking before reading/writing to the bios area of the epia-m (vt8235)? niki From rminnich at lanl.gov Tue Sep 9 11:33:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 11:33:00 2003 Subject: epia-m -- accessing bios rom In-Reply-To: <200309091526.h89FQ4ZS017770@enterprise2.newlogic.at> Message-ID: On Tue, 9 Sep 2003, Niki Waibel wrote: > is it necessary to do some unlocking before reading/writing > to the bios area of the epia-m (vt8235)? bash-2.05b$ more ~/src/bios/freebios/src/mainboard/via/epia/README To enable flash write, $ setpci -s 0:11.0 40.b=54 -Andrew From nathanael at gnat.ca Tue Sep 9 12:22:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Tue Sep 9 12:22:00 2003 Subject: Acquiring Flash Parts In-Reply-To: Message-ID: <711DFB00-E2E4-11D7-9903-0003931B4D6A@gnat.ca> On Monday, September 8, 2003, at 02:43 PM, ron minnich wrote: > never flash the original bios. never. > > try digikey or jameco for onesy-twosy orders. But the'll end up costing > more like $10 overall. I can handle $10, that is fine. I've called both, and neither handle SST parts. Any others you can think of? Is there anyone else that would want these parts that I could resell them at cost I'm in Canada, so the exchange is in your favor... -- 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 ts1 at tsn.or.jp Tue Sep 9 12:49:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 9 12:49:00 2003 Subject: epia800 direct vga working In-Reply-To: <3F5BE42E.4060506@nexpath.com> References: <3F5BE42E.4060506@nexpath.com> Message-ID: <20030909170813.GA30446@tsn.or.jp> On Sun, Sep 07, 2003 at 07:06:38PM -0700, Steve Gehlbach wrote: > I finally got the epia 800 (vt8601 chipset) direct register vga working. > The diff is short, so I attached it. I tried this tonight and it's working on my EPIA 5000! Thanks for the great work. However there is some issue. via_vga.c doesn't compile when VIDEO_SHOW_LOGO is not defined. I added an extra #ifdef - #endif to a '}' near the end of the file to compile. Secondly, shadow ram code in vgainit.inc doesn't work for me, because I don't use "biosbase 0xffff0000" option, the asm part itself executes on the shadowed area. When I added "biosbase 0xffff0000" to my config, it doesn't build because of the binutils issue. I have tried this option before (when my binutils was old) but it just hung, for reason I don't know. So, I just commented out the shadow ram code, and it still works just fine. I don't know if it affects the warm boot issue, since the warm boot always fails for me, I'm always doing a system reset through the ISA bridge. -- Takeshi From prl-linuxbios at sychron.com Tue Sep 9 13:14:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Tue Sep 9 13:14:00 2003 Subject: Laptop with Sis 650 chipset In-Reply-To: Your message of "Tue, 09 Sep 2003 08:05:17 MDT." Message-ID: > I would love to see this happen, the only problem will be the lcd control > I think. Hm - I haven't quite got your idea of scale, Ron. Is that "problem" a "slight inconvenience" or "several months and NDA'd docs"? :) I have seen various traffic go past about video BIOS, and noted how Adam and Adam dealt with extracting the "real" VGA BIOS. Is that what you are referring to? Or, given that SiS make decent chips and Ollie's a nice helpful guy, is there a reasonable chance of success the direct way? Can anyone comment on the differences between the 650 and M650 (the notebook version)? The chipset is billed as 650, but as it's a laptop, I rather assume that it will be a M650. The I/O chip is a SiS 962 for what it's worth (USB 2 and FireWire). Anyone thinking of a USB stack yet??? Anyway, it's ordered. More news, including lspci -vv when I have it (they're telling me Thursday). From rminnich at lanl.gov Tue Sep 9 13:20:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 13:20:01 2003 Subject: Laptop with Sis 650 chipset In-Reply-To: Message-ID: On Tue, 9 Sep 2003 prl-linuxbios at sychron.com wrote: > Hm - I haven't quite got your idea of scale, Ron. Is that "problem" a > "slight inconvenience" or "several months and NDA'd docs"? :) I wish I knew. > > I have seen various traffic go past about video BIOS, and noted how Adam > and Adam dealt with extracting the "real" VGA BIOS. Is that what you are > referring to? Or, given that SiS make decent chips and Ollie's a nice > helpful guy, is there a reasonable chance of success the direct way? probably but only Ollie knows. ron From rminnich at lanl.gov Tue Sep 9 14:55:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 14:55:01 2003 Subject: more on the arima/hdama pci bus problem Message-ID: the 8111 is being put on pci bus 1, but Linux never sees it. I'm not totally clear yet on why this is happening, but I've got to work on a different problem with this board, so if anyone has any suggestions I'll try them out later. thanks ron From ebiederman at lnxi.com Tue Sep 9 17:44:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 9 17:44:01 2003 Subject: more on the arima/hdama pci bus problem In-Reply-To: References: Message-ID: ron minnich writes: > the 8111 is being put on pci bus 1, but Linux never sees it. > > I'm not totally clear yet on why this is happening, but I've got to work > on a different problem with this board, so if anyone has any suggestions > I'll try them out later. Hmm. I will have to sync up with you. Are you certain the pirq table refers to a device on bus 1? I have a couple odd ball issues but my internal version is starting to look pretty solid. The internal guys won't give me bug reports anymore because the bugs are few enough. I have some serious broadcom NIC tracing to do and then I should be able to sync with the public tree again. Eric From rminnich at lanl.gov Tue Sep 9 18:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 18:04:00 2003 Subject: more on the arima/hdama pci bus problem In-Reply-To: Message-ID: On 9 Sep 2003, Eric W. Biederman wrote: > Hmm. I will have to sync up with you. Are you certain the pirq table > refers to a device on bus 1? It does. The issue is that Linux does not enumerate any devices on Bus 1. LinuxBIOS, however, does, and the 1022:746b device shows up on bus 1 in linuxbios. The PIRQ table in the public tree is wrong, need to fix it. Linux itself enumerates bus 0, then jumps to bus 2. > I have some serious broadcom NIC tracing to do and then I should be able > to sync with the public tree again. we're working on the same thing then. I'm not going to worry about this for present while I look at the tg3 problems. ron From rminnich at lanl.gov Tue Sep 9 18:13:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 18:13:01 2003 Subject: linuxbios, linux, hyperthreading, ACPI, and 2.4.22 Message-ID: We're seeing an interesting problem here. 2.4.22 appears to want to rely on ACPI tables for information on hyperthreading. Diffs seem to show that the linux code that works directly with the hardware to work out hyperthreading is gone. What's happened now is that a dell box, without acpi bios support, will no longer enable hyperthreading. Turn the ACPI support on, and, on the occasions when 2.4.22 doesn't panic when coming up, it does find hyperthreaded CPUs. To panic 2.4.22 while coming up, just hit random keyboard characters while it is engaged in working out hyperthreading. It dies or, sometimes, locks up. This seems like a counterproductive change to me, as it moves Linux more in the direction of depending on factory BIOSes which may, at times, be broken. Has anyone else looked at 2.4.22, and can they confirm or disprove what we think we're seeing? thanks ron From agnew at cs.umd.edu Tue Sep 9 19:10:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 9 19:10:01 2003 Subject: linuxbios, linux, hyperthreading, ACPI, and 2.4.22 In-Reply-To: Message-ID: <20030909192248.G86153-300000@www.missl.cs.umd.edu> Funny you should ask. I was just preparing 2.4.22 again. It does detect 4 processors, though it gives them rather strange numbers. This might be normal? Attached is my serial console log for a Tyan Tiger i7501 and also attached is my 2.4.22 config file. - Adam Agnew On Tue, 9 Sep 2003, ron minnich wrote: > > We're seeing an interesting problem here. 2.4.22 appears to want to rely > on ACPI tables for information on hyperthreading. Diffs seem to show that > the linux code that works directly with the hardware to work out > hyperthreading is gone. > > What's happened now is that a dell box, without acpi bios support, will no > longer enable hyperthreading. Turn the ACPI support on, and, on the > occasions when 2.4.22 doesn't panic when coming up, it does find > hyperthreaded CPUs. To panic 2.4.22 while coming up, just hit random > keyboard characters while it is engaged in working out hyperthreading. It > dies or, sometimes, locks up. > > This seems like a counterproductive change to me, as it moves Linux more > in the direction of depending on factory BIOSes which may, at times, be > broken. > > Has anyone else looked at 2.4.22, and can they confirm or disprove what we > think we're seeing? > > thanks > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -------------- next part -------------- APICID:00 LinuxBIOS-1.0.0 Tue Sep 9 14:12:04 EDT 2003 starting... dimm 50 80 08 07 0d 0b 02 48 00 04 75 75 02 82 04 04 01 0e 04 0c 01 02 26 00 a0 75 00 00 50 3c 50 2d 80 90 90 50 50 00 00 00 00 00 43 4b 34 32 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a 7f 7f 7f 16 00 00 00 00 00 4e 4c 39 31 32 37 52 44 36 34 30 35 32 2d 44 32 31 4a 41 00 02 38 00 00 00 00 4e 65 74 4c 69 73 74 20 49 6e 63 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff dimm 51 80 08 07 0d 0b 02 48 00 04 75 75 02 82 04 04 01 0e 04 0c 01 02 26 00 a0 75 00 00 50 3c 50 2d 80 90 90 50 50 00 00 00 00 00 43 4b 34 32 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a 7f 7f 7f 16 00 00 00 00 00 4e 4c 39 31 32 37 52 44 36 34 30 35 32 2d 44 32 31 4a 41 00 02 38 00 00 00 00 4e 65 74 4c 69 73 74 20 49 6e 63 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff dimm 52 Ram1 dump northbridge: 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 00 00 00 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: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 44 00 80: 00 00 71 00 00 00 00 00 00 a0 31 02 80 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 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: 44 c0 50 11 00 40 ff 03 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 56 46 00 00 00 00 00 00 f0: 00 00 00 00 74 00 00 80 40 0f 00 00 00 00 00 00 Done. C:0000002c:00000000:358015d9 C:00000080:fffff000:00000bb1 C:00000088:ffffff00:00000080 C:00000058:cccccf7f:33333000 C:0000005c:cccccccc:33333333 C:00000060:00000000:04030201 C:00000064:00000000:08070605 C:00000068:ffffffff:00000000 C:0000006c:ffffffff:00000000 C:00000070:00000000:00000000 C:00000074:ffffffff:00000000 C:00000078:c0f8f9c0:3901040f C:0000007c:ff82fcff:00650000 C:0000008c:fffffff0:0000000f C:000000c4:fc0007ff:03ff2000 C:000000c8:fffffc00:00000000 C:000000e0:ffffffe2:0000001c dump northbridge: 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 00 00 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 0f 04 01 39 09 00 65 00 80: b1 0b 71 00 00 00 00 00 00 a0 31 02 8f 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 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: 44 c0 50 11 00 20 ff 03 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 56 48 00 00 00 00 00 00 f0: 00 00 00 00 74 00 00 80 40 0f 00 00 00 00 00 00 Done. Ram2 Reading SPD data... setting based on SPD data... done Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram Enable 6 Ram Enable 7 Ram Enable 8 Ram Enable 9 Ram Enable 10 Ram Enable 11 Ram4 dump northbridge: 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 00 00 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00 70: cc cc 00 00 00 00 00 00 04 04 01 28 79 02 65 00 80: b1 0b 71 00 00 00 00 00 00 98 10 d2 8c 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 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: 44 c0 50 11 00 20 ff 03 00 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 56 48 00 00 00 00 00 00 f0: 00 00 00 00 74 00 00 80 40 0f 00 00 00 00 00 00 Done. Ram5 Initializing ECC state... ECC state initialized. dump northbridge: 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 00 0d 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 10 20 30 40 40 40 40 40 00 00 00 00 00 00 00 00 70: cc cc 00 00 00 00 00 00 04 04 01 28 79 02 65 20 80: b1 0b 71 00 00 00 00 00 00 98 10 d2 8c 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 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: 44 c0 50 11 00 c0 40 00 50 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 56 46 00 00 00 00 00 00 f0: 00 00 00 00 74 00 00 80 40 0f 00 00 00 00 00 00 Done. Bank 01 Side 00 Spot checking: 00000000-0007ffff Bank 01 Side 01 Spot checking: 04000000-0407ffff Bank 02 Side 00 Spot checking: 08000000-0807ffff Bank 02 Side 01 Spot checking: 0c000000-0c07ffff Ram6 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Tue Sep 9 14:12:04 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 handle_superio start, nsuperio 1 handle_superio: Pass 0, check #0, s 00011960 s->super 00013458 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/254c] PCI: 00:00.1 [8086/2541] PCI: 00:02.0 [8086/2543] PCI: 00:1d.0 [8086/2482] PCI: 00:1d.1 [8086/2484] PCI: 00:1d.2 [8086/2487] PCI: 00:1d.7 [8086/248d] PCI: 00:1e.0 [8086/244e] PCI: 00:1f.0 [8086/2480] PCI: 00:1f.1 [8086/248b] PCI: 00:1f.3 [8086/2483] PCI: 00:1f.5 [8086/2485] PCI: 00:1f.6 [8086/2486] PCI: pci_scan_bus for bus 1 PCI: 01:1c.0 [8086/1461] PCI: 01:1d.0 [8086/1460] PCI: 01:1e.0 [8086/1461] PCI: 01:1f.0 [8086/1460] PCI: pci_scan_bus for bus 2 PCI: 02:01.0 [8086/100f] PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:01.0 [8086/1229] PCI: 04:02.0 [1002/4752] PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:02.0 24 <- [0xfe300000 - 0xfe2fffff] bus 1 prefmem PCI: 00:02.0 20 <- [0xfe100000 - 0xfe2fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:1c.0 10 <- [0xfe200000 - 0xfe200fff] mem PCI: 01:1d.0 1c <- [0x00001000 - 0x00001fff] bus 2 io PCI: 01:1d.0 24 <- [0xfe300000 - 0xfe2fffff] bus 2 prefmem PCI: 01:1d.0 20 <- [0xfe100000 - 0xfe1fffff] bus 2 mem ASSIGN RESOURCES, bus 2 PCI: 02:01.0 10 <- [0xfe100000 - 0xfe11ffff] mem PCI: 02:01.0 20 <- [0x00001000 - 0x0000103f] io ASSIGNED RESOURCES, bus 2 PCI: 01:1e.0 10 <- [0xfe201000 - 0xfe201fff] mem PCI: 01:1f.0 1c <- [0x00002000 - 0x00001fff] bus 3 io PCI: 01:1f.0 24 <- [0xfe300000 - 0xfe2fffff] bus 3 prefmem PCI: 01:1f.0 20 <- [0xfe200000 - 0xfe1fffff] bus 3 mem ASSIGNED RESOURCES, bus 1 PCI: 00:1d.0 20 <- [0x000038c0 - 0x000038df] io PCI: 00:1d.1 20 <- [0x000038e0 - 0x000038ff] io PCI: 00:1d.2 20 <- [0x00003c00 - 0x00003c1f] io PCI: 00:1d.7 10 <- [0xfe300000 - 0xfe3003ff] mem PCI: 00:1e.0 1c <- [0x00002000 - 0x00002fff] bus 4 io PCI: 00:1e.0 24 <- [0xfe300000 - 0xfe2fffff] bus 4 prefmem PCI: 00:1e.0 20 <- [0xfd000000 - 0xfe0fffff] bus 4 mem ASSIGN RESOURCES, bus 4 PCI: 04:01.0 10 <- [0xfe020000 - 0xfe020fff] mem PCI: 04:01.0 14 <- [0x00002400 - 0x0000243f] io PCI: 04:01.0 18 <- [0xfe000000 - 0xfe01ffff] mem PCI: 04:02.0 10 <- [0xfd000000 - 0xfdffffff] mem PCI: 04:02.0 14 <- [0x00002000 - 0x000020ff] io PCI: 04:02.0 18 <- [0xfe021000 - 0xfe021fff] mem ASSIGNED RESOURCES, bus 4 PCI: 00:1f.1 10 <- [0x00003c50 - 0x00003c57] io PCI: 00:1f.1 14 <- [0x00003c70 - 0x00003c73] io PCI: 00:1f.1 18 <- [0x00003c60 - 0x00003c67] io PCI: 00:1f.1 1c <- [0x00003c80 - 0x00003c83] io PCI: 00:1f.1 20 <- [0x00003c40 - 0x00003c4f] io PCI: 00:1f.1 24 <- [0xfe301000 - 0xfe3013ff] mem PCI: 00:1f.3 20 <- [0x00003c20 - 0x00003c3f] 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:00.1 cmd <- 00 PCI: 00:02.0 cmd <- 07 PCI: 00:1d.0 cmd <- 01 PCI: 00:1d.1 cmd <- 01 PCI: 00:1d.2 cmd <- 01 PCI: 00:1d.7 cmd <- 02 PCI: 00:1e.0 cmd <- 07 PCI: 00:1f.0 cmd <- 0f PCI: 00:1f.1 cmd <- 03 PCI: 00:1f.3 cmd <- 01 PCI: 00:1f.5 cmd <- 01 PCI: 00:1f.6 cmd <- 01 PCI: 01:1c.0 cmd <- 02 PCI: 01:1d.0 cmd <- 07 PCI: 01:1e.0 cmd <- 02 PCI: 01:1f.0 cmd <- 07 PCI: 02:01.0 cmd <- 03 PCI: 04:01.0 cmd <- 03 PCI: 04:02.0 cmd <- 83 done. Initializing PCI devices... PCI devices initialized remap_high is 0 totalram: 4096M Initializing CPU #0 Updating microcode microcode_info: sig = 0x00000f27 pf=0x00000002 rev = 0x00000000 microcode updated from revision 0 to 40 Thermal Monitoring off L3 cache disabled Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) type: WB Setting fixed MTRRs(24-88) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Setting variable MTRR 5, base: 4096MB, range: 128MB, 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 : 0x0f Processor Model : 0x02 Processor Mask : 0x00 Processor Stepping : 0x07 Feature flags : 0xbfebfbff Cache/TLB descriptor values: 1 reads required Desc 0x50 : UNKNOWN Desc 0x5b : UNKNOWN Desc 0x66 : 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 0x40 : No L2 cache Desc 0x70 : UNKNOWN Desc 0x7b : UNKNOWN Desc 0x00 : null MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic...done. CPU #0 Initialized clocks_per_usec: 3864 secondary_cpu_init Initializing CPU #6 Updating microcode microcode_info: sig = 0x00000f27 pf=0x00000002 rev = 0x00000000 microcode updated from revision 0 to 40 secondary_cpu_init Initializing CPU #1 Updating microcode Thermal Monitoring off microcode_info: sig = 0x00000f27 pf=0x00000002 rev = 0x00000028 CW2 mainboard fixup: microcode updated from revision 40 to 40 ioapic southbridge enabled 2186 Thermal Monitoring off L3 cache disabled Southbridge apic id = 2000000 Enabling cache...Southbridge apic DT = 1 Setting fixed MTRRs(0-88) type: UC IOAPIC 3 at 01:1c.0 MBAR = fe200000 DataAddr = fe200010 L3 cache disabled Setting fixed MTRRs(0-16) type: WB Enabling cache...PCI 3 apic id = 3000000 Setting fixed MTRRs(24-88) type: WB PCI 3 apic DT = 1 DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB IOAPIC 4 at 01:1e.0 MBAR = fe201000 DataAddr = fe201010 Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB PCI 4 apic id = 4000000 Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB secondary_cpu_init Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting fixed MTRRs(0-88) type: UC PCI 4 apic DT = 1 Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Initializing CPU #7 handle_superio start, nsuperio 1 Setting variable MTRR 5, base: 4096MB, range: 128MB, type WB Updating microcode DONE variable MTRRs Clear out the extra MTRR's Setting fixed MTRRs(0-16) type: WB call intel_enable_fixed_mtrr() call intel_enable_var_mtrr() Leave setup_mtrrs handle_superio: Pass 1, check #0, s 00011960 s->super 00013458 done. 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 Max cpuid index : 2 Vendor ID : GenuineIntel Processor Type : 0x00 Processor Family : 0x0f Processor Model : 0x02 Processor Mask : 0x00 Processor Stepping : 0x07 Feature flags : 0xbfebfbff Cache/TLB descriptor values: 1 reads required Desc 0x50 : UNKNOWN Desc 0x5b : handle_superio: Pass 1, done #0 handle_superio done UNKNOWN Desc 0x66 : 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 0x40 : No L2 cache Desc 0x70 : UNKNOWN Desc 0x7b : UNKNOWN Desc 0x00 : null handle_superio start, nsuperio 1 handle_superio: Pass 2, check #0, s 00011960 s->super 00013458 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 MTRR check Waiting for 4 CPUS to stop Fixed MTRRs : Enabled Variable MTRRs: Enabled microcode_info: sig = 0x00000f27 pf=0x00000002 rev = 0x00000028 Setting up local apic...done. microcode updated from revision 40 to 40 CPU #1 Initialized secondary_cpu_init 2/1 Waiting for 3 CPUS to stop Thermal Monitoring off Setting fixed MTRRs(24-88) type: WB L3 cache disabled DONE fixed MTRRs Enabling cache...Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting fixed MTRRs(0-88) type: UC Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB Setting fixed MTRRs(0-16) type: WB Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting fixed MTRRs(24-88) type: WB Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB DONE fixed MTRRs Setting variable MTRR 5, base: 4096MB, range: 128MB, type WB Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB DONE variable MTRRs Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Clear out the extra MTRR's Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB call intel_enable_fixed_mtrr() Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB call intel_enable_var_mtrr() Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Leave setup_mtrrs Setting variable MTRR 5, base: 4096MB, range: 128MB, type WB done. DONE variable MTRRs Clear out the extra MTRR's call intel_enable_fixed_mtrr() Max cpuid index : 2 Vendor ID : GenuineIntel call intel_enable_var_mtrr() Processor Type : 0x00 Processor Family : 0x0f Processor Model : 0x02 Processor Mask : 0x00 Processor Stepping : 0x07 Feature flags : 0xbfebfbff Leave setup_mtrrs Cache/TLB descriptor values: 1 reads required Desc 0x50 : done. UNKNOWN Desc 0x5b : Max cpuid index : 2 Vendor ID : GenuineIntel UNKNOWN Desc 0x66 : 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 0x40 : No L2 cache Desc 0x70 : UNKNOWN Desc 0x7b : UNKNOWN Desc 0x00 : null Processor Type : 0x00 Processor Family : 0x0f Processor Model : 0x02 Processor Mask : 0x00 Processor Stepping : 0x07 Feature flags : 0xbfebfbff MTRR check Cache/TLB descriptor values: 1 reads required Fixed MTRRs : Enabled Variable MTRRs: Enabled Desc 0x50 : Setting up local apic...UNKNOWN Desc 0x5b : UNKNOWN Desc 0x66 : UNKNOWN Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : done. null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x40 : CPU #6 Initialized No L2 cache Desc 0x70 : UNKNOWN Desc 0x7b : UNKNOWN Desc 0x00 : null secondary_cpu_init 1/6 Waiting for 2 CPUS to stop MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic...done. CPU #7 Initialized secondary_cpu_init 3/7 All AP CPUs stopped INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1002, did=4752 rom base, size: f0000000 BAD SIGNATURE 0x0 0x0 Copying IRQ routing tables to 0xf0000...done. Wrote the mp table end at: 00000020 - 000001a4Wrote linuxbios table at: 00000500 - 00000b90 checksum 73bb Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 New segment addr 0x20000 size 0xcc04 offset 0x1000 filesize 0x2b40 (cleaned up) New segment addr 0x20000 size 0xcc04 offset 0x1000 filesize 0x2b40 Loading Segment: addr: 0x00000000f7fe4928 memsz: 0x0000000000001b6c filesz: 0x0000000000001b6c Loading Segment: addr: 0x0000000000021b6c memsz: 0x000000000000b098 filesz: 0x0000000000000fd4 Clearing Segment: addr: 0x0000000000022b40 memsz: 0x000000000000a0c4 Jumping to boot code at 0x2009c Found LinuxBIOS table at: 500 Welcome to the LinuxLabs boot chooser! 210:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff 71:rom_read_bytes() - overflowed source buffer. max_block = 15 init_bytes found 4 tags 71:rom_read_bytes() - overflowed source buffer. max_block = 15 Stream count = 4 blocks STREAM: 0. filo STREAM: 1. linux STREAM: 2. ether STREAM: 3. mem86 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 Found ELF candiate at offset 0 get_bounce_buffer: param = 07fffcf0 get_bounce_buffer: save = 07ff7000, free_ramtop = 07fdd7f8 Loading Linux version: Dropping non PT_LOAD segment New segment addr 0x10000 size 0x58b8 offset 0xd4 filesize 0x562c (cleaned up) New segment addr 0x10000 size 0x58b8 offset 0xd4 filesize 0x562c New segment addr 0x91000 size 0x28 offset 0x58b8 filesize 0x0 (cleaned up) New segment addr 0x91000 size 0x28 offset 0x58b8 filesize 0x0 New segment addr 0x100000 size 0x700000 offset 0x58b8 filesize 0xce565 (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x58b8 filesize 0xce565 Dropping empty segment Loading Segment: addr: 0x0000000000010000 memsz: 0x00000000000058b8 filesz: 0x000000000000562c Clearing Segment: addr: 0x000000000001562c memsz: 0x000000000000028c Loading Segment: addr: 0x0000000000091000 memsz: 0x0000000000000028 filesz: 0x0000000000000000 Clearing Segment: addr: 0x0000000000091000 memsz: 0x0000000000000028 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x00000000000ce565 Clearing Segment: addr: 0x00000000001ce565 memsz: 0x0000000000631a9b Jumping to boot code at 0x101c0 entry = 0x000101c0 lb_start = 0x00020000 lb_size = 0x0000cc04 adjust = 0x07fca3fc buffer = 0x07fdd7f8 elf_boot_notes = 0x00022ae0 adjusted_boot_notes = 0x07fecedc Firmware type: LinuxBIOS Linux version 2.4.22 (root at localhost) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Tue Sep 9 14:50:55 EDT 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000bf0 (reserved) BIOS-e820: 0000000000000bf0 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 00000000f8000000 (usable) BIOS-e820: 0000000100000000 - 0000000108000000 (usable) 3328MB HIGHMEM available. 896MB LOWMEM available. hm, page 00000000 reserved twice. found SMP MP-table at 00000010 hm, page 00000000 reserved twice. hm, page 00001000 reserved twice. hm, page 00000000 reserved twice. hm, page 00001000 reserved twice. On node 0 totalpages: 1081344 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 851968 pages. DMI not present. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: LnxLabs Product ID: Tyan i7500 APIC at: 0xFEE00000 Processor #0 Pentium 4(tm) XEON(tm) APIC version 20 Processor #6 Pentium 4(tm) XEON(tm) APIC version 20 Processor #1 Pentium 4(tm) XEON(tm) APIC version 20 Processor #7 Pentium 4(tm) XEON(tm) APIC version 20 I/O APIC #2 Version 32 at 0xFEC00000. I/O APIC #3 Version 32 at 0xFE201000. I/O APIC #4 Version 32 at 0xFE200000. Enabling APIC mode: Flat. Using 3 I/O APICs Processors: 4 Kernel command line: root=/dev/hda3 console=ttyS0,115200 console=tty0 Initializing CPU#0 Detected 2799.249 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 5583.66 BogoMIPS Memory: 4140624k/4325376k available (1267k kernel code, 53292k reserved, 254k data, 292k init, 3276800k highmem) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode cache hash table entries: 262144 (order: 9, 2097152 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 524288 (order: 9, 2097152 bytes) Page-cache hash table entries: 524288 (order: 9, 2097152 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check reporting enabled on CPU#0. CPU0: Intel(R) Xeon(TM) CPU 2.80GHz stepping 07 per-CPU timeslice cutoff: 1462.64 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 5596.77 BogoMIPS CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check reporting enabled on CPU#1. CPU1: Intel(R) Xeon(TM) CPU 2.80GHz stepping 07 Booting processor 2/6 eip 2000 Initializing CPU#2 masked ExtINT on CPU#2 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 5596.77 BogoMIPS CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 3 Intel machine check reporting enabled on CPU#2. CPU2: Intel(R) Xeon(TM) CPU 2.80GHz stepping 07 Booting processor 3/7 eip 2000 Initializing CPU#3 masked ExtINT on CPU#3 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 5596.77 BogoMIPS CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 3 Intel machine check reporting enabled on CPU#3. CPU3: Intel(R) Xeon(TM) CPU 2.80GHz stepping 07 Total of 4 processors activated (22373.99 BogoMIPS). cpu_sibling_map[0] = 1 cpu_sibling_map[1] = 0 cpu_sibling_map[2] = 3 cpu_sibling_map[3] = 2 ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. Setting 3 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 3 ... ok. Setting 4 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 4 ... ok. ..TIMER: vector=0x31 pin1=2 pin2=0 testing the IO APIC....................... .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2799.2559 MHz. ..... host bus clock speed is 133.2977 MHz. cpu: 0, clocks: 1332977, slice: 266595 CPU0 Message-ID: Greetings, The CPU numbers are normal enough. Or at least that's what I get on my boards. G'day, sjames On Tue, 9 Sep 2003, Adam Agnew wrote: > > Funny you should ask. I was just preparing 2.4.22 again. It does detect 4 > processors, though it gives them rather strange numbers. This might be > normal? > > Attached is my serial console log for a Tyan Tiger i7501 and also attached > is my 2.4.22 config file. > > - Adam Agnew > > > On Tue, 9 Sep 2003, ron minnich wrote: > > > > > We're seeing an interesting problem here. 2.4.22 appears to want to rely > > on ACPI tables for information on hyperthreading. Diffs seem to show that > > the linux code that works directly with the hardware to work out > > hyperthreading is gone. > > > > What's happened now is that a dell box, without acpi bios support, will no > > longer enable hyperthreading. Turn the ACPI support on, and, on the > > occasions when 2.4.22 doesn't panic when coming up, it does find > > hyperthreaded CPUs. To panic 2.4.22 while coming up, just hit random > > keyboard characters while it is engaged in working out hyperthreading. It > > dies or, sometimes, locks up. > > > > This seems like a counterproductive change to me, as it moves Linux more > > in the direction of depending on factory BIOSes which may, at times, be > > broken. > > > > Has anyone else looked at 2.4.22, and can they confirm or disprove what we > > think we're seeing? > > > > thanks > > > > ron > > > > _______________________________________________ > > 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 Tue Sep 9 21:33:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 21:33:01 2003 Subject: linuxbios, linux, hyperthreading, ACPI, and 2.4.22 In-Reply-To: <20030909192248.G86153-300000@www.missl.cs.umd.edu> Message-ID: On Tue, 9 Sep 2003, Adam Agnew wrote: > > Funny you should ask. I was just preparing 2.4.22 again. It does detect 4 > processors, though it gives them rather strange numbers. This might be > normal? the numbers look ok. Now I'm more confused than ever. Why would linuxbios work, and the Dell with ACPI turned off not work? Could it be that the dell bios won't turn on hyperthreading unless ACPI is on? This is 2.4.22 right? ron From agnew at cs.umd.edu Tue Sep 9 21:36:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 9 21:36:01 2003 Subject: overriding command line options in LinuxBIOS Message-ID: <20030909214046.T87001-100000@www.missl.cs.umd.edu> Are there currently any elf loaders that boot under linuxbios which will let you change the default command line in kernel's made with mkelfImage from the serial console? If not, can someone point me to an example of anywhere this works, perhaps outside of linuxbios? I'd like to add it. Thanks! - Adam Agnew From rminnich at lanl.gov Tue Sep 9 21:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 9 21:41:01 2003 Subject: overriding command line options in LinuxBIOS In-Reply-To: <20030909214046.T87001-100000@www.missl.cs.umd.edu> Message-ID: On Tue, 9 Sep 2003, Adam Agnew wrote: > Are there currently any elf loaders that boot under linuxbios which will > let you change the default command line in kernel's made with mkelfImage > from the serial console? no, but I can try to find my hack which lets you change it interactively with the kernel before it is processed. It was a simple hack. ron From ebiederman at lnxi.com Tue Sep 9 21:57:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 9 21:57:01 2003 Subject: overriding command line options in LinuxBIOS In-Reply-To: <20030909214046.T87001-100000@www.missl.cs.umd.edu> References: <20030909214046.T87001-100000@www.missl.cs.umd.edu> Message-ID: Adam Agnew writes: > Are there currently any elf loaders that boot under linuxbios which will > let you change the default command line in kernel's made with mkelfImage > from the serial console? > > If not, can someone point me to an example of anywhere this works, perhaps > outside of linuxbios? I'd like to add it. If you do the magic dhcp option dance etherboot should let you append to the command line. So the user interface sucks but the code path has been tested. Eric From agnew at cs.umd.edu Tue Sep 9 21:59:11 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 9 21:59:11 2003 Subject: linuxbios, linux, hyperthreading, ACPI, and 2.4.22 In-Reply-To: Message-ID: <20030909221546.G87086-100000@www.missl.cs.umd.edu> On Tue, 9 Sep 2003, ron minnich wrote: > > Now I'm more confused than ever. Why would linuxbios work, and the Dell > with ACPI turned off not work? > > Could it be that the dell bios won't turn on hyperthreading unless ACPI is > on? > Your guess is better than mine :) > > This is 2.4.22 right? > Yes, sure is. - Adam Agnew From agnew at cs.umd.edu Tue Sep 9 22:02:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 9 22:02:01 2003 Subject: overriding command line options in LinuxBIOS In-Reply-To: Message-ID: <20030909221732.X87086-100000@www.missl.cs.umd.edu> > > Are there currently any elf loaders that boot under linuxbios which will > > let you change the default command line in kernel's made with mkelfImage > > from the serial console? > > no, but I can try to find my hack which lets you change it interactively > with the kernel before it is processed. > > It was a simple hack. > Even better. I'd love it. - Adam Agnew From ebiederman at lnxi.com Tue Sep 9 22:27:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 9 22:27:01 2003 Subject: more on the arima/hdama pci bus problem In-Reply-To: References: Message-ID: ron minnich writes: > On 9 Sep 2003, Eric W. Biederman wrote: > > > Hmm. I will have to sync up with you. Are you certain the pirq table > > refers to a device on bus 1? > > It does. The issue is that Linux does not enumerate any devices on Bus 1. > LinuxBIOS, however, does, and the 1022:746b device shows up on bus 1 in > linuxbios. > > The PIRQ table in the public tree is wrong, need to fix it. > > Linux itself enumerates bus 0, then jumps to bus 2. For that I cannot think of a reasonable explanation. I will have to look and verify this. I am pretty certain I booted a kernel after I made those changes.. > > > I have some serious broadcom NIC tracing to do and then I should be able > > to sync with the public tree again. > > we're working on the same thing then. I'm not going to worry about this > for present while I look at the tg3 problems. Ok. We might have to sync up then. Eric From ts1 at cma.co.jp Wed Sep 10 03:03:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 10 03:03:00 2003 Subject: overriding command line options in LinuxBIOS In-Reply-To: <20030909214046.T87001-100000@www.missl.cs.umd.edu> References: <20030909214046.T87001-100000@www.missl.cs.umd.edu> Message-ID: <20030910072216.GA6343@cma.co.jp> On Tue, Sep 09, 2003 at 09:56:16PM -0400, Adam Agnew wrote: > > Are there currently any elf loaders that boot under linuxbios which will > let you change the default command line in kernel's made with mkelfImage > from the serial console? > > If not, can someone point me to an example of anywhere this works, perhaps > outside of linuxbios? I'd like to add it. How about this: define a new ELF boot note which tells the image to ignore the embedded command line, and modify convert_params.c in mkelfImage to respect this note. The new command line can be passed using existing mechanism. -- Takeshi From stepan at suse.de Wed Sep 10 04:56:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 10 04:56:00 2003 Subject: more than a segment of code Message-ID: <20030910091857.GA10391@suse.de> Hi, I'm trying to adopt the AMD Quartet target to the new config scheme completely, but until now I failed when using the code I checked into CVS. The static tables and structures like the mem_controller cpu[] are twice as big as with the HDAMA most of the time, so the image does not fit in 64k anymore: /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .reset [00000000fffffff0 -> 00000000ffffffff] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca] /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps section .payload [00000000ffffb5b0 -> 00000001000008ca] When I set the image size to 128k (ROM_IMAGE_SIZE), I get /home/stepan/LinuxBIOS/freebios2/src/cpu/i386/reset16.inc:16:3: #error _ROMBASE is an unsupported value Is there any solution except stripping down? Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Wed Sep 10 08:11:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Sep 10 08:11:01 2003 Subject: more than a segment of code In-Reply-To: <20030910091857.GA10391@suse.de> References: <20030910091857.GA10391@suse.de> Message-ID: Stefan Reinauer writes: > Hi, > > I'm trying to adopt the AMD Quartet target to the new config scheme > completely, but until now I failed when using the code I checked into > CVS. The static tables and structures like the mem_controller cpu[] > are twice as big as with the HDAMA most of the time, so the image does > not fit in 64k anymore: Ouch. > /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: > section .reset [00000000fffffff0 -> 00000000ffffffff] overlaps section > .payload [00000000ffffb5b0 -> 00000001000008ca] > /usr/lib/gcc-lib/i486-suse-linux/3.3/../../../../i486-suse-linux/bin/ld: > section .id [00000000ffffffd8 -> 00000000ffffffef] overlaps section > .payload [00000000ffffb5b0 -> 00000001000008ca] > > When I set the image size to 128k (ROM_IMAGE_SIZE), I get > /home/stepan/LinuxBIOS/freebios2/src/cpu/i386/reset16.inc:16:3: #error > _ROMBASE is an unsupported value > > Is there any solution except stripping down? Fixing romcc so it does not inline everything. There are a lot of good reasons for keeping LinuxBIOS within 64K. The two top ones are to limit code bloat and because startup is very tricky if you don't fit into 64K. One thing you can look at is to strip down the debugging messages from the romcc code. That has at times made a large difference. Eric From ts1 at cma.co.jp Wed Sep 10 09:56:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 10 09:56:00 2003 Subject: Announcing FILO Message-ID: <20030910141538.GA21218@cma.co.jp> Hi, I wrote a bootloader, available here: http://te.to/~ts1/filo/ and here the README: This is FILO, a bootloader which loads boot images from local filesystem, without help from legacy BIOS services. Expected usage is to be burned into the BIOS ROM together with LinuxBIOS. FEATURES - Console on VGA + keyboard, serial port, or both - Line editing with ^H, ^W and ^U keys to type arbitrary filename to boot - Improved IDE driver derived from Etherboot 5.1 - Support for filesystems: ext2, fat, jfs, minix, reiserfs, and xfs - Full support for the ELF Boot Proposal (where is it btw, Eric?) - Auxiliary tool to compute checksum of ELF boot images - Full 32-bit code, no BIOS calls REQUIREMENT Only i386 PC architecture is currently supported. Recent version of GNU toolchain is required to build. I have tested with Debian/woody (gcc 2.95.4, binutils 2.12.90.0.1, make 3.79.1) and Debian/sid (gcc 3.3.2, binutils 2.14.90.0.5, make 3.80). INSTALL First invokation of make creates the default Config file. $ make Edit this file as you like. It's fairly straightforward (I hope). $ vi Config Then running make again will build filo.elf, the ELF boot image of FILO. $ make Use filo.elf as your payload of LinuxBIOS, or a boot image for Etherboot. USING At "boot:" prompt, type the name of your boot image in the form: devicename:filename (eg. hda1:/boot/kernel.elf). FILO supports only IDE hard disk (or compatible) for now. The devicename for IDE disk is same as in Linux (eg. hda1 means the first partition of master device on primary controller). FILO can boot any bootable ELF images, which include Linux converted by mkelfImage, Etherboot .elf and .zelf, Memtest86, FILO itself, etc. If AUTOBOOT_FILE is set in Config, FILO tries to boot this file first, and falls back to boot: prompt if it fails. If AUTOBOOT_DELAY is also set, FILO waits specified time in seconds for a key hit before booting AUTOBOOT_FILE. Otherwise it tries to boot AUTOBOOT_FILE immediately unless a key stroke is waiting. BUG REPORTING If you have trouble, set DEBUG_ALL in Config and send its console output to me at . ACKNOWLEDGEMENT I have taken pieces of code and learned concepts from various standalone programs including GNU GRUB, Etherboot, polled IDE patch by Adam Agnew, Memtest86, LinuxBIOS, and Linux. I must say thanks to all the developers of these wonderful software, especially to Eric Biederman for his great development work in this area. LICENSE Copyright (C) 2003 by SONE Takeshi and others. This program is licensed under the terms of GNU General Public License. See the COPYING file for details. -- Takeshi From stepan at suse.de Wed Sep 10 10:01:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 10 10:01:01 2003 Subject: more than a segment of code In-Reply-To: References: <20030910091857.GA10391@suse.de> Message-ID: <20030910142415.GB12916@suse.de> * Eric W. Biederman [030910 14:38]: > > Is there any solution except stripping down? > > Fixing romcc so it does not inline everything. This sounds like it's going to be pretty complex > There are a lot of good reasons for keeping LinuxBIOS within 64K. The > two top ones are to limit code bloat and because startup is very > tricky if you don't fit into 64K. ack > One thing you can look at is to strip down the debugging messages from > the romcc code. That has at times made a large difference. I got it compiling now with a log level of 7, but unfortunately it doesnt produce much output with that: LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting... LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting... Looks like it at least attempts to reset when doing ht init ... I'll switch as much debug on as possible again now.. Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Wed Sep 10 10:06:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 10 10:06:01 2003 Subject: more on the arima/hdama pci bus problem In-Reply-To: Message-ID: On 9 Sep 2003, Eric W. Biederman wrote: > For that I cannot think of a reasonable explanation. I will have to look > and verify this. I am pretty certain I booted a kernel after I made those > changes.. are you on 2.4.21? I'll get the serial output (node is not on ethernet yet) thanks ron From rminnich at lanl.gov Wed Sep 10 10:10:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 10 10:10:01 2003 Subject: more than a segment of code In-Reply-To: <20030910091857.GA10391@suse.de> Message-ID: On Wed, 10 Sep 2003, Stefan Reinauer wrote: > Is there any solution except stripping down? we need a way to set it up so the linuxbios compressed payload is BELOW linuxbios in memory. That would buy a lot of room. I have not looked at this yet. ron From rminnich at lanl.gov Wed Sep 10 10:12:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 10 10:12:01 2003 Subject: more than a segment of code In-Reply-To: Message-ID: On 10 Sep 2003, Eric W. Biederman wrote: > There are a lot of good reasons for keeping LinuxBIOS within 64K. The > two top ones are to limit code bloat and because startup is very > tricky if you don't fit into 64K. true, but ... :-) > One thing you can look at is to strip down the debugging messages from > the romcc code. That has at times made a large difference. see if your auto.c has a high debug message level ... yes, this has helped me a lot. ron From rminnich at lanl.gov Wed Sep 10 10:16:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 10 10:16:01 2003 Subject: more than a segment of code In-Reply-To: <20030910142415.GB12916@suse.de> Message-ID: On Wed, 10 Sep 2003, Stefan Reinauer wrote: > I got it compiling now with a log level of 7, but unfortunately it > doesnt produce much output with that: > LinuxBIOS-1.1.4.0Fallback Mit Sep 10 15:13:38 CEST 2003 starting... what are you trying to debug? What I've done is this: set MAXIMUM_CONSOLE_LOGLEVEL and DEFAULT_CONSOLE_LOGLEVEL in auto.c directly, if that is where your trouble is. So leave them low in Config.lb, and in auto.c, set them high. Then things fit. Mostly you need that high level in auto.c anyway, it's where all the problems will happen if you have any. ron From prl-linuxbios at sychron.com Wed Sep 10 10:49:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Wed Sep 10 10:49:00 2003 Subject: Heads up - /proc/kcore May Be Going Away Message-ID: Noticed this on kernel traffic shortly after noting that the description of extracting Video BIOS in the ADLO paper uses /dev/kcore. I take it that there'd be no problem in creating a more specialised architecture specific device for extracting things like parts of the BIOS. http://kt.zork.net/kernel-traffic/kt20030908_229.html#5 From steve at nexpath.com Wed Sep 10 11:02:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Sep 10 11:02:00 2003 Subject: more than a segment of code In-Reply-To: References: <20030910091857.GA10391@suse.de> Message-ID: <3F5F4393.3070801@nexpath.com> Eric W. Biederman wrote: > startup is very > tricky if you don't fit into 64K. > Maybe you can amplify on this. I can see it for older chipsets, but for modern ones, if we go into 32-bit mode immediately, why is this a problem? -Steve From steve at nexpath.com Wed Sep 10 11:05:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Sep 10 11:05:01 2003 Subject: Announcing FILO In-Reply-To: <20030910141538.GA21218@cma.co.jp> References: <20030910141538.GA21218@cma.co.jp> Message-ID: <3F5F444E.4080202@nexpath.com> SONE Takeshi wrote: > Hi, I wrote a bootloader, available here: > http://te.to/~ts1/filo/ > and here the README: > > This is FILO, a bootloader which loads boot images from local filesystem, > without help from legacy BIOS services. Great work SONE, this is definitely something I need. Maybe I can give it a try this weekend with the Epia800. -Steve From stepan at suse.de Wed Sep 10 12:09:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 10 12:09:00 2003 Subject: more than a segment of code In-Reply-To: References: Message-ID: <20030910163205.GA14265@suse.de> * ron minnich [030910 16:32]: > > One thing you can look at is to strip down the debugging messages from > > the romcc code. That has at times made a large difference. > > see if your auto.c has a high debug message level ... yes, this has > helped me a lot. right.. i was stupid. The results are rather less good though.. Something seems to be severely wrong with the ht setup on quartet. LinuxBIOS-1.1.4.0Fallback Mit Sep 10 17:08:05 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling SMP settings setup_remote_node setup_remote_done Renaming current temp node to 00000001 done. Enabling routing table for node 00000001 done. Renaming current temp node to 00000002 LinuxBIOS-1.1.4.0Fallback Mit Sep 10 17:08:05 CEST 2003 starting... setting up resource map.... done. Enabling routing table for node 00000000 done. Enabling SMP settings setup_remote_node Stefan -- Architecture Team SuSE Linux AG From YhLu at tyan.com Wed Sep 10 12:26:01 2003 From: YhLu at tyan.com (YhLu) Date: Wed Sep 10 12:26:01 2003 Subject: newer solo motherboards Message-ID: <3174569B9743D511922F00A0C943142303188F2A@TYANWEB> Stefan, If you set HAVE_HARD_RESET=0 in the Config.lb, does it work? YH. -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?8? 12:18 ???: YhLu ??: LinuxBIOS ??: Re: newer solo motherboards * YhLu [030908 18:55]: > HyperT reset needed > HyperT reset not needed > > In the scan_hypertranport_chain.c missed one "else" > > YH. ./src/devices/hypertransport.c:hypertransport_scan_chain() should do the right thing, i.e. trigger a reset. And it seems the reset should go to PCIDEV(1,4,0), as on all other hammer boards. But obviously the code does not do a reset, or does it continue at the same PC afterwards? > SMBus controller enabled > Ram1.00 > setting up CPU00 northbridge registers > done. > Ram2.00 How can i verify that the smbus channels LinuxBIOS uses are correct for my board? The old solos only found RAM in the first socket it seems. > Hyper transport scan link: 0 max: 1 > PCI: 01:01.0 [1022/7454] enabled next_unitid: 0004 > PCI: 01:04.0 [1022/7460] enabled next_unitid: 0008 > HyperT reset needed [ LinuxBIOS should restart HERE ] > HyperT reset not needed > PCI: pci_scan_bus for bus 1 > PCI: 01:01.0 [1022/7454] ops [..] Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From ts1 at tsn.or.jp Wed Sep 10 13:47:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Wed Sep 10 13:47:00 2003 Subject: Heads up - /proc/kcore May Be Going Away In-Reply-To: References: Message-ID: <20030910180651.GA17680@tsn.or.jp> On Wed, Sep 10, 2003 at 04:08:22PM +0100, prl-linuxbios at sychron.com wrote: > > Noticed this on kernel traffic shortly after noting that the description > of extracting Video BIOS in the ADLO paper uses /dev/kcore. I take it > that there'd be no problem in creating a more specialised architecture > specific device for extracting things like parts of the BIOS. No problem, we have /dev/mem. I use this command to extract video bios. $ sudo dd if=/dev/mem of=/tmp/vgabios bs=65536 skip=12 count=1 -- Takeshi From moedeker at hmk-gmbh.de Wed Sep 10 14:43:01 2003 From: moedeker at hmk-gmbh.de (=?iso-8859-1?Q?Bernd_M=F6deker?=) Date: Wed Sep 10 14:43:01 2003 Subject: National SC1200 with DP83815 Ethernetcontroller problem Message-ID: <003f01c377ce$57dd8710$0179a8c0@hmkhow2000> Hi list, all SC1200 internal devices were correctly detected by pci bus scan. But the only external device DP83815 count'nt be detected. Scanning PCI bus...PCI: pci_scan_bus for bus 0 POST: 0x24 PCI: 00:00.0 [1078/0001] PCI: 00:12.0 [100b/0500] PCI: 00:12.1 [100b/0501] PCI: 00:12.2 [100b/0502] PCI: 00:12.3 [100b/0503] PCI: 00:12.4 [100b/0504] PCI: 00:12.5 [100b/0505] PCI: 00:13.0 [0e11/a0f8] POST: 0x25 I am missing: PCI: 00:0E.0 [100b/0020] After some measurements I saw that there is a PCI frame generated during an access, but no ADxx signals are high during this frame. Normally AD24 which is connected to IDSEL of the Ethernetcontroller should be "high". So the DP83815 don't think that he is selected. My suggestion is that the external pci bus is not correct initialized. I attached some files of my configuration. Has anybody some advises to me? Thanks Benno Sorry for sending to admin -------------- next part -------------- A non-text attachment was scrubbed... Name: CSC1_SC1200.config Type: application/octet-stream Size: 651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scx200_setup.inc Type: application/octet-stream Size: 6643 bytes Desc: not available URL: From niki.waibel at newlogic.com Thu Sep 11 06:05:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Thu Sep 11 06:05:01 2003 Subject: flash_and_burn patch Message-ID: <200309111025.h8BAPOZS023596@enterprise2.newlogic.at> hello, i cleaned up the util/flash_and_burn dir of linuxbios cvs 20030910. everyting compiles without warnings now. i am about to add support for the msystems doc device chips. who actually maintains the util/flash_and_burn tree? i could not find any email address in the files. i am going to post a patch === $ ls -la flash_and_burn_20030910.patch.bz2 -rw-r----- 1 nwaibel staff 5539 2003-09-11 12:13 flash_and_burn_20030910.patch.bz2 === to this list if noone complains within the next 20 minutes. niki From niki.waibel at newlogic.com Thu Sep 11 06:35:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Thu Sep 11 06:35:00 2003 Subject: flash_and_burn patch In-Reply-To: <200309111025.h8BAPOZS023596@enterprise2.newlogic.at> Message-ID: <200309111054.h8BAsmZS026866@enterprise2.newlogic.at> okay -- here is the patch. > hello, > > i cleaned up the util/flash_and_burn dir of linuxbios cvs 20030910. > everyting compiles without warnings now. > > i am about to add support for the msystems doc device chips. > > who actually maintains the util/flash_and_burn tree? > i could not find any email address in the files. > > i am going to post a patch > === > $ ls -la flash_and_burn_20030910.patch.bz2 > -rw-r----- 1 nwaibel staff 5539 2003-09-11 12:13 flash_and_burn_20030910.patch.bz2 > === > to this list if noone complains within the next 20 minutes. -------------- next part -------------- A non-text attachment was scrubbed... Name: flash_and_burn_20030910.patch.bz2 Type: application/octet-stream Size: 5539 bytes Desc: flash_and_burn_20030910.patch.bz2 URL: From stepan at suse.de Thu Sep 11 07:38:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 11 07:38:01 2003 Subject: newer solo motherboards In-Reply-To: <3174569B9743D511922F00A0C943142303188F2A@TYANWEB> References: <3174569B9743D511922F00A0C943142303188F2A@TYANWEB> Message-ID: <20030911120056.GA19065@suse.de> * YhLu [030910 18:46]: > Stefan, > > If you set HAVE_HARD_RESET=0 in the Config.lb, does it work? Good hint. Now I get the system booted again. Is this a problem of the hard reset function itself or rather of the link speed changes getting activated by the hard reset? Stefan From stepan at suse.de Thu Sep 11 07:42:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 11 07:42:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: <20030908140450.GA8055@suse.de> Message-ID: <20030911120447.GB19065@suse.de> * ron minnich [030908 17:03]: > On Mon, 8 Sep 2003, Stefan Reinauer wrote: > > > Did you have a look at the implementation of hard_reset in reset.c? > > void hard_reset(void) > > { > > set_bios_reset(); > > pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); > > } > > the only reset.c I see is in the mainboard-specific code. Nevertheless > this code really should do the find_device thing. I don't think that the wrong device is used though: 01:04.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) PCI: 01:04.0 [1022/7460] enabled Stefan From stepan at suse.de Thu Sep 11 07:50:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 11 07:50:00 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: References: <20030904142833.GB22287@suse.de> <20030908132620.GA7054@suse.de> Message-ID: <20030911121244.GC19065@suse.de> * Eric W. Biederman [030908 22:04]: > Stefan Reinauer writes: > > > uses XIP_ROM_SIZE > > uses XIP_ROM_BASE > > [..] > > option CONFIG_CHIP_CONFIGURE=1 > > option CPU_FIXUP=1 > > option CONFIG_UDELAY_TSC=0 > > option i686=1 > > option i586=1 > > option INTEL_PPRO_MTRR=1 > > option k7=1 > > option k8=1 > > option _RAMBASE=0x00004000 > > > > These are currently found in the arima targets-Config.lb but they seem > > pretty much mainboard specific, not build specific. > > Correct. It is a little better on the HDAMA. But currently there are > some options that don't seem to work properly when I move them in closer. The above was taken from the hdama CVS. So is there a difference for the build process whether an option is placed into the build target specific config file or in the mainboard specific config file? > > I had trouble getting a build to work with a kernel (800k) in the normal > > image and etherboot (~20k) in the fallback image. Do the payload image sizes > > have to be the same for fallback and normal? > > No. Although there are some peculiarities in the new configuration tool. I now have a weird effect in the new DS1006 target I checked in. It uses an 872887 bytes elf image payload, and the whole rom is 1MB (SST 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table and failsafe booting is disabled in the Config files. Unfortunately this makes LinuxBIOS hang when setting up the default resource map: LinuxBIOS-1.1.4.0-dspace Don Sep 11 13:14:37 CEST 2003 starting... setting up resource map.... Running a Solo image on the same machine (Solo for testing purposes) works fine. Is there any magic in the failsafe bootcode that is missing before resources can be set up? At least amd8111_enable_rom() is only called in failover.c Stefan From rminnich at lanl.gov Thu Sep 11 09:28:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 11 09:28:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030911121244.GC19065@suse.de> Message-ID: On Thu, 11 Sep 2003, Stefan Reinauer wrote: > > Correct. It is a little better on the HDAMA. But currently there are > > some options that don't seem to work properly when I move them in closer. > > The above was taken from the hdama CVS. > So is there a difference for the build process whether an option is > placed into the build target specific config file or in the mainboard > specific config file? due to a bug, yes. > I now have a weird effect in the new DS1006 target I checked in. It uses > an 872887 bytes elf image payload, and the whole rom is 1MB (SST > 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table > and failsafe booting is disabled in the Config files. Unfortunately this > makes LinuxBIOS hang when setting up the default resource map: > if I am only loading one image, I always make it a failsafe image and it all works. ron From ebiederman at lnxi.com Thu Sep 11 09:43:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 11 09:43:01 2003 Subject: [COMMIT] Infrastructure Updates 4 In-Reply-To: <20030911121244.GC19065@suse.de> References: <20030904142833.GB22287@suse.de> <20030908132620.GA7054@suse.de> <20030911121244.GC19065@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030908 22:04]: > > Stefan Reinauer writes: > > > > > uses XIP_ROM_SIZE > > > uses XIP_ROM_BASE > > > [..] > > > option CONFIG_CHIP_CONFIGURE=1 > > > option CPU_FIXUP=1 > > > option CONFIG_UDELAY_TSC=0 > > > option i686=1 > > > option i586=1 > > > option INTEL_PPRO_MTRR=1 > > > option k7=1 > > > option k8=1 > > > option _RAMBASE=0x00004000 > > > > > > These are currently found in the arima targets-Config.lb but they seem > > > pretty much mainboard specific, not build specific. > > > > Correct. It is a little better on the HDAMA. But currently there are > > some options that don't seem to work properly when I move them in closer. > > The above was taken from the hdama CVS. Ouch I had not realized it was that bad. > So is there a difference for the build process whether an option is > placed into the build target specific config file or in the mainboard > specific config file? Yes. Some options don't work in the mainboard directory. At least they didn't when I tested them. > > > I had trouble getting a build to work with a kernel (800k) in the normal > > > image and etherboot (~20k) in the fallback image. Do the payload image sizes > > > > have to be the same for fallback and normal? > > > > No. Although there are some peculiarities in the new configuration tool. > > I now have a weird effect in the new DS1006 target I checked in. It uses > an 872887 bytes elf image payload, and the whole rom is 1MB (SST > 49LF080A). Since the machine it shall run on has no CMOS, the CMOS table > and failsafe booting is disabled in the Config files. Unfortunately this > makes LinuxBIOS hang when setting up the default resource map: The default failover.c depends on having a CMOS... This is something that definitely needs fixing. Although I have trouble imagining where to place BIOS options if you have an SST chip. Unless you have found the magic sequence that always works. > > Running a Solo image on the same machine (Solo for testing purposes) > works fine. Odd. > Is there any magic in the failsafe bootcode that is missing before > resources can be set up? At least amd8111_enable_rom() is only called > in failover.c I think amd8111_enable_rom is the only one. But I may be wrong. I know I enumerate the whole HT chain for the bus with the amd8111. There are a lot of pieces to work through. Eric From YhLu at tyan.com Thu Sep 11 12:33:00 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 11 12:33:00 2003 Subject: [COMMIT] Infrastructure Updates 4 Message-ID: <3174569B9743D511922F00A0C943142303466680@TYANWEB> It is AMD-8111 LPC, and 0x47 will trigger SWRST. I have checked the schematic that pin is routed to corresponding LDT_RESET. But it's no luck. PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled Bus 1, device 4, function 0: ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 5). -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?11? 5:05 ???: ron minnich ??: YhLu; ebiederman at lnxi.com; LinuxBIOS ??: Re: [COMMIT] Infrastructure Updates 4 * ron minnich [030908 17:03]: > On Mon, 8 Sep 2003, Stefan Reinauer wrote: > > > Did you have a look at the implementation of hard_reset in reset.c? > > void hard_reset(void) > > { > > set_bios_reset(); > > pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1); > > } > > the only reset.c I see is in the mainboard-specific code. Nevertheless > this code really should do the find_device thing. I don't think that the wrong device is used though: 01:04.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) PCI: 01:04.0 [1022/7460] enabled Stefan From stepan at suse.de Fri Sep 12 06:37:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Sep 12 06:37:00 2003 Subject: nested description of chains Message-ID: <20030912103028.GA14013@suse.de> Hi, looking at the big picture again and again, I don't think that nesting hypertransport devices when doing the chain description is a very good idea as it gives us some limitations. * CPUs (North bridges) don't fit in the scenario, since they might be arranged in a circular chain: CPU-3 --- CPU-2 | | | | CPU-0 --- CPU-1 If trying to pack this into the nested description manner as it is now, we can't describe the fact that it's a circular organization: northbridge amd/amdk8 "mc0" pci 0:18.0 [..] northbridge amd/amdk8 "mc1" pci 0:19.0 northbridge amd/amdk8 "mc2" pci 0:1a.0 northbridge amd/amdk8 "mc3" [..] (nesting ad nauseum) end end end northbridge amd/amdk8 "mc3" [..] (nesting ad nauseum) end end * Non-CPU components can be described as long as they are not ring organized, but for Hypertransport devices the description tries to hide the fact that the organization form is a chain. Adding a nested description for components like a superio chip makes perfect sense, since it's unlikely that superio chips are ever cascaded or put into a circular chain. Also, the connection between the I/O hub (southbridge) and the superio can be seen as a peer-to-peer connection rather than a bus that allows arbitrary links between all components. The reason why I am writing this is that currently we have a hardcoded assumption in in LinuxBIOS' coherent hypertransport setup that looks like this: | | [2] [2] CPU-3 [1] --- [1] CPU-2 [0] [0] | | [2] [2] CPU-0 [1] --- [1] CPU-1 [0] [0] | | [x] means that HT link no x is used for a certain link. But this is not the only available organization method for a hypertransport setup. Assumed a CPU HT device looks like this: | [LDT2] ___|__ | | | CPU0 |-- [LDT1] |______| | | [LDT0] A hypertransport setup like this is a little more complex, but still perfectly valid: _______________ | ______ | | | 8111 | | | |______| | | ___|__ | | | | | | | CPU0 |__| | |______| | ______| | | ________________ | | ___|__ ______ | | | | | | 8131 | | | | | CPU1 |--|______| | | | |______| | | |_____| | |_______ | ___|__ | | | | | CPU2 |--[term] | |______| | ________| | | | | [term] | | ___|__ | | | | | | | CPU3 |------------- | |______| |______| I'll look at getting this scenario supported in the coherent_ht setup. But it would be nice to see configurations like this happen without actually touching the code when working a new opteron based port somewhen in future. Comments? Flames? Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Fri Sep 12 08:46:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 12 08:46:00 2003 Subject: nested description of chains In-Reply-To: <20030912103028.GA14013@suse.de> Message-ID: On Fri, 12 Sep 2003, Stefan Reinauer wrote: > looking at the big picture again and again, I don't think that > nesting hypertransport devices when doing the chain description is a > very good idea as it gives us some limitations. you mean nesting them in the config file? I agree. It is not a good idea. The config language only supports a parent-child relationship, and HT has a much richer interconnection structure. Are you saying that we should reflect this richer topology that HT has in the config language? ron From stepan at suse.de Fri Sep 12 10:37:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Sep 12 10:37:00 2003 Subject: nested description of chains In-Reply-To: References: <20030912103028.GA14013@suse.de> Message-ID: <20030912145703.GB15882@suse.de> * ron minnich [030912 15:06]: > The config language only supports a parent-child relationship, and HT has > a much richer interconnection structure. Yes. Currently the config tool only allows an acyclic graph for describing hardware. this does not suit the machine description that would be needed for hypertransport. > Are you saying that we should reflect this richer topology that HT has in > the config language? Yes, and I think this does not need to be really complex. See the below example. Then the romimage class could be extended to write a new file htlinks.h in case it detects "htlink" keywords in any device. I'm currently fighting myself a bit through config.g to see how this can be done. I don't think this necessarily should go to the static device tree, since we would have to use the device tree in romcc code then, which is not yet possible iirc. (And might bloat romcc code up) typedef struct htlink { int direction; // 0,1,2 for LDT0,1,2 int speed; int width; int nodenum; // ht device number of remote component } htlink_t; enum { NORTHBRIDGE, SOUTHBRIDGE, PCIBRIDGE, } htdev_t; typedev struct htdev { htdev_t type; // type int num; // instance, i.e. the num'th device of type "type" htlink_t links[3]; } htdev_t; htdevs_t **get_htdevs() { htdevt_t htdevs[]={ { NORTHBRIDGE, 0, { { 0, 800, 16, 1 }, { 1, 800, 16, 3 }, { 2, 800, 16, 4 }, // range 0-3 used by cpus } }, { NORTHBRIDGE, 1, { { 0, 800, 16, 0 }, { 1, 800, 16, 5 }, { 2, 800, 16, 3 }, } }, [..] }; return htdevs; } generated from a config file like this: northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 htlink 0 "mc1" [ speed=default|200|400.. ] [ width=default|8|16 ] htlink 1 "mc3" speed=default width=16 htlink 2 "amd8111" speed=600 width=8 end northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 htlink 0 "mc0" htlink 1 "amd8131" htlink 2 "mc3" end northbridge amd/amdk8 "mc2" pci 0:1a.0 pci 0:1a.0 pci 0:1a.0 pci 0:1a.1 pci 0:1a.2 pci 0:1a.3 htlink 0 "mc3" htlink 2 "mc0" end northbridge amd/amdk8 "mc3" pci 0:1b.0 pci 0:1b.0 pci 0:1b.0 pci 0:1b.1 pci 0:1b.2 pci 0:1b.3 htlink 0 "mc2" htlink 1 "mc1" end southbridge amd/amd8131 "amd8131-1" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 htlink 0 "mc0" htlink 1 "amd8131-2" end southbridge amd/amd8131 "amd8131-2" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 htlink 0 "amd8131-1" end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 pci 0:1.1 pci 0:1.2 pci 0:1.3 pci 0:1.5 pci 0:1.6 superio NSC/pc87360 pnp 1:2e.0 pnp 1:2e.1 pnp 1:2e.2 pnp 1:2e.3 pnp 1:2e.4 pnp 1:2e.5 pnp 1:2e.6 pnp 1:2e.7 pnp 1:2e.8 pnp 1:2e.9 pnp 1:2e.a register "com1" = "{1, 0, 0x3f8, 4}" register "lpt" = "{1}" end htlink 0 "mc0" speed=200 width=8 end Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Fri Sep 12 12:45:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Sep 12 12:45:01 2003 Subject: extending "buildrom" Message-ID: <20030912170523.GB17491@suse.de> Hi, to get used to the config tool, I wrote the attached little patch to change the buildrom command to allow specifying a filename of a rom file that is produced when building LinuxBIOS i.e. buildrom ROM_SIZE "normal" "fallback" changed to: buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" creating a linuxbios.rom file in the build target directory that consists of the 2 concatenated romimages "normal" and "fallback" This way it's now possible to build several roms with "buildrom" that take the specified "romimage"s that were built. This could i.e. be used to build several roms at once i.e. with different payloads in them. Is this ok to check in? -- Architecture Team SuSE Linux AG -------------- next part -------------- Index: targets/amd/quartet/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/amd/quartet/Config.lb,v retrieving revision 1.1 diff -u -r1.1 Config.lb --- targets/amd/quartet/Config.lb 11 Sep 2003 11:55:18 -0000 1.1 +++ targets/amd/quartet/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -103,4 +103,4 @@ payload /suse/stepan/tg3--ide_disk.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: targets/amd/solo/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/amd/solo/Config.lb,v retrieving revision 1.2 diff -u -r1.2 Config.lb --- targets/amd/solo/Config.lb 11 Sep 2003 11:55:18 -0000 1.2 +++ targets/amd/solo/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -103,4 +103,4 @@ payload /suse/stepan/tg3--ide_disk.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: targets/arima/hdama/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/arima/hdama/Config.lb,v retrieving revision 1.17 diff -u -r1.17 Config.lb --- targets/arima/hdama/Config.lb 1 Sep 2003 23:17:57 -0000 1.17 +++ targets/arima/hdama/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -104,4 +104,4 @@ payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: targets/dspace/ds1006/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/dspace/ds1006/Config.lb,v retrieving revision 1.1 diff -u -r1.1 Config.lb --- targets/dspace/ds1006/Config.lb 11 Sep 2003 11:55:18 -0000 1.1 +++ targets/dspace/ds1006/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -91,4 +91,4 @@ payload /suse/stepan/LinuxBIOS/dspacepayload.elf end -buildrom ROM_SIZE "normal" +buildrom ./linuxbios.rom ROM_SIZE "normal" Index: targets/embeddedplanet/ep405pc/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/embeddedplanet/ep405pc/Config.lb,v retrieving revision 1.3 diff -u -r1.3 Config.lb --- targets/embeddedplanet/ep405pc/Config.lb 1 Sep 2003 23:17:57 -0000 1.3 +++ targets/embeddedplanet/ep405pc/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -94,4 +94,4 @@ mainboard embeddedplanet/ep405pc end -buildrom ROM_SIZE "normal" +buildrom ./linuxbios.rom ROM_SIZE "normal" Index: targets/motorola/sandpoint/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/motorola/sandpoint/Config.lb,v retrieving revision 1.7 diff -u -r1.7 Config.lb --- targets/motorola/sandpoint/Config.lb 1 Sep 2003 23:17:57 -0000 1.7 +++ targets/motorola/sandpoint/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -95,4 +95,4 @@ mainboard motorola/sandpoint end -buildrom ROM_SIZE "normal" +buildrom ./linuxbios.rom ROM_SIZE "normal" Index: targets/tyan/s2880/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/tyan/s2880/Config.lb,v retrieving revision 1.3 diff -u -r1.3 Config.lb --- targets/tyan/s2880/Config.lb 1 Sep 2003 23:17:57 -0000 1.3 +++ targets/tyan/s2880/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -231,4 +231,4 @@ payload ../../tg3.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: targets/tyan/s2882/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/tyan/s2882/Config.lb,v retrieving revision 1.2 diff -u -r1.2 Config.lb --- targets/tyan/s2882/Config.lb 1 Sep 2003 23:17:57 -0000 1.2 +++ targets/tyan/s2882/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -230,4 +230,4 @@ payload ../../tg3.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: targets/tyan/s2885/Config.lb =================================================================== RCS file: /cvsroot/freebios/freebios2/targets/tyan/s2885/Config.lb,v retrieving revision 1.2 diff -u -r1.2 Config.lb --- targets/tyan/s2885/Config.lb 1 Sep 2003 23:17:58 -0000 1.2 +++ targets/tyan/s2885/Config.lb 12 Sep 2003 16:56:22 -0000 @@ -230,4 +230,4 @@ payload ../../tg3.zelf end -buildrom ROM_SIZE "normal" "fallback" +buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" Index: util/newconfig/config.g =================================================================== RCS file: /cvsroot/freebios/freebios2/util/newconfig/config.g,v retrieving revision 1.44 diff -u -r1.44 config.g --- util/newconfig/config.g 1 Sep 2003 23:17:58 -0000 1.44 +++ util/newconfig/config.g 12 Sep 2003 16:56:23 -0000 @@ -428,9 +428,16 @@ class buildrom: """A buildrom statement""" - def __init__ (self, size, roms): + def __init__ (self, filename, size, roms): + self.name = filename self.size = size self.roms = roms + + def __len__ (self): + return len(self.roms) + + def __getitem__(self,i): + return self.roms[i] class initinclude: """include file for initialization code""" @@ -1073,10 +1080,10 @@ curimage.setroot(partstack.tos()) partpop() -def addbuildrom(size, roms): +def addbuildrom(filename, size, roms): global buildroms print "Build ROM size %d" % size - b = buildrom(size, roms) + b = buildrom(filename, size, roms) buildroms.append(b) def addinitobject(object_name): @@ -1518,7 +1525,7 @@ ( STR {{ s = s + "," + STR }} )* {{ return eval(s + ')') }} - rule buildrom: BUILDROM expr roms {{ addbuildrom(expr, roms) }} + rule buildrom: BUILDROM DIRPATH expr roms {{ addbuildrom(DIRPATH, expr, roms) }} rule romstmts: romimage | buildrom @@ -1781,7 +1788,7 @@ file.write("all: ") for i in romimages.keys(): file.write("%s-rom " % i) - file.write("\n\n") + file.write("buildroms\n\n") for i, o in romimages.items(): file.write("%s-rom:\n" % o.getname()) file.write("\tif (cd %s; \\\n" % o.getname()) @@ -1794,6 +1801,15 @@ for i, o in romimages.items(): file.write("%s-clean:\n" % o.getname()) file.write("\t(cd %s; make clean)\n" % o.getname()) + + file.write("\nbuildroms:\n") + for i in range(len(buildroms)): + file.write("\tcat "); + for j in range(len(buildroms[i])): + file.write("%s/linuxbios.rom " % buildroms[i][j] ) + file.write("> %s\n" % buildroms[i].name); + file.write("\n\n") + file.close() def writeinitincludes(image): From YhLu at tyan.com Fri Sep 12 12:59:00 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 12 12:59:00 2003 Subject: extending "buildrom" Message-ID: <3174569B9743D511922F00A0C94314230346676A@TYANWEB> For s2880 that with LSI scsi FW and some other ATI onboad Server Mainboard may need us to put the FW or VGA ROM in the linuxbios.rom too. For s2880 I cat lsiscsifw, normal, and fallback together. -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?12? 10:05 ???: LinuxBIOS ??: extending "buildrom" Hi, to get used to the config tool, I wrote the attached little patch to change the buildrom command to allow specifying a filename of a rom file that is produced when building LinuxBIOS i.e. buildrom ROM_SIZE "normal" "fallback" changed to: buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" creating a linuxbios.rom file in the build target directory that consists of the 2 concatenated romimages "normal" and "fallback" This way it's now possible to build several roms with "buildrom" that take the specified "romimage"s that were built. This could i.e. be used to build several roms at once i.e. with different payloads in them. Is this ok to check in? -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Fri Sep 12 13:24:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 12 13:24:01 2003 Subject: extending "buildrom" In-Reply-To: <20030912170523.GB17491@suse.de> Message-ID: On Fri, 12 Sep 2003, Stefan Reinauer wrote: > creating a linuxbios.rom file in the build target directory that > consists of the 2 concatenated romimages "normal" and "fallback" > This way it's now possible to build several roms with "buildrom" > that take the specified "romimage"s that were built. This could > i.e. be used to build several roms at once i.e. with different > payloads in them. neat. It's fine by me. ron From gwatson at lanl.gov Fri Sep 12 13:31:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Fri Sep 12 13:31:01 2003 Subject: nested description of chains In-Reply-To: <20030912145703.GB15882@suse.de> References: <20030912103028.GA14013@suse.de> <20030912145703.GB15882@suse.de> Message-ID: Stefan, This should be a relatively straight forward change to config.g. I would prefer to see the config format maintained, so I would suggest using: htlink 0 "mc1" speed = 200 width = 8 end htlink 0 "amd8131-1" end rather than htlink 0 "mc1" speed=200 width=8 htlink 0 "amd8131-1" Let me know if you need any help in implementing it. Regards, Greg At 4:57 PM +0200 12/9/03, Stefan Reinauer wrote: >* ron minnich [030912 15:06]: > >> The config language only supports a parent-child relationship, and HT has >> a much richer interconnection structure. > >Yes. Currently the config tool only allows an acyclic graph for >describing hardware. this does not suit the machine description that >would be needed for hypertransport. > >> Are you saying that we should reflect this richer topology that HT has in >> the config language? > >Yes, and I think this does not need to be really complex. See the below >example. Then the romimage class could be extended to write a new file >htlinks.h in case it detects "htlink" keywords in any device. I'm >currently fighting myself a bit through config.g to see how this can be >done. > >I don't think this necessarily should go to the static device tree, >since we would have to use the device tree in romcc code then, which >is not yet possible iirc. (And might bloat romcc code up) > >typedef struct htlink >{ > int direction; // 0,1,2 for LDT0,1,2 > int speed; > int width; > int nodenum; // ht device number of remote component >} htlink_t; > >enum { >NORTHBRIDGE, >SOUTHBRIDGE, >PCIBRIDGE, >} htdev_t; > >typedev struct htdev >{ > htdev_t type; // type > int num; // instance, i.e. the num'th device of type "type" > htlink_t links[3]; >} htdev_t; > >htdevs_t **get_htdevs() >{ > htdevt_t htdevs[]={ > { NORTHBRIDGE, 0, { > { 0, 800, 16, 1 }, > { 1, 800, 16, 3 }, > { 2, 800, 16, 4 }, // range 0-3 used by cpus > } > }, > { NORTHBRIDGE, 1, { > { 0, 800, 16, 0 }, > { 1, 800, 16, 5 }, > { 2, 800, 16, 3 }, > } > }, > [..] > }; > > return htdevs; >} > >generated from a config file like this: > >northbridge amd/amdk8 "mc0" > pci 0:18.0 > pci 0:18.0 > pci 0:18.0 > pci 0:18.1 > pci 0:18.2 > pci 0:18.3 > htlink 0 "mc1" [ speed=default|200|400.. ] [ width=default|8|16 ] > htlink 1 "mc3" speed=default width=16 > htlink 2 "amd8111" speed=600 width=8 >end > >northbridge amd/amdk8 "mc1" > pci 0:19.0 > pci 0:19.0 > pci 0:19.0 > pci 0:19.1 > pci 0:19.2 > pci 0:19.3 > htlink 0 "mc0" > htlink 1 "amd8131" > htlink 2 "mc3" >end > >northbridge amd/amdk8 "mc2" > pci 0:1a.0 > pci 0:1a.0 > pci 0:1a.0 > pci 0:1a.1 > pci 0:1a.2 > pci 0:1a.3 > htlink 0 "mc3" > htlink 2 "mc0" >end > >northbridge amd/amdk8 "mc3" > pci 0:1b.0 > pci 0:1b.0 > pci 0:1b.0 > pci 0:1b.1 > pci 0:1b.2 > pci 0:1b.3 > htlink 0 "mc2" > htlink 1 "mc1" >end > >southbridge amd/amd8131 "amd8131-1" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > htlink 0 "mc0" > htlink 1 "amd8131-2" >end > >southbridge amd/amd8131 "amd8131-2" > pci 0:0.0 > pci 0:0.1 > pci 0:1.0 > pci 0:1.1 > htlink 0 "amd8131-1" >end > >southbridge amd/amd8111 "amd8111" > pci 0:0.0 > pci 0:1.0 > pci 0:1.1 > pci 0:1.2 > pci 0:1.3 > pci 0:1.5 > pci 0:1.6 > superio NSC/pc87360 > pnp 1:2e.0 > pnp 1:2e.1 > pnp 1:2e.2 > pnp 1:2e.3 > pnp 1:2e.4 > pnp 1:2e.5 > pnp 1:2e.6 > pnp 1:2e.7 > pnp 1:2e.8 > pnp 1:2e.9 > pnp 1:2e.a > register "com1" = "{1, 0, 0x3f8, 4}" > register "lpt" = "{1}" > end > htlink 0 "mc0" speed=200 width=8 >end > > >Stefan > >-- >Architecture Team > SuSE Linux AG >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From dhroepaem at freechal.com Fri Sep 12 22:30:01 2003 From: dhroepaem at freechal.com (dhroepaem at freechal.com) Date: Fri Sep 12 22:30:01 2003 Subject: EPIA-M 10000 etherboot Message-ID: <18770.1063421383746.JavaMail.Administrator@smtp3> thanks, ron now i have four questions. first, i modified the config file. now linuxbios does not run correctly, but it shows more messages. when load the linuxbios directly, the message is ? xxxxxxxfx~ffxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxffxf when load the linuxbios after doing original bios, the message is linuxbios-1.0.0 2003. 09. 09. (ȭ) 16:04:55 kst starting... dump device: 00000000 00: 06 11 23 31 06 00 30 02 00 00 00 06 00 00 00 00 10: 08 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 a0 00 00 00 00 00 00 00 00 00 40: 00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50: e0 00 00 02 c0 04 00 00 22 00 01 01 01 01 00 00 60: 00 00 00 00 e4 00 00 2a 00 00 00 00 00 00 00 00 70: 00 48 00 00 01 00 00 00 01 00 00 00 00 00 02 00 80: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 01 02 00 1f 00 00 00 00 00 02 00 00 b0: 00 00 00 00 c0 00 00 00 aa 00 00 00 00 00 00 00 c0: 01 00 02 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 e0: 00 00 00 00 00 00 01 00 40 00 00 00 00 00 00 00.............................= 11 f0: 00 00 00 00 00 00 03 13 00 00 00 00 00 00 00 00 .................................... done...... dump device: 00008800...........0001c60 - 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00............................ef] ioup) new segment a 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 .......................................... 40: 00 80 00 00 00 00 00 00 0c 20 00 00 04 00 00 00000 - 0x000010ff] io 50: 09 1d 00 00 00 00 00 00 20 00 00 01 00 00 00 00 ................... 60: 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00.........cmd ................................................. 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-07- 00000674 ch c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00ader class! pci devices i d0: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 data=0009884e firmware t e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00m linux version 2.4.18 (root at epiam) ( f0: 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 done. dump device: 00008900cache... 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffios-e820: 00000000000006d4 - 00000000000a0000 (us 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffnuxbios_c.o(.te inode-cache hash 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff un mount-cache hash table entries: 2048 (or 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff < re 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffr-cache hash table entries: 4096 (order: 2, 16384 b 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff checking 'hlt' instruction... ok.:11 done. dump device: 00000000 check 00: 06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 apnp enabled cmd <- 07 tty 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00k or from (l)ocal? cl 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00: 128 slots per queue, batch=320:01.0 1c <- [ 80: 00 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00rt> boot fr vp_ide: not 100% native m 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 probing...[via 86c100]fou a0: 02 c0 20 00 01 02 00 1f 00 00 00 00 00 02 00 00bm-dma at 0x18e0-0x18e7, bios settings: hda:pio, hd b0: 00 00 00 00 c0 00 00 00 aa 00 00 00 00 00 00 00 io address 1400 ethernet addres c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 analyzing media type,this 40: 45 7f f0 00 00 00 00 00 0c 20 00 00 44 00 0b 08 you might want to try agp_tr 50: 81 1d 09 00 00 b0 ac 50 23 00 00 00 00 00 00 00 linespeed=100mbs fullduplex usb.c: new usb bus registered, assign 90: 00 f1 60 88 a0 c0 00 00 00 20 00 00 00 00 00 00 pci: 00:01.0 [1106/b a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0009. (ȭ) 16:04:55 kst starting... b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.0 [1106/3038] dump device: c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 23 31 06 00 30 02 00 00 00 06 00 00 00 00 d0: 01 05 01 00 00 00 00 00 00 00 00 00 00 00 00 000.3 [1106/3104] 10: 08 00 0 e0: 00 00 00 00 14 08 00 00 00 00 00 00 00 00 00 00 pci: 00:11. f0: 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 0 00 00 00 00 00 40: 0b f2 00 05 18 1c c0 00 a8 a8 a8 20 ff 00 b6 b600 00 00 eaffff 50: 07 07 07 07 0c 03 00 00 a8 a8 a8 a8 00 00 00 00 00: 06 11 77 31 87 00 10 0 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00io 70: 02 01 00 00 00 00 00 00 82 01 00 00 00 00 00 000 00 00 00 00 00 00 00 00 00 0018c0 - 0x000018df] i 80: 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 0 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00: 00:01.0 cmd <- 07 p 80: 00 d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00d <- 01 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000: 00 f1 60 00 b0 c0 00 00 10 20 00 00 00 00 00 001 f0: 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 pci: 00:10.3 cmd <- 02 a0: 0 done.0 00 copying linuxbios to ram. 00 00 00 jumping to linuxbios. pci: 00 linuxbios-1.0.0 2003. 09. 09. (ȭ) 16:04:55 kst booting... 00 00 00 00 00 00 00 00 00 00i: 00:12.0 cmd <- 83 finding pci configuration type. pci: 00:0d.0 [1106/3044] e0: 00 00 00 0 pci: 00:10.0 [1106/3038] 00 00 00 00 pci: 00:10.1 [1106/3038] setting f pci: 00:10.2 [1106/3038] pci: 00:10.3 [1106/3104]0 05 00 00 00 00 00 00 0 pci: 00:11.0 [1106/3177] pci: 00:11.1 [1106/0571] ff ff ff ff ff ff ff ff pci: 00:11.5 [1106/3059] pci: 00:12.0 [1106/3065]or type : 0x00 pci: pci_scan_bus for bus 1f ff ff ff ff ff ff ff ff f pci: pci_scan_bus returning with max=01 initia pci: pci_scan_bus returning with max=01 b0: donef ff allocating pci resources...ff ff ff ff fix d pci: 00:00.0 register 10(00000008), read-only ignoring itenabled pci: 00:00.0 register 10(00000008), read-only ignoring it ff ff ff ff ff ff ff ff ff ff ff ff ff initialized assign resources, bus 0 pci: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff f pci: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmemthbridge fixup cpu #0 in setting pci: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem0 to 0:d.0 112mb, ra pci: 00:0d.0 10 <- [0xfeb00000 - 0xfeb007ff] mem00 00 00 00ng usb pci: 00:0d.0 14 <- [0x00001800 - 0x0000187f] irq 11 to 0:10.0 rom s pci: 00:12.0 10 <- [0x00001400 - 0x000014ff] io 00 pci: 00:12.0 14 <- [0xfeb02000 - 0xfeb020ff] mem 80: 20 84 59 00 f2 70 00 00 01 04 00 00 00 assigned resources, bus 0 done. et enabling pci resourcess...pci: 00:00.0 cmd <- 06 from (n)etwork o 90: 00 f1 pci: 00:01.0 cmd <- 070 00 00 00 00 00 00 pci: 00:0d.0 cmd <- 07 pci: 00:12.0 cmd <- 07 00 00 00 00 00ec done. initializing pci devices... io address 1400 e pci devices initialized3 totalram: 127m c0: 01 0 initializing cpu #000 00 00 00 00 00 0 enabling cache... setting fixed mtrrs(0-88) type: uca type,this will take severa setting fixed mtrrs(0-16) type: wb d0: 01 05 01 00 00 00 00 00 00 0 done fixed mtrrs0090 via lane3): setting variable mtrr 0, base: 0mb, range: 64mb, type wb linespeed=100mbs fulld setting variable mtrr 1, base: 64mb, range: 32mb, type wb00 not enabled thisrtc i setting variable mtrr 5, base: 124mb, range: 2mb, type wb c0: 01 00 02 done variable mtrrs 00 00 00 00 00 00 clear out the extra mtrr's ju call intel_enable_fixed_mtrr() unknown d0: 06 call intel_enable_var_mtrr()0 00 00 00 00 000000us 00 pc leave setup_mtrrs done. max cpuid index : 1 data=0009884ences vendor id : centaurhauls firmwa e0: 00 00 00 00 00 processor type : 0x00 00 00sion 2.4.18 (root at e processor family : 0x06 processor model : 0x08 fixed mtrrs : enabled variable mtrrs: enabled-provided physical r disabling local apic...done. linuxbios-1.0.0 20 cpu #0 initialized:04:55 kst mainboard fixup final mainboard fixup_bus southbridge fixup6/3044]0 setting firewirehm, page 0000000 assigning irq 12 to 0:d.0 pci: 00:10.0 [1106/303 readback = 12 sear setting usb assigning irq 11 to 0:10.0/3038]urning with max=01oc readback = 11 assigning irq 12 to 0:10.100:10.2 [1106/3038] readback = 12 zone(1 assigning irq 10 to 0:10.2 readback = 10 pci: assigning irq 5 to 0:10.3ommand line: conso readback = 5 setting ethernet 00:11.1 [1106/0 assigning irq 11 t calibrating pci: pci_scan_bus returning with max=0 able() - irq_routing_table located at: 0x000090000.2 cmd <- 0107. memor done.i: pc copying irq routing tables to 0xf0000...done. reserved,0:10.3 cmd <- 0 verifing priq routing tables copy at 0xf0000...failed done00:0 allocating pci resourc wrote linuxbios table at: 00000500 - 00000664 checksum 4050 [0xfeb01000 - 0xfeb010ff] mempci: probing pci hardware welcome to elfboot, the open sourced starter. pci: 00:11.1 20 <- [0x0 january 2002, eric biederman.ci: 00:01.0 24 <- [0xfeb00000 version 1.2 ven linux n done.for l enabling pci resource 000000000037e0.0 cmd <- 06ns clearing segment: addr: 0x00000000000977e0 memsz: 0x0000000000003b48 pci: 00: jumping to boot code at 0x9400001 rom segment 0x0000 length 0x0000 reloc 0x9400 pci_scan_ etherboot 5.0.8 (gpl) tagged analyzing media type,this will take several seconds........okbus sp initializing cpu #0verride linespeed=100mbs fullduplex enab searching for server (dhcp)...setting fixed mtrrs(0-88) type ..me: 192.168.1.102, server: 203.252.137.169 vp_ide: ide controller on loading 203.252.137.169:/vmlinuz.epiam ...(elf)... ............................. i think that the 2th message and the 1th message are same but output type(?) is different. (correct? ?.,?;) i will be waitting for your advices :) second, after loading the linux kernel, the booting stops with a following message. ... linux kernel card services 3.1.22 options: [pci] [cardbus] [pm] usb.c: registered new driver hub uhci.c: usb universal host controller interface driver v1.1 uhci.c: usb uhci at i/o 0x1880, irq 11 usb.c: new usb bus registered, assigned bus number 1 i don't know why the booting stops here. third, what is the post card? post = power on self test? if it does, how can i check the post card? fourth, what does [pmx:##] mean? :) have a nice day~ DDR?? ???! ????? ??? 3D??? ?? ?? http://showtime2.freechal.com/index.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: From aip at cwlinux.com Fri Sep 12 23:00:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri Sep 12 23:00:01 2003 Subject: EPIA-M 10000 etherboot In-Reply-To: <10670.1062953503528.JavaMail.Administrator@smtp3>; from dhroepaem@freechal.com on Mon, Sep 08, 2003 at 01:51:43AM +0900 References: <10670.1062953503528.JavaMail.Administrator@smtp3> Message-ID: <20030913112041.A404@mail.cwlinux.com> > i have been testing linuxbios with epia-m10000 and rom emulator. > i made the romimage from /freebios/src/mainboard/via/epia-m/example.config. > when loaded it to rom emulator and reset, hyperterminal said "x-x-f" > but when loaded it and reset after loading original epia-m 10000 bios and reset, etherboot worked successfully. You may want to use 57600 instead. It is a magic from Award which I haven't figured out yet. -Andrew > following is the config file > # > # linuxbios config file for: via epia-m mini-itx > # > target /opt/cwlinux/buildrom/epia-m > # via epia > mainboard via/epia-m > # enable serial console for debugging > option serial_console=1 > # option serial_post=1 > option ttys0_baud=115200 > # option ttys0_baud=57600 > 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 /opt/cwlinux/etherboot/src/bin32/via-rhine.ebi > # payload /opt/cwlinux/memtest86/memtest > > plz, give me some hints~ :-) > > > DDR???? ??????! ?????????? ?????? 3D?????? ???? ???? > http://showtime2.freechal.com/index.asp -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From Michael at Fenner.org Sat Sep 13 08:57:01 2003 From: Michael at Fenner.org (Michael Fenner) Date: Sat Sep 13 08:57:01 2003 Subject: support for Epia or other Mini-ITX boards Message-ID: Hallo, want to set up a machine with LinuxBios - do not know which board to choose - I want to buy a new one and it has to be small. At the moment I have a FV24 with a VIA 1GHz processor. I'm looking into buying an Eipa, Epia-M or Epia-V board. The status page says that only the Eipa is fully supported - but I would prefer an Eipa-M or Eipa-V. Which one would you recommend if I want to install LinuxBios? Or do you have any other sugestions for a Mini-ITX board? Do you have something like a documentation for installing LinuxBios? Thanks for your help, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Sat Sep 13 11:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 13 11:07:00 2003 Subject: support for Epia or other Mini-ITX boards In-Reply-To: Message-ID: you could just buy one of these boards direct from cwlinux.com, as they come with linuxbios pre-loaded. Saved work. ron From cforney at opus.com Sat Sep 13 13:46:00 2003 From: cforney at opus.com (Craig C. Forney) Date: Sat Sep 13 13:46:00 2003 Subject: Getting started Message-ID: <000001c37a21$d7cb9a20$6701a8c0@CCFLAPTOP> Hi! I'm a newbie with linuxbios (and linux for that matter). We are in the process of creating a stripped-down (but extremely dense) dual Opteron server. It is basically a pair of Opterons and an 8111 that has a 10/100 NIC, a pair of USB ports, and an IDE interface, along with 4GB of RAM. We'd like to run linuxbios on it. I have an Arima Hdma dual Opteron system I am using for development. I'd like to start by building a linuxbios for the Arima system. I have been able to build and run a 64-bit kernel from the Suse _64 distribution on the Arima system successfully. I have downloaded the latest (as of yesterday) freebios2 tree from sourceforge.net. I went to targets and ran: # buildtarget arima/hdama Then I did the following: # cd arima/hdma/hdma # make It successfully made romcc, but when it tried to run it to make either the failover or normal rom, it gets the following error: reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad type passed to copy I'm probably missing some steps, or starting in the wrong place. I'd appreciate some advice. I spent some time looking through the archives, but did not find any definitive tutorial for the latest linuxbios creation (although the March 2003 linux-magazine article was useful to gain a perspective). Any help appreciated. I've been reading the mailing list for about a month, and I'm impressed with the progress this group has made. Thanks, Craig ========================================================== Craig C. Forney cforney at opus.com Opus Innovations LLC http://www.opus.com ========================================================== From rminnich at lanl.gov Sat Sep 13 14:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 13 14:39:00 2003 Subject: Getting started In-Reply-To: <000001c37a21$d7cb9a20$6701a8c0@CCFLAPTOP> Message-ID: On Sat, 13 Sep 2003, Craig C. Forney wrote: > It successfully made romcc, but when it tried to run it to make either > the failover or normal rom, it gets the following error: > reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad > type passed to copy romcc is sensitive to the version of linux you are running at present. You have done everything right, or it seems you have. What distro and version of distro are you running? ron From justin at street-vision.com Sun Sep 14 18:36:01 2003 From: justin at street-vision.com (Justin Cormack) Date: Sun Sep 14 18:36:01 2003 Subject: [Fwd: Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)] Message-ID: <1063580172.1350.106.camel@lotte.street-vision.com> This is from lkml. Can someone reply (and persuade Dell how broken their thought process is). Actually the whole thread about boot disk is odd. My usual problem with lilo and grub was trying to persuade them to install on something that wasnt the boot disk but was going to be. -----Forwarded Message----- From: Matt Domsch To: Jeff Garzik Cc: linux-kernel at vger.kernel.org Subject: Re: 2.7 block ramblings (was Re: DMA for ide-scsi?) Date: 13 Sep 2003 16:11:17 +1400 > Further, some sites may prefer block-level GUIDs to fs-level ones. > Sites using raw partitions instead of filesystems, for one. The EFI GUID Partition scheme (aka GPT aka CONFIG_EFI_PARTITION) stores a GUID in the disk label to define the whole disk, plus another per-partition GUID and per-partition label. So even if the file system doesn't have one, if you're using GPT, one *could* use those. I haven't hacked up mount to search for those though. If there's enough interest, I'll do so. Recall GPT is currently only used on ia64, though the code works fine on other arches including x86, and it's been decided (on l-k at least) that GPT will be the default disk label format for systems running 2.6.x kernels with disks >2TB, as the msdos label can't hold it. > The boot disk, OTOH, is tough. Right now, we just assume the > sysadmin knows what's he's doing, when he installs lilo or grub on a > disk. You care about the boot disk when installing lilo... maybe > there are similar situations too which I do not recall. As Alan > said, besides EDD (only on newer boxes) there's really nothing. EDD BIOSs are coming, slowly... 2 work today correctly, several more are "close but no cigar", it's all the rest that worry me. There's one more trick that's being used successfully, which I would like to add to the EDD code. That's "let BIOS help you out before installing". i.e. you boot into a FreeDOS environment, write a system-unique disk signature to the boot disk (int13 device 80h) "BOOT" or something - we've got 4 bytes available in the msdos label for it, then reboot and let Linux go grab the signature, store it, and like edd.o does, export it to userspace. Now from userspace one can see what Linux-named-disk has the signature you're looking for, and voila, you now solved it w/o needing EDD BIOSs. But it requires a non-Linux boot step somewhere in the install process. Thanks, Matt -- Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From ebiederman at lnxi.com Mon Sep 15 06:37:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 06:37:00 2003 Subject: Getting started In-Reply-To: <000001c37a21$d7cb9a20$6701a8c0@CCFLAPTOP> References: <000001c37a21$d7cb9a20$6701a8c0@CCFLAPTOP> Message-ID: "Craig C. Forney" writes: > Hi! I'm a newbie with linuxbios (and linux for that matter). > > We are in the process of creating a stripped-down (but extremely dense) > dual Opteron server. It is basically a pair of Opterons and an 8111 > that has a 10/100 NIC, a pair of USB ports, and an IDE interface, along > with 4GB of RAM. We'd like to run linuxbios on it. Sounds reasonable. > I have an Arima Hdma dual Opteron system I am using for development. I'd > like to start by building a linuxbios for the Arima system. I have been > able to build and run a 64-bit kernel from the Suse _64 distribution on > the Arima system successfully. > > I have downloaded the latest (as of yesterday) freebios2 tree from > sourceforge.net. I went to targets and ran: > # buildtarget arima/hdama > > Then I did the following: > # cd arima/hdma/hdma > # make > > It successfully made romcc, but when it tried to run it to make either > the failover or normal rom, it gets the following error: > reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad > type passed to copy > > I'm probably missing some steps, or starting in the wrong place. I'd > appreciate some advice. I spent some time looking through the archives, > but did not find any definitive tutorial for the latest linuxbios > creation (although the March 2003 linux-magazine article was useful to > gain a perspective). > > Any help appreciated. I've been reading the mailing list for about a > month, and I'm impressed with the progress this group has made. Something very strange is going on. If you get an error like that it should be: > reset_test.c:13.111: 0x1e43570 copy Internal compiler error: bad type passed to copy The comma instead of the period is worrisome. So far everything has been done with a 32bit toolchain. So that may account for some of the differences. If romcc has problems as Ron suggests when it is a compiled with different compilers that is something needs to get fixed, as that is a very bad bug and not the kind I would expect to still remain in the code. Eric From stepan at suse.de Mon Sep 15 06:41:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 15 06:41:00 2003 Subject: extending "buildrom" In-Reply-To: <3174569B9743D511922F00A0C94314230346676A@TYANWEB> References: <3174569B9743D511922F00A0C94314230346676A@TYANWEB> Message-ID: <20030915110132.GA27240@suse.de> * YhLu [030912 19:20]: > For s2880 that with LSI scsi FW and some other ATI onboad Server Mainboard > may need us to put the FW or VGA ROM in the linuxbios.rom too. > > For s2880 I cat lsiscsifw, normal, and fallback together. then we should maybe change this to fit the other linuxbios config commands, maybe like this: buildrom size ROM_SIZE data ./lsiscsifw 65536 image normal NORMAL_SIZE image fallback FALLBACK_SIZE end Or maybe it makes sense to move the payloads into the buildrom section as well and keep the romimage tag for building the LinuxBIOS code only while the buildrom tag describes the composition of the final rom image to flash? Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Mon Sep 15 06:41:29 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 06:41:29 2003 Subject: Getting started In-Reply-To: References: Message-ID: ron minnich writes: > On Sat, 13 Sep 2003, Craig C. Forney wrote: > > > It successfully made romcc, but when it tried to run it to make either > > the failover or normal rom, it gets the following error: > > reset_test.c:13,111: 0x1e43570 copy Internal compiler error: bad > > type passed to copy > > romcc is sensitive to the version of linux you are running at present. Ron how so? If romcc compiles it should work. I don't have any excuse for romcc to behave different depending on what compiler compiles it. Eric From ebiederman at lnxi.com Mon Sep 15 06:43:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 06:43:00 2003 Subject: [Fwd: Re: 2.7 block ramblings (was Re: DMA for ide-scsi?)] In-Reply-To: <1063580172.1350.106.camel@lotte.street-vision.com> References: <1063580172.1350.106.camel@lotte.street-vision.com> Message-ID: Justin Cormack writes: > This is from lkml. > > Can someone reply (and persuade Dell how broken their thought process > is). > > Actually the whole thread about boot disk is odd. My usual problem with > lilo and grub was trying to persuade them to install on something that > wasnt the boot disk but was going to be. What is your problem with the thread? EFI GUID partitions are a reasonable solution to multiple terabyte partitions. They are not too nasty, they already exist, and they work. I don't think a classic dos partition table will. Eric From stepan at suse.de Mon Sep 15 08:10:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 15 08:10:01 2003 Subject: Getting started In-Reply-To: References: Message-ID: <20030915123037.GC27240@suse.de> * Eric W. Biederman [030915 13:10]: > Ron how so? If romcc compiles it should work. I don't have any > excuse for romcc to behave different depending on what compiler > compiles it. But there is a difference in the resulting romcc depending on whether you compile it for AMD64 or IA32. I tracked it down to lines 211 and 212: /* Long on the destination platform */ typedef unsigned long ulong_t; typedef long long_t; The IA32 version of the size_of() function will return 4 when it gets a pointer or a long, whereas the AMD64 version will return 8. The function transform_to_arch_instruction checks the result of size_of() in the OP_COPY branch of the big case statement and fails with an internal compiler error if the size is not 1, 2 or 4. Since IA32 code (including AMD64 special registers) is the only target platform currently supported, it should be OK to change above typedefs to 4 byte types. If this seems not appropriate it might make sense to seperate the platform dependent code into several files and have an additional target for AMD64 long mode. Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 15 10:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 15 10:29:01 2003 Subject: Getting started In-Reply-To: Message-ID: On 15 Sep 2003, Eric W. Biederman wrote: > > romcc is sensitive to the version of linux you are running at present. > > Ron how so? If romcc compiles it should work. I don't have any > excuse for romcc to behave different depending on what compiler > compiles it. it makes no sense to me either, as romcc is clean and well-written. It is just what I have seen: it won't work on my RH 7.3 box, with: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) BTW, config.py as of today doesn't work with this error: File "/home/rminnich/src/freebios2/util/newconfig/config.py", line 1393, in term return long(NUM, 10) TypeError: long requires exactly 1 argument; 2 given I think somebody broke something. Python it turns out rotates function definitions frequently, with the result that it is hard to write python-version-independent code. ron From rminnich at lanl.gov Mon Sep 15 10:31:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 15 10:31:01 2003 Subject: extending "buildrom" In-Reply-To: <20030915110132.GA27240@suse.de> Message-ID: On Mon, 15 Sep 2003, Stefan Reinauer wrote: > buildrom > size ROM_SIZE > data ./lsiscsifw 65536 ????????? What is that data thing? ron > image normal NORMAL_SIZE no, you need this info when you build the board, it can't move here. > Or maybe it makes sense to move the payloads into the buildrom section > as well and keep the romimage tag for building the LinuxBIOS code only > while the buildrom tag describes the composition of the final rom image > to flash? it's not a romimage tag, it's the name of the output file, I thought. ron From Michael at Fenner.org Mon Sep 15 14:36:00 2003 From: Michael at Fenner.org (Michael Fenner) Date: Mon Sep 15 14:36:00 2003 Subject: DoC on Eipa Message-ID: Hallo, does anybody have experience with DOC's on an Epia-M board? I read in a previous message ( http://www.mail-archive.com/linuxbios at clustermatic.org/msg03307.html ) that the DOC Millennium 8MB Module MD2802-D08 might work. Can anybody confirm this? They also say I need a ZIF socket, which makes sense, and an DIP-32 256K X8 120NS Atmel Flash Memory. I don't really understand what I would need that for. Can anybody help? Also I read that the EPIA-M still has problems with some DDR-Rams. Does anybody have a list which Rams are supported? thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From hansolofalcon at worldnet.att.net Mon Sep 15 14:44:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Mon Sep 15 14:44:01 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <000601c37bbc$5e5988e0$0100a8c0@who5> Hello from Gregg C Levine I might. The ZIF socket is for easy insertions of the part in question, which you have correctly decided. As for the Atmel part. Good question. I suspect that's the part number the boards are wearing. Not having seen one of them physically, I can only take a guess or three on this subject. First off, do you have the board where you are? Does it run Linux effectively? No complaints, et cetera? Suggest you post the output of the command, "#lspci -v", to this list, and we should be able to advise. (The command is the string after the # mark, the mark is the shell prompt.) ------------------- 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 Michael Fenner Sent: Monday, September 15, 2003 2:57 PM To: linuxbios at clustermatic.org Subject: DoC on Eipa Hallo, ? does anybody have experience with DOC's on an Epia-M board? I read in a previous message ( http://www.mail-archive.com/linuxbios at clustermatic.org/msg03307.html?) that the DOC Millennium 8MB Module MD2802-D08 might work. Can anybody confirm this? ? They also say I need a ZIF socket, which makes sense, and an DIP-32 256K X8 120NS Atmel Flash Memory. I don't really understand what I would need that for. ? Can anybody help? ? Also I read that the EPIA-M still has problems with some DDR-Rams. Does anybody have a list which Rams are supported? ? thanks, ? Michael From ebiederman at lnxi.com Mon Sep 15 15:36:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 15:36:00 2003 Subject: Getting started In-Reply-To: References: Message-ID: ron minnich writes: > On 15 Sep 2003, Eric W. Biederman wrote: > > > > romcc is sensitive to the version of linux you are running at present. > > > > Ron how so? If romcc compiles it should work. I don't have any > > excuse for romcc to behave different depending on what compiler > > compiles it. > > it makes no sense to me either, as romcc is clean and well-written. It is > just what I have seen: it won't work on my RH 7.3 box, with: > gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) Hmm. Ok. When you get a good datapoint... > BTW, config.py as of today doesn't work with this error: > File "/home/rminnich/src/freebios2/util/newconfig/config.py", line 1393, > in term > return long(NUM, 10) > TypeError: long requires exactly 1 argument; 2 given > > I think somebody broke something. Python it turns out rotates function > definitions frequently, with the result that it is hard to write > python-version-independent code. Which rev of python is this? Either I am not executing this, in my configuration file. Or it works fine for me with python2.1 python2.2 and python2.3 Eric From ebiederman at lnxi.com Mon Sep 15 15:38:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 15:38:00 2003 Subject: Getting started In-Reply-To: <20030915123037.GC27240@suse.de> References: <20030915123037.GC27240@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030915 13:10]: > > Ron how so? If romcc compiles it should work. I don't have any > > excuse for romcc to behave different depending on what compiler > > compiles it. > > But there is a difference in the resulting romcc depending on whether > you compile it for AMD64 or IA32. I tracked it down to lines 211 and > 212: > /* Long on the destination platform */ > typedef unsigned long ulong_t; > typedef long long_t; > > The IA32 version of the size_of() function will return 4 when it gets a > pointer or a long, whereas the AMD64 version will return 8. > > The function transform_to_arch_instruction checks the result of > size_of() in the OP_COPY branch of the big case statement and fails with > an internal compiler error if the size is not 1, 2 or 4. Ok. That looks like an easy mistake to make and it sounds reasonable that it exists. > Since IA32 code (including AMD64 special registers) is the only target > platform currently supported, it should be OK to change above typedefs > to 4 byte types. If this seems not appropriate it might make sense to > seperate the platform dependent code into several files and have an > additional target for AMD64 long mode. That is where I want to go eventually. For now which ever is most convenient. I have been doing my best to abstract things so I can add additional ports without too much trouble but I have not been worry about it very much. Eric From rminnich at lanl.gov Mon Sep 15 16:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 15 16:15:01 2003 Subject: Getting started In-Reply-To: Message-ID: On 15 Sep 2003, Eric W. Biederman wrote: > Either I am not executing this, in my configuration file. Or > it works fine for me with python2.1 python2.2 and python2.3 I'll look at version, I just hit this and then had to go to work. ron From steve at nexpath.com Mon Sep 15 16:55:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 15 16:55:01 2003 Subject: USB Memory Key booting In-Reply-To: References: Message-ID: <3F662E1B.7050403@nexpath.com> Has anyone done any thinking about booting from USB memory keys? I noticed an article on Dell's site from June, that Ford Motor has standardized on Dells with no floppy and boot capable from USB memory keys. Apparently it is Dell's own BIOS standard to do this. At least, it isn't in the BIOS Boot Specification and I don't recall seeing it in any BIOS I've used lately. I don't own any Dells, though. -Steve From Antony at Soft-Solutions.co.uk Mon Sep 15 17:11:00 2003 From: Antony at Soft-Solutions.co.uk (Antony Stone) Date: Mon Sep 15 17:11:00 2003 Subject: USB Memory Key booting In-Reply-To: <3F662E1B.7050403@nexpath.com> References: <3F662E1B.7050403@nexpath.com> Message-ID: <200309152131.h8FLVi530678@onyx.rockstone.co.uk> On Monday 15 September 2003 10:24 pm, Steve Gehlbach wrote: > Has anyone done any thinking about booting from USB memory keys? Do you mean the little solid state things commonly known as flash drives (even though there's no 'drive' as such)? > I noticed an article on Dell's site from June, that Ford Motor has > standardized on Dells with no floppy and boot capable from USB memory > keys. Apparently it is Dell's own BIOS standard to do this. At least, > it isn't in the BIOS Boot Specification and I don't recall seeing it in > any BIOS I've used lately. I don't own any Dells, though. The Bios of anything I've seen in the past 12-18 months has been capable of booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip The solid state flash drives behave exactly like USB-IDE as far as what they're plugged into is concerned - just like Compact Flash cards vs. normal IDE drives. Regards, Antony. -- If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilisation. From steve at nexpath.com Mon Sep 15 18:03:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 15 18:03:00 2003 Subject: USB Memory Key booting In-Reply-To: <200309152131.h8FLVi530678@onyx.rockstone.co.uk> References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> Message-ID: <3F663E2D.5020004@nexpath.com> Antony Stone wrote: > The Bios of anything I've seen in the past 12-18 months has been capable of > booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip > > The solid state flash drives behave exactly like USB-IDE as far as what > they're plugged into is concerned - just like Compact Flash cards vs. normal > IDE drives. > Hmmm... I guess I need to look at a current BIOS, I must have overlooked it. Anyway, any idea how much work it would be to get linuxbios to be able to read the USB-IDE? -Steve From ebiederman at lnxi.com Mon Sep 15 18:50:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 18:50:01 2003 Subject: USB Memory Key booting In-Reply-To: <3F663E2D.5020004@nexpath.com> References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> Message-ID: Steve Gehlbach writes: > Antony Stone wrote: > > > The Bios of anything I've seen in the past 12-18 months has been capable of > > booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip > > The solid state flash drives behave exactly like USB-IDE as far as what > > they're plugged into is concerned - just like Compact Flash cards vs. normal > > IDE drives. > > > > Hmmm... I guess I need to look at a current BIOS, I must have overlooked it. > > Anyway, any idea how much work it would be to get linuxbios to be able to read > the USB-IDE? I don't think there is USB-IDE. I think the stack looks like USB-SCSI. The challenge is that the USB stack is fairly tall. We should be able to incorporate a version of that into etherboot or FILO. I don't think we want a version of that in the core of LinuxBIOS, but I can be surprised. Eric From steve at nexpath.com Mon Sep 15 19:39:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 15 19:39:00 2003 Subject: USB Memory Key booting In-Reply-To: References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> Message-ID: <3F6654B5.90407@nexpath.com> Eric W. Biederman wrote: > I don't think there is USB-IDE. I think the stack looks like USB-SCSI. > > The challenge is that the USB stack is fairly tall. > > We should be able to incorporate a version of that into etherboot or FILO. > > I don't think we want a version of that in the core of LinuxBIOS, but > I can be surprised. I checked the latest EPIA BIOS and it says USB-HDD. I figured the USB stack was deep; I may do some experimenting with Linux and booting from one of these and see what is involved. I haven't checked the price to see how these compare with Compact Flash, but the small size and ease of customer installation is attractive. The CF requires an adaptor to IDE that is a little awkward. The USB flash memory can be installed by a customer without opening the case, and saves the price of a CDROM drive (and the mechanical failure problems with a CDROM drive). All of this is from the standpoint of an embedded system and may be of no interest to clusters. -Steve From rminnich at lanl.gov Mon Sep 15 19:42:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 15 19:42:00 2003 Subject: USB Memory Key booting In-Reply-To: <3F6654B5.90407@nexpath.com> Message-ID: I think the USB stuff is of interest. I'm clueless how to write the support for USB however, but I think it's worth somebody looking at it. ron From ebiederman at lnxi.com Mon Sep 15 19:53:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 15 19:53:00 2003 Subject: USB Memory Key booting In-Reply-To: <3F6654B5.90407@nexpath.com> References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> <3F6654B5.90407@nexpath.com> Message-ID: Steve Gehlbach writes: > Eric W. Biederman wrote: > > > I don't think there is USB-IDE. I think the stack looks like USB-SCSI. > > The challenge is that the USB stack is fairly tall. > > We should be able to incorporate a version of that into etherboot or FILO. > > I don't think we want a version of that in the core of LinuxBIOS, but > > I can be surprised. > > I checked the latest EPIA BIOS and it says USB-HDD. > > I figured the USB stack was deep; I may do some experimenting with Linux and > booting from one of these and see what is involved. > > I haven't checked the price to see how these compare with Compact Flash, but the > > small size and ease of customer installation is attractive. The CF requires an > adaptor to IDE that is a little awkward. The USB flash memory can be installed > by a customer without opening the case, and saves the price of a CDROM drive > (and the mechanical failure problems with a CDROM drive). All of this is from > the standpoint of an embedded system and may be of no interest to clusters. I totally think USB is interesting. My only concern is that we will have more problems getting it right than we did IDE. Eric From dale_anderson at paradise.net.nz Mon Sep 15 20:53:01 2003 From: dale_anderson at paradise.net.nz (dale_anderson at paradise.net.nz) Date: Mon Sep 15 20:53:01 2003 Subject: Intel 865G Message-ID: <1063674821.3f6663c5e0815@www.paradise.net.nz> Hi All Have been watching for a while and hadnt seen any discussion on this one so I thought I'd ask :) Anyone working on the Intel 865G equiped boards atm ? I currently have a Gigabyte GA-8IG1000 in my possession and was wondering if anything in cvs atm , would have peliminary support ? Im assuming stuff like enabling hyperthreading etc is a wee way off , but as im running a celery it doesnt really worry me :) what are the chances like in getting something to work ? TIA Dale Anderson. From steve at nexpath.com Mon Sep 15 22:12:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 15 22:12:01 2003 Subject: USB Memory Key booting In-Reply-To: References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> <3F6654B5.90407@nexpath.com> Message-ID: <3F667699.2090409@nexpath.com> Eric W. Biederman wrote: > I totally think USB is interesting. > > My only concern is that we will have more problems getting it right than > we did IDE. > No kidding, it is clearly much more complicated than IDE, that's for sure. But all of that aside, it would be a slick way to boot from linuxbios. -Steve From aip at cwlinux.com Mon Sep 15 22:52:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Sep 15 22:52:01 2003 Subject: USB Memory Key booting In-Reply-To: <3F6654B5.90407@nexpath.com>; from Steve Gehlbach on Mon, Sep 15, 2003 at 05:09:25PM -0700 References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> <3F6654B5.90407@nexpath.com> Message-ID: <20030916111244.A13618@mail.cwlinux.com> Hi, > I checked the latest EPIA BIOS and it says USB-HDD. Under Linux, it uses USB and SCSI stack to access USB IDE harddisk or USB flash disk. > I figured the USB stack was deep; I may do some experimenting with Linux > and booting from one of these and see what is involved. > I haven't checked the price to see how these compare with Compact Flash, > but the small size and ease of customer installation is attractive. The It is just a little more expensive than CF, but its size is much smaller. > CF requires an adaptor to IDE that is a little awkward. The USB flash > memory can be installed by a customer without opening the case, and > saves the price of a CDROM drive (and the mechanical failure problems > with a CDROM drive). All of this is from the standpoint of an embedded > system and may be of no interest to clusters. I think we can take a look at u-boot which has USB storage access already. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From ollie at sis.com.tw Mon Sep 15 23:28:00 2003 From: ollie at sis.com.tw (???) Date: Mon Sep 15 23:28:00 2003 Subject: [OT] Phoenix Developing DRM-Equipped BIOS References: Message-ID: <075d01c37c05$51188cf0$0201a8c0@ollie> > On Fri, 5 Sep 2003, ??? wrote: > > > I am afraid they will buy it when they have no or very few choice. When > > the majority of the boards on the market are DRM enabled or most of > > the digital information requires DRM to be accessed, pepole will > > buy these products. I don't know how it is in the U.S., but here in > > Taiwan, MS is using the recent SoBig/Blaster virus as a "sales point" > > for its "Trusted Computing" hype. > > that's quite funny. First, M$ builds insecure software, then pushes DRM as > a fix for their own software? > Yea, that is their old trick. Sell something borken first and sell another thing to fix it. Ollie From spirit at reactor.ru Tue Sep 16 01:49:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Tue Sep 16 01:49:00 2003 Subject: USB Memory Key booting In-Reply-To: <200309152131.h8FLVi530678@onyx.rockstone.co.uk> References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> Message-ID: <47814674449.20030916100800@reactor.ru> Hello Antony, Tuesday, September 16, 2003, 1:31:40 AM, you wrote: AS> The Bios of anything I've seen in the past 12-18 months has been capable of AS> booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip AS> The solid state flash drives behave exactly like USB-IDE as far as what AS> they're plugged into is concerned - just like Compact Flash cards vs. normal AS> IDE drives. Actually, most USB flash drives comply to USB-ZIP, not to USB-IDE. With best regards, Alexander spirit at reactor.ru --8<--just-a-cookie---------------------------------------------- Solution for any problem of your life can be found on the Net. You just need to know how to search. --8<------------------------------------------------------------- From ts1 at cma.co.jp Tue Sep 16 02:55:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Tue Sep 16 02:55:00 2003 Subject: USB Memory Key booting In-Reply-To: <20030916111244.A13618@mail.cwlinux.com> References: <3F662E1B.7050403@nexpath.com> <200309152131.h8FLVi530678@onyx.rockstone.co.uk> <3F663E2D.5020004@nexpath.com> <3F6654B5.90407@nexpath.com> <20030916111244.A13618@mail.cwlinux.com> Message-ID: <20030916071545.GA3207@cma.co.jp> On Tue, Sep 16, 2003 at 11:12:44AM +0800, Andrew Ip wrote: > I think we can take a look at u-boot which has USB storage access already. I've been interested in supporting USB storage (as well as keyboards) in FILO, but I didn't know where to start. I'm now looking at the sourcecode of u-boot, and I think this is what I've been looking for. Thanks a lot, Andrew! -- Takeshi From niki.waibel at newlogic.com Tue Sep 16 03:36:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 16 03:36:01 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <200309160756.h8G7uYZS023196@enterprise2.newlogic.at> > does anybody have experience with DOC's on an Epia-M board? I read in a previous message ( > http://www.mail-archive.com/linuxbios at clustermatic.org/msg03307.html ) > that the DOC Millennium 8MB Module MD2802-D08 might work. > Can anybody confirm > this? i am currently playing with this. my epia-m has no DIP32 socket. i decided to use a DIP2PLCC adapter to use the MD2802-D08. so i can plug it directly into the bios socket. > They also say I need a ZIF socket, which makes sense, and an DIP-32 256K X8 120NS > Atmel Flash Memory. I don't really understand > what I would need that for. i dont understand. you could exchange the rom ... but then there is no space for the MD2802-D08. > Also I read that the EPIA-M still has problems with some DDR-Rams. Does anybody > have a list which Rams are supported? i am currently trying to use (mount;-) the the MD2802-D08 when plugged into the bios socket. this seems to be much more tricky then i thought. i've already written some test prg -- and it seems that the behavior of my DoC is very strange. niki From cforney at opus.com Tue Sep 16 03:54:00 2003 From: cforney at opus.com (Craig C. Forney) Date: Tue Sep 16 03:54:00 2003 Subject: Getting started In-Reply-To: <20030915123037.GC27240@suse.de> Message-ID: <000301c37c2a$ad497910$6701a8c0@CCFLAPTOP> > > But there is a difference in the resulting romcc depending on > whether you compile it for AMD64 or IA32. I tracked it down > to lines 211 and > 212: > /* Long on the destination platform */ > typedef unsigned long ulong_t; > typedef long long_t; > > The IA32 version of the size_of() function will return 4 when > it gets a pointer or a long, whereas the AMD64 version will return 8. > > The function transform_to_arch_instruction checks the result of > size_of() in the OP_COPY branch of the big case statement and > fails with an internal compiler error if the size is not 1, 2 or 4. > Although I certainly don't understand all the implications, I changed lines 211 and 212 to: typedef unsigned int ulong_t; typedef int long_t; and made romcc on an Opteron based system running the 8.2 beta. Romcc got further, but failed with the following: console.c: 136.35: Incompatible types in initializer As an experiment I went ahead and commented out the code in console.c that it was complaining about. The next failure was a malloc error with a HUGE malloc value ... So I gave up and built a PC with a standard Intel 32-bit processor, reloaded everything, and romcc appears to work just fine. It built a ROM image, at least. I thought I might get lucky building on the Opteron system with the changes, but not today. Thanks for your help. Regards, Craig ========================================================== Craig C. Forney email : cforney at opus.com Opus Innovations LLC www : http://www.opus.com ========================================================== From hansolofalcon at worldnet.att.net Tue Sep 16 07:43:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue Sep 16 07:43:01 2003 Subject: USB Memory Key booting In-Reply-To: <47814674449.20030916100800@reactor.ru> Message-ID: <000a01c37c4a$d7fcd100$0100a8c0@who5> Hello (again) from Gregg C Levine Actually gentlemen, and ladies, no it is not. I have available for this system a USB Key Drive, from Memorex, and a CF reader, also from them. To use them under Linux, I need to turn on SCSI, and USB-Mass drive support. Also, the mass drive functions look more like SCSI to me, then anything like IDE. Granted this is one example. I grok, that there are others out there who do use IDE, but I doubted. There are mistakes in the mass transport layers for Linux, certainly. But nothing that gross. Incidentally that's the 2.4.20 group, and I am using Slackware Linux here. ------------------- 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 Alexander Amelkin > Sent: Tuesday, September 16, 2003 2:08 AM > To: Antony Stone > Cc: linuxbios at clustermatic.org > Subject: Re[2]: USB Memory Key booting > > Hello Antony, > > Tuesday, September 16, 2003, 1:31:40 AM, you wrote: > > AS> The Bios of anything I've seen in the past 12-18 months has been capable of > AS> booting from USB-IDE, USB-CD, USB-Floppy and USB-Zip > > AS> The solid state flash drives behave exactly like USB-IDE as far as what > AS> they're plugged into is concerned - just like Compact Flash cards vs. normal > AS> IDE drives. > > Actually, most USB flash drives comply to USB-ZIP, not to USB-IDE. > > With best regards, > Alexander spirit at reactor.ru > > --8<--just-a-cookie---------------------------------------------- > Solution for any problem of your life can be found on the Net. You just need to > know how to search. > --8<------------------------------------------------------------- > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From stepan at suse.de Tue Sep 16 08:35:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 16 08:35:01 2003 Subject: romcc fixes for AMD64 Message-ID: <20030916125559.GA1229@suse.de> Hi, with the attached fix romcc is able to compile all of auto.c for the freebios2 amd64 targets. To keep all changes clean and visible, they're encapsulated in ifdefs. Note: This fix alone does not make LinuxBIOS compile on AMD64 completely yet. GCC and ld need the -m32 in some places at least to compile everything. Is there any need in going 64bit for the LinuxBIOS C payload on Opteron? Since the kernel does long mode switching itself this should not be the case, but maybe there are different opinions. Next fail I saw after romcc passed auto.c was the following: /home/stepan/freebios2/src/superio/NSC/pc87360/superio.c:61: warning: `pnp_read_enable' defined but not used /tmp/ccLriZXb.s: Assembler messages: /tmp/ccLriZXb.s:243: Error: Incorrect register `%rdx' used with `l' suffix /tmp/ccLriZXb.s:245: Error: Incorrect register `%rdx' used with `l' suffix make: *** [superio.o] Error 1 Greetings, Stefan -- Architecture Team SuSE Linux AG -------------- next part -------------- ? romcc.diff ? romcc2.diff ? romcc3.diff ? romcc4.diff Index: romcc.c =================================================================== RCS file: /cvsroot/freebios/freebios2/util/romcc/romcc.c,v retrieving revision 1.23 diff -u -r1.23 romcc.c --- romcc.c 21 Jul 2003 20:13:45 -0000 1.23 +++ romcc.c 16 Sep 2003 12:46:28 -0000 @@ -208,8 +208,13 @@ } /* Long on the destination platform */ +#ifdef __x86_64__ +typedef unsigned int ulong_t; +typedef int long_t; +#else typedef unsigned long ulong_t; typedef long long_t; +#endif struct file_state { struct file_state *prev; @@ -861,7 +866,11 @@ * type-> holds the number of elements. */ +#ifdef __x86_64__ +#define ELEMENT_COUNT_UNSPECIFIED (~0U) +#else #define ELEMENT_COUNT_UNSPECIFIED (~0UL) +#endif struct type { unsigned int type; @@ -2952,8 +2961,13 @@ meat(state, index, TOK_LIT_INT); errno = 0; val = strtol(state->token[index].val.str, &end, 0); +#ifdef __x86_64__ + if (((val == INT_MIN) || (val == INT_MAX)) && + (errno == ERANGE)) { +#else if (((val == LONG_MIN) || (val == LONG_MAX)) && (errno == ERANGE)) { +#endif error(state, 0, "Integer constant to large"); } break; @@ -7101,7 +7115,11 @@ errno = 0; decimal = (tk->val.str[0] != '0'); val = strtoul(tk->val.str, &end, 0); +#ifdef __x86_64__ + if ((val == UINT_MAX) && (errno == ERANGE)) { +#else if ((val == ULONG_MAX) && (errno == ERANGE)) { +#endif error(state, 0, "Integer constant to large"); } u = l = 0; @@ -7125,7 +7143,11 @@ } else if (l) { type = &long_type; +#ifdef __x86_64__ + if (!decimal && (val > INT_MAX)) { +#else if (!decimal && (val > LONG_MAX)) { +#endif type = &ulong_type; } } @@ -7140,7 +7162,11 @@ if (!decimal && (val > INT_MAX) && (val <= UINT_MAX)) { type = &uint_type; } +#ifdef __x86_64__ + else if (!decimal && (val > INT_MAX)) { +#else else if (!decimal && (val > LONG_MAX)) { +#endif type = &ulong_type; } else if (val > INT_MAX) { From stepan at suse.de Tue Sep 16 08:37:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 16 08:37:00 2003 Subject: extending "buildrom" In-Reply-To: References: <20030915110132.GA27240@suse.de> Message-ID: <20030916125834.GB1229@suse.de> * ron minnich [030915 16:51]: > On Mon, 15 Sep 2003, Stefan Reinauer wrote: > > > buildrom > > size ROM_SIZE > > data ./lsiscsifw 65536 > > ????????? What is that data thing? I assumed that packing option roms or similar data hunks into an image might become more and more a default. But it does not really fit, I agree. > > image normal NORMAL_SIZE > > no, you need this info when you build the board, it can't move here. What information is needed? I would have thought it's only the start address of the payload? Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Tue Sep 16 09:34:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 09:34:00 2003 Subject: DoC on Eipa In-Reply-To: <200309160756.h8G7uYZS023196@enterprise2.newlogic.at> Message-ID: On Tue, 16 Sep 2003, Niki Waibel wrote: > i am currently playing with this. my epia-m has no DIP32 socket. i > decided to use a DIP2PLCC adapter to use the MD2802-D08. so i can plug > it directly into the bios socket. please remember, getting to work in the socket is the easy part. Getting epia support for memory up and running in 256 or so bytes is the hard part. ron From rminnich at lanl.gov Tue Sep 16 09:54:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 09:54:00 2003 Subject: USB Memory Key booting In-Reply-To: <000a01c37c4a$d7fcd100$0100a8c0@who5> Message-ID: On Tue, 16 Sep 2003, Gregg C Levine wrote: > Actually gentlemen, and ladies, no it is not. I have available for > this system a USB Key Drive, from Memorex, and a CF reader, also from > them. To use them under Linux, I need to turn on SCSI, and USB-Mass > drive support. Also, the mass drive functions look more like SCSI to > me, then anything like IDE. Granted this is one example. here again is the case for linux in the bios, if only the flash parts were big enough. Linux in the bios could easily drive all usb devices for mass storage, and boot linux off the mass store. Without linux in the bios, we will have to write all that code and deal with all the hardware bugs. If only the flash parts would get big. ron From rminnich at lanl.gov Tue Sep 16 09:58:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 09:58:00 2003 Subject: romcc fixes for AMD64 In-Reply-To: <20030916125559.GA1229@suse.de> Message-ID: On Tue, 16 Sep 2003, Stefan Reinauer wrote: > Is there any need in going 64bit for the LinuxBIOS C payload on Opteron? > Since the kernel does long mode switching itself this should not be the > case, but maybe there are different opinions. I think maybe when we start putting > 4 GB memory on these machines, I don't know how we're going to zero memory absent a true 64-bit C payload. ron From rminnich at lanl.gov Tue Sep 16 10:00:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 10:00:01 2003 Subject: extending "buildrom" In-Reply-To: <20030916125834.GB1229@suse.de> Message-ID: On Tue, 16 Sep 2003, Stefan Reinauer wrote: > * ron minnich [030915 16:51]: > > On Mon, 15 Sep 2003, Stefan Reinauer wrote: > > > > > buildrom > > > size ROM_SIZE > > > data ./lsiscsifw 65536 > > > > ????????? What is that data thing? > > I assumed that packing option roms or similar data hunks into an image > might become more and more a default. But it does not really fit, I > agree. Now that you've explained it, I realize that's a really good idea. It would eliminate much kludgery that we have for the linuxbios splash image. > > > > image normal NORMAL_SIZE > > > > no, you need this info when you build the board, it can't move here. > > What information is needed? I would have thought it's only the start > address of the payload? Actually it is good to have it here after all, as it is a double-check: if the "normal" image is not NORMAL_SIZE then there is a problem in building. I would like as many checks as possible in this process, since when things go wrong the machine usually sits there with no output. ron From rminnich at lanl.gov Tue Sep 16 10:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 10:04:00 2003 Subject: extending "buildrom" In-Reply-To: Message-ID: On Tue, 16 Sep 2003, ron minnich wrote: > On Tue, 16 Sep 2003, Stefan Reinauer wrote: > > > * ron minnich [030915 16:51]: > > > On Mon, 15 Sep 2003, Stefan Reinauer wrote: > > > > > > > buildrom > > > > size ROM_SIZE > > > > data ./lsiscsifw 65536 So the one change I'd make is to have an optional offset. data ./lsiscsifs 65536 image normal NORMAL_SIZE 0x20000 etc. This would be so that you could have non-contiguous data areas. ron From niki.waibel at newlogic.com Tue Sep 16 10:18:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 16 10:18:01 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <200309161439.h8GEdMZS015070@enterprise2.newlogic.at> >> i am currently playing with this. my epia-m has no DIP32 socket. i >> decided to use a DIP2PLCC adapter to use the MD2802-D08. so i can plug >> it directly into the bios socket. > > please remember, getting to work in the socket is the easy part. Getting > epia support for memory up and running in 256 or so bytes is the hard > part. that is true. where can i get more info in how to init the mem on a epia-m? do i have to rev eng the bios? niki From rminnich at lanl.gov Tue Sep 16 10:19:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 10:19:01 2003 Subject: DoC on Eipa In-Reply-To: <200309161439.h8GEdMZS015070@enterprise2.newlogic.at> Message-ID: On Tue, 16 Sep 2003, Niki Waibel wrote: > where can i get more info in how to init the mem on a > epia-m? do i have to rev eng the bios? > read the linuxbios source, of course! ron From rminnich at lanl.gov Tue Sep 16 10:25:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 10:25:01 2003 Subject: DoC on Eipa In-Reply-To: <200309161439.h8GEdMZS015070@enterprise2.newlogic.at> Message-ID: On Tue, 16 Sep 2003, Niki Waibel wrote: > where can i get more info in how to init the mem on a > epia-m? do i have to rev eng the bios? src/northbridge/via/vt8601/ipl.S is code that worked for the vt8601 2 years ago for DoC uses. Not guaranteed to work with all DRAM. The 8601 is very tricky. ron From stepan at suse.de Tue Sep 16 10:35:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 16 10:35:01 2003 Subject: romcc fixes for AMD64 In-Reply-To: References: <20030916125559.GA1229@suse.de> Message-ID: <20030916145543.GA2446@suse.de> * ron minnich [030916 16:19]: > I think maybe when we start putting > 4 GB memory on these machines, I > don't know how we're going to zero memory absent a true 64-bit C payload. This could be done using the Opterons PAE feature. Currently I see a tradeoff between LinuxBIOS image size and the design conflict when going away from 16bit firmware on 32bit systems while staying with 32bit on a 64bit platform. Stefan -- Architecture Team SuSE Linux AG From niki.waibel at newlogic.com Tue Sep 16 10:51:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 16 10:51:01 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <200309161511.h8GFBgZS019512@enterprise2.newlogic.at> >> where can i get more info in how to init the mem on a >> epia-m? do i have to rev eng the bios? > > src/northbridge/via/vt8601/ipl.S is code that worked for the vt8601 2 > years ago for DoC uses. > > Not guaranteed to work with all DRAM. The 8601 is very tricky. nwaibel at blade100-2 ~/freebios-20030910 $ for i in `find -iname "*ipl*"`; do echo $i; mpage -4fHl $i | lp; done as you can see -- i am going to rtfm :) i think that the CLE266 (epia-m) is quite different then the vt8601. right now i've no idea about northbringes, but i hope that will change soon :) where did the ppl (who have written all the ipl.S files) got the information from? niki From aip at cwlinux.com Tue Sep 16 10:51:22 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue Sep 16 10:51:22 2003 Subject: DoC on Eipa In-Reply-To: ; from ron minnich on Tue, Sep 16, 2003 at 08:40:16AM -0600 References: <200309161439.h8GEdMZS015070@enterprise2.newlogic.at> Message-ID: <20030916231209.A21654@mail.cwlinux.com> Hi, > > where can i get more info in how to init the mem on a > > epia-m? do i have to rev eng the bios? > read the linuxbios source, of course! I think EPIA-M is even harder to fit into IPL. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From niki.waibel at newlogic.com Tue Sep 16 10:52:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 16 10:52:00 2003 Subject: DoC on Eipa In-Reply-To: <20030916231209.A21654@mail.cwlinux.com> Message-ID: <200309161513.h8GFDNZS019556@enterprise2.newlogic.at> >> > where can i get more info in how to init the mem on a >> > epia-m? do i have to rev eng the bios? >> read the linuxbios source, of course! > I think EPIA-M is even harder to fit into IPL. why do you think so? niki From stepan at suse.de Tue Sep 16 11:42:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 16 11:42:00 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released Message-ID: <20030916160247.GA2778@suse.de> Dear LinuxBIOS community, After some months of development I am happy to announce the new OpenBIOS forth kernel "BeginAgain". It is available from the OpenBIOS CVS in the directory "kernel/" or at http://www.openbios.org/bin/kernel-1.0.tar.bz2 Features -------- - indirect-threaded forth engine - openfirmware user interface - small and portable - easily enhancable Platform Notes -------------- Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth kernel was developed using gcc on Linux systems. Minor changes might be necessary in non-linux/gcc build environments. Design Goals ------------ The design goals of "BeginAgain" were: 1) Portability 2) Maintainability 3) Small Size ---------------------------------------------------------------------- 1) Portability BeginAgain, with minimal changes, will work on new systems. There is support for X86 and AMD64 at the moment. Implementing support for new systems only requires adaptions to the start code and system abstraction. The current code has been developed using gcc 3.x, but no explicit GCCisms are used. Since gcc is the most widely spread compiler, it should be a good base for easily porting OpenBIOS to new platforms. 2) Maintainability The code is split into several parts: _________________________________________ | | | Forth dictionary | |_________________________________________| ^ | forth code ________|_________________________|_________ | | | v native code _____________ ___________________ | | | | | Scheduler | ----> | primitive words | |_____________| |___________________| ^ ^ | | | | _____________ ____________________ | | | | -->| Startup | | system abstraction | |_____________| |____________________| Platform dependent part ----------------------- a) After taking control the "scheduler", in forth context called "inner interpreter, reads the forth dictionary, a list of nested word definitions that are built using primitive words. b) These primitive words are written in C, so they take advantage of the compiler's ability to optimize code. They represent the minimum set of forth words that are needed to define all language constructs, including the Open Firmware system. c) The startup code is probably the most platform sensitive code. It's task is simple - get the scheduler up and running and provide a dictionary to execute. OpenBIOS provides multiple boot targets per platform. For example, on x86 it is possible to run the kernel either from Grub or LinuxBIOS. An additional target (available on all platforms) allows running the code from a Unix shell. d) The system abstraction part ought to be kept as small as possible. The primary words provide an interface for non-memory-mapped IO, and there's a small builtin console due to the fact that OpenBIOS has no device tree and/or drivers at the moment. Once these platform dependent parts are in place, they can be used to create an indirect-threaded dictionary file. This dictionary file contains a platform abstracted version of forth code that currently depends on the endianness and pointer (cell) size of the target platform. To keep the forth dictionary and the native code strictly seperate the unix hosted version of the kernel has a small builtin interpreter able to bootstrap all of the base system including a forth written interpreter, which represents part of the openfirmware user interface. In a second stage the advanced forth written interpreter is used to extend the bootstrap dictionary with additional features. As an example, ANS forth wordlist support is added, which will be used in the device tree code. Currently the OpenBIOS dictionary contains a nearly complete implementation of the Open Firmware user interface. It passes the Hayes ANS Forth test suite that is run when OpenBIOS is built, writing it's output to the file forth.html. Since the machine is abstracted as early and completly as possible, porting OpenBIOS to a new platform requires only minor efforts. 3) Small size The less code that needs to be adopted when porting OpenBIOS to a new platform, the quicker new ports can happen. Therefore the OpenBIOS kernel is really small. Here is a sample: size in | x86 | amd64 bytes | gcc 3.3 | gcc 3.3.1 -----------------+---------+---------------- multiboot kernel | 6724 | 15464 -----------------+---------+---------------- LinuxBIOS kernel | 7016 | 15896 -----------------+---------+---------------- LinuxBIOS kernel | | inc. dictionary | 27048 | 52920 -------------------------------------------- Installation and usage ---------------------- Run "make" to compile all binaries and dictionaries required to run the OpenBIOS kernel $ make Per default all binaries will be placed in the directory obj-{platform}. Then you can execute the kernel from a shell, by giving the command $ make run To boot LinuxBIOS from GRUB, copy openbios.multiboot and openfirmware.dict to /boot, then add a new entry to your menu.lst config file which looks like this: -------------------- 8< -------------------- title openbios kernel (hd0,2)/boot/openbios.multiboot module (hd0,2)/boot/openfirmware.dict -------------------- 8< -------------------- (hd0,2) is the equivalent to the Linux partition /dev/hda3 OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org) or booted in EtherBoot (www.etherboot.org). The simplest way is to use the kernel that includes the full dictionary: openbios.full Bug reports ----------- Any trouble, bugs etc. should be reported to the openbios mailinglist Further Development ------------------- BeginAgain is pretty much complete now. Expect only bugfixes and optimizations in the future. Interpretation mode versions of most loop constructs should be included although they are not really needed to get more development going. The next steps in writing an Open Firmware implementation is to complete the Device and Client Interfaces. These two parts are needed to set up a device tree, initialize hardware, and boot the operating system. Once there is a device tree and some basic device interface functions it will be possible to run fcode drivers for device initialization in OpenBIOS, using the FCode evaluator that resides in the OpenBIOS CVS directory forth/evaluator/. Regards, Stefan From rminnich at lanl.gov Tue Sep 16 11:43:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 11:43:01 2003 Subject: romcc fixes for AMD64 In-Reply-To: <20030916145543.GA2446@suse.de> Message-ID: On Tue, 16 Sep 2003, Stefan Reinauer wrote: > This could be done using the Opterons PAE feature. Currently I see a > tradeoff between LinuxBIOS image size and the design conflict when going > away from 16bit firmware on 32bit systems while staying with 32bit on > a 64bit platform. this won't last very long here. 36 bits only gets us to 64 GB -- too small. LinuxBIOS has run in 64-bit mode on a 64-bit platform -- the alpha. I see no real issue with going to 64-bit opteron mode. rno From rminnich at lanl.gov Tue Sep 16 11:45:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 11:45:01 2003 Subject: DoC on Eipa In-Reply-To: <200309161511.h8GFBgZS019512@enterprise2.newlogic.at> Message-ID: On Tue, 16 Sep 2003, Niki Waibel wrote: > i think that the CLE266 (epia-m) is quite different then the vt8601. > right now i've no idea about northbringes, but i hope that will change soon :) doubtful, I have found lots of reuse of cores in these norhtbridges. But I'm willing to be convinced :-) > where did the ppl (who have written all the ipl.S files) got the > information from? I wrote it. I got info from VIA. They were quite helpful about it. ron From aip at cwlinux.com Tue Sep 16 12:00:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue Sep 16 12:00:01 2003 Subject: DoC on Eipa In-Reply-To: <200309161513.h8GFDNZS019556@enterprise2.newlogic.at>; from Niki Waibel on Tue, Sep 16, 2003 at 05:13:23PM +0200 References: <20030916231209.A21654@mail.cwlinux.com> <200309161513.h8GFDNZS019556@enterprise2.newlogic.at> Message-ID: <20030917002109.A22911@mail.cwlinux.com> Hi, > > I think EPIA-M is even harder to fit into IPL. > why do you think so? More steps are required to init DDR. It might not fit in 512 bytes. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From YhLu at tyan.com Tue Sep 16 12:22:01 2003 From: YhLu at tyan.com (YhLu) Date: Tue Sep 16 12:22:01 2003 Subject: extending "buildrom" Message-ID: <3174569B9743D511922F00A0C943142303466946@TYANWEB> Optional offset is a good idea. But seem when We build normal or fallback image the offset are fixed at the time. For example: The LsiSCSIFW is 48k. and its final offset in ROM is 0. When building fallback image, I set ROM_SIZE is 512K, and fallback section size if 96K ( 32k+64k) so the offset is 512K-96K.The final offset in ROM should be 512K-96K. When building normal image, I set ROM_SIZE is 512K-48K. and normal section size is 512k-48k-96k, and the offset is 48K. The final offset in ROM should be 48K. So We only need to cat them all together, except We don't want normal you may need the optional offset. Regards YH. -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?9?16? 7:25 ???: Stefan Reinauer ??: YhLu; LinuxBIOS ??: Re: extending "buildrom" On Tue, 16 Sep 2003, ron minnich wrote: > On Tue, 16 Sep 2003, Stefan Reinauer wrote: > > > * ron minnich [030915 16:51]: > > > On Mon, 15 Sep 2003, Stefan Reinauer wrote: > > > > > > > buildrom > > > > size ROM_SIZE > > > > data ./lsiscsifw 65536 So the one change I'd make is to have an optional offset. data ./lsiscsifs 65536 image normal NORMAL_SIZE 0x20000 etc. This would be so that you could have non-contiguous data areas. ron From linuxbios at denkmair.de Tue Sep 16 12:30:00 2003 From: linuxbios at denkmair.de (Hubert Denkmair) Date: Tue Sep 16 12:30:00 2003 Subject: Help! with Linuxbios + EPIA 5000 + Etherboot Message-ID: <3F673F74.5070709@denkmair.de> Hi, I finally received a working BIOS Saviour and tried linuxbios the first time last night. I tried to exactly follow the EPIA-Howto but failed because I can't compile etherboot as described there: First of all there's no line "CFLAGS+= -DPCIBIOS" to comment out in the etherboot-5.0.11 "Config" file - I assume it might be a typo in the howto and commented out the line "CFLAGS+= -DPCBIOS", but it won't work. Anyways, I'm not able to compile the etherboot-5.0.[10,11] sources at all. I'm using a fresh upgraded debian "testing" with gcc-3.3.1 Simply doing a --- tar xvjf etherboot-5.0.11.tar.bz2 cd etherboot-5.0.11/src make bin32/via-rhine.elf --- throws tons of warnings and fails to link with messages like --- bin32/via-rhine.o(.text+0x2e8): In function `rhine_probe1': : undefined reference to `currticks' --- As I'm not familiar with C/GCC I have no idea where this may come from (wrong compiler version, wrong libs...?) I tried the etherboot-5.2.1 source package. Opposing to etherboot-5.0 there are no linuxbios options so I suppose they are not needed any more. The etherboot-5.2 package compiles fine (I'm doing a "make bin/via-rhine.elf"). From there on I'm following the EPIA-HOWTO again and the linuxbios build runs smoothly, flashing the romimage also was no problem. When booting, the linuxbios initialization seems to be ok, but after loading etherboot nothing seems to happen any more. The last lines on the serial console are: --- Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...succeed Wrote linuxbios table at: 00000500 - 00000698 checksum 345e Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 Loading Etherboot version: 5.2.1 Dropping non PT_LOAD segment New segment addr 0x20000 size 0xf160 offset 0xb0 filesize 0x5bdc (cleaned up) New segment addr 0x20000 size 0xf160 offset 0xb0 filesize 0x5bdc Loading Segment: addr: 0x000000000ff7faa8 memsz: 0x000000000000f160 filesz: 0x0000000000005bdc Clearing Segment: addr: 0x000000000ff85684 memsz: 0x0000000000009584 Jumping to boot code at 0x20000 --- Now, who can help be getting linuxbios/etherboot to work at all, or - better: boot from local IDE? Do I need special config options for etherboot-5.2? I searched the mailinglist but did not find any indication... What's wrong with my etherboot-5.0? Is my debian broken? Thanks for your help, Hubert From ebiederman at lnxi.com Tue Sep 16 13:26:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 16 13:26:01 2003 Subject: romcc fixes for AMD64 In-Reply-To: References: Message-ID: ron minnich writes: > On Tue, 16 Sep 2003, Stefan Reinauer wrote: > > > This could be done using the Opterons PAE feature. Currently I see a > > tradeoff between LinuxBIOS image size and the design conflict when going > > away from 16bit firmware on 32bit systems while staying with 32bit on > > a 64bit platform. > > this won't last very long here. 36 bits only gets us to 64 GB -- too > small. PAE is really has 64bit addresses in the page tables. Intel implements 36bits physical and AMD 40bits of physical address space. > LinuxBIOS has run in 64-bit mode on a 64-bit platform -- the alpha. I see > no real issue with going to 64-bit opteron mode. Neither do I. I have memory initialization working for all 64bits in 32bit physical mode, so it isn't needed at the moment. But there is a noticeable performance hit. Any dynamic page table based solution though needs to move out of romcc compiled code, and into the normal part of LinuxBIOS where we already have memory initialized. That's not a bad idea anyway given how slow it is to do memory writes over hypertransport before the link speed is configured up. > rno Eric From ebiederman at lnxi.com Tue Sep 16 13:30:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 16 13:30:01 2003 Subject: romcc fixes for AMD64 In-Reply-To: <20030916125559.GA1229@suse.de> References: <20030916125559.GA1229@suse.de> Message-ID: Stefan Reinauer writes: > Hi, > > with the attached fix romcc is able to compile all of auto.c > for the freebios2 amd64 targets. To keep all changes clean > and visible, they're encapsulated in ifdefs. > > Note: This fix alone does not make LinuxBIOS compile on AMD64 > completely yet. GCC and ld need the -m32 in some places at least > to compile everything. The -m32 can easily be added in the compiler over rides so that is simple enough. > Is there any need in going 64bit for the LinuxBIOS C payload > on Opteron? Since the kernel does long mode switching itself > this should not be the case, but maybe there are different > opinions. There is not any need yet. But there are certainly advantages. So far keeping it 32bit has made things simpler. Ideally I'd like to be able to do either. > Next fail I saw after romcc passed auto.c was the following: > /home/stepan/freebios2/src/superio/NSC/pc87360/superio.c:61: warning: > `pnp_read_enable' defined but not used > > /tmp/ccLriZXb.s: Assembler messages: > /tmp/ccLriZXb.s:243: Error: Incorrect register `%rdx' used with `l' suffix > /tmp/ccLriZXb.s:245: Error: Incorrect register `%rdx' used with `l' suffix > make: *** [superio.o] Error 1 Hmm. This looks like an inline assembler problem. Eric From ts1 at tsn.or.jp Tue Sep 16 14:08:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 16 14:08:00 2003 Subject: Help! with Linuxbios + EPIA 5000 + Etherboot In-Reply-To: <3F673F74.5070709@denkmair.de> References: <3F673F74.5070709@denkmair.de> Message-ID: <20030916182857.GA16827@tsn.or.jp> On Tue, Sep 16, 2003 at 06:51:00PM +0200, Hubert Denkmair wrote: > First of all there's no line "CFLAGS+= -DPCIBIOS" to comment out in the > etherboot-5.0.11 "Config" file - I assume it might be a typo in the > howto and commented out the line "CFLAGS+= -DPCBIOS", but it won't work. Yeah, it must be a typo. > --- > bin32/via-rhine.o(.text+0x2e8): In function `rhine_probe1': > : undefined reference to `currticks' > --- Perhaps you don't have the -DCONFIG_TSC_CURRTICKS option in the Config. > Opposing to etherboot-5.0 there are no linuxbios options so I suppose > they are not needed any more. The etherboot-5.2 package compiles fine > (I'm doing a "make bin/via-rhine.elf"). Etherboot 5.2 has another Config file in arch/i386 directory. You have to edit this file too. > Now, who can help be getting linuxbios/etherboot to work at all, or - > better: boot from local IDE? You might want to look at FILO: http://te.to/~ts1/filo/ for booting from local filesystem on IDE disk. -- Takeshi From linuxbios at xdr.com Tue Sep 16 16:22:00 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Tue Sep 16 16:22:00 2003 Subject: CVS not working, link to daily snapshot broken Message-ID: <200309162043.h8GKhmgi025491@xdr.com> http://www.linuxbios.org/developer/download/index.html cvs [checkout aborted]: recv() from server cvs.freebios.sourceforge.net: EOF cvs [checkout aborted]: recv() from server cvs.freebios.sourceforge.net: Connection reset by peer http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz Object not found! The requested URL was not found on this server. The link on the referring page seems to be wrong or outdated. Please inform the author of that page about the error. If you think this is a server error, please contact the webmaster Error 404 From pyro at linuxlabs.com Tue Sep 16 17:24:01 2003 From: pyro at linuxlabs.com (steven james) Date: Tue Sep 16 17:24:01 2003 Subject: USB Memory Key booting In-Reply-To: <20030916071545.GA3207@cma.co.jp> Message-ID: Greetings, Just getting caught up again. I have a more or less functional polling USB stack for UHCI controllers built on the baremetal toolkit. So far, it works on some devices but not others. I'm cleaning it up now, but should be able to get it in CVS in the next few days. G'day, sjames On Tue, 16 Sep 2003, SONE Takeshi wrote: > On Tue, Sep 16, 2003 at 11:12:44AM +0800, Andrew Ip wrote: > > I think we can take a look at u-boot which has USB storage access already. > > I've been interested in supporting USB storage (as well as keyboards) > in FILO, but I didn't know where to start. > I'm now looking at the sourcecode of u-boot, and I think this is what > I've been looking for. Thanks a lot, Andrew! > > -- > Takeshi > _______________________________________________ > 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 sven.luebke at mikrosol.de Tue Sep 16 18:06:01 2003 From: sven.luebke at mikrosol.de (Sven =?iso-8859-1?Q?L=FCbke?=) Date: Tue Sep 16 18:06:01 2003 Subject: LinuxBios + EPIA5000 + Win2k Bootloader + HD + VGA Message-ID: <5.1.1.6.2.20030916234456.01fc27e8@POP.RZ.FH-Wolfenbuettel.DE> Hi! I want to install LinuxBIOS on my EPIA5000 in combination with an IDE-Harddisk. The harddisk contains a Win2k bootloader which boots LiLo or Win2k. The VGA port on the EPIA board should be enabled! Is that combination possible/up-to-date at all? Which setup has the fastest boottime? I tried to compile LinuxBIOS with ADLO and Bochs, cause I don't want to use etherboot, but for some reason the computer didn't boot. I read all the FAQs and the "How to" for EPIA mainboards but it's not working anyway! Is ADLO able to boot the Win2k loader? Is someone using the same setup and has a config-file for me? Can someone help me? My goal is to boot Linux as fast as possible and sometimes (if I need it) switch to Win2k. Thank you for your help! Best regards, Sven From sc at flagen.com Tue Sep 16 18:18:00 2003 From: sc at flagen.com (David Hendricks) Date: Tue Sep 16 18:18:00 2003 Subject: EPIA-800 and VGA post LinuxBIOS init Message-ID: <34760.128.165.250.182.1063755427.squirrel@mail.flagen.com> I have successfully managed to boot an EPIA-800 board to a usable state using Steve Gehlback's VGA configuration, Etherboot, and a vanilla FreeBIOS tree. VGA comes up reliably every time I boot. However VGA output only appears until Etherboot jumps to my phase 1 beoboot image. What must be done to have VGA output after Etherboot loads my image? From rminnich at lanl.gov Tue Sep 16 20:47:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 20:47:01 2003 Subject: DoC on Eipa In-Reply-To: <20030917002109.A22911@mail.cwlinux.com> Message-ID: On Wed, 17 Sep 2003, Andrew Ip wrote: > More steps are required to init DDR. It might not fit > in 512 bytes. oops, I forgot the DDR nightmare. I think DoC is out for EPIA-M. ron From rminnich at lanl.gov Tue Sep 16 20:54:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 20:54:00 2003 Subject: Help! with Linuxbios + EPIA 5000 + Etherboot In-Reply-To: <3F673F74.5070709@denkmair.de> Message-ID: We've had no real luck building etherboot here lately. I'm not sure what's wrong, but we get the same problems you do. ron From rminnich at lanl.gov Tue Sep 16 21:10:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 16 21:10:01 2003 Subject: CVS not working, link to daily snapshot broken In-Reply-To: <200309162043.h8GKhmgi025491@xdr.com> Message-ID: Wow, I keep thinking sourceforge is fixed, and it keeps not being fixed. OK, I'll try to do something about this (again) ron From hansolofalcon at worldnet.att.net Tue Sep 16 23:41:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue Sep 16 23:41:01 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released In-Reply-To: <20030916160247.GA2778@suse.de> Message-ID: <000001c37cd0$ad7873e0$0100a8c0@who5> Hello (again) from Gregg C Levine Nice! And I am reporting an error of sorts. Here's a paste of the log from a script for the build process. For some reason its breaking towards the end, with regards to the dictionary that was created for booting from GRUB. Here, I'll post it: Script started on Tue Sep 16 23:52:05 2003 root at who3:/usr/src/openbios/kernel# make Welcome to OpenBIOS.. Creating build directory /usr/src/openbios/kernel/obj-x86 Checking types...found 32bit platform, creating "types.h" Building common core files for architecture x86 compiling primitives.c... ok compiling stack.c... ok compiling dict.c... ok compiling lib.c... ok compiling openbios.c... ok Building files for unix hosted bootstrap compiling unix.c... ok linking unix bootstrap... ok Bootstrapping dictionary... ok Building final dictionary... ok Building binary converter... ok Compiling x86 architecture specific binaries assembling mboot.S... ok compiling multiboot.c... ok assembling boot.S... ok compiling plainboot.c... ok generating linkable dictionary... ok compiling builtin.c... ok compiling console.c... ok Linking: native multiboot kernel for grub... /usr/src/openbios/kernel/obj-x86/dict.o: In function `load_dictionary': /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined reference to `strncmp' /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined reference to `memcpy' collect2: ld returned 1 exit status make[1]: *** [openbios.multiboot] Error 1 make: *** [x86] Error 2 root at who3:/usr/src/openbios/kernel# exit Script done on Tue Sep 16 23:52:47 2003 Any suggestions Stefan? Besides I like your ideas regarding the Open BIOS concepts. Incidentally for that project, can you put up the older versions of the /dev/bios files? Say, anything up to 3.*? ------------------- 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 Stefan Reinauer > Sent: Tuesday, September 16, 2003 12:03 PM > To: LinuxBIOS > Subject: [announce] OpenBIOS Forth Kernel V1.0 released > > Dear LinuxBIOS community, > > After some months of development I am happy to announce the new > OpenBIOS forth kernel "BeginAgain". > > It is available from the OpenBIOS CVS in the directory "kernel/" > or at http://www.openbios.org/bin/kernel-1.0.tar.bz2 > > Features > -------- > - indirect-threaded forth engine > - openfirmware user interface > - small and portable > - easily enhancable > > Platform Notes > -------------- > > Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth > kernel was developed using gcc on Linux systems. Minor changes might > be necessary in non-linux/gcc build environments. > > Design Goals > ------------ > > The design goals of "BeginAgain" were: > > 1) Portability > 2) Maintainability > 3) Small Size > > ---------------------------------------------------------------------- > > 1) Portability > > BeginAgain, with minimal changes, will work on new systems. There > is support for X86 and AMD64 at the moment. Implementing support > for new systems only requires adaptions to the start code and > system abstraction. The current code has been developed using gcc > 3.x, but no explicit GCCisms are used. Since gcc is the most > widely spread compiler, it should be a good base for easily porting > OpenBIOS to new platforms. > > 2) Maintainability > > The code is split into several parts: > > _________________________________________ > | | > | Forth dictionary | > |_________________________________________| > > ^ | forth code > ________|_________________________|_________ > | | > | v native code > _____________ ___________________ > | | | | > | Scheduler | ----> | primitive words | > |_____________| |___________________| > ^ ^ > | | > | | > _____________ ____________________ > | | | | > -->| Startup | | system abstraction | > |_____________| |____________________| > > > Platform dependent part > ----------------------- > > a) After taking control the "scheduler", in forth context called > "inner interpreter, reads the forth dictionary, a list of nested > word definitions that are built using primitive words. > > b) These primitive words are written in C, so they take advantage > of the compiler's ability to optimize code. They represent the > minimum set of forth words that are needed to define all language > constructs, including the Open Firmware system. > > c) The startup code is probably the most platform sensitive code. > It's task is simple - get the scheduler up and running and > provide a dictionary to execute. OpenBIOS provides multiple boot > targets per platform. For example, on x86 it is possible to run > the kernel either from Grub or LinuxBIOS. An additional target > (available on all platforms) allows running the code from a Unix > shell. > > d) The system abstraction part ought to be kept as small as > possible. The primary words provide an interface for > non-memory-mapped IO, and there's a small builtin console due to > the fact that OpenBIOS has no device tree and/or drivers at the > moment. > > > Once these platform dependent parts are in place, they can be used > to create an indirect-threaded dictionary file. This dictionary > file contains a platform abstracted version of forth code that > currently depends on the endianness and pointer (cell) size of the > target platform. > To keep the forth dictionary and the native code strictly seperate > the unix hosted version of the kernel has a small builtin > interpreter able to bootstrap all of the base system including a > forth written interpreter, which represents part of the > openfirmware user interface. > In a second stage the advanced forth written interpreter is used to > extend the bootstrap dictionary with additional features. As an > example, ANS forth wordlist support is added, which will be used in > the device tree code. > Currently the OpenBIOS dictionary contains a nearly complete > implementation of the Open Firmware user interface. It passes the > Hayes ANS Forth test suite that is run when OpenBIOS is built, > writing it's output to the file forth.html. > > Since the machine is abstracted as early and completly as possible, > porting OpenBIOS to a new platform requires only minor efforts. > > > 3) Small size > > The less code that needs to be adopted when porting OpenBIOS to a > new platform, the quicker new ports can happen. Therefore the > OpenBIOS kernel is really small. Here is a sample: > > size in | x86 | amd64 > bytes | gcc 3.3 | gcc 3.3.1 > -----------------+---------+---------------- > multiboot kernel | 6724 | 15464 > -----------------+---------+---------------- > LinuxBIOS kernel | 7016 | 15896 > -----------------+---------+---------------- > LinuxBIOS kernel | | > inc. dictionary | 27048 | 52920 > -------------------------------------------- > > > Installation and usage > ---------------------- > > Run "make" to compile all binaries and dictionaries required to run > the OpenBIOS kernel > $ make > Per default all binaries will be placed in the directory obj-{platform}. > > Then you can execute the kernel from a shell, by giving the command > $ make run > > To boot LinuxBIOS from GRUB, copy openbios.multiboot and > openfirmware.dict to /boot, then add a new entry to your > menu.lst config file which looks like this: > > -------------------- 8< -------------------- > title openbios > kernel (hd0,2)/boot/openbios.multiboot > module (hd0,2)/boot/openfirmware.dict > -------------------- 8< -------------------- > > (hd0,2) is the equivalent to the Linux partition /dev/hda3 > > OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org) or > booted in EtherBoot (www.etherboot.org). The simplest way is to use > the kernel that includes the full dictionary: openbios.full > > Bug reports > ----------- > > Any trouble, bugs etc. should be reported to the openbios mailinglist > > > Further Development > ------------------- > > BeginAgain is pretty much complete now. Expect only bugfixes and > optimizations in the future. Interpretation mode versions of most loop > constructs should be included although they are not really needed to > get more development going. The next steps in writing an Open Firmware > implementation is to complete the Device and Client Interfaces. These > two parts are needed to set up a device tree, initialize hardware, and > boot the operating system. Once there is a device tree and some basic > device interface functions it will be possible to run fcode drivers > for device initialization in OpenBIOS, using the FCode evaluator that > resides in the OpenBIOS CVS directory forth/evaluator/. > > Regards, > Stefan > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From ts1 at cma.co.jp Wed Sep 17 02:42:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 17 02:42:00 2003 Subject: LinuxBios + EPIA5000 + Win2k Bootloader + HD + VGA In-Reply-To: <5.1.1.6.2.20030916234456.01fc27e8@POP.RZ.FH-Wolfenbuettel.DE> References: <5.1.1.6.2.20030916234456.01fc27e8@POP.RZ.FH-Wolfenbuettel.DE> Message-ID: <20030917070335.GA8936@cma.co.jp> On Wed, Sep 17, 2003 at 12:26:33AM +0200, Sven L?bke wrote: > I want to install LinuxBIOS on my EPIA5000 in combination with > an IDE-Harddisk. The harddisk contains a Win2k bootloader > which boots LiLo or Win2k. The VGA port on the EPIA board should > be enabled! Is that combination possible/up-to-date at all? Which > setup has the fastest boottime? I would rather use a BIOS Saviour to switch between LinuxBIOS (fast linux-only boot) and the factory BIOS (compatible boot). ADLO is not stable yet and the legacy boot loaders are slow anyway. -- Takeshi From ts1 at cma.co.jp Wed Sep 17 03:06:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 17 03:06:01 2003 Subject: EPIA-800 and VGA post LinuxBIOS init In-Reply-To: <34760.128.165.250.182.1063755427.squirrel@mail.flagen.com> References: <34760.128.165.250.182.1063755427.squirrel@mail.flagen.com> Message-ID: <20030917072704.GB8936@cma.co.jp> On Tue, Sep 16, 2003 at 04:37:07PM -0700, David Hendricks wrote: > I have successfully managed to boot an EPIA-800 board to a usable state > using Steve Gehlback's VGA configuration, Etherboot, and a vanilla > FreeBIOS tree. VGA comes up reliably every time I boot. However VGA output > only appears until Etherboot jumps to my phase 1 beoboot image. > > What must be done to have VGA output after Etherboot loads my image? It's working for me, VGA is up all the way LinuxBIOS + SG patch --> FILO --> Linux. However, framebuffer (epiafb) doesn't work well, and TV-out doesn't work either even if it is re-programmed by tvtool or tvout. -- Takeshi From ts1 at cma.co.jp Wed Sep 17 03:07:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 17 03:07:00 2003 Subject: USB Memory Key booting In-Reply-To: References: <20030916071545.GA3207@cma.co.jp> Message-ID: <20030917072841.GC8936@cma.co.jp> On Tue, Sep 16, 2003 at 05:44:31PM -0400, steven james wrote: > Just getting caught up again. I have a more or less functional polling USB > stack for UHCI controllers built on the baremetal toolkit. So far, it > works on some devices but not others. That sounds great. I would love to see this code. -- Takeshi From niki.waibel at newlogic.com Wed Sep 17 03:26:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 03:26:01 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <200309170747.h8H7l6ZS015555@enterprise2.newlogic.at> >> i think that the CLE266 (epia-m) is quite different then the vt8601. >> right now i've no idea about northbringes, but i hope that will change soon :) > > doubtful, I have found lots of reuse of cores in these norhtbridges. But > I'm willing to be convinced :-) > >> where did the ppl (who have written all the ipl.S files) got the >> information from? > > I wrote it. I got info from VIA. They were quite helpful about it. so you know some guys at via already. may you ask them if the same code could be use in a cle266? or (if not) how that northbridge can be initialized? niki From niki.waibel at newlogic.com Wed Sep 17 03:37:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 03:37:00 2003 Subject: funny idea Message-ID: <200309170758.h8H7w7ZS016844@enterprise2.newlogic.at> hi, i just had a funny idea... what about haveing bios savior + DoC in a mb _and_ connecting the bios savior switch to an address pin... that way it should be possible to have enough room in the bios savior rom for doing everything. then the DoC could be activated... i think that booting should start with the internal bios savior chip (with linuxbios). and then, at some stage (all init of mem and copying of bios savior rom done) the switch is "activated" (by a read of some address or sthg). then a copy of the DoC is done ... what do you think? niki From niki.waibel at newlogic.com Wed Sep 17 03:49:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 03:49:00 2003 Subject: DoC on Eipa In-Reply-To: Message-ID: <200309170810.h8H8AaZS018621@enterprise2.newlogic.at> >> More steps are required to init DDR. It might not fit >> in 512 bytes. > > oops, I forgot the DDR nightmare. I think DoC is out for EPIA-M. what is so complex with ddr? could you send me / point me to some more info about init a ddr? or ask the guys at via? niki From aip at cwlinux.com Wed Sep 17 04:02:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Sep 17 04:02:01 2003 Subject: DoC on Eipa In-Reply-To: <200309170810.h8H8AaZS018621@enterprise2.newlogic.at>; from Niki Waibel on Wed, Sep 17, 2003 at 10:10:36AM +0200 References: <200309170810.h8H8AaZS018621@enterprise2.newlogic.at> Message-ID: <20030917162307.B3224@mail.cwlinux.com> Hi Niki, > what is so complex with ddr? > could you send me / point me to some more info about init a ddr? > or ask the guys at via? It is the hardware limitation since the ddr init code probably does not fit in ipl area of DOC which is only 512byte . -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From niki.waibel at newlogic.com Wed Sep 17 04:08:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 04:08:00 2003 Subject: DoC on Eipa In-Reply-To: <20030917162307.B3224@mail.cwlinux.com> Message-ID: <200309170829.h8H8TEZS020629@enterprise2.newlogic.at> >> what is so complex with ddr? >> could you send me / point me to some more info about init a ddr? >> or ask the guys at via? > It is the hardware limitation since the ddr init code probably does > not fit in ipl area of DOC which is only 512byte . yes. i got the point. but to be sure we need to know _how_ a ddr is initialized. so the question is -- who knows how to init a ddr? niki From aip at cwlinux.com Wed Sep 17 04:13:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Sep 17 04:13:01 2003 Subject: DoC on Eipa In-Reply-To: <200309170829.h8H8TEZS020629@enterprise2.newlogic.at>; from Niki Waibel on Wed, Sep 17, 2003 at 10:29:13AM +0200 References: <20030917162307.B3224@mail.cwlinux.com> <200309170829.h8H8TEZS020629@enterprise2.newlogic.at> Message-ID: <20030917163354.C3224@mail.cwlinux.com> Hi Niki, > yes. i got the point. but to be sure we need to know _how_ a ddr > is initialized. so the question is -- who knows how to init a ddr? It is already checked in. Checkout the memory init code under vt8623. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From ts1 at cma.co.jp Wed Sep 17 04:18:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Wed Sep 17 04:18:01 2003 Subject: funny idea In-Reply-To: <200309170758.h8H7w7ZS016844@enterprise2.newlogic.at> References: <200309170758.h8H7w7ZS016844@enterprise2.newlogic.at> Message-ID: <20030917083924.GA11888@cma.co.jp> On Wed, Sep 17, 2003 at 09:58:07AM +0200, Niki Waibel wrote: > what about haveing bios savior + DoC in a mb _and_ > connecting the bios savior switch to an address pin... > > that way it should be possible to have enough room > in the bios savior rom for doing everything. then > the DoC could be activated... > > i think that booting should start with the internal > bios savior chip (with linuxbios). and then, at some > stage (all init of mem and copying of bios savior rom done) > the switch is "activated" (by a read of some address or sthg). If you connect the switch to A18, you can have the ROM at 4G-256K (it's where the ROM resides normally) and the DoC at 4G-512K (or vice versa)...? I don't know if it really works but if it does, you can have existing LinuxBIOS code in the ROM and configure it to load kernel from the DoC. However I don't know what the advantage of it compaired to the IDE-CF configuration. -- Takeshi From niki.waibel at newlogic.com Wed Sep 17 04:36:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 04:36:01 2003 Subject: DoC on Eipa In-Reply-To: <20030917163354.C3224@mail.cwlinux.com> Message-ID: <200309170856.h8H8utZS024449@enterprise2.newlogic.at> >> who knows how to init a ddr? > It is already checked in. Checkout the memory init code under > vt8623. ok. this means that vt8623 == cle266? From RGrosseBoerger at dspace.de Wed Sep 17 04:42:00 2003 From: RGrosseBoerger at dspace.de (=?ISO-8859-1?Q?Ralf_Gro=DFe_B=F6rger?=) Date: Wed Sep 17 04:42:00 2003 Subject: solo + SST49LF080A Message-ID: <84257D042AA7D411B3F700D0B7DB9B7C0670730D@PDC-DSPACE> Hi, I am seeing strange effects, if I am using LinuxBIOS in a SST49LF080A on a solo system. The same LinuxBIOS image(256KB) works flawless with a SST49LF040 or the preinstalled Winbond chip, but it gets stuck somewhere in setup_resource_map with the SST49LF080A. On the other hand, the preinstalled Pheonix BIOS boots from a SST49LF080A without a problem. A quick look into the datasheets of both SST chips revealed a slight difference: The SST49LF080A decodes the bottom 128 KB memory access address (0x000FFFFF to 0x000E0000) only, whereas the SST49LF040 decodes the complete 512KB memory area (0x000FFFFF to 0x0007FFFF). Does this pose any problems for LinuxBIOS? Or has anyone else made experiences with the SST49LF080A? There has been a thread about sporadic problems, but I can reproduce this behaviour with several SST49LF080A and I'm quite sure the chip is flashed correctly. Best regards Ralf From linuxbios at denkmair.de Wed Sep 17 05:13:00 2003 From: linuxbios at denkmair.de (Hubert Denkmair) Date: Wed Sep 17 05:13:00 2003 Subject: Help! with Linuxbios + EPIA 5000 + Etherboot In-Reply-To: <3F673F74.5070709@denkmair.de> References: <3F673F74.5070709@denkmair.de> Message-ID: <3F682A9E.1010600@denkmair.de> Thank you for your answers, I'm using filo now and although it doesn't work yet, I'm definitely gettig ahead :-) Hubert From niki.waibel at newlogic.com Wed Sep 17 05:52:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 17 05:52:01 2003 Subject: damaged DoC MD2808-D08? Message-ID: <200309171013.h8HAD9ZS003979@enterprise2.newlogic.at> my DoC MD2808-D08 responds fine to the control registers (chipid and ecc toggle bit are ok i.e.). but if it comes to the stage of sending nand commands and reading memory it seems to do nothing. if mem is read from the same IO reg (0x800) then i always get the same value (0x55). also if the nand ID command is sent, 0x800 responses with 0x55. 0x55 is the beginning of 0x55 0xaa 0x10 0xeb which is the beginning of the IPL code (rom extension)... in addition if i read a page. and then read it again. i get some different bytes: === --- xxx.xxd 2003-09-17 12:01:44.615883064 +0200 +++ xxx2.xxd 2003-09-17 12:01:44.629880936 +0200 @@ -1,67 +1,67 @@ 0000000: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst 0000010: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... 0000020: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... -0000030: 0000 0000 8001 9400 0000 0000 8181 8181 ................ +0000030: 0000 0000 8001 9400 0000 0000 8181 98e6 ................ 0000040: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. -0000050: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... +0000050: 8ec0 33ff 83c2 408e da81 fa00 439a 8181 ..3... at .....C... 0000060: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0075 ........u......u -0000070: 021e 0747 83ff 3072 8181 8181 8181 98e6 ...G..0r........ +0000070: 021e 0747 83ff 3072 8181 98e6 439a 8181 ...G..0r....C... 0000080: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. 0000090: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. 00000a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F -00000b0: 048e d8bb 0000 c687 439a 0081 8181 8198 ........C....... +00000b0: 048e d8bb 0000 c687 0381 0081 8181 8181 ................ 00000c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. -00000d0: b100 e855 002e 8b0e e643 9a81 8181 8181 ...U.....C...... +00000d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ 00000e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. -00000f0: 8814 8834 8181 8181 8181 8181 8181 8198 ...4............ +00000f0: 8898 8834 e643 9a81 8181 8198 e643 9a81 ...4.C.......C.. 0000100: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. 0000110: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. 0000120: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ -0000130: 0cc6 871e 1000 c687 0410 09f6 e643 9a81 .............C.. +0000130: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ 0000140: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... -0000150: 8704 1080 74f9 f687 2010 80f6 8181 8198 ....t... ....... -0000160: c31c 0000 0000 0000 0000 0000 e600 439a ..............C. -0000170: 0000 0000 0000 8181 8181 8181 8181 8181 ................ +0000150: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... +0000160: c31c 0000 0000 0000 0000 0000 0000 8181 ................ +0000170: 0000 0000 8181 0000 8181 8181 8181 8198 ................ 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00001b0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ +00001b0: 0000 0000 0000 0000 e643 9a81 8181 8198 .........C...... 00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00001d0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... -00001e0: 0000 0000 0000 0000 0000 0000 8181 98e6 ................ -00001f0: 0000 0000 439a 8181 8181 8181 8181 8181 ....C........... +00001d0: 0000 0000 0000 0000 e643 9a81 8181 8181 .........C...... +00001e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ +00001f0: 8100 0000 8181 8181 8181 8181 8181 9898 ................ 0000200: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst 0000210: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... 0000220: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... -0000230: 0000 0000 8001 9400 0000 0000 8181 8181 ................ +0000230: 0000 0000 8001 9400 0000 0000 439a 8181 ............C... 0000240: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. -0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... -0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 8175 ........u......u -0000270: 021e 0747 83ff 3072 8198 e643 9a81 8181 ...G..0r...C.... +0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 98e6 ..3... at ......... +0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0043 ........u......C +0000270: 021e 0747 83ff 3072 9a81 8181 8181 8181 ...G..0r........ 0000280: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. 0000290: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. 00002a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F -00002b0: 048e d8bb 0000 c687 0381 98e6 439a 8181 ............C... +00002b0: 048e d8bb 0000 c687 8181 8181 8181 8181 ................ 00002c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. -00002d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ -00002e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. -00002f0: 8814 8881 8181 8181 8198 e643 9a81 8181 ...........C.... +00002d0: b100 e855 002e 8b0e 8181 8181 8198 e643 ...U...........C +00002e0: 7523 c687 0410 0d2e 8b16 1c00 9a81 8181 u#.............. +00002f0: 8814 8834 8198 e643 9a81 8181 8181 8181 ...4...C........ 0000300: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. 0000310: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. 0000320: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ -0000330: 0cc6 871e 1000 c687 0410 09f6 8198 e643 ...............C +0000330: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ 0000340: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... -0000350: 8704 1080 74f9 f687 2010 80f6 9a81 8181 ....t... ....... -0000360: c31c 0000 0000 0000 0000 0000 8100 0081 ................ -0000370: 0000 0000 8100 8181 8181 8181 8181 8181 ................ +0000350: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... +0000360: c31c 0000 0000 0000 0000 0000 0081 8181 ................ +0000370: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... 0000380: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000390: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00003b0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. +00003b0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... 00003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00003d0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. +00003d0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ 00003e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ -00003f0: 0000 8100 8181 8181 8181 8181 8181 8181 ................ +00003f0: 8181 0000 8181 8181 98e6 439a 8181 8181 ..........C..... 0000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................ === that data was read by === cmd(bios, NAND_CMD_READ0); adr(bios, page); doc_read_nop(bios); /* nop between write/read */ doc_write_cdsncontrol(bios, CDSN_CTRL_CE); doc_read(bios, ReadPipelineInitialization); for(i=0; i<512-1; i++) { doc_read_4nop(bios); doc_read(bios, CDSNSlowIO); doc_read_4nop(bios); buf[offset++] = doc_read(bios, _CDSNIO_BASE+i); doc_read_4nop(bios); } buf[offset++] = doc_read(bios, LastDataRead); doc_write_cdsncontrol(bios, CDSN_CTRL_CE); if(doc_wait(bios, 5000)) { printf("outch...\n"); return(-1); } === if i read without CDSNSlowIO and without doc_read_4nop(bios) then the result is worse and more bits/bytes are different each read. if i read doc_read(bios, _CDSNIO_BASE) (***check the missing ``+ i''***) then i get 0x55 all the time (except for doc_read(bios, LastDataRead)). all this is very strange and i am beginning to think that my DoC (the flash in it) is damaged. any idea? niki w. waibel From stepan at suse.de Wed Sep 17 06:57:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 17 06:57:00 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released In-Reply-To: <000001c37cd0$ad7873e0$0100a8c0@who5> References: <20030916160247.GA2778@suse.de> <000001c37cd0$ad7873e0$0100a8c0@who5> Message-ID: <20030917111829.GE5467@suse.de> * Gregg C Levine [030917 06:03]: > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined > reference to `strncmp' > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined > reference to `memcpy' Ups. What gcc version are you using? Can you try compiling with -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions. > Any suggestions Stefan? Besides I like your ideas regarding the Open > BIOS concepts. Incidentally for that project, can you put up the older > versions of the /dev/bios files? Say, anything up to 3.*? All old versions I have lying around are in http://www.openbios.info/bin/ Do you need some particular code? The CVS version should be better in most cases. Stefan -- Architecture Team SuSE Linux AG From hansolofalcon at worldnet.att.net Wed Sep 17 07:02:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed Sep 17 07:02:01 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released In-Reply-To: <20030917111829.GE5467@suse.de> Message-ID: <000b01c37d0e$39e18140$0100a8c0@who5> Hello (again) from Gregg C Levine Okay, I knew you'd ask that question, when I sent that bug report off. But forgot to include this in the first message. Version of GCC=2.9.5.3, short version of binary utilities 2.10, and they were built for I386, for Slackware Linux. I'll try adding that to the section for the C Flags in the make file. ------------------- 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: Stefan Reinauer [mailto:stepan at suse.de] > Sent: Wednesday, September 17, 2003 7:18 AM > To: Gregg C Levine > Cc: 'LinuxBIOS' > Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released > > * Gregg C Levine [030917 06:03]: > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined > > reference to `strncmp' > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined > > reference to `memcpy' > > Ups. What gcc version are you using? Can you try compiling with > -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions. > > > Any suggestions Stefan? Besides I like your ideas regarding the Open > > BIOS concepts. Incidentally for that project, can you put up the older > > versions of the /dev/bios files? Say, anything up to 3.*? > > All old versions I have lying around are in > http://www.openbios.info/bin/ > > Do you need some particular code? The CVS version should be better in > most cases. > > Stefan > > -- > Architecture Team > SuSE Linux AG From stepan at suse.de Wed Sep 17 09:06:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 17 09:06:00 2003 Subject: solo + SST49LF080A In-Reply-To: <84257D042AA7D411B3F700D0B7DB9B7C0670730D@PDC-DSPACE> References: <84257D042AA7D411B3F700D0B7DB9B7C0670730D@PDC-DSPACE> Message-ID: <20030917132752.GA6406@suse.de> * Ralf Gro?e B?rger [030917 12:03]: > I am seeing strange effects, if I am using LinuxBIOS in a SST49LF080A on a > solo system. > The same LinuxBIOS image(256KB) works flawless with a SST49LF040 or the > preinstalled Winbond chip, but it gets stuck somewhere in setup_resource_map > with the SST49LF080A. setup_resource_map is kind of sensitive. It does also hang when LinuxBIOS is used without the failsafe mechanism. This code from amd8111_enable_rom.c blends in the complete address space at 4G-4MB /* Enable 4MB rom access at 0xFFC00000 - 0xFFFFFFFF */ /* Locate the amd8111 */ addr = pci_locate_device(PCI_ID(0x1022, 0x7468), 0); /* Set the 4MB enable bit bit */ byte = pci_read_config8(addr, 0x43); byte |= 0x80; pci_write_config8(addr, 0x43, byte); > On the other hand, the preinstalled Pheonix BIOS boots from a SST49LF080A > without a problem. > > A quick look into the datasheets of both SST chips revealed a slight > difference: The SST49LF080A decodes the bottom 128 KB memory access address > (0x000FFFFF to 0x000E0000) only, whereas the SST49LF040 decodes the complete > 512KB memory area (0x000FFFFF to 0x0007FFFF). > Does this pose any problems for LinuxBIOS? I am not sure whether this causes the problem. The Datasheet says: ----------------------- Device #0 - 3 Memory Access FFFF FFFFH : FFC0 0000H 4 MByte Register Access FFBF FFFFH : FF80 0000H 4 MByte For device #0 (Boot Device), SST49LF080A decodes the physical addresses of the top 2 blocks (including Boot Block) both at system memory ranges FFFF FFFFH to FFFE 0000H and 000F FFFFH to 000E 0000H. ----------------------- So it looks like only the 1MB-128k range is partly decoded, but the upper range, which is used for the kernel, is fully visible Does maybe the Solo motherboard lack some wires to physically see all of the chip? > Or has anyone else made experiences with the SST49LF080A? > There has been a thread about sporadic problems, but I can reproduce this > behaviour with several SST49LF080A and I'm quite sure the chip is flashed > correctly. The sporadic problems were mostly about writing the flash iirc. Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Wed Sep 17 09:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 17 09:15:01 2003 Subject: funny idea In-Reply-To: <200309170758.h8H7w7ZS016844@enterprise2.newlogic.at> Message-ID: On Wed, 17 Sep 2003, Niki Waibel wrote: > what about haveing bios savior + DoC in a mb _and_ > connecting the bios savior switch to an address pin... which address pin? where are you going to find it? I've not had good luck with adding wires to these boards -- we've done it (see the web page) but it's rarely possible. > what do you think? sorry, but I think it is impractical on anything other than onesy-twosy scale. Maybe not even that. ron From rminnich at lanl.gov Wed Sep 17 09:16:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 17 09:16:01 2003 Subject: DoC on Eipa In-Reply-To: <200309170829.h8H8TEZS020629@enterprise2.newlogic.at> Message-ID: On Wed, 17 Sep 2003, Niki Waibel wrote: > yes. i got the point. but to be sure we need to know _how_ a ddr > is initialized. so the question is -- who knows how to init a ddr? we do. It's all over the newer mobos. ron From rminnich at lanl.gov Wed Sep 17 09:16:05 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 17 09:16:05 2003 Subject: DoC on Eipa In-Reply-To: <200309170810.h8H8AaZS018621@enterprise2.newlogic.at> Message-ID: On Wed, 17 Sep 2003, Niki Waibel wrote: > could you send me / point me to some more info about init a ddr? look at the linuxbios ddr code ;-) ron From sc at flagen.com Wed Sep 17 15:13:00 2003 From: sc at flagen.com (David Hendricks) Date: Wed Sep 17 15:13:00 2003 Subject: Question about PCX support Message-ID: <35964.128.165.250.182.1063830785.squirrel@mail.flagen.com> In the vga_load_pcx.c file, it says: // This routine supports variable width and height but the default // for linuxbios is 640 x 400 pixels. Is that 400 a typo? It seems like it should be 640 x 480. From steve at nexpath.com Wed Sep 17 16:05:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Sep 17 16:05:00 2003 Subject: Question about PCX support In-Reply-To: <35964.128.165.250.182.1063830785.squirrel@mail.flagen.com> References: <35964.128.165.250.182.1063830785.squirrel@mail.flagen.com> Message-ID: <3F68C5A1.2010707@nexpath.com> David Hendricks wrote: > In the vga_load_pcx.c file, it says: > // This routine supports variable width and height but the default > // for linuxbios is 640 x 400 pixels. > > Is that 400 a typo? It seems like it should be 640 x 480. > Well it is not a typo, but it may be implemented off standard. The setting really is 640 x 400. The idea was to match the character display setting. Maybe that is non-traditional for graphics. The character display is 640 x 400 since it is 80 x 25 characters using an 8 x 16 pixel font. And I think that is traditional MDA compatible alpha mode 7. It is possible to change it to 640 x 480 and change the pcx file, but the gmode implementation would need some registers changed. I was lazy and it did not seem that important. -Steve From jknight at oceansuit.com Wed Sep 17 16:17:01 2003 From: jknight at oceansuit.com (Jeffrey Knight) Date: Wed Sep 17 16:17:01 2003 Subject: Thinkpad 440BX bios Message-ID: <0EC5CFFA-E94F-11D7-95BB-000393991A6A@oceansuit.com> Hi I noticed on the linuxbios site that there was some suceess with linuxBIOS on an IBM T22 thinkpad. Nice! Was this done using Intel's phlash utilities, or did did it require some disk-on-chip hardware work? If the installation was pretty smooth, I was thinking of trying it on a 385XD thinkpad. Any advice ? Jeff From rminnich at lanl.gov Wed Sep 17 16:44:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 17 16:44:01 2003 Subject: Thinkpad 440BX bios In-Reply-To: <0EC5CFFA-E94F-11D7-95BB-000393991A6A@oceansuit.com> Message-ID: On Wed, 17 Sep 2003, Jeffrey Knight wrote: > I noticed on the linuxbios site that there was some suceess with > linuxBIOS on an IBM T22 thinkpad. Nice! no, sorry, there was only failure. IBM (Thinkpad division) has no interest in linuxbios. > If the installation was pretty smooth, I was thinking of trying it on a > 385XD thinkpad. Any advice ? buy the lindows laptop and try that instead. ron From hansolofalcon at worldnet.att.net Wed Sep 17 17:37:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed Sep 17 17:37:00 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released In-Reply-To: <20030917111829.GE5467@suse.de> Message-ID: <001401c37d66$e7005240$0100a8c0@who5> Hello (again) from Gregg C Levine Okay, by adding that flag to the flags region of the make file, made it work, sort of. Now the explosion happens when the process reaches the steps for creating an image for working with our project here, Linux BIOS, that's where it happens, something to do with the strip command. GCC is still 2.9.5.3, and binary utilities are still 2.11.90.0.19, (my mistake), below this will be my script file, (cut and paste): Script started on Wed Sep 17 13:21:21 2003 root at who3:/usr/src/openbios/kernel# make Welcome to OpenBIOS.. Creating build directory /usr/src/openbios/kernel/obj-x86 Checking types...found 32bit platform, creating "types.h" Building common core files for architecture x86 compiling primitives.c... ok compiling stack.c... ok compiling dict.c... ok compiling lib.c... ok compiling openbios.c... ok Building files for unix hosted bootstrap compiling unix.c... ok linking unix bootstrap... ok Bootstrapping dictionary... ok Building final dictionary... ok Building binary converter... ok Compiling x86 architecture specific binaries assembling mboot.S... ok compiling multiboot.c... ok assembling boot.S... ok compiling plainboot.c... ok generating linkable dictionary... ok compiling builtin.c... ok compiling console.c... ok Linking: native multiboot kernel for grub... ok native kernel (for LinuxBIOS)... ok Usage: strip in-file(s) The switches are: -I --input-target Assume input file is in format -O --output-target Create an output file in format -F --target Set both input and output format to -p --preserve-dates Copy modified/access timestamps to the output -R --remove-section Remove section from the output -s --strip-all Remove all symbol and relocation information -g -S --strip-debug Remove all debugging symbols --strip-unneeded Remove all symbols not needed by relocations -N --strip-symbol Do not copy symbol -K --keep-symbol Only copy symbol -x --discard-all Remove all non-global symbols -X --discard-locals Remove any compiler-generated symbols -v --verbose List all object files modified -V --version Display this program's version number -h --help Display this output -o Place stripped output into strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core make[1]: *** [openbios] Error 1 make: *** [x86] Error 2 root at who3:/usr/src/openbios/kernel# exit Script done on Wed Sep 17 13:23:00 2003 Stefan your guess is as good as mine, as to what happened here. For /dev/bios, I found that the version you have there, tended to cause an oops, with my system tools, I'll grab it again, and try it. Basically the earlier ones, 2.9 for example, worked. This is before your site migrated to its present home. Oh and Ron, thank you for quoting me. It makes me feel better to see that happen. ------------------- 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: Stefan Reinauer [mailto:stepan at suse.de] > Sent: Wednesday, September 17, 2003 7:18 AM > To: Gregg C Levine > Cc: 'LinuxBIOS' > Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released > > * Gregg C Levine [030917 06:03]: > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined > > reference to `strncmp' > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined > > reference to `memcpy' > > Ups. What gcc version are you using? Can you try compiling with > -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions. > > > Any suggestions Stefan? Besides I like your ideas regarding the Open > > BIOS concepts. Incidentally for that project, can you put up the older > > versions of the /dev/bios files? Say, anything up to 3.*? > > All old versions I have lying around are in > http://www.openbios.info/bin/ > > Do you need some particular code? The CVS version should be better in > most cases. > > Stefan > > -- > Architecture Team > SuSE Linux AG From hansolofalcon at worldnet.att.net Wed Sep 17 20:52:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed Sep 17 20:52:00 2003 Subject: [announce] OpenBIOS Forth Kernel V1.0 released In-Reply-To: <001401c37d66$e7005240$0100a8c0@who5> Message-ID: <000001c37d82$268cfba0$0100a8c0@who5> Hello (again) from Gregg C Levine Stefan, it looks as if I was right. The version that's on your site, does cause an oops, here it is: invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: c2861e4a ebx: c2860000 ecx: c2860000 edx: c2861e40 esi: 00000000 edi: c2860000 ebp: c1781fbc esp: c1781f1c ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 1317, stackpage=c1781000) Stack: c2860000 c28600f5 c0117625 c1780000 40020a40 bfffcabc c011dbaa c2860000 00004c30 00004664 c09cf000 00000060 c0367000 ffffffea 00000004 c1da093c 00000060 c285d000 c2860060 00004c30 00000000 00000000 00000000 00000000 Call Trace: [] [] [] [] [] Code: 0f 45 c2 50 68 60 1e 86 c2 e8 e0 67 8b fd e8 ab 75 95 fd 83 I suspect that the module, is causing insmod to have a bad time. Here's the decoded one: ksymoops 2.4.9 on i586 2.4.21. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.21/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __ide_do_rw_disk_R__ver___ide_do_rw_disk not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_build_dmatable_R__ver_ide_build_dmatable not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_destroy_dmatable_R__ver_ide_destroy_dmatable not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_dma_intr_R__ver_ide_dma_intr not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_get_best_pio_mode_R__ver_ide_get_best_pio_mode not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_pci_register_driver_R__ver_ide_pci_register_driver not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_pci_unregister_driver_R__ver_ide_pci_unregister_driver not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_pio_timings_R__ver_ide_pio_timings not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_set_xfer_rate_R__ver_ide_set_xfer_rate not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_setup_dma_R__ver_ide_setup_dma not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_setup_pci_device_R__ver_ide_setup_pci_device not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol ide_setup_pci_devices_R__ver_ide_setup_pci_devices not found in System.map. Ignoring ksyms_base entry invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: c2861e4a ebx: c2860000 ecx: c2860000 edx: c2861e40 esi: 00000000 edi: c2860000 ebp: c1781fbc esp: c1781f1c ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 1317, stackpage=c1781000) Stack: c2860000 c28600f5 c0117625 c1780000 40020a40 bfffcabc c011dbaa c2860000 00004c30 00004664 c09cf000 00000060 c0367000 ffffffea 00000004 c1da093c 00000060 c285d000 c2860060 00004c30 00000000 00000000 00000000 00000000 Call Trace: [] [] [] [] [] Code: 0f 45 c2 50 68 60 1e 86 c2 e8 e0 67 8b fd e8 ab 75 95 fd 83 >>EIP; c2860072 <[bios]__module_license+a/88> <===== >>eax; c2861e4a <[bios].rodata.start+2a/120> >>ebx; c2860000 <[bios]__module_kernel_version+0/16> >>ecx; c2860000 <[bios]__module_kernel_version+0/16> >>edx; c2861e40 <[bios].rodata.start+20/120> >>edi; c2860000 <[bios]__module_kernel_version+0/16> >>ebp; c1781fbc <_end+1490fa0/2514fe4> >>esp; c1781f1c <_end+1490f00/2514fe4> Trace; c28600f5 <[bios]init_module+5/8> Trace; c0117625 Trace; c011dbaa Trace; c2860060 <[bios]bios_init+0/0> Trace; c0108973 Code; c2860072 <[bios]__module_license+a/88> 0000000000000000 <_EIP>: Code; c2860072 <[bios]__module_license+a/88> <===== 0: 0f 45 c2 cmovne %edx,%eax <===== Code; c2860075 <[bios]__module_license+d/88> 3: 50 push %eax Code; c2860076 <[bios]__module_license+e/88> 4: 68 60 1e 86 c2 push $0xc2861e60 Code; c286007b <[bios]__module_license+13/88> 9: e8 e0 67 8b fd call fd8b67ee <_EIP+0xfd8b67ee> c0116860 Code; c2860080 <[bios]__module_license+18/88> e: e8 ab 75 95 fd call fd9575be <_EIP+0xfd9575be> c01b7630 Code; c2860085 <[bios]__module_license+1d/88> 13: 83 00 00 addl $0x0,(%eax) 13 warnings issued. Results may not be reliable. I don't know what ksymoops means about the last line, but its all there. Everything is as I last posted regarding the kernel project program. Other then the peculiar complaint from strip it works. Ron, if your curious, that's from the latest version of Stefan's /dev/bios module. Why it compiles, but promptly throws that, is why I'm here. If you want, I'll switch to any other methods of communicating with Stefan. ------------------- 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 Gregg C Levine > Sent: Wednesday, September 17, 2003 5:59 PM > To: 'Stefan Reinauer' > Cc: 'LinuxBIOS' > Subject: RE: [announce] OpenBIOS Forth Kernel V1.0 released > > Hello (again) from Gregg C Levine > Okay, by adding that flag to the flags region of the make file, made > it work, sort of. Now the explosion happens when the process reaches > the steps for creating an image for working with our project here, > Linux BIOS, that's where it happens, something to do with the strip > command. GCC is still 2.9.5.3, and binary utilities are still > 2.11.90.0.19, (my mistake), below this will be my script file, (cut > and paste): > Script started on Wed Sep 17 13:21:21 2003 > root at who3:/usr/src/openbios/kernel# make > > Welcome to OpenBIOS.. > > Creating build directory /usr/src/openbios/kernel/obj-x86 > Checking types...found 32bit platform, creating "types.h" > > Building common core files for architecture x86 > compiling primitives.c... ok > compiling stack.c... ok > compiling dict.c... ok > compiling lib.c... ok > compiling openbios.c... ok > > Building files for unix hosted bootstrap > compiling unix.c... ok > linking unix bootstrap... ok > > Bootstrapping dictionary... ok > Building final dictionary... ok > Building binary converter... ok > > Compiling x86 architecture specific binaries > assembling mboot.S... ok > compiling multiboot.c... ok > assembling boot.S... ok > compiling plainboot.c... ok > generating linkable dictionary... ok > compiling builtin.c... ok > compiling console.c... ok > > Linking: > native multiboot kernel for grub... ok > native kernel (for LinuxBIOS)... ok > Usage: strip in-file(s) > The switches are: > -I --input-target Assume input file is in format > > -O --output-target Create an output file in format > > -F --target Set both input and output format to > > -p --preserve-dates Copy modified/access timestamps to > the output > -R --remove-section Remove section from the > output > -s --strip-all Remove all symbol and relocation > information > -g -S --strip-debug Remove all debugging symbols > --strip-unneeded Remove all symbols not needed by > relocations > -N --strip-symbol Do not copy symbol > -K --keep-symbol Only copy symbol > -x --discard-all Remove all non-global symbols > -X --discard-locals Remove any compiler-generated > symbols > -v --verbose List all object files modified > -V --version Display this program's version > number > -h --help Display this output > -o Place stripped output into > strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 > elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core > make[1]: *** [openbios] Error 1 > make: *** [x86] Error 2 > root at who3:/usr/src/openbios/kernel# exit > Script done on Wed Sep 17 13:23:00 2003 > > Stefan your guess is as good as mine, as to what happened here. For > /dev/bios, I found that the version you have there, tended to cause an > oops, with my system tools, I'll grab it again, and try it. Basically > the earlier ones, 2.9 for example, worked. This is before your site > migrated to its present home. > > Oh and Ron, thank you for quoting me. It makes me feel better to see > that happen. > ------------------- > 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: Stefan Reinauer [mailto:stepan at suse.de] > > Sent: Wednesday, September 17, 2003 7:18 AM > > To: Gregg C Levine > > Cc: 'LinuxBIOS' > > Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released > > > > * Gregg C Levine [030917 06:03]: > > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined > > > reference to `strncmp' > > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined > > > reference to `memcpy' > > > > Ups. What gcc version are you using? Can you try compiling with > > -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions. > > > > > Any suggestions Stefan? Besides I like your ideas regarding the > Open > > > BIOS concepts. Incidentally for that project, can you put up the > older > > > versions of the /dev/bios files? Say, anything up to 3.*? > > > > All old versions I have lying around are in > > http://www.openbios.info/bin/ > > > > Do you need some particular code? The CVS version should be better > in > > most cases. > > > > Stefan > > > > -- > > Architecture Team > > SuSE Linux AG > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From ollie at sis.com.tw Wed Sep 17 21:27:00 2003 From: ollie at sis.com.tw (???) Date: Wed Sep 17 21:27:00 2003 Subject: damaged DoC MD2808-D08? References: <200309171013.h8HAD9ZS003979@enterprise2.newlogic.at> Message-ID: <02fa01c37d86$cb990a40$0201a8c0@ollie> Did you try to read the ECC area and check with the ECC status registers ? Ollie ----- Original Message ----- From: "Niki Waibel" To: Cc: Sent: Wednesday, September 17, 2003 6:13 PM Subject: damaged DoC MD2808-D08? my DoC MD2808-D08 responds fine to the control registers (chipid and ecc toggle bit are ok i.e.). but if it comes to the stage of sending nand commands and reading memory it seems to do nothing. if mem is read from the same IO reg (0x800) then i always get the same value (0x55). also if the nand ID command is sent, 0x800 responses with 0x55. 0x55 is the beginning of 0x55 0xaa 0x10 0xeb which is the beginning of the IPL code (rom extension)... in addition if i read a page. and then read it again. i get some different bytes: === --- xxx.xxd 2003-09-17 12:01:44.615883064 +0200 +++ xxx2.xxd 2003-09-17 12:01:44.629880936 +0200 @@ -1,67 +1,67 @@ 0000000: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst 0000010: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... 0000020: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... -0000030: 0000 0000 8001 9400 0000 0000 8181 8181 ................ +0000030: 0000 0000 8001 9400 0000 0000 8181 98e6 ................ 0000040: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. -0000050: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... +0000050: 8ec0 33ff 83c2 408e da81 fa00 439a 8181 ..3... at .....C... 0000060: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0075 ........u......u -0000070: 021e 0747 83ff 3072 8181 8181 8181 98e6 ...G..0r........ +0000070: 021e 0747 83ff 3072 8181 98e6 439a 8181 ...G..0r....C... 0000080: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. 0000090: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. 00000a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F -00000b0: 048e d8bb 0000 c687 439a 0081 8181 8198 ........C....... +00000b0: 048e d8bb 0000 c687 0381 0081 8181 8181 ................ 00000c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. -00000d0: b100 e855 002e 8b0e e643 9a81 8181 8181 ...U.....C...... +00000d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ 00000e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. -00000f0: 8814 8834 8181 8181 8181 8181 8181 8198 ...4............ +00000f0: 8898 8834 e643 9a81 8181 8198 e643 9a81 ...4.C.......C.. 0000100: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. 0000110: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. 0000120: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ -0000130: 0cc6 871e 1000 c687 0410 09f6 e643 9a81 .............C.. +0000130: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ 0000140: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... -0000150: 8704 1080 74f9 f687 2010 80f6 8181 8198 ....t... ....... -0000160: c31c 0000 0000 0000 0000 0000 e600 439a ..............C. -0000170: 0000 0000 0000 8181 8181 8181 8181 8181 ................ +0000150: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... +0000160: c31c 0000 0000 0000 0000 0000 0000 8181 ................ +0000170: 0000 0000 8181 0000 8181 8181 8181 8198 ................ 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00001b0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ +00001b0: 0000 0000 0000 0000 e643 9a81 8181 8198 .........C...... 00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00001d0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... -00001e0: 0000 0000 0000 0000 0000 0000 8181 98e6 ................ -00001f0: 0000 0000 439a 8181 8181 8181 8181 8181 ....C........... +00001d0: 0000 0000 0000 0000 e643 9a81 8181 8181 .........C...... +00001e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ +00001f0: 8100 0000 8181 8181 8181 8181 8181 9898 ................ 0000200: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst 0000210: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... 0000220: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... -0000230: 0000 0000 8001 9400 0000 0000 8181 8181 ................ +0000230: 0000 0000 8001 9400 0000 0000 439a 8181 ............C... 0000240: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. -0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... -0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 8175 ........u......u -0000270: 021e 0747 83ff 3072 8198 e643 9a81 8181 ...G..0r...C.... +0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 98e6 ..3... at ......... +0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0043 ........u......C +0000270: 021e 0747 83ff 3072 9a81 8181 8181 8181 ...G..0r........ 0000280: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. 0000290: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. 00002a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F -00002b0: 048e d8bb 0000 c687 0381 98e6 439a 8181 ............C... +00002b0: 048e d8bb 0000 c687 8181 8181 8181 8181 ................ 00002c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. -00002d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ -00002e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. -00002f0: 8814 8881 8181 8181 8198 e643 9a81 8181 ...........C.... +00002d0: b100 e855 002e 8b0e 8181 8181 8198 e643 ...U...........C +00002e0: 7523 c687 0410 0d2e 8b16 1c00 9a81 8181 u#.............. +00002f0: 8814 8834 8198 e643 9a81 8181 8181 8181 ...4...C........ 0000300: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. 0000310: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. 0000320: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ -0000330: 0cc6 871e 1000 c687 0410 09f6 8198 e643 ...............C +0000330: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ 0000340: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... -0000350: 8704 1080 74f9 f687 2010 80f6 9a81 8181 ....t... ....... -0000360: c31c 0000 0000 0000 0000 0000 8100 0081 ................ -0000370: 0000 0000 8100 8181 8181 8181 8181 8181 ................ +0000350: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... +0000360: c31c 0000 0000 0000 0000 0000 0081 8181 ................ +0000370: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... 0000380: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000390: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00003a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00003b0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. +00003b0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... 00003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ -00003d0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. +00003d0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ 00003e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ -00003f0: 0000 8100 8181 8181 8181 8181 8181 8181 ................ +00003f0: 8181 0000 8181 8181 98e6 439a 8181 8181 ..........C..... 0000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................ === that data was read by === cmd(bios, NAND_CMD_READ0); adr(bios, page); doc_read_nop(bios); /* nop between write/read */ doc_write_cdsncontrol(bios, CDSN_CTRL_CE); doc_read(bios, ReadPipelineInitialization); for(i=0; i<512-1; i++) { doc_read_4nop(bios); doc_read(bios, CDSNSlowIO); doc_read_4nop(bios); buf[offset++] = doc_read(bios, _CDSNIO_BASE+i); doc_read_4nop(bios); } buf[offset++] = doc_read(bios, LastDataRead); doc_write_cdsncontrol(bios, CDSN_CTRL_CE); if(doc_wait(bios, 5000)) { printf("outch...\n"); return(-1); } === if i read without CDSNSlowIO and without doc_read_4nop(bios) then the result is worse and more bits/bytes are different each read. if i read doc_read(bios, _CDSNIO_BASE) (***check the missing ``+ i''***) then i get 0x55 all the time (except for doc_read(bios, LastDataRead)). all this is very strange and i am beginning to think that my DoC (the flash in it) is damaged. any idea? niki w. waibel _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From nathanael at gnat.ca Thu Sep 18 02:45:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu Sep 18 02:45:00 2003 Subject: EPIA Information... Message-ID: Hello I have received shipment of my epia flash. Although my flash came with an SST chip. www.badflash.com sent me a Windbond chip. I was a little worried, but after using flash_rom to extract the original bios. I proceeded to flash this new chip. It all worked. I rebooted and everything is as it should be. It is unfortunate that I had to pay $10 to find this out, since I have 10 of those chips here for another project. The chip sent is W29C020CP90B. So as to let others know, you can use those in replacement of the original BIOS chip on the EPIA-800. I would suspect that the EPIA-500 and such would also work, but well can't guarantee it. Now on to flashing linuxBIOS to these chips... How exciting... I wonder though if it is prudent to do this at 1am...;) oh well. -- 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 niki.waibel at newlogic.com Thu Sep 18 03:04:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Thu Sep 18 03:04:01 2003 Subject: damaged DoC MD2808-D08? In-Reply-To: <02fa01c37d86$cb990a40$0201a8c0@ollie> Message-ID: <200309180725.h8I7PMZS003891@enterprise2.newlogic.at> On 18-Sep-2003 ??? wrote: > Did you try to read the ECC area and check with the ECC status > registers ? do you mean this: === probe_md2802: ChipID: 0x30 probe_md2802: DOCStatus: 0x01 probe_md2802: FloorSelect: 0x00 probe_md2802: CDSNControl: 0x80 probe_md2802: CDSNDeviceSelect: 0x00 probe_md2802: ECCConfiguration: 0x82 probe_md2802: CDSNSlowIO: 0x82 probe_md2802: ECCSyndrome0: 0xff probe_md2802: ECCSyndrome1: 0x00 probe_md2802: ECCSyndrome2: 0xff probe_md2802: ECCSyndrome3: 0xff probe_md2802: ECCSyndrome4: 0xff probe_md2802: ECCSyndrome5: 0xff probe_md2802: AliasResolution: 0x00 probe_md2802: ConfigurationInput: 0x01 probe_md2802: ReadPipelineInitialization: 0x01 probe_md2802: LastDataRead: 0xe6 probe_md2802: probe_md2802: checking ECCConfiguration toggle bit probe_md2802: 0x01 0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x01 0x00 probe_md2802: toggle result: 0/5 === or do you mean the ecc stuff in the flash (nand_ecc) itself? niki > ----- Original Message ----- > From: "Niki Waibel" > To: > Cc: > Sent: Wednesday, September 17, 2003 6:13 PM > Subject: damaged DoC MD2808-D08? > > > my DoC MD2808-D08 responds fine to the control registers > (chipid and ecc toggle bit are ok i.e.). > > but if it comes to the stage of sending nand commands and > reading memory it seems to do nothing. > > if mem is read from the same IO reg (0x800) then > i always get the same value (0x55). also if the > nand ID command is sent, 0x800 responses with 0x55. > 0x55 is the beginning of 0x55 0xaa 0x10 0xeb which > is the beginning of the IPL code (rom extension)... > > in addition if i read a page. and then read it again. > i get some different bytes: > === > --- xxx.xxd 2003-09-17 12:01:44.615883064 +0200 > +++ xxx2.xxd 2003-09-17 12:01:44.629880936 +0200 > @@ -1,67 +1,67 @@ > 0000000: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst > 0000010: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... > 0000020: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... > -0000030: 0000 0000 8001 9400 0000 0000 8181 8181 ................ > +0000030: 0000 0000 8001 9400 0000 0000 8181 98e6 ................ > 0000040: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. > -0000050: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... > +0000050: 8ec0 33ff 83c2 408e da81 fa00 439a 8181 ..3... at .....C... > 0000060: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0075 ........u......u > -0000070: 021e 0747 83ff 3072 8181 8181 8181 98e6 ...G..0r........ > +0000070: 021e 0747 83ff 3072 8181 98e6 439a 8181 ...G..0r....C... > 0000080: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. > 0000090: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. > 00000a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F > -00000b0: 048e d8bb 0000 c687 439a 0081 8181 8198 ........C....... > +00000b0: 048e d8bb 0000 c687 0381 0081 8181 8181 ................ > 00000c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. > -00000d0: b100 e855 002e 8b0e e643 9a81 8181 8181 ...U.....C...... > +00000d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ > 00000e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. > -00000f0: 8814 8834 8181 8181 8181 8181 8181 8198 ...4............ > +00000f0: 8898 8834 e643 9a81 8181 8198 e643 9a81 ...4.C.......C.. > 0000100: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. > 0000110: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. > 0000120: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ > -0000130: 0cc6 871e 1000 c687 0410 09f6 e643 9a81 .............C.. > +0000130: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ > 0000140: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... > -0000150: 8704 1080 74f9 f687 2010 80f6 8181 8198 ....t... ....... > -0000160: c31c 0000 0000 0000 0000 0000 e600 439a ..............C. > -0000170: 0000 0000 0000 8181 8181 8181 8181 8181 ................ > +0000150: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... > +0000160: c31c 0000 0000 0000 0000 0000 0000 8181 ................ > +0000170: 0000 0000 8181 0000 8181 8181 8181 8198 ................ > 0000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 0000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 00001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > -00001b0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ > +00001b0: 0000 0000 0000 0000 e643 9a81 8181 8198 .........C...... > 00001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > -00001d0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... > -00001e0: 0000 0000 0000 0000 0000 0000 8181 98e6 ................ > -00001f0: 0000 0000 439a 8181 8181 8181 8181 8181 ....C........... > +00001d0: 0000 0000 0000 0000 e643 9a81 8181 8181 .........C...... > +00001e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ > +00001f0: 8100 0000 8181 8181 8181 8181 8181 9898 ................ > 0000200: 55aa 10eb 3c00 0028 4329 4d2d 5379 7374 U...<..(C)M-Syst > 0000210: 656d 7331 3939 3800 0000 2100 0004 001c ems1998...!..... > 0000220: 5524 506e 5001 0200 0000 1e6d 1a01 1000 U$PnP......m.... > -0000230: 0000 0000 8001 9400 0000 0000 8181 8181 ................ > +0000230: 0000 0000 8001 9400 0000 0000 439a 8181 ............C... > 0000240: 009c 5053 5152 5657 551e 06ba c01f 33c0 ..PSQRVWU.....3. > -0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 8181 ..3... at ......... > -0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 8175 ........u......u > -0000270: 021e 0747 83ff 3072 8198 e643 9a81 8181 ...G..0r...C.... > +0000250: 8ec0 33ff 83c2 408e da81 fa00 8181 98e6 ..3... at ......... > +0000260: f6b9 0002 fcad 0bc0 75e8 e2f9 83ff 0043 ........u......C > +0000270: 021e 0747 83ff 3072 9a81 8181 8181 8181 ...G..0r........ > 0000280: 588e c20e 1f8b ec83 ec04 8cc0 8c46 fec7 X............F.. > 0000290: 46fc ab00 0ee8 1300 8b46 fe8e c033 ffb9 F........F...3.. > 00002a0: 0060 33c0 fcf3 ab8b e5eb 7455 8bec 8b46 .`3.......tU...F > -00002b0: 048e d8bb 0000 c687 0381 98e6 439a 8181 ............C... > +00002b0: 048e d8bb 0000 c687 8181 8181 8181 8181 ................ > 00002c0: c687 0210 85be 0008 b1ff e85d 00fc 32e4 ...........]..2. > -00002d0: b100 e855 002e 8b0e 8181 8181 8181 8181 ...U............ > -00002e0: 7523 c687 0410 0d2e 8b16 1c00 8181 8181 u#.............. > -00002f0: 8814 8881 8181 8181 8198 e643 9a81 8181 ...........C.... > +00002d0: b100 e855 002e 8b0e 8181 8181 8198 e643 ...U...........C > +00002e0: 7523 c687 0410 0d2e 8b16 1c00 9a81 8181 u#.............. > +00002f0: 8814 8834 8198 e643 9a81 8181 8181 8181 ...4...C........ > 0000300: 1009 e836 0084 870d 10ac 02e0 aa4e e2cc ...6.........N.. > 0000310: 2e3a 2620 0075 065d 0633 c050 cb5d cb07 .:& .u.].3.P.].. > 0000320: 1f5d 5f5e 5a59 5b58 9dcb c687 0410 0b88 .]_^ZY[X........ > -0000330: 0cc6 871e 1000 c687 0410 09f6 8198 e643 ...............C > +0000330: 0cc6 871e 1000 c687 0410 09f6 8181 8181 ................ > 0000340: f687 2010 80f6 8720 1080 f687 2010 80f6 .. .... .... ... > -0000350: 8704 1080 74f9 f687 2010 80f6 9a81 8181 ....t... ....... > -0000360: c31c 0000 0000 0000 0000 0000 8100 0081 ................ > -0000370: 0000 0000 8100 8181 8181 8181 8181 8181 ................ > +0000350: 8704 1080 74f9 f687 2010 80f6 8181 8181 ....t... ....... > +0000360: c31c 0000 0000 0000 0000 0000 0081 8181 ................ > +0000370: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... > 0000380: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 0000390: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 00003a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > -00003b0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. > +00003b0: 0000 0000 0000 0000 8181 98e6 439a 8181 ............C... > 00003c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > -00003d0: 0000 0000 0000 0000 8181 8181 98e6 439a ..............C. > +00003d0: 0000 0000 0000 0000 8181 8181 8181 8181 ................ > 00003e0: 0000 0000 0000 0000 0000 0000 8181 8181 ................ > -00003f0: 0000 8100 8181 8181 8181 8181 8181 8181 ................ > +00003f0: 8181 0000 8181 8181 98e6 439a 8181 8181 ..........C..... > 0000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 0000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 0000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > === > that data was read by > === > cmd(bios, NAND_CMD_READ0); > adr(bios, page); > doc_read_nop(bios); /* nop between write/read */ > doc_write_cdsncontrol(bios, CDSN_CTRL_CE); > doc_read(bios, ReadPipelineInitialization); > for(i=0; i<512-1; i++) { > doc_read_4nop(bios); > doc_read(bios, CDSNSlowIO); > doc_read_4nop(bios); > buf[offset++] = doc_read(bios, _CDSNIO_BASE+i); > doc_read_4nop(bios); > } > buf[offset++] = doc_read(bios, LastDataRead); > doc_write_cdsncontrol(bios, CDSN_CTRL_CE); > if(doc_wait(bios, 5000)) { > printf("outch...\n"); > return(-1); > } > === > if i read without CDSNSlowIO and without doc_read_4nop(bios) then the result > is > worse and more bits/bytes are different each read. > if i read doc_read(bios, _CDSNIO_BASE) (***check the missing ``+ i''***) > then > i get 0x55 all the time (except for doc_read(bios, LastDataRead)). > > all this is very strange and i am beginning to think > that my DoC (the flash in it) is damaged. > > any idea? > > niki w. waibel From rezso at rdsor.ro Thu Sep 18 05:22:00 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Thu Sep 18 05:22:00 2003 Subject: Re OpenBIOS Forth Kernel V1.0 released In-Reply-To: <20030917111829.GE5467@suse.de> References: <20030916160247.GA2778@suse.de> <000001c37cd0$ad7873e0$0100a8c0@who5> <20030917111829.GE5467@suse.de> Message-ID: <200309181244.29613.rezso@rdsor.ro> Hi Stefan, Hi all ! > Stefan Hust an Q from a very courios person: Some forthfirmare init code ? Are you/team started working on it ? Forth Base Dictionary : : : : : : : : Status: 95% Open Firmware specific Forth Dictionary : : : : : : : : Status: 0% Device Interface : : : : : : : : Status: 0% Client Interface : : : : : : : : Status: 0% User Interface : : : : : : : : Status: 0% Best Regards, Cristian From sven.luebke at mikrosol.de Thu Sep 18 06:03:01 2003 From: sven.luebke at mikrosol.de (Sven =?iso-8859-1?Q?L=FCbke?=) Date: Thu Sep 18 06:03:01 2003 Subject: EPIA Information... In-Reply-To: Message-ID: <5.1.1.6.2.20030918114213.00b0d360@pop.onlinehome.de> At 01:06 18.09.2003 -0600, you wrote: Hi Nathanael! >the original bios. I proceeded to flash this new chip. It all worked. I >rebooted and everything is as it should be. It is unfortunate that I had >to pay $10 to find this out, since I have 10 of those chips here for >another project. The chip sent is W29C020CP90B. So as to let others know, >you can use those in replacement of the original BIOS chip on the >EPIA-800. I would suspect that the EPIA-500 and such would also work, but >well can't guarantee it. Of course you can use FlashROMs other than the 39SF020A for all EPIA boards. I installed an AMD AM29F040B-55JI in an EPIA5000 and everything is working great! Just download the datasheet of your chip and compare the pinout/voltages with the pinout/voltages of the original FlashROM. If all signals and the access time are the same (or better/faster), you can use it. BUT: It's possible, that the original EPIA flashwriter software (running under DOS or Windows) is only capable of writing the 39sf020a chips, because they didn't implement other FlashROM programming algorithms. The flashwriter which is included in the Linuxbios package is capable of programming (nearly) all FlashROMs. Best regards, Sven From han2004 at hotmail.com Thu Sep 18 06:58:00 2003 From: han2004 at hotmail.com (gimyung han) Date: Thu Sep 18 06:58:00 2003 Subject: Any story to boot from Hard Disk Message-ID: Is anyone tried to boot LinuxBIOS from Hard Disk not using etherboot? I heard that etherboot can also boot ide devices........... But I don't know how to do it......... Thanks for any help _________________________________________________________________ ?? ?? ?? ??? ??? ?? ? ????. MSN ??/?? http://www.msn.co.kr/stock/ From gwatson at lanl.gov Thu Sep 18 09:08:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Thu Sep 18 09:08:00 2003 Subject: Any story to boot from Hard Disk In-Reply-To: References: Message-ID: I've used the IDE stream code to boot Linux from and IDE flash. This should also work from any IDE device, though I've not tested it. See freebios2/src/ide_stream.c. Greg At 11:19 AM +0000 18/9/03, gimyung han wrote: >Is anyone tried to boot LinuxBIOS from Hard Disk not using etherboot? > >I heard that etherboot can also boot ide devices........... > >But I don't know how to do it......... > >Thanks for any help > >_________________________________________________________________ >???? ???? ???? ?????? ?????' ???? ?? ????????. MSN ????/???? >http://www.msn.co.kr/stock/ >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From ts1 at cma.co.jp Thu Sep 18 09:37:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu Sep 18 09:37:00 2003 Subject: Any story to boot from Hard Disk In-Reply-To: References: Message-ID: <20030918135845.GA22333@cma.co.jp> On Thu, Sep 18, 2003 at 11:19:57AM +0000, gimyung han wrote: > Is anyone tried to boot LinuxBIOS from Hard Disk not using etherboot? > > I heard that etherboot can also boot ide devices........... > > But I don't know how to do it......... > > Thanks for any help Check out this: http://te.to/~ts1/filo/ From stepan at suse.de Thu Sep 18 10:30:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 18 10:30:01 2003 Subject: Announcing FILO In-Reply-To: <20030910141538.GA21218@cma.co.jp> References: <20030910141538.GA21218@cma.co.jp> Message-ID: <20030918145152.GA12691@suse.de> * SONE Takeshi [030910 16:15]: > Hi, I wrote a bootloader, available here: > http://te.to/~ts1/filo/ > and here the README: > > This is FILO, a bootloader which loads boot images from local filesystem, > without help from legacy BIOS services. Very nice! When I compiled it, I had to change one line in "makerules" < GCCINCDIR = $(shell $(CC) -print-search-dirs | head -1 | cut -d' ' -f2)include > GCCINCDIR = $(shell $(CC) -print-search-dirs | head -n 1 | cut -d' ' -f2)include This is required by newer coreutils, but it works fine with older versions. Stefan -- Architecture Team SuSE Linux AG From YhLu at tyan.com Thu Sep 18 12:16:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 18 12:16:01 2003 Subject: Any story to boot from Hard Disk Message-ID: <3174569B9743D511922F00A0C943142303466AAA@TYANWEB> It's interesting, so it support to file system, while Etherboot only scan first 32 sectors to find the elf. Eric, When using Etherboot 5.2 with LinuxBIOS, does it still support boot from floppy disk? My boss said that if I can flash BIOS only with Floppy under LinuxBIOS, then We could ship some MBs with LinuxBIOS. YH. -----????----- ???: SONE Takeshi [mailto:ts1 at cma.co.jp] ????: 2003?9?18? 6:59 ???: gimyung han ??: Linuxbios at clustermatic.org ??: Re: Any story to boot from Hard Disk On Thu, Sep 18, 2003 at 11:19:57AM +0000, gimyung han wrote: > Is anyone tried to boot LinuxBIOS from Hard Disk not using etherboot? > > I heard that etherboot can also boot ide devices........... > > But I don't know how to do it......... > > Thanks for any help Check out this: http://te.to/~ts1/filo/ _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From nathanael at gnat.ca Thu Sep 18 13:09:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu Sep 18 13:09:01 2003 Subject: EPIA Up Message-ID: Hello, I just wanted to say thanks to everyone that has worked on linuxBIOS. my EPIA board is fully functioning... um no wait, without VGABIOS.. but thats the next step. Its been keeping me at the console for a little too long, but I had a board that I tried porting over and realize the amount of work to get these things working like this. Either way it works and I'm liking it. the Filo bootloader is great, simplifies the load process significantly. I stayed up WAY too late playing with this thing. It felt almost like Christmas... So anyway thanks. -- 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 ts1 at tsn.or.jp Thu Sep 18 14:45:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Thu Sep 18 14:45:01 2003 Subject: Announcing FILO In-Reply-To: <20030918145152.GA12691@suse.de> References: <20030910141538.GA21218@cma.co.jp> <20030918145152.GA12691@suse.de> Message-ID: <20030918190615.GA31361@tsn.or.jp> On Thu, Sep 18, 2003 at 04:51:53PM +0200, Stefan Reinauer wrote: > When I compiled it, I had to change one line in "makerules" > < GCCINCDIR = $(shell $(CC) -print-search-dirs | head -1 | cut -d' ' -f2)include > > GCCINCDIR = $(shell $(CC) -print-search-dirs | head -n 1 | cut -d' ' -f2)include > > This is required by newer coreutils, but it works fine with older > versions. Thanks, I'll post a new version of FILO with this fix. -- Takeshi From YhLu at tyan.com Thu Sep 18 18:32:00 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 18 18:32:00 2003 Subject: S2850 Message-ID: <3174569B9743D511922F00A0C943142303466B32@TYANWEB> Eric, Does the Etherboot 5.2.0 support Broadcom 5705? The device id is 0x1653. Regards Yinghai Lu From sven.luebke at mikrosol.de Fri Sep 19 04:25:01 2003 From: sven.luebke at mikrosol.de (Sven =?iso-8859-1?Q?L=FCbke?=) Date: Fri Sep 19 04:25:01 2003 Subject: Help needed (LinuxBIOS & FILO on EPIA5000) Message-ID: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> Hi all! I tried to install LinuxBIOS in my EPIA board, but with no luck. I don't have a serial null-modem cable, so I can't see debugging information :-(. I read the HOW TO for EPIA boards and used FILO as payload, cause I want to boot from IDE. In FILO I edited the file "Config" and changed only: AUTOBOOT_FILE = "hda5:/vmlinuz" FILO compiles without problems and creates an ELF file, which is 34 KB in size. Then I edited the file "epia.config" (changed only "payload /root/filo-0.1/filo.elf"), ran the python script, executed "make clean" and "make" in the target folder and linuxbios compiles with no problem. I burned the file "romimage" into the flash, rebooted but nothing is happening :-((. I tried the same with extracting the VGA-Bios and creating a combined payload with no result also! Am I doing something wrong? I have three questions anyway: 1. In "epia.config" there is the option PAYLOAD_SIZE! Do I have to change it to the size of the "filo.elf" payload?? I tried it, but it's not working nevertheless... 2. Is FILO compatible with the ext3 filesystem? I am using it in my root partition, but read, that ext2 and ext3 are compatible! Is that my failure? 3. Is VGA support for the EPIA5000 possible in this combination? Thanks for your help! Best regards, Sven From ts1 at cma.co.jp Fri Sep 19 05:03:00 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri Sep 19 05:03:00 2003 Subject: Help needed (LinuxBIOS & FILO on EPIA5000) In-Reply-To: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> References: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> Message-ID: <20030919092438.GA9611@cma.co.jp> On Fri, Sep 19, 2003 at 10:32:05AM +0200, Sven L?bke wrote: > In FILO I edited the file "Config" and changed only: > AUTOBOOT_FILE = "hda5:/vmlinuz" If this file is the bzImage format kernel, FILO can't load it (yet). Use mkelfImage from ftp://ftp.lnxi.com/pub/mkelfImage/ to convert your vmlinuz to ELF. > 1. In "epia.config" there is the option PAYLOAD_SIZE! Do I have to change > it to the size of the "filo.elf" payload?? I tried it, but it's not working > nevertheless... I have never tried to change that option. > 2. Is FILO compatible with the ext3 filesystem? I am using it in my root > partition, > but read, that ext2 and ext3 are compatible! Is that my failure? FILO works with ext3 just fine. In fact I'm using ext3 too. Filesystem routines are from GNU GRUB and it's been compatilbe with ext3 for quite a while. > 3. Is VGA support for the EPIA5000 possible in this combination? Yes, it's working on my EPIA 5000. However, VGA support (either VGABIOS or direct access) is not stable yet, it works for some of us but not for others. You definitely need a serial cable to see what is going on. I have several fixes to VGABIOS support, which should increase compatibility, and I believe David and Ron at LANL are working on it to integrate it to the tree. -- Takeshi From sven.luebke at mikrosol.de Fri Sep 19 08:12:01 2003 From: sven.luebke at mikrosol.de (Sven Luebke) Date: Fri Sep 19 08:12:01 2003 Subject: Help needed (LinuxBIOS & FILO on EPIA5000) In-Reply-To: <20030919092438.GA9611@cma.co.jp> References: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> Message-ID: <5.1.1.6.2.20030919141259.00b0d670@pop.onlinehome.de> At 18:24 19.09.2003 +0900, SONE Takeshi wrote: Hi Takeshi! > > In FILO I edited the file "Config" and changed only: > > AUTOBOOT_FILE = "hda5:/vmlinuz" > >If this file is the bzImage format kernel, FILO can't load it (yet). >Use mkelfImage from ftp://ftp.lnxi.com/pub/mkelfImage/ >to convert your vmlinuz to ELF. Thank you, that was my first failure! I had to replace the binutils package, which was installed with my Debian distribution, to get the ELF image (otherwise an internal error occured). Which command-line parameters do I have to use if I want VGA support? I used: mkelfImage --kernel=/usr/src/linux-2.4.21/arch/i386/boot/bzImage \ --output=/vmlinuz.elf \ --command-line="console=ttyS0,115200n8 root=/dev/hda5" > > 1. In "epia.config" there is the option PAYLOAD_SIZE! Do I have to change > > it to the size of the "filo.elf" payload?? I tried it, but it's not > working > > nevertheless... > >I have never tried to change that option. Ok, then I do not change it also... > > 2. Is FILO compatible with the ext3 filesystem? I am using it in my root > > partition, > > but read, that ext2 and ext3 are compatible! Is that my failure? > >FILO works with ext3 just fine. In fact I'm using ext3 too. >Filesystem routines are from GNU GRUB and it's been compatilbe with ext3 >for quite a while. Oh, that's great, because I don't have to convert from ext3 to ext2! >You definitely need a serial cable to see what is going on. Yes, you are right. I build a nullmodem cable to see the debug infos, but Linuxbios isn't very "verbose" :-): ------------------ begin ----------- 0 LinuxBIOS-1.0.0 Fri Sep 19 13:58:31 CEST 2003 starting... ------------------- end -------------- That's the last message... Any idea? Is it better to deactivate VGA support first and get the rest working first? Thank you so much for your help! Best regards, Sven From ts1 at cma.co.jp Fri Sep 19 08:39:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri Sep 19 08:39:01 2003 Subject: Announcing FILO In-Reply-To: <20030918190615.GA31361@tsn.or.jp> References: <20030910141538.GA21218@cma.co.jp> <20030918145152.GA12691@suse.de> <20030918190615.GA31361@tsn.or.jp> Message-ID: <20030919130058.GA19847@cma.co.jp> On Fri, Sep 19, 2003 at 04:06:15AM +0900, SONE Takeshi wrote: > On Thu, Sep 18, 2003 at 04:51:53PM +0200, Stefan Reinauer wrote: > > When I compiled it, I had to change one line in "makerules" > > < GCCINCDIR = $(shell $(CC) -print-search-dirs | head -1 | cut -d' ' -f2)include > > > GCCINCDIR = $(shell $(CC) -print-search-dirs | head -n 1 | cut -d' ' -f2)include > > > > This is required by newer coreutils, but it works fine with older > > versions. > > Thanks, I'll post a new version of FILO with this fix. Released version 0.2 here: http://te.to/~ts1/filo/ Version 0.2 ts1 2003-09-19 * Added code to pass kernel command line parameter from console. * Changed not to disable automatic boot by ANY key. Now you have to press to cancel autoboot. This fixes the problem that FILO gets stuck at boot prompt when a phantom byte is read from a fickle serial or keyboard hardware. Additionaly, now key does autoboot immediately. * Fixed build problem with new coreutils. Thanks to Stefan Reinauer . * Updated fsys_fat.c and fsys_reiserfs.c from GRUB CVS. * Lots of minor tweaks. * Beginning of PCI layer and a sound driver (what??). Don't worry, it doesn't even get compiled with default configuration. -- Takeshi From ts1 at cma.co.jp Fri Sep 19 09:04:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Fri Sep 19 09:04:01 2003 Subject: Help needed (LinuxBIOS & FILO on EPIA5000) In-Reply-To: <5.1.1.6.2.20030919141259.00b0d670@pop.onlinehome.de> References: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> <5.1.1.6.2.20030919141259.00b0d670@pop.onlinehome.de> Message-ID: <20030919132520.GA20672@cma.co.jp> On Fri, Sep 19, 2003 at 02:33:39PM +0200, Sven Luebke wrote: > mkelfImage --kernel=/usr/src/linux-2.4.21/arch/i386/boot/bzImage \ > --output=/vmlinuz.elf \ > --command-line="console=ttyS0,115200n8 root=/dev/hda5" That looks ok. > ------------------ begin ----------- > 0 > > LinuxBIOS-1.0.0 Fri Sep 19 13:58:31 CEST 2003 starting... > ------------------- end -------------- > > That's the last message... Looks like it successfully initialized the serial port but failed to initialize DRAM. What kind of RAM do you use? (size, single or double side, speed, etc..) If you have a POST card you can see how far it goes. Otherwise, you have to insert some CONSOLE_DEBUG_TX_STRING macros in (perhaps) freebios/src/northbridge/via/vt8601/raminit.inc to see it. > Any idea? Is it better to deactivate VGA support first and get the rest > working first? That's a good idea. -- Takeshi From ebiederman at lnxi.com Fri Sep 19 10:35:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Sep 19 10:35:01 2003 Subject: Opteron ECC Syndrome Issues In-Reply-To: <20030919123139.GA16268@suse.de> References: <99F2150714F93F448942F9A9F112634C0638B238@txexmtae.amd.com> <20030919123139.GA16268@suse.de> Message-ID: Stefan Reinauer writes: > Eric, > > with the latest CVS I am seeing memory errors on all addresses of the > second dimm module in our solo systems. This does not happen on the > HDAMA. Memory size is correctly detected though. Any good starting point > for debugging this? The first dimm module works perfectly fine. Is this ECC SDRAM? If so the current code in the public CVS tree is incorrect. To get the check bits correct the memory needs to be explicitly written to. There are also a couple of B3 stepping errata that can cause bugs like that. And I believe there is an errata that says something about the first dimm slot needing to be populated for the Athlon64. So I would start by ensuring the know errata are fixed. And testing to see what the problems follows if you swap the DIMMS. I need to push the bug fixes from my internal tree back to the public tree. This is a please bug me until I get it done request. I will see what I can do later today. Eric From han2004 at hotmail.com Fri Sep 19 12:13:00 2003 From: han2004 at hotmail.com (gimyung han) Date: Fri Sep 19 12:13:00 2003 Subject: about FILO ........ Message-ID: I just tested FILO on my EPIA machine............ it works fine, buf I just want to confirm that the image to be use by FILO should be elf image ? (which was combined with kernel image by mkelfimage utility..) I mean, can't FILO can use kernal image to boot linux? I just want to confirm it. _________________________________________________________________ ????? ???? ? ?? ???? MSN Hotmail? ?? ???. http://loginnet.passport.com/login.srf?id=2&svc=mail&cbid=24325&msppjph=1&lc=1042 From steve at nexpath.com Fri Sep 19 13:16:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Fri Sep 19 13:16:01 2003 Subject: Help needed (LinuxBIOS & FILO on EPIA5000) In-Reply-To: <20030919092438.GA9611@cma.co.jp> References: <5.1.1.6.2.20030919031815.00b0d4e0@POP.RZ.FH-Wolfenbuettel.DE> <20030919092438.GA9611@cma.co.jp> Message-ID: <3F6B4106.4030002@nexpath.com> SONE Takeshi wrote: > On Fri, Sep 19, 2003 at 10:32:05AM +0200, Sven L?bke wrote: > >>In FILO I edited the file "Config" and changed only: >>AUTOBOOT_FILE = "hda5:/vmlinuz" > > > If this file is the bzImage format kernel, FILO can't load it (yet). "Yet" means maybe soon? I am very much interested in booting bzImage. Eric has pointed out that putting the startup code for bzImage in the linuxbios flash makes it tied to one method of booting, that may change as Linux changes. But if you have a file system aware bootloader, then maybe we could put the startup code in an image file on the filesystem. Actually I don't care that much about whether it is in the flash or not, but others may. I have done the Linux startup code many times, if you want any additional code samples. One thing that is needed is to completely support the settings in the zero page, particularly the video mode and x,y cursor location. Booting vmlinuz with linuxbios would reduce newby questions on this ML significantly, since most who try linuxbios for the first time expect it to do this until they read the fine print (IMHO). -Steve From amits at myrealbox.com Fri Sep 19 13:20:01 2003 From: amits at myrealbox.com (amits at myrealbox.com) Date: Fri Sep 19 13:20:01 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio Message-ID: Hello, I am working on doing a Linux BIOS on an optoma thin client "ST320" its got PS/2 mouse and PS/2 kbd connectors, two USB , 1 serial ,1 parellel and 1 VGA.Its got a DoC ...but NO IDE it used to come originally with WinCE.It uses the XpressROM insyde BIOS. the plan is to do some sort of boot over lan(etherboot/netboot?).From whatever i dug up on the list archives it seems that the Geode is pretty much supported....but is VGA supported properly??i read somewhere that there *are* NSC drivers for the VGA..but they are buggy(or so i heard!).Also read that there exist framebuffer drivers that work....what i want to know is ...how do I get some display on this board?Is there anyother way apart from using ADLO?? i dont care if i dont see the kernel messages all i want is to start X on it.Has ANYONE got a geode running from linuxbios and showing some display? Is it possible to extract the VideoBIOS from the XpressROM and use it somehow like in the EPIA ?? If yes has anyone done it? Thanks in advance, regards, Amit Shirodkar amits at myrealbox.com From rminnich at lanl.gov Fri Sep 19 14:38:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 19 14:38:01 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: Message-ID: On Fri, 19 Sep 2003 amits at myrealbox.com wrote: > Is it possible to extract the VideoBIOS from the XpressROM and use it > somehow like in the EPIA ?? If yes has anyone done it? It ought to work but I don't know if anyone has done it. ron From ts1 at tsn.or.jp Fri Sep 19 15:40:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Fri Sep 19 15:40:01 2003 Subject: about FILO ........ In-Reply-To: References: Message-ID: <20030919200205.GC14768@tsn.or.jp> On Fri, Sep 19, 2003 at 04:35:07PM +0000, gimyung han wrote: > I just tested FILO on my EPIA machine............ Thanks. > it works fine, buf I just want to confirm that the image to be use by FILO > should be elf image ? > > (which was combined with kernel image by mkelfimage utility..) FILO can boot only ELF images. Loader for bzImage (vmlinuz) might or not be implemented in the future. -- Takeshi From nathanael at gnat.ca Fri Sep 19 16:04:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Fri Sep 19 16:04:01 2003 Subject: epia800 direct vga working In-Reply-To: <3F5BE42E.4060506@nexpath.com> Message-ID: <6AFBB62C-EADF-11D7-9429-0003931B4D6A@gnat.ca> Just wondering, have these changes been merged into the freebios tree? I've been having sporadic VGA problems on my epia800 and wondered if I had the latest or if I should start taking a peek at what is not working..? > diff --exclude-from exclude_epia --recursive --unified -P > freebios/src/mainboard/via/epia/Config > freebios_epia_works/src/mainboard/via/epia/Config > --- freebios/src/mainboard/via/epia/Config Sun Sep 7 18:22:01 2003 > +++ freebios_epia_works/src/mainboard/via/epia/Config Sun Sep 7 > 17:24:15 2003 > @@ -6,6 +6,7 @@ > mainboardinit cpu/i386/reset16.inc > ldscript cpu/i386/reset16.lds > > +option VGA_HARDWARE_FIXUP=1 > mainboardinit superio/via/vt8231/setup_ethernet.inc > mainboardinit superio/via/vt8231/setup_serial.inc > mainboardinit pc80/serial.inc > diff --exclude-from exclude_epia --recursive --unified -P > freebios/src/mainboard/via/epia/mainboard.c > freebios_epia_works/src/mainboard/via/epia/mainboard.c > --- freebios/src/mainboard/via/epia/mainboard.c Sun Sep 7 18:22:01 > 2003 > +++ freebios_epia_works/src/mainboard/via/epia/mainboard.c Sun Sep 7 > 18:34:15 2003 > @@ -2,9 +2,18 @@ > #include > #include > #include > +#include > > #include > > +void northbridge_fixup(); > +void southbridge_fixup(); > +void video_init(); > +void nvram_on(); > +void keyboard_on(); > +void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char > pIntAtoD[4]); > + > + > static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 }; > static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 }; > static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 }; > @@ -65,6 +74,15 @@ > > nvram_on(); > keyboard_on(); > + southbridge_fixup(); > + > +#ifdef VIDEO_CONSOLE > + vga_hardware_fixup(); > + // this has to be done here due to pci not always being up > + // earlier and pci resources are not ready > + video_init(); > +#endif > + > pci_routing_fixup(); > } > > diff --exclude-from exclude_epia --recursive --unified -P > freebios/src/northbridge/via/vt8601/Config > freebios_epia_works/src/northbridge/via/vt8601/Config > --- freebios/src/northbridge/via/vt8601/Config Sun Sep 7 18:22:01 2003 > +++ freebios_epia_works/src/northbridge/via/vt8601/Config Fri Sep 5 > 10:27:10 2003 > @@ -1 +1,2 @@ > object northbridge.o > +object via_vga.o VIDEO_CONSOLE > diff --exclude-from exclude_epia --recursive --unified -P > freebios/src/northbridge/via/vt8601/vgainit.inc > freebios_epia_works/src/northbridge/via/vt8601/vgainit.inc > --- freebios/src/northbridge/via/vt8601/vgainit.inc Sun Sep 7 > 18:29:59 2003 > +++ freebios_epia_works/src/northbridge/via/vt8601/vgainit.inc Sun Sep > 7 18:40:42 2003 > @@ -21,3 +21,32 @@ > > #endif > > +#if VIDEO_CONSOLE > + > +/* > + * by Steve M. Gehlbach, Ph.D. > + * steve @ kesa . com > + * > + * 9/7/03 smg > + * minor chipset settings for vga > + * more work needed for init, since reboot > + * from linux has problems (hdwr reset okay) > + * > + */ > + // set shadow ram to award settings > + > + CS_WRITE($0x61, $0x2a) > + CS_WRITE($0x62, $0x00) > + CS_WRITE($0x63, $0x20) > + > + // turn off GA > + > + CS_WRITE($0x88,$0x00) > + > + // enable vga, fb > + > + CS_WRITE($0xF9,$0x42) > + CS_WRITE($0xFB,$0xb0) > + > +#endif > + > diff --exclude-from exclude_epia --recursive --unified -P > freebios/src/northbridge/via/vt8601/via_vga.c > freebios_epia_works/src/northbridge/via/vt8601/via_vga.c > --- freebios/src/northbridge/via/vt8601/via_vga.c Wed Dec 31 16:00:00 > 1969 > +++ freebios_epia_works/src/northbridge/via/vt8601/via_vga.c Sun Sep > 7 16:11:37 2003 > @@ -0,0 +1,168 @@ > +/* > + * > + * By > + * Steve M. Gehlbach > + * > + * vga initialization specific for > + * via vt8601 chipset > + * > + * The font load code follows technique used > + * in the tiara project, which came from > + * the Universal Talkware Boot Loader, > + * http://www.talkware.net. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define VGA_FONT_BASE 0xa0000; > +#define VGA_GRAFIX_BASE 0xa0000; > +#define CHAR_HEIGHT 16 > + > +// splash_done is a global to avoid putting up splash screen twice. > +// Kind of a hack, but the problem is that the vga pci resources > +// are sometimes ready early, sort of, and the initial call to > +// vga_hardware_fixup puts up the splash screen; then a later call > +// to it from hardware_main does it again; but this does not always > +// happen, sometimes it fails the first call. It is either a timing > or initialization > +// problem that needs to be tracked down and fixed. Note that both > calls (fixup) are necessary > +// since some vga boards are not ready early, but some are, and of > course, the epia is sometimes ready > +// and sometimes not ready. > +// > +int splash_done = 0; > + > +extern unsigned char fontdata_8x16[]; > +extern void beep (int msec); > +extern void udelay (int usec); > + > +// The screeninfo structure is in pc80/vga_load_regs.c and has the vga > +// parameters for screen size etc. > +// This is _not_ the struct used in the zero_page > +// for linux init. It is only used for vga init. > +extern struct screeninfo vga_settings; > + > +// prototypes > +int vga_decode_var(struct screeninfo *var, struct vga_par *par); > +int vga_set_regs(struct vga_par *par); > + > + > +void vga_set_amode(void); > +void vga_set_gmode(void); > +void delay(int secs); > +void mdelay(int msecs); > +void vga_font_load(unsigned char *vidmem, unsigned char *font, int > height, int num_chars); > +int vga_load_pcx( char * pcx_file, int pcx_file_length); > + > +void vt8601_video_init(void) { > + int res; > + u8 byte; > + struct vga_par vga_params; > + > + > + // convert the general vga parameters in screeninfo structure > + // to actual vga register settings > + > + res = vga_decode_var(&vga_settings, &vga_params); > + if ( res < 0 ) { post_code (0xFD); } //no error return for now > + > + // enable vga system > + outb(0x01, 0x3c3); // enable VGA > + > + // write the registers > + res = vga_set_regs( &vga_params ); > + if ( res < 0 ) { post_code(0xFE); } //no error return for now > + byte = inb(MIS_R); // get 3c2 value by reading 3cc > + outb(byte & ~0xc,MIS_W); // clear last bits to set 25Mhz clock > + > + // enable epia extended regs > + write_seq(0x92,0x11); > + > + // setup the video clocks > + // -follows award settings > + // not all of these are necessary > + write_seq(0xbd,0x18); > + write_seq(0xcc,0x19); > + write_seq(0xff,0x1a); > + write_seq(0xff,0x1b); > + write_seq(0x46,0x1c); > + write_seq(0xbf,0x1d); > + write_seq(0xff,0x1e); > + write_seq(0xcc,0x1f); > + write_seq(0x04,0x20); > + write_seq(0x4f,0x24); > + > + // setup extended crtc regs > + // -follows award settings > + // not all of these are necessary > + write_crtc(0x64,0x1f); > + write_crtc(0x20,0x20); > + write_crtc(0x0,0x21); > + write_crtc(0x7,0x25); > + write_crtc(0x4,0x29); > + write_crtc(0x1f,0x2a); > + write_crtc(0x0,0x2b); > + write_crtc(0xdf,0x2f); > + write_crtc(0x10,0x38); > + > + > +} > + > +#ifdef VGA_HARDWARE_FIXUP > +void vga_hardware_fixup(void) { > + u8 *font_mem, *vga_mem, *pcx_file; > + int *file_size; > + > +#ifdef PCX_FILE_LOCATION > + pcx_file = (u8 *) PCX_FILE_LOCATION; > +#else > + pcx_file = (u8 *) 0xfffe0000; > +#endif > + file_size = (int *) pcx_file; > + > + vga_mem = (u8 *) VGA_GRAFIX_BASE; > + font_mem = (u8 *) VGA_FONT_BASE; > + > + outb(0x01, 0x3b8); // enable VGA > + outb(0x01, 0x3c3); // enable VGA > + outb(0x08, 0x46e8); // enable VGA (does not appear to be used) > + > + if (inb(0x3c3) != 1) { > + printk_info("VGA not ready yet.\n"); > + return; > + } > + printk_info("Initializing vt8601 vga..."); > + post_code(0xa0); > + > + vt8601_video_init(); > + > + printk_info("done.\n"); > + > +#ifdef VIDEO_SHOW_LOGO > + if (!splash_done) { > + printk_debug("Setting graphics mode...\n"); > + vga_set_gmode(); // set graphics mode > + > + // > + // the pcx_file is in flash at an address set > + // in the config file with PCX_FILE_LOCATION > + // the length of the file is at offset 0, file starts at 4 > + // > + > + printk_debug("pcx file at %x length %d\n",&pcx_file[4], *file_size); > + vga_load_pcx( &pcx_file[4], *file_size); > + delay(VIDEO_SHOW_LOGO); > + > +#endif > + vga_set_amode(); > + vga_font_load(font_mem,fontdata_8x16,CHAR_HEIGHT,256); > + splash_done++; // mark done > + printk_debug("alpha mode set.\n"); > + post_code(0xa1); > + } > +} > +#endif > diff --exclude-from exclude_epia --recursive --unified -P > freebios/util/config/epia800.config > freebios_epia_works/util/config/epia800.config > --- freebios/util/config/epia800.config Wed Dec 31 16:00:00 1969 > +++ freebios_epia_works/util/config/epia800.config Sun Sep 7 16:48:42 > 2003 > @@ -0,0 +1,63 @@ > +# > +# LinuxBIOS config file for: VIA epia mini-itx > +# > + > +target /usr/src/epia > + > +# via epia > +mainboard via/epia > +biosbase 0xffff0000 > + > +# setup delay using TSC > +option CONFIG_UDELAY_TSC=1 > + > +# Enable Serial Console for debugging > +option CONFIG_COMPRESS=0 > +option SERIAL_CONSOLE=1 > +option VIDEO_CONSOLE=1 > +option TTYS0_BAUD=115200 > + > +# For printk_debug, set level to 8 > +# for printk_info, set level to 7 > +#option DEFAULT_CONSOLE_LOGLEVEL=8 > +#option DEFAULT_CONSOLE_LOGLEVEL=7 > +option DEFAULT_CONSOLE_LOGLEVEL=6 > + > +#option DEBUG=1 > + > +option BOOT_IDE=1 > +option IDE_BOOT_DRIVE=0 > +#need to know size of partition table for ide > +#option ONE_TRACK=32 > +option ONE_TRACK=63 > + > + > +# the logo is displayed for VIDEO_SHOW_LOGO seconds. > +# Need to have to have a 128k rom since the logo image is at the > +# beginning (0xfffe0000) > +option VIDEO_SHOW_LOGO=10 > +option ROM_IMAGE_SIZE=131072 > +option PCX_FILE_LOCATION=0xfffe0000 > + > + > +# Use 256KB Standard Flash as Normal BIOS > +option RAMTEST=1 > + > +linux /usr/src/linux > +commandline root=/dev/hda2 ro console=ttyS0,115200n8 console=tty1 > + > +# > +# these actions put the pcx image file on the front of the bios. > +# the image size is placed in the first 4 bytes then the pcx file > +# important that ROM_IMAGE_SIZE be set to 128K or larger. > +# The logo file is called linuxbioslogo.pcx and is by default located > at > +# src/pc80/linuxbioslogo.pcx. > +# Change the variable LOGOFILE below if you want to use your own file. > +# See the file src/pc80/vga_load_pcx.c for details on the file format. > +# > +option LOGOFILE=$(TOP)/src/pc80/linuxbioslogo.pcx > +addaction linuxbios.rom dd if=$(LOGOFILE) of=linuxbios.rom bs=1 > seek=4 conv=notrunc; > +addaction linuxbios.rom perl -e '@a=stat > "$(LOGOFILE)";$$a=pack("L",$$a[7]); print $$a' | dd of=linuxbios.rom > bs=1 conv=notrunc > + > +# copy to home dir where flash programmer can reach. > +addaction linuxbios.rom /bin/cp -f linuxbios.rom > $(HOME)/cti/software/bios/exp/linuxbios_epia.bin > -- 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 ebiederman at lnxi.com Fri Sep 19 18:08:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Sep 19 18:08:01 2003 Subject: [Etherboot-users] S2850 In-Reply-To: <3174569B9743D511922F00A0C943142303466B32@TYANWEB> References: <3174569B9743D511922F00A0C943142303466B32@TYANWEB> Message-ID: YhLu writes: > Eric, > > Does the Etherboot 5.2.0 support Broadcom 5705? > > The device id is 0x1653. Now it does. Eric From YhLu at tyan.com Fri Sep 19 18:10:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 19 18:10:01 2003 Subject: [Etherboot-users] S2850 Message-ID: <3174569B9743D511922F00A0C943142303466BEF@TYANWEB> But there is no entry for 0x1653 in tg3.c YH. -----????----- ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] ????: 2003?9?19? 15:39 ???: YhLu ??: 'Etherboot-users'; linuxbios at clustermatic.org ??: Re: [Etherboot-users] S2850 YhLu writes: > Eric, > > Does the Etherboot 5.2.0 support Broadcom 5705? > > The device id is 0x1653. Now it does. Eric From ebiederman at lnxi.com Fri Sep 19 18:16:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Sep 19 18:16:00 2003 Subject: [Etherboot-users] S2850 In-Reply-To: <3174569B9743D511922F00A0C943142303466BEF@TYANWEB> References: <3174569B9743D511922F00A0C943142303466BEF@TYANWEB> Message-ID: YhLu writes: > But there is no entry for 0x1653 in tg3.c I just committed the code so it will take a little while to propogate. I have not tested it on a 5705, but it should work. Eric From sc at flagen.com Fri Sep 19 18:56:01 2003 From: sc at flagen.com (David Hendricks) Date: Fri Sep 19 18:56:01 2003 Subject: Sourceforge back from the dead? Message-ID: <38419.128.165.250.182.1064016947.squirrel@mail.flagen.com> Today, for the first time in months, I was able to successfully checkout an entire freebios tree with CVS! For those who have ben getting "connection reset by peer" errors, I'd suggest trying again ASAP while it still works. From rimy2000 at hotmail.com Fri Sep 19 19:31:01 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Fri Sep 19 19:31:01 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio References: Message-ID: Hi , Has the util/vgabios bug fixed? Does the CONSOLE_VIDEO have similar bug? Is the CS5530 direct VGA(as epia) working? Best Regards! ----- Original Message ----- From: "ron minnich" To: Cc: Sent: Saturday, September 20, 2003 2:59 AM Subject: Re: NS Geode GX1 + CS5530 +PC 97317 superio > On Fri, 19 Sep 2003 amits at myrealbox.com wrote: > > > Is it possible to extract the VideoBIOS from the XpressROM and use it > > somehow like in the EPIA ?? If yes has anyone done it? > > It ought to work but I don't know if anyone has done it. > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Sat Sep 20 15:59:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 20 15:59:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: Message-ID: On Sat, 20 Sep 2003, rimy2000 wrote: > Has the util/vgabios bug fixed? which one? ron From rimy2000 at hotmail.com Sat Sep 20 19:40:01 2003 From: rimy2000 at hotmail.com (rimy2000) Date: Sat Sep 20 19:40:01 2003 Subject: Fw: about util/vgabios Message-ID: ----- Original Message ----- From: "ron minnich" To: "elife elife" Cc: Sent: Sunday, September 07, 2003 12:00 PM Subject: Re: about util/vgabios > On Sun, 7 Sep 2003, elife elife wrote: > > > > > Hi, > > I am trying util/vgabios but encounter a strange problem: testbios seems > > fetching wrong instruction > > > > [root at linux vgabios]# ./testbios -s 64k -t ~/lb/500video.bios.bin > > running file /root/lb/500video.bios.bin > > No base specified. defaulting to 0xc0000 > > No initial code segment specified. defaulting to 0xc000 > > No initial instruction pointer specified. defaulting to 0x0003 > > Switching to single step mode. > > AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 > > DI=0000 > > DS=0040 ES=0000 SS=0030 CS=c000 IP=0005 NV UP DI PL NZ NA PO > > NC > > c000:0003 eb53 JMP 58 > > c000:3 - > > AX=00ff BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 > > DI=0000 > > DS=0040 ES=0000 SS=0030 CS=c000 IP=005a NV UP DI PL NZ NA PO > > NC > > c000:0058 0000 ADD [BX+SI],AL > > c000:58 - > > > > [root at linux lb]# od -x 500vi* |more > > 0000000 aa55 eb60 3753 3034 3030 c237 2a8a 522a > > 0000020 5345 5245 4556 2044 00b1 4f46 2052 4249 > > 0000040 204d 4f43 504d 5441 4249 4c49 5449 2a59 > > 0000060 2a2a a807 0000 1090 3130 302f 2f37 3032 > > 0000100 3230 0000 2e31 3431 3c20 4144 203e 2020 > > 0000120 3156 2033 2020 2020 83e9 075e 6f43 7970 > > > > testbios said c000:0058 is 0000 but in file, it's E9835E JMP > > 5EDE > > > > Best Regards! > > interesting, I have seen a similar sort of problem but was not sure what > it was. I'll try to take a look. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From nathanael at gnat.ca Sat Sep 20 20:58:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sat Sep 20 20:58:00 2003 Subject: epia800 direct vga working In-Reply-To: <3F5BE42E.4060506@nexpath.com> Message-ID: I have a few questions regarding the changes you made. I have an epia800 board. I altered the epia.config / HOWTO instructions to boot filo. Once that worked I added to the filo payload the vga bios extracted from the normal bios while running. Now I've applied this patch and I'm trying to figure out the differences between the two. The main difference as I see it is that you use the linux /path/to/linux command and I'm trying to do the payload /path/to/filo+vga... I'm wondering if these two things are compatible? I'm also wondering if I NEED the vga bios extracted still? I'd rather not alter the setup to make it boot from a kernel dd' to the hardrive as I like the fact that filo allows me to boot whatever kernel I feel like. Could you give me a hand so I can alter this. I've looked around and I'm trying to figure out what to change in my config... > diff --exclude-from exclude_epia --recursive --unified -P > freebios/util/config/epia800.config > freebios_epia_works/util/config/epia800.config > --- freebios/util/config/epia800.config Wed Dec 31 16:00:00 1969 > +++ freebios_epia_works/util/config/epia800.config Sun Sep 7 16:48:42 > 2003 > @@ -0,0 +1,63 @@ > +# > +# LinuxBIOS config file for: VIA epia mini-itx > +# > + > +target /usr/src/epia > + > +# via epia > +mainboard via/epia > +biosbase 0xffff0000 > + > +# setup delay using TSC > +option CONFIG_UDELAY_TSC=1 > + > +# Enable Serial Console for debugging > +option CONFIG_COMPRESS=0 > +option SERIAL_CONSOLE=1 > +option VIDEO_CONSOLE=1 > +option TTYS0_BAUD=115200 > + > +# For printk_debug, set level to 8 > +# for printk_info, set level to 7 > +#option DEFAULT_CONSOLE_LOGLEVEL=8 > +#option DEFAULT_CONSOLE_LOGLEVEL=7 > +option DEFAULT_CONSOLE_LOGLEVEL=6 > + > +#option DEBUG=1 > + > +option BOOT_IDE=1 > +option IDE_BOOT_DRIVE=0 > +#need to know size of partition table for ide > +#option ONE_TRACK=32 > +option ONE_TRACK=63 > + > + > +# the logo is displayed for VIDEO_SHOW_LOGO seconds. > +# Need to have to have a 128k rom since the logo image is at the > +# beginning (0xfffe0000) > +option VIDEO_SHOW_LOGO=10 > +option ROM_IMAGE_SIZE=131072 > +option PCX_FILE_LOCATION=0xfffe0000 > + > + > +# Use 256KB Standard Flash as Normal BIOS > +option RAMTEST=1 > + > +linux /usr/src/linux > +commandline root=/dev/hda2 ro console=ttyS0,115200n8 console=tty1 > + > +# > +# these actions put the pcx image file on the front of the bios. > +# the image size is placed in the first 4 bytes then the pcx file > +# important that ROM_IMAGE_SIZE be set to 128K or larger. > +# The logo file is called linuxbioslogo.pcx and is by default located > at > +# src/pc80/linuxbioslogo.pcx. > +# Change the variable LOGOFILE below if you want to use your own file. > +# See the file src/pc80/vga_load_pcx.c for details on the file format. > +# > +option LOGOFILE=$(TOP)/src/pc80/linuxbioslogo.pcx > +addaction linuxbios.rom dd if=$(LOGOFILE) of=linuxbios.rom bs=1 > seek=4 conv=notrunc; > +addaction linuxbios.rom perl -e '@a=stat > "$(LOGOFILE)";$$a=pack("L",$$a[7]); print $$a' | dd of=linuxbios.rom > bs=1 conv=notrunc > + > +# copy to home dir where flash programmer can reach. > +addaction linuxbios.rom /bin/cp -f linuxbios.rom > $(HOME)/cti/software/bios/exp/linuxbios_epia.bin > -- 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 steve at nexpath.com Sat Sep 20 23:58:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sat Sep 20 23:58:01 2003 Subject: epia800 direct vga working In-Reply-To: References: Message-ID: <3F6D273F.8070303@nexpath.com> Nathanael Noblet wrote: > I'm also wondering if I NEED the vga bios extracted still? The mod's that I made are for using vga without any vga bios by directly writing the chipset registers and legacy vga registers to put it in legacy vga mode. But it is only for text mode, so if you need extended graphics that is another matter. -Steve From nathanael at gnat.ca Sun Sep 21 00:11:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun Sep 21 00:11:01 2003 Subject: epia800 direct vga working In-Reply-To: <3F6D273F.8070303@nexpath.com> Message-ID: On Saturday, September 20, 2003, at 10:21 PM, Steve Gehlbach wrote: > Nathanael Noblet wrote: >> I'm also wondering if I NEED the vga bios extracted still? > > The mod's that I made are for using vga without any vga bios by > directly writing the chipset registers and legacy vga registers to put > it in legacy vga mode. But it is only for text mode, so if you need > extended graphics that is another matter. I don't need a framebuffer on boot, but once loaded would I be able to insmod the epiafb module and get that working? If that is the case, the boot sequence can be anything... Though, I'm wondering if the modifications you've made are (specifically the epia800.config) are compatible with an elf filo payload? The add action commands seem to run after the commands that concatenate the linuxbios image file with its payload.. so I'm somewhat at a loss as to what to flash the chip with. If you know what I mean. -- 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 steve at nexpath.com Sun Sep 21 02:02:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sun Sep 21 02:02:01 2003 Subject: epia800 direct vga working In-Reply-To: References: Message-ID: <3F6D4476.8000303@nexpath.com> Nathanael Noblet wrote: > I don't need a framebuffer on boot, but once loaded would I be able to > insmod the epiafb module and get that working? More than likely, since a framebuffer driver made for epia vga must have intimate knowledge of the chipset, so it should completely initialize it. > > Though, I'm wondering if the modifications you've made are (specifically > the epia800.config) are compatible with an elf filo payload? The add > action commands seem to run after the commands that concatenate the > linuxbios image file with its payload.. so I'm somewhat at a loss as to > what to flash the chip with. If you know what I mean. > I have not used payloads, so I am not sure, maybe others can comment. If you comment out VIDEO_SHOW_LOGO and the addactions, though, there is a bug in the file via_vga.c, you will need reverse two lines: #ifdef VIDEO_SHOW_LOGO if (!splash_done) { change it to: if (!splash_done) { #ifdef VIDEO_SHOW_LOGO -Steve From linuxbios at denkmair.de Sun Sep 21 05:28:01 2003 From: linuxbios at denkmair.de (Hubert Denkmair) Date: Sun Sep 21 05:28:01 2003 Subject: EPIA5000 & parallel port Message-ID: <3F6D7444.9020108@denkmair.de> Hello again, linuxbios+filo works now on my EPIA, thanks to everybody who helped me :-) There seems to be just one more problem - Is it possible that the parallel port is not initialized correctly by LinuxBIOS? I need it for my LCD which is controlled by LCDproc. With my original BIOS, everything works smoothly - with or without kernel parallel port support. But with LinuxBIOS nothing happens on the Display, seems as if no data is written to the port. LCDproc doesn't complain at all, but that's no surprise since it does not get any feedback from the LCD device anyways. Additionally, seems as if a kernel compiled with parallel port support doesn't find it either: --- imaudo:/# echo "Hallo" > /dev/lp0 bash: /dev/lp0: No such device --- Thanks for your help, again! Hubert From sven.luebke at mikrosol.de Sun Sep 21 07:35:01 2003 From: sven.luebke at mikrosol.de (Sven Luebke) Date: Sun Sep 21 07:35:01 2003 Subject: EPIA5000 & parallel port Message-ID: <5.1.1.6.2.20030921135651.021c79b0@pop.onlinehome.de> At 11:49 21.09.2003 +0200, you wrote: Hi Hubert! >There seems to be just one more problem - Is it possible that the parallel >port is not initialized correctly by LinuxBIOS? It's not initialized at all... >I need it for my LCD which is controlled by LCDproc. > >With my original BIOS, everything works smoothly - with or without kernel >parallel port support. But with LinuxBIOS nothing happens on the Display, >seems as if no data is written to the port. LCDproc doesn't complain at >all, but that's no surprise since it does not get any feedback from the >LCD device anyways. >Additionally, seems as if a kernel compiled with parallel port support >doesn't find it either: I had the same problem and implemented the parallel port initialization. It is working now, patches sent to Ron Minnich, but he wanted to do some cosmetic changes next week. If you are in a hurry, you can download it here, http://www.mikrosol.de/southbridge.c copy it to freebios\src\superio\via\vt8231\ http://www.mikrosol.de/setup_serial.inc copy it to freebios\src\southbridge\via\vt8231\ then recompile, flash and lcdproc should work now! Best regards, Sven From sven.luebke at mikrosol.de Sun Sep 21 08:14:00 2003 From: sven.luebke at mikrosol.de (Sven Luebke) Date: Sun Sep 21 08:14:00 2003 Subject: Homemade BIOS switch for EPIA boards (and others with 2MBit chips) Message-ID: <5.1.1.6.2.20030921124722.02135348@POP.RZ.FH-Wolfenbuettel.DE> Hi! I didn't find the BIOS Sa**our here in Germany so I made my own one. Of course this hack is nothing special, but perhaps useful for beginners! EPIA5000 owners don't have to modificate the board itself. Background: The capacity of the new flash chip is twice as large (4MBit) as the original chip, so we can burn a full BIOS in the lower part of the memory AND in the upper part of the memory. To choose between them, we use the highest address pin (A18). If A18 is low, the "lower" BIOS is selected, if it is high, the "upper" BIOS is activated (you need a reboot of course). I use this setup since 5 days and everything is working as it should. Please don't build it, if you do not know what I'm talking about!!! Use it at your own risk !!!! Installation: Take a AMD 29F040(B)-70 (you can find them on ebay) flash chip, bend Pin 1 (A18) in the other direction, as close to the chip as possible. Then solder an isolated wire to this pin, isolate this pin EVERYWHERE with a piece of tape (it's IMPORTANT, that it doesn't get contact with the PLCC socket pin, you can't bend it so close to the chip) and solder this wire to the "middle" contact (which connects EITHER to the left pin OR to the right pin) of a 3-pin-switch. Now you have to find a 5V and GND source, solder/connect two isolated wires to them and solder the other side of the wires to the two other pins of the 3-pin-switch. For other boards than the EPIA5000 you have to be sure, that the supply voltage of the flash chip (called VCC) is 5V, otherwise you have to measure it and search for a source equal to the measured voltage (!!!they have to be the same!!!). For the EPIA5000 you can use the "Modem wakeup" connector, take an appropriate plug inclusive wires and connect the other sides of the wire to the switch (that's what I did). If your board is powered on, TURN OFF YOUR BOARD NOW, insert the AMD flash chip (take out the SSF 39SF020A before :-) ) and make sure, that pin 1 of the flash chip has no electrical contact to the PLCC socket contact. Make sure that you soldered your switch as described above: Pin 1 of the flash chip has to be connected (through the switch) to EITHER VCC (for EPIA = 5V) OR GND. If everything was OK, you are ready with the hardware part. Reinsert the original flash chip, boot Linux, get the original BIOS file, replace /freebios/util/flash_and_burn/flash_rom.c with this one at http://www.mikrosol.de/flash_rom.c (it is the SAME sourcecode, but the size of the 29F040 is reduced to burn only 256KB), compile it, take the chip out while power is turned on, insert the soldered AMD chip, write the original bios to the flash chip (if you have an EPROM Programmer, use it, cause it is safer) and mark the position of the switch. Everytime you will switch to this position, you are booting the ORIGINAL BIOS. If you want to burn the other part of the memory, switch to the other side (while power is on and you are at the console) and burn it. Be aware that both parts of the memory are writable, so you have to check the position of the switch BEFORE you are flashing. Flashing at the marked position of the switch is only necessary, if you want to replace the original bios. That's all! Really helpful I think! Best regards, Sven From sven.luebke at mikrosol.de Sun Sep 21 08:22:00 2003 From: sven.luebke at mikrosol.de (Sven Luebke) Date: Sun Sep 21 08:22:00 2003 Subject: EPIA5000 & parallel port In-Reply-To: <5.1.1.6.2.20030921135651.021c79b0@pop.onlinehome.de> Message-ID: <5.1.1.6.2.20030921143948.05d96d18@pop.onlinehome.de> At 13:57 21.09.2003 +0200, Sven Luebke wrote: Hi again! >I had the same problem and implemented the parallel port initialization. >It is working now, patches sent >to Ron Minnich, but he wanted to do some cosmetic changes next week. If >you are in a hurry, you can >download it here, > >http://www.mikrosol.de/southbridge.c copy it >to freebios\src\superio\via\vt8231\ >http://www.mikrosol.de/setup_serial.inc copy it >to freebios\src\southbridge\via\vt8231\ For some reason *.inc files are not downloadable. Use these diff files instead: http://www.mikrosol.de/southbridge.diff http://www.mikrosol.de/setup_serial.diff Best regards, Sven From ts1 at tsn.or.jp Sun Sep 21 09:33:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sun Sep 21 09:33:00 2003 Subject: epia800 direct vga working In-Reply-To: <3F6D4476.8000303@nexpath.com> References: <3F6D4476.8000303@nexpath.com> Message-ID: <20030921135510.GA8580@tsn.or.jp> On Sat, Sep 20, 2003 at 11:25:58PM -0700, Steve Gehlbach wrote: > Nathanael Noblet wrote: > > >I don't need a framebuffer on boot, but once loaded would I be able to > >insmod the epiafb module and get that working? > > More than likely, since a framebuffer driver made for epia vga must have > intimate knowledge of the chipset, so it should completely initialize it. Unfortunately it does not. Looks like we have to program some more VGA registers for framebuffer to function properly. > >Though, I'm wondering if the modifications you've made are (specifically > >the epia800.config) are compatible with an elf filo payload? The add > >action commands seem to run after the commands that concatenate the > >linuxbios image file with its payload.. so I'm somewhat at a loss as to > >what to flash the chip with. If you know what I mean. > I have not used payloads, so I am not sure, maybe others can comment. Steve's config uses linux loader rather than ELF loader. -- Takeshi From charlet.damien at libertysurf.fr Sun Sep 21 10:34:00 2003 From: charlet.damien at libertysurf.fr (Damien Charlet) Date: Sun Sep 21 10:34:00 2003 Subject: flash_rom & epia 800 Message-ID: <20030921165616.220df123.charlet.damien@libertysurf.fr> Hello list, First of all thank all of you for this great work. I'd like to flash my epia 800 + bios savior with linuxbios. Un fortunately flash_rom doesn't manage to write correctly the rom image, even after numerous tries. I removed the prints statement in w49f002u.c (the chip detected) to see if that helps with timings, but it doesn't change anything. The version I use is last friday's CVS. I've seen that different people have had problems of the same type, how have you solved that ? thx Damien -- Damien(.)Charlet(AT pu-pm.univ-fcomte.fr) Doctorant UIN:78754463 Laboratoire d'Informatique de l'Universite de Franche-Comte FRE CNRS 2661 - Centre de Developement du Multimedia de Montbeliard Tel: +33-(0)3.81.99.47.76 damien.charlet at pu-pm.univ-fcomte.fr From steve at nexpath.com Sun Sep 21 13:27:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sun Sep 21 13:27:00 2003 Subject: epia800 direct vga working In-Reply-To: <20030921135510.GA8580@tsn.or.jp> References: <3F6D4476.8000303@nexpath.com> <20030921135510.GA8580@tsn.or.jp> Message-ID: <3F6DE4BA.2040009@nexpath.com> SONE Takeshi wrote: > On Sat, Sep 20, 2003 at 11:25:58PM -0700, Steve Gehlbach wrote: > >>Nathanael Noblet wrote: >> >> >>>I don't need a framebuffer on boot, but once loaded would I be able to >>>insmod the epiafb module and get that working? >> >>More than likely, since a framebuffer driver made for epia vga must have >>intimate knowledge of the chipset, so it should completely initialize it. > > > Unfortunately it does not. Looks like we have to program some more > VGA registers for framebuffer to function properly. > > Hmmm... this is strange. Has anyone used HAVE_FRAMEBUFFER option without VIDEO_CONSOLE and gotten that to work? The only difference is the 0xFB chipset register, however, the setting I use matches the Award setting when it boots. The HAVE_FRAMEBUFER sets the framebuffer size to something different, but I don't think this is releveant, my setting would be 8M but the frambuffer access bit (bit 3) is off, and the address of the framebuffer is not set (bits 2-0 and reg 0xFA and others). I suspect it has something to do with the graphics aperture settings (GA). The GA relevant registers are 0x13 and 0x80-0x8B. You can try putting in the settings at the bottom of afteram.inc (this file is not used in my config), the CS_WRITE commands to 0x13, 0x84, 0x80, 0x88. These match the Award settings, except for 0x84, which is 0 in Award (256M aperture) rather than 0xc0 (64M aperture). I know that these registers can cause hangs, though. I would try putting these in the vgainit.inc file replacing the 0x88 setting where it says "turn off GA". Which epiafb are you using? Maybe I can try it later this week, but I am not a big user of framebuffers. -Steve From nathanael at gnat.ca Sun Sep 21 14:03:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun Sep 21 14:03:01 2003 Subject: epia800 direct vga working In-Reply-To: <3F6DE4BA.2040009@nexpath.com> Message-ID: On Sunday, September 21, 2003, at 11:49 AM, Steve Gehlbach wrote: > SONE Takeshi wrote: >> On Sat, Sep 20, 2003 at 11:25:58PM -0700, Steve Gehlbach wrote: >>> Nathanael Noblet wrote: >>> >>> >>>> I don't need a framebuffer on boot, but once loaded would I be able >>>> to insmod the epiafb module and get that working? >>> >>> More than likely, since a framebuffer driver made for epia vga must >>> have intimate knowledge of the chipset, so it should completely >>> initialize it. >> Unfortunately it does not. Looks like we have to program some more >> VGA registers for framebuffer to function properly. > > Hmmm... this is strange. Has anyone used HAVE_FRAMEBUFFER option > without VIDEO_CONSOLE and gotten that to work? The only difference is > the 0xFB chipset register, however, the setting I use matches the > Award setting when it boots. The HAVE_FRAMEBUFER sets the framebuffer > size to something different, but I don't think this is releveant, my > setting would be 8M but the frambuffer access bit (bit 3) is off, and > the address of the framebuffer is not set (bits 2-0 and reg 0xFA and > others). > > I suspect it has something to do with the graphics aperture settings > (GA). The GA relevant registers are 0x13 and 0x80-0x8B. You can try > putting in the settings at the bottom of afteram.inc (this file is not > used in my config), the CS_WRITE commands to 0x13, 0x84, 0x80, 0x88. > These match the Award settings, except for 0x84, which is 0 in Award > (256M aperture) rather than 0xc0 (64M aperture). I know that these > registers can cause hangs, though. I would try putting these in the > vgainit.inc file replacing the 0x88 setting where it says "turn off > GA". > > Which epiafb are you using? Maybe I can try it later this week, but I > am not a big user of framebuffers. I've used the epiafb (epiafb.sf.net) and I'm currently working on getting the tridentfb to work. I am noticing some kernel oops? Though the system is still functional, but the vga console is garbled. I have yet to get the epiafb working or even try the tridentfb with a linuxbios boot. The epia complains of unresolved dependancies which look like missing symbols for the generic framebuffer, even though that is loaded... so I'm not sure what is going on there. I have been taking lspci -xxx output of each boot, normal boot, filo boot, filo with vgabios extracted boot. I have noticed differences in the register settings between the two. Where do you get the CS_WRITE and register information about this board? And more importantly, can I have a copy? I have yet to get your changes to work though, mainly because of the difference in the payloads, though that is on my list of getting working. I'd like to see from there how it goes. I haven't looked much at the new code you supplied a diff for, but will be poking around there, though a spec sheet as always would be nice. Thanks so far for the work and information... -- 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 ts1 at tsn.or.jp Sun Sep 21 14:32:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sun Sep 21 14:32:01 2003 Subject: epia800 direct vga working In-Reply-To: <3F6DE4BA.2040009@nexpath.com> References: <3F6D4476.8000303@nexpath.com> <20030921135510.GA8580@tsn.or.jp> <3F6DE4BA.2040009@nexpath.com> Message-ID: <20030921185350.GA18349@tsn.or.jp> On Sun, Sep 21, 2003 at 10:49:46AM -0700, Steve Gehlbach wrote: > Hmmm... this is strange. Has anyone used HAVE_FRAMEBUFFER option > without VIDEO_CONSOLE and gotten that to work? The only difference is > the 0xFB chipset register, however, the setting I use matches the Award > setting when it boots. The HAVE_FRAMEBUFER sets the framebuffer size to > something different, but I don't think this is releveant, my setting > would be 8M but the frambuffer access bit (bit 3) is off, and the > address of the framebuffer is not set (bits 2-0 and reg 0xFA and others). Both HAVE_FRAMEBUFFER and VIDEO_CONSOLE set 0xB0 to register 0xFB in a default config (SMA_SIZE==8). With only this setting, if I run the factory VGABIOS, it does all the rest of configuation to VGA (and TV encoder also), and I can use epiafb, or even X, with TV-out, flawlessly. I don't touch GA registers, neither do VGABIOS. So I think the missing bit is in the VGA registers. -- Takeshi From ts1 at tsn.or.jp Sun Sep 21 14:38:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sun Sep 21 14:38:01 2003 Subject: epia800 direct vga working In-Reply-To: References: <3F6DE4BA.2040009@nexpath.com> Message-ID: <20030921185947.GB18349@tsn.or.jp> On Sun, Sep 21, 2003 at 12:25:01PM -0600, Nathanael Noblet wrote: > I have yet to get the epiafb working or even try the tridentfb with a > linuxbios boot. The epia complains of unresolved dependancies which > look like missing symbols for the generic framebuffer, even though that > is loaded... so I'm not sure what is going on there. Did you enabled (and build and insmod) kernel options like "8 bpp packed pixels support" (and others)? I think this is bug in epiafb documentation. -- Takeshi From ts1 at tsn.or.jp Sun Sep 21 14:44:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sun Sep 21 14:44:01 2003 Subject: flash_rom & epia 800 In-Reply-To: <20030921165616.220df123.charlet.damien@libertysurf.fr> References: <20030921165616.220df123.charlet.damien@libertysurf.fr> Message-ID: <20030921190629.GC18349@tsn.or.jp> On Sun, Sep 21, 2003 at 04:56:16PM +0200, Damien Charlet wrote: > I removed the prints statement in w49f002u.c (the chip detected) to see if that helps with timings, but it doesn't change anything. My EPIA uses SST chip and my BIOS Saviour has Mx chip. Yours has different one... -- Takeshi From nathanael at gnat.ca Sun Sep 21 14:47:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun Sep 21 14:47:01 2003 Subject: epia800 direct vga working In-Reply-To: <20030921185947.GB18349@tsn.or.jp> Message-ID: <128883BC-EC67-11D7-8818-0003931B4D6A@gnat.ca> On Sunday, September 21, 2003, at 12:59 PM, SONE Takeshi wrote: > On Sun, Sep 21, 2003 at 12:25:01PM -0600, Nathanael Noblet wrote: >> I have yet to get the epiafb working or even try the tridentfb with a >> linuxbios boot. The epia complains of unresolved dependancies which >> look like missing symbols for the generic framebuffer, even though >> that >> is loaded... so I'm not sure what is going on there. > > Did you enabled (and build and insmod) kernel options like > "8 bpp packed pixels support" (and others)? > I think this is bug in epiafb documentation. Not sure, I'm using the stock kernel that came with my distro (RedHat at the moment)... It works when the original bios is booted. I have only moments ago realized which modules weren't being loaded (the fb_con-*) which once loaded I loaded the vesafb module. I'll try the epiafb next. At the moment though, I'm having difficulty getting filo to boot anything but the original kernel. Here is what I have done. Perhaps you have insight into the problem. in the filo Config file: AUTOBOOT_FILE = "hda1:/epia.vmlinuz root...." now if I, using the boot prompt provided by filo, attempt to boot any other kernel, specifically in this instance a 2.4.22 vanilla kernel, compiled on the target machine, and which mkelfimage 2.5 has been run against. It says it cannot find the file. I couldn't figure out why. I used epia.vmlinuz-2.4.22 as a name, thought perhaps that FILO couldn't read it for one reason or another, filename length or something. Anyway so I copied it to epia.vmlinux22, no go there either. So then I made a backup of the epia.vmlinuz as epia.vmlinuz-bak and overwrote the epia.vmlinuz file with my 2.4.22 version and rebooted. Let it autoboot, which it did, but well it booted the elf image version of the original kernel 2.4.20-20.9 (the Redhat one that I had renamed and overwritten with something else) not sure what is happening here. -- 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 ts1 at tsn.or.jp Sun Sep 21 15:06:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Sun Sep 21 15:06:01 2003 Subject: epia800 direct vga working In-Reply-To: <128883BC-EC67-11D7-8818-0003931B4D6A@gnat.ca> References: <20030921185947.GB18349@tsn.or.jp> <128883BC-EC67-11D7-8818-0003931B4D6A@gnat.ca> Message-ID: <20030921192824.GA19639@tsn.or.jp> On Sun, Sep 21, 2003 at 01:09:06PM -0600, Nathanael Noblet wrote: > At the moment though, I'm having difficulty getting filo to boot > anything but the original kernel. > > Here is what I have done. Perhaps you have insight into the problem. > > in the filo Config file: > AUTOBOOT_FILE = "hda1:/epia.vmlinuz root...." Could you enable DEBUG_ALL, and also add a line "E2DEBUG = 1" to Config (if the kernel is on ext2/3 fs. For other filesystems you could use relevant debug option, find it in the fs directory). It will spit out lots of messages, more than you ever want. -- Takeshi From nathanael at gnat.ca Sun Sep 21 15:23:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun Sep 21 15:23:00 2003 Subject: epia800 direct vga working In-Reply-To: <20030921192824.GA19639@tsn.or.jp> Message-ID: <20B53793-EC6C-11D7-8818-0003931B4D6A@gnat.ca> On Sunday, September 21, 2003, at 01:28 PM, SONE Takeshi wrote: > On Sun, Sep 21, 2003 at 01:09:06PM -0600, Nathanael Noblet wrote: >> At the moment though, I'm having difficulty getting filo to boot >> anything but the original kernel. >> >> Here is what I have done. Perhaps you have insight into the problem. >> >> in the filo Config file: >> AUTOBOOT_FILE = "hda1:/epia.vmlinuz root...." > > Could you enable DEBUG_ALL, and also add a line "E2DEBUG = 1" to Config > (if the kernel is on ext2/3 fs. For other filesystems you could use > relevant debug option, find it in the fs directory). > It will spit out lots of messages, more than you ever want. doing that now. I'll send the debug messages if I can't figure it out myself just a FYI, I removed the file from the partition and it is still booting using that file apparently??? I'm really at a loss now, hopefully this debug messages gives me a clue as to what is happening. -- 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 steve at nexpath.com Sun Sep 21 16:18:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sun Sep 21 16:18:00 2003 Subject: epia800 direct vga working In-Reply-To: <20030921185350.GA18349@tsn.or.jp> References: <3F6D4476.8000303@nexpath.com> <20030921135510.GA8580@tsn.or.jp> <3F6DE4BA.2040009@nexpath.com> <20030921185350.GA18349@tsn.or.jp> Message-ID: <3F6E0CD4.6010906@nexpath.com> SONE Takeshi wrote: > Both HAVE_FRAMEBUFFER and VIDEO_CONSOLE set 0xB0 to register 0xFB > in a default config (SMA_SIZE==8). > > With only this setting, if I run the factory VGABIOS, it does all > the rest of configuation to VGA (and TV encoder also), and > I can use epiafb, or even X, with TV-out, flawlessly. > > I don't touch GA registers, neither do VGABIOS. > > So I think the missing bit is in the VGA registers. Hmmm... well if it is not the GA setup, then this could be more difficult. I see that the epiafb is not a binary from via, as I was assuming, but open source. So at least we can look at the code and see what they are doing. There are quite a number of extended function vga registers in the epia, however, so it is hard to know which ones are important. Probably the way to proceed on this is to take a snap of the vga extended registers with Award, then boot with linuxbios and set some registers to match Award that look promising, and each time try insmod'ing the driver until it works. This takes some simple C code to set and read the various vga registers, which I have, so I will try this when I get a chance. -Steve From nathanael at gnat.ca Sun Sep 21 18:54:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Sun Sep 21 18:54:00 2003 Subject: epia800 direct vga working In-Reply-To: <20030921192824.GA19639@tsn.or.jp> Message-ID: <869602E4-EC89-11D7-8818-0003931B4D6A@gnat.ca> On Sunday, September 21, 2003, at 01:28 PM, SONE Takeshi wrote: > On Sun, Sep 21, 2003 at 01:09:06PM -0600, Nathanael Noblet wrote: >> At the moment though, I'm having difficulty getting filo to boot >> anything but the original kernel. >> >> Here is what I have done. Perhaps you have insight into the problem. >> >> in the filo Config file: >> AUTOBOOT_FILE = "hda1:/epia.vmlinuz root...." > > Could you enable DEBUG_ALL, and also add a line "E2DEBUG = 1" to Config > (if the kernel is on ext2/3 fs. Ok so this is embarrassing, somehow I had a stray old boot partition that had the image on it but not the others... I figured that part out after it could boot without there being the file there at all... took a look at the partition table and such... Anyway so it is now booting with VGABIOS and FRAMEBUFFER etc... I can load the epiafb and get a console FB working. The problem I had after this (this is the second time I go through this... I want to really understand what I'm doing) I couldn't run any of the DirectFB example apps... I bet this has to do with those extended registers that we're missing... I will be getting the different lspci register dumps to compare the regular AWARD bios settings and the linuxbios vga settings. -- 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 Sun Sep 21 19:45:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Sep 21 19:45:00 2003 Subject: EPIA5000 & parallel port In-Reply-To: <3F6D7444.9020108@denkmair.de> Message-ID: we're working the lp0 issue. ron From rminnich at lanl.gov Sun Sep 21 21:17:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Sep 21 21:17:00 2003 Subject: epia800 direct vga working In-Reply-To: <869602E4-EC89-11D7-8818-0003931B4D6A@gnat.ca> Message-ID: And HOWTO on these last steps, with sample kernel .config, is most welcome. ron From bendany at mistdl.com Mon Sep 22 02:36:01 2003 From: bendany at mistdl.com (bendany) Date: Mon Sep 22 02:36:01 2003 Subject: about SIS630 base mainboard & direct VGA support Message-ID: <0f8301c380d6$f212f070$2a00a8c0@ben> hi all, I am working with a mainboard similar to PCCHIPS m758lmr+. I want to enable VGA support. but I get some error message. ======================================================== PCCHIPS m758lmr+ (and similar)...Entering the initregs process Southbridge fixup done for SIS 603 handle_superio start, nsuperio 1 handle_superio: Pass 2, check #0, s 0000bba0 s->super 0000bef8 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 INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1039, did=6300 0x55 0xaa 0x60 0xe9 0x53 0x2 0x31 0x2e 0x30 0x37 0x2e 0x35 0x34 0x20 0x2d 0x6a biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 biosint: ip 0x3 cs 0x0 flags 0x46 biosint: Unsupport int #0x6 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 biosint: ip 0x3 cs 0x0 flags 0x46 ........................... =================================================================== It seems that the biosint unsupport some bioscall. how can I solve this problem? btw: this mainboard works fine with LinuxBIOS+FILO. best reguards. bendany. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: serialoutput.txt URL: From niki.waibel at newlogic.com Mon Sep 22 06:33:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Sep 22 06:33:00 2003 Subject: linuxbios on epia-m -- not starting Message-ID: <200309221054.h8MAsph4017173@enterprise2.newlogic.at> linuxbios does not start ... i can see: === LinuxBIOS-1.0.0 Mon Sep 22 02:17:36 CEST 2003 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. === that's it. first i tought it is a mem problem (512MB Infineon CL2). i changed 0x350 to 0x150 in src/northbridge/via/vt8623/raminit.inc and i've activated ../freebios/src/ram/ramtest.inc in ../freebios/src/mainboard/via/epia-m/Config. it seems that everything is ok: === LinuxBIOS-1.0.0 Mon Sep 22 12:38:53 CEST 2003 starting... Testing SDRAM : 00000000-0009ffff SDRAM fill: 0009ffff SDRAM verify: 0009ffff Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. === so i tried to figure out where the stop occurs. i verified if the code is copied correctly: === LinuxBIOS-1.0.0 Mon Sep 22 02:17:36 CEST 2003 starting... Copying LinuxBIOS to ram. NIKI: Jumping to LinuxBIOS. src: 000f0b70 dst: 00004000 size: 0000aa8c src_code: 010f2efa00405215 dst_code: 010f2efa00405215 === -> fine. unfort i dont know much about x86 asm... but it seems that the problem is somewhere in c_start.s ... if i put movl $0xfffe0000, %edi jmp *%edi to the top of the _start: function then linuxbios loops. (i just wanted to check if the copied code is executed...) is that a better way to find out what's wrong? by the way: === gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s crt0.S: Assembler messages: crt0.S:163: Warning: indirect jmp without `*' === instead of: leal _iseg, %edi jmp %edi shouldn't it be: leal _iseg, %edi jmp *%edi ? niki w. waibel From moedeker at hmk-gmbh.de Mon Sep 22 07:29:01 2003 From: moedeker at hmk-gmbh.de (=?US-ASCII?Q?Bernd_Modeker?=) Date: Mon Sep 22 07:29:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <3F6E0CD4.6010906@nexpath.com> Message-ID: <135968A4EEB54B43A96B269C80D3B2C59BF1@frontman.hmk.de> I saw a discussion in the list on the same problem with epia800. Since one week we are working on a solution for having text console and framebuffer for national's SC1200. We came to the same result that the problem must be the vga registers which were normally set by the vgabios. So if we startup the system with linuxbios the vga registers are not set and we dont have a screen output on crt. If we boot with i.e. insyde bios we have output on crt. Is there anyone who solved this problem for SC1200? Benno From hubert at denkmair.de Mon Sep 22 09:22:01 2003 From: hubert at denkmair.de (Hubert Denkmair) Date: Mon Sep 22 09:22:01 2003 Subject: /dev/nvram useable? Message-ID: <3F6EFCB1.7030603@denkmair.de> Hello again, does anyone know if/how the linux /dev/nvram device is working with linuxbios and my Epia5000? I would love to store some status information of my car mp3 player in the nvram, since power supply can be cut any time and I want my harddisk to be mounted readonly. On linuxbios startup, the following two lines are printed: >RTC Init >Invalid CMOS LB checksum And after every linuxbios boot, when switching back to the original BIOS, it complains "CMOS checksum error, defaults loaded..." Writing to /dev/nvram raises no error (echo "hello" > /dev/nvram), but reading from /dev/nvram results in "reading `/dev/nvram': Input/output error" :( (How) can I use the nvram? Is there another possibility, maybe without the /dev/nvram device driver? Hubert From rminnich at lanl.gov Mon Sep 22 09:38:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 09:38:01 2003 Subject: about SIS630 base mainboard & direct VGA support In-Reply-To: <0f8301c380d6$f212f070$2a00a8c0@ben> Message-ID: On Mon, 22 Sep 2003, bendany wrote: > biosint: ip 0x3 cs 0x0 flags 0x46 > biosint: Unsupport int #0x6 > biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e > biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 > biosint: ip 0x3 cs 0x0 flags 0x46 > biosint: Unsupport int #0x6 > biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x20 edx 0x9d2e > biosint: ebp 0x12060 esp 0xff6 edi 0xe0ac esi 0x846a2 > biosint: ip 0x3 cs 0x0 flags 0x46 as mentioned before this is a real trap of some sort. I don't know what's going wrong on this case. ron From rminnich at lanl.gov Mon Sep 22 09:44:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 09:44:00 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: <200309221054.h8MAsph4017173@enterprise2.newlogic.at> Message-ID: I think you should get memtest86, set it up to run on serial console, and see if it works or not. ron From rminnich at lanl.gov Mon Sep 22 09:46:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 09:46:00 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <135968A4EEB54B43A96B269C80D3B2C59BF1@frontman.hmk.de> Message-ID: On Mon, 22 Sep 2003, Bernd Modeker wrote: > Is there anyone who solved this problem for SC1200? not yet. If you have a copy of the vgabios binary for that hardware you could try seeing if it would work. The vga register problem is a mess, as the vendors rarely want to help. ron From rminnich at lanl.gov Mon Sep 22 09:49:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 09:49:00 2003 Subject: /dev/nvram useable? In-Reply-To: <3F6EFCB1.7030603@denkmair.de> Message-ID: this these. ron -------------- next part -------------- /* * $Id: rdcmos.c,v 1.1 1998/09/24 21:08:20 hendriks Exp $ */ #include #include #include #include static inline unsigned char readreg(int regno) { outb(regno, 0x70); return inb(0x71); } static inline void writereg(int regno, unsigned char val) { outb(regno, 0x70); outb(val, 0x71); } unsigned char data[128]; int main(int argc, char *argv[]) { int i; if (ioperm(0x70, 2, 1) == -1) { perror("ioperm"); exit(1); } for (i=0; i < 128; i++) data[i] = readreg(i); write(STDOUT_FILENO, data, sizeof(data)); exit(0); } -------------- next part -------------- /* * * $Id: wrcmos.c,v 1.1 1998/09/24 21:08:20 hendriks Exp $ */ #include #include #include #include static inline unsigned char readreg(int regno) { outb(regno, 0x70); return inb(0x71); } static inline void writereg(int regno, unsigned char val) { outb(regno, 0x70); outb(val, 0x71); } unsigned char data[128]; int main(int argc, char *argv[]) { int i; if (ioperm(0x70, 2, 1) == -1) { perror("ioperm"); exit(1); } read(STDIN_FILENO, data, sizeof(data)); for (i=0; i < 128; i++) writereg(i, data[i]); exit(0); } From niki.waibel at newlogic.com Mon Sep 22 10:18:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Sep 22 10:18:01 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: Message-ID: <200309221440.h8MEe9h4017071@enterprise2.newlogic.at> > I think you should get memtest86, set it up to run on serial console, and > see if it works or not. hmmm -- you mean with lilo? i've never used memtest86. will give it a try. niki From rminnich at lanl.gov Mon Sep 22 10:20:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 10:20:01 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: <200309221440.h8MEe9h4017071@enterprise2.newlogic.at> Message-ID: On Mon, 22 Sep 2003, Niki Waibel wrote: > i've never used memtest86. make memtest86 the payload. be sure to build with serial console only. ron From niki.waibel at newlogic.com Mon Sep 22 10:53:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Sep 22 10:53:00 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: Message-ID: <200309221515.h8MFF0h4021747@enterprise2.newlogic.at> >> i've never used memtest86. > > make memtest86 the payload. be sure to build with serial console only. no, no, that does not work. the payload is never loaded/reached. the trouble is caused earier! right after crt0.s a jmp to the copied mem is done. the copied mem is c_start.s at the beginning. there it seems to stop. (otherwise i'd see the messages from hardwaremain.c, am i wrong?) anyway -- running memtest86 with lilo right now and it seems that everything is fine (test4 is running. it will take some time to finnish). i dont think it is a mem problem (but i might be wrong). niki From steve at nexpath.com Mon Sep 22 11:15:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 22 11:15:01 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: <200309221515.h8MFF0h4021747@enterprise2.newlogic.at> References: <200309221515.h8MFF0h4021747@enterprise2.newlogic.at> Message-ID: <3F6F1961.60601@nexpath.com> Niki Waibel wrote: > anyway -- running memtest86 with lilo right now and > it seems that everything is fine (test4 is running. > it will take some time to finnish). i dont think it > is a mem problem (but i might be wrong). > But the issue is, is linuxbios setting up ram correctly. I posted some time ago some simple assy language instructions to check each byte as it is copied to ram. Or make your own, but as the C-code is copied test each byte and see if it matches. Did you try both ram slots? I think only one works with a single SDRAM. Also set CONFIG_COMPRESS=0 is simpler code. What size SDRAM? -Steve From niki.waibel at newlogic.com Mon Sep 22 11:19:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Mon Sep 22 11:19:00 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: <3F6F1961.60601@nexpath.com> Message-ID: <200309221541.h8MFfZh4025640@enterprise2.newlogic.at> >> anyway -- running memtest86 with lilo right now and >> it seems that everything is fine (test4 is running. >> it will take some time to finnish). i dont think it >> is a mem problem (but i might be wrong). >> > > But the issue is, is linuxbios setting up ram correctly. I posted some > time ago some simple assy language instructions to check each byte as it > is copied to ram. Or make your own, but as the C-code is copied test > each byte and see if it matches. > > Did you try both ram slots? there is only one in the epia-m (600mhz). > I think only one works with a single SDRAM. > Also set CONFIG_COMPRESS=0 is simpler code. What size SDRAM? i use CONFIG_COMPRESS=0. size is 512MByte CL2. have to leave company now. pls Cc ``niki dot waibel at gmx dot net''. thanks, niki From dhroepaem at freechal.com Mon Sep 22 11:22:01 2003 From: dhroepaem at freechal.com (dhroepaem at freechal.com) Date: Mon Sep 22 11:22:01 2003 Subject: supporting the EPIA-M 10000 VGA Message-ID: <6539.1064245433241.JavaMail.Administrator@smtp3> thanks, andrew i used 57600 instead so i solved the problem of original and linux bios. now i can boot linux by serial but i need to support vga i read past mailing lists but i couldn't get a certain answer i tried to do howto like epia but failed how can i support vga on epia-m 10000? have a nice day~ :) ??? 3D??? ?? ??!! ???? ?? ???? ?????. http://3dmall.freechal.com/AvtMall/ImMall.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at nexpath.com Mon Sep 22 11:23:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 22 11:23:00 2003 Subject: linuxbios on epia-m -- not starting In-Reply-To: <200309221541.h8MFfZh4025640@enterprise2.newlogic.at> References: <200309221541.h8MFfZh4025640@enterprise2.newlogic.at> Message-ID: <3F6F1B51.6060309@nexpath.com> Niki Waibel wrote: > size is 512MByte CL2. > The only thing I can think of is to try a different/ smaller SDRAM; 64M or 128M. The RAM setup code is not always that smart about configuration. But has anyone else got the epia-m working? I have only used EPIA-800. -Steve From rminnich at lanl.gov Mon Sep 22 11:56:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 11:56:01 2003 Subject: supporting the EPIA-M 10000 VGA [PMX:##] In-Reply-To: <6539.1064245433241.JavaMail.Administrator@smtp3> Message-ID: I just committed various patches that have allowed us here to use VGA on the M800 ron From amits at myrealbox.com Mon Sep 22 12:47:00 2003 From: amits at myrealbox.com (amits at myrealbox.com) Date: Mon Sep 22 12:47:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: References: Message-ID: <200309221646.h8MGku815465@nwn.definitive.org> Hi , How do I extract the VGA BIOS from the Insyde ExpressROM??the same way as in case of the EPIA will work? ANd in that case ... how can we find out IF it uses some calls that are implemented in the underlying XpressROM BIOS ?? rgds, Amit. On Sat 20 Sep 03 00:29, you wrote: > On Fri, 19 Sep 2003 amits at myrealbox.com wrote: > > Is it possible to extract the VideoBIOS from the XpressROM and use it > > somehow like in the EPIA ?? If yes has anyone done it? > > It ought to work but I don't know if anyone has done it. > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From nathanael at gnat.ca Mon Sep 22 14:12:01 2003 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon Sep 22 14:12:01 2003 Subject: epia800 direct vga working Message-ID: <1064255673.9795.6.camel@platinum.gnat.ca> Hello, So I've got the epia800 working with the original BIOS that was extracted from the original BIOS. I've been looking over the code that was submitted, and as well as the difference between register settings on boot with regular BIOS settings and LinuxBIOS settings. I have been trying to get DirectFB to work with the epiafb module. It works when I boot with regular bios, but not the LinuxBIOS version. Here are the differences between the two. ORIGINAL 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) 00: 23 10 00 85 07 00 b0 02 6a 00 00 03 00 20 00 00 10: 00 00 80 e1 00 00 00 e2 00 00 00 e1 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 23 10 00 85 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00 LINUXBIOS with extracted VGABIOS 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) 00: 23 10 00 85 03 00 b0 02 6a 00 00 03 00 40 00 00 10: 00 00 80 fd 00 00 80 fe 00 00 00 fe 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 23 10 00 85 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 01 00 00 I remember working on a sis530 board that had to set particular registers, I'm wondering if someone can give me a little tutorial on how to read these values and turn them into a corresponding register address so that I can play around with the settings to get it all working. Once I have that all working like the original bios I guess the direct vga changes could incorporate the changes and we would not need the VGABIOS if I am not mistaken? I'd like to help, but need to know how to go about reading the above in a better way then I know right now... -- Nathanael D. Noblet Gnat Solutions From ts1 at tsn.or.jp Mon Sep 22 15:00:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Mon Sep 22 15:00:01 2003 Subject: epia800 direct vga working In-Reply-To: <1064255673.9795.6.camel@platinum.gnat.ca> References: <1064255673.9795.6.camel@platinum.gnat.ca> Message-ID: <20030922192228.GA16269@tsn.or.jp> On Mon, Sep 22, 2003 at 12:34:33PM -0600, Nathanael D. Noblet wrote: > ORIGINAL > 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 > (rev 6a) > 00: 23 10 00 85 07 00 b0 02 6a 00 00 03 00 20 00 00 > 10: 00 00 80 e1 00 00 00 e2 00 00 00 e1 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 23 10 00 85 > 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00 > LINUXBIOS with extracted VGABIOS > 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 > (rev 6a) > 00: 23 10 00 85 03 00 b0 02 6a 00 00 03 00 40 00 00 > 10: 00 00 80 fd 00 00 80 fe 00 00 00 fe 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 23 10 00 85 > 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 01 00 00 > > I remember working on a sis530 board that had to set particular > registers, I'm wondering if someone can give me a little tutorial on how > to read these values and turn them into a corresponding register address > so that I can play around with the settings to get it all working. Once > I have that all working like the original bios I guess the direct vga > changes could incorporate the changes and we would not need the VGABIOS > if I am not mistaken? I'd like to help, but need to know how to go about > reading the above in a better way then I know right now... This is PCI configuration space registers. And it is not the device specific part. Usually there is no intersting thing here. You see some differences in resource assignment. Different BIOSes assign different framebuffer address, etc. The real fun part is in the extended VGA registers. And just dumping them all is not a trivial task. You can see what the standard VGA registers look like at FreeVGA project. Our VGA device has lots of extended registers over this standard. Some of them are on "the other side" of standard registers (something like "reading this standard register 4 times turns it into the extended register"). -- Takeshi From charlet.damien at libertysurf.fr Mon Sep 22 15:31:00 2003 From: charlet.damien at libertysurf.fr (Damien Charlet) Date: Mon Sep 22 15:31:00 2003 Subject: w49f002u.c ? Message-ID: <20030922215348.59c17ac0.charlet.damien@libertysurf.fr> First, Thank you for your answers. Unfortunately I tried again and again today and I can't properly flash my winbond chip. I even tried to nice -19 flash_rom, remove the print's but it doesn't help. I dumped several time the content burned, and there are each time several errors, not twice the same, randomly placed across the chip. The wrong bytes are often burned as FF, but this is not always the case. What else could I try ? Where should I dig into ? Thx Damien -- Damien(.)Charlet(AT pu-pm.univ-fcomte.fr) Doctorant UIN:78754463 Laboratoire d'Informatique de l'Universite de Franche-Comte FRE CNRS 2661 - Centre de Developement du Multimedia de Montbeliard Tel: +33-(0)3.81.99.47.76 damien.charlet at pu-pm.univ-fcomte.fr From rminnich at lanl.gov Mon Sep 22 15:42:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 15:42:00 2003 Subject: w49f002u.c ? In-Reply-To: <20030922215348.59c17ac0.charlet.damien@libertysurf.fr> Message-ID: need more info. What is the chip that is in the socket already? Are you trying to burn a 49F in a slot that won't support it? ron From charlet.damien at libertysurf.fr Mon Sep 22 15:50:00 2003 From: charlet.damien at libertysurf.fr (Damien Charlet) Date: Mon Sep 22 15:50:00 2003 Subject: w49f002u.c ? In-Reply-To: References: <20030922215348.59c17ac0.charlet.damien@libertysurf.fr> Message-ID: <20030922221157.2518d319.charlet.damien@libertysurf.fr> [forgot to cc: the list - resending] Sorry, this is related to my previous mail "flash_rom and epia 800". I got a BIOS Savior on my via epia 800. The chip in the RD1-PL is (recognized as ?) a w49f002u. Maybe I should check physically which chip is on the savior ? On Mon, 22 Sep 2003 14:04:41 -0600 (MDT) ron minnich wrote: > need more info. > > What is the chip that is in the socket already? Are you trying to burn a > 49F in a slot that won't support it? > > ron -- Damien(.)Charlet(AT pu-pm.univ-fcomte.fr) Doctorant UIN:78754463 Laboratoire d'Informatique de l'Universite de Franche-Comte FRE CNRS 2661 - Centre de Developement du Multimedia de Montbeliard Tel: +33-(0)3.81.99.47.76 damien.charlet at pu-pm.univ-fcomte.fr From stepan at suse.de Mon Sep 22 16:02:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 22 16:02:00 2003 Subject: w49f002u.c ? In-Reply-To: <20030922221157.2518d319.charlet.damien@libertysurf.fr> References: <20030922215348.59c17ac0.charlet.damien@libertysurf.fr> <20030922221157.2518d319.charlet.damien@libertysurf.fr> Message-ID: <20030922202317.GB27912@suse.de> * Damien Charlet [030922 22:11]: > Sorry, this is related to my previous mail "flash_rom and epia 800". > > I got a BIOS Savior on my via epia 800. The chip in the RD1-PL is (recognized as ?) a w49f002u. Maybe I should check physically which chip is on the savior ? IIRC the Epia-M board I saw had a 39x020 in it instead a 49. Do you have the original bios chip to check? The Bios savior might not get the right voltage. Stefan -- Architecture Team SuSE Linux AG From charlet.damien at libertysurf.fr Mon Sep 22 16:13:01 2003 From: charlet.damien at libertysurf.fr (Damien Charlet) Date: Mon Sep 22 16:13:01 2003 Subject: w49f002u.c ? In-Reply-To: <20030922202317.GB27912@suse.de> References: <20030922215348.59c17ac0.charlet.damien@libertysurf.fr> <20030922221157.2518d319.charlet.damien@libertysurf.fr> <20030922202317.GB27912@suse.de> Message-ID: <20030922223550.1f9a2e20.charlet.damien@libertysurf.fr> My original BIOS is a 39SF020 A. According to http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionSheet.html I got the good savior for epia (better double check !). You don't think so ? Damien On Mon, 22 Sep 2003 22:23:17 +0200 Stefan Reinauer wrote: > IIRC the Epia-M board I saw had a 39x020 in it instead a 49. Do you have > the original bios chip to check? The Bios savior might not get the right > voltage. > Stefan > > > -- > Architecture Team > SuSE Linux AG -- Damien(.)Charlet(AT pu-pm.univ-fcomte.fr) Doctorant UIN:78754463 Laboratoire d'Informatique de l'Universite de Franche-Comte FRE CNRS 2661 - Centre de Developement du Multimedia de Montbeliard Tel: +33-(0)3.81.99.47.76 damien.charlet at pu-pm.univ-fcomte.fr From rminnich at lanl.gov Mon Sep 22 16:30:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 16:30:01 2003 Subject: w49f002u.c ? In-Reply-To: <20030922223550.1f9a2e20.charlet.damien@libertysurf.fr> Message-ID: On Mon, 22 Sep 2003, Damien Charlet wrote: > My original BIOS is a 39SF020 A. > > According to http://www.ioss.com.tw/web/English/RD1BIOSSavior/SelectionSheet.html I got the good savior for epia (better double check !). > You don't think so ? I don't think that 39F and 49F are compatible. ron From nathanael at gnat.ca Mon Sep 22 19:26:01 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Mon Sep 22 19:26:01 2003 Subject: unsupported int on Epia800 Message-ID: <2F482C75-ED57-11D7-B052-0003931B4D6A@gnat.ca> Hello, I'm still not sure what is causing it yet. I know it happens when I seem to turn on my epia board after it being off for awhile, while looking only at the screen and not the serial console. I get these message biosint: Unsupported int #0xff ... register settings... ... register settings... biosint: Unsupported int #0xfc ... register settings... ... register settings... biosint: Unsupported int #0xcd ... register settings... ... register settings... once I go back to look at the serial output because nothing is coming on screen. If I am viewing the output on serial, and turn it off then back on. This works. I always have linux shutdown cleanly and then power off. So I'm not sure what it is. I'm looking through that link posted earlier about BIOS Ints but haven't found these ones yet. Earlier when I was first getting this to work with my board I had had messages like these, only different ones I wrote them down biosint: Unsupported int #0xf7 ... register settings... ... register settings... biosint: Unsupported int #0xfc ... register settings... ... register settings... biosint: Unsupported int #0xc4 ... register settings... ... register settings... Ideas? -- 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 Mon Sep 22 19:33:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 19:33:01 2003 Subject: epia800 Message-ID: david hendriks has now built linuxbios from scratch, from the cvs tree, and it all works with graphics etc. ide is still not working well. ron From steve at nexpath.com Mon Sep 22 19:54:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 22 19:54:01 2003 Subject: epia800 In-Reply-To: References: Message-ID: <3F6F9319.3070306@nexpath.com> ron minnich wrote: > > ide is still not working well. > What I think I have found on the ide is that some older drives report they are LBA but sector reads fail. Maybe that they are CHS, or, it may be the status bits are different and it is a timing thing. But a simple read of linear sector 0 got the wrong data even though all areas of the ide code thought things were fine (no errors). -Steve From rminnich at lanl.gov Mon Sep 22 21:18:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 21:18:01 2003 Subject: epia800 In-Reply-To: <3F6F9319.3070306@nexpath.com> Message-ID: fixes welcome. This is CF that is failing. Actually it reads the data and the data is fine, but when it jumps to the payload nothing happens. ron From aip at cwlinux.com Mon Sep 22 21:35:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Sep 22 21:35:01 2003 Subject: epia800 In-Reply-To: ; from ron minnich on Mon, Sep 22, 2003 at 07:40:15PM -0600 References: <3F6F9319.3070306@nexpath.com> Message-ID: <20030923095743.A20557@mail.cwlinux.com> Hi Ron, > fixes welcome. This is CF that is failing. Actually it reads the data and > the data is fine, but when it jumps to the payload nothing happens. Have you tried different CF? Different CF behave differently. Some CF card need more delay/timeout in the IDE driver. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Mon Sep 22 21:44:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 21:44:00 2003 Subject: epia800 In-Reply-To: <20030923095743.A20557@mail.cwlinux.com> Message-ID: On Tue, 23 Sep 2003, Andrew Ip wrote: > > > fixes welcome. This is CF that is failing. Actually it reads the data and > > the data is fine, but when it jumps to the payload nothing happens. > Have you tried different CF? Different CF behave differently. Some CF actually, as near as we could tell the data was getting in to memory. But once it jumped to the payload it never came back. ron From aip at cwlinux.com Mon Sep 22 21:58:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Sep 22 21:58:01 2003 Subject: epia800 In-Reply-To: ; from ron minnich on Mon, Sep 22, 2003 at 08:06:32PM -0600 References: <20030923095743.A20557@mail.cwlinux.com> Message-ID: <20030923102046.C20557@mail.cwlinux.com> Hi Ron, > actually, as near as we could tell the data was getting in to memory. But > once it jumped to the payload it never came back. Interesting. What payload are u using? I have been using etherboot which is pretty stable. However, Filo will be my next target. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Mon Sep 22 22:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 22 22:39:00 2003 Subject: epia800 In-Reply-To: <20030923102046.C20557@mail.cwlinux.com> Message-ID: On Tue, 23 Sep 2003, Andrew Ip wrote: > > actually, as near as we could tell the data was getting in to memory. But > > once it jumped to the payload it never came back. > Interesting. What payload are u using? I have been using etherboot which > is pretty stable. However, Filo will be my next target. > etherboot we built here. We have not had much luck building etherboot, however. ron From aip at cwlinux.com Mon Sep 22 22:51:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Sep 22 22:51:00 2003 Subject: epia800 In-Reply-To: ; from ron minnich on Mon, Sep 22, 2003 at 09:01:54PM -0600 References: <20030923102046.C20557@mail.cwlinux.com> Message-ID: <20030923111326.B21266@mail.cwlinux.com> Hi Ron, > etherboot we built here. We have not had much luck building etherboot, > however. I have been using 5.0.6 with Adam's patch. Have you tried earlier version? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From steve at nexpath.com Mon Sep 22 22:57:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Mon Sep 22 22:57:01 2003 Subject: epia800 In-Reply-To: References: Message-ID: <3F6FBC05.5000303@nexpath.com> ron minnich wrote: > On Tue, 23 Sep 2003, Andrew Ip wrote: >>>actually, as near as we could tell the data was getting in to memory. But >>>once it jumped to the payload it never came back. >> >>Interesting. What payload are u using? I have been using etherboot which >>is pretty stable. However, Filo will be my next target. >> Filo works very well. I am working with Takeshi to put bzImage boot into it also. Actually, my ide problems were with filo, but the ide code is the same, I think-- it all is from etherboot AFAIK. My CF drive works (128M) but 1.2G WD Caviar fails. -Steve From agnew at cs.umd.edu Tue Sep 23 00:38:01 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Tue Sep 23 00:38:01 2003 Subject: epia800 In-Reply-To: <3F6FBC05.5000303@nexpath.com> Message-ID: <20030923005626.P64206-100000@www.missl.cs.umd.edu> On Mon, 22 Sep 2003, Steve Gehlbach wrote: > ron minnich wrote: > > On Tue, 23 Sep 2003, Andrew Ip wrote: > >>>actually, as near as we could tell the data was getting in to memory. But > >>>once it jumped to the payload it never came back. > >> > >>Interesting. What payload are u using? I have been using etherboot which > >>is pretty stable. However, Filo will be my next target. > >> > > Filo works very well. I am working with Takeshi to put bzImage boot > into it also. > > Actually, my ide problems were with filo, but the ide code is the same, > I think-- it all is from etherboot AFAIK. My CF drive works (128M) but > 1.2G WD Caviar fails. There are slight differences between the ide code from my etherboot patch (i believe this is where takeshi took the polled ide code from) and the polled ide code in etherboot development branches. If you're having trouble with one, it may be worth trying the other. Takeshi really did a fine job with Filo and I'd like to see if replace my etherboot patch for its admitted hackishness alone :) - Adam Agnew From ebiederman at lnxi.com Tue Sep 23 03:55:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 23 03:55:01 2003 Subject: epia800 In-Reply-To: <20030923005626.P64206-100000@www.missl.cs.umd.edu> References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> Message-ID: Adam Agnew writes: > On Mon, 22 Sep 2003, Steve Gehlbach wrote: > > > ron minnich wrote: > > > On Tue, 23 Sep 2003, Andrew Ip wrote: > > >>>actually, as near as we could tell the data was getting in to memory. But > > >>>once it jumped to the payload it never came back. > > >> > > >>Interesting. What payload are u using? I have been using etherboot which > > >>is pretty stable. However, Filo will be my next target. > > >> > > > > Filo works very well. I am working with Takeshi to put bzImage boot > > into it also. > > > > Actually, my ide problems were with filo, but the ide code is the same, > > I think-- it all is from etherboot AFAIK. My CF drive works (128M) but > > 1.2G WD Caviar fails. > > There are slight differences between the ide code from my etherboot patch > (i believe this is where takeshi took the polled ide code from) and the > polled ide code in etherboot development branches. Actually the FILO polled IDE derives most directly from etherboot 5.1. There are a couple of small differences but nothing that looked too substantial. The biggest is the ide_bus_floating() that attempts to quickly see if an IDE cable is absent. > If you're having > trouble with one, it may be worth trying the other. Takeshi really did a > fine job with Filo and I'd like to see if replace my etherboot patch for > its admitted hackishness alone :) FILO does look good from what I have seen of it. Before anyone can guess anything we need a lot more detailed bug report than what has been seen so far. Steve how does your 1.2G Caviar fail? Is it not detected or is the problem something else? SONE do you really have a system that with no IDE disk has the BSY bit stuck high. Or is that just what happens when you scan PIO ports that are not connected to and IDE controller. As far as I know that is the biggest difference between our drivers. You scan PIO space and I primarily scan pci space for IDE controllers. Eric From ts1 at tsn.or.jp Tue Sep 23 08:27:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 23 08:27:00 2003 Subject: epia800 In-Reply-To: References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> Message-ID: <20030923124941.GA7680@tsn.or.jp> On Tue, Sep 23, 2003 at 02:27:08AM -0600, Eric W. Biederman wrote: > Actually the FILO polled IDE derives most directly from etherboot 5.1. > > There are a couple of small differences but nothing that looked too > substantial. The biggest is the ide_bus_floating() that attempts to > quickly see if an IDE cable is absent. Yes, I took it from Etherboot 5.1. I added floating bus detection, and also changed the soft reset code to see if the drive asserts BSY. > FILO does look good from what I have seen of it. I'm really glad to hear that from you. > Before anyone can guess anything we need a lot more detailed bug > report than what has been seen so far. > > Steve how does your 1.2G Caviar fail? Is it not detected or is the > problem something else? I think his problem is something related with geometry. Not with detection. I thought I had a similar WD drive in my junk box, and I looked for it today, without success. Instead I've found a 250MB Conner(!) drive, and it worked perfectly with FILO! > SONE do you really have a system that with no IDE disk has the BSY bit > stuck high. Or is that just what happens when you scan PIO ports that > are not connected to and IDE controller. On EPIA the BSY bit is low when drive is absent, and it is the only real hardware I run FILO. However, it helps quickly skipping the non-existent 3rd and 4th IDE controllers, as you pointed out. -- Takeshi From ian at abelon.com Tue Sep 23 10:13:01 2003 From: ian at abelon.com (Ian Smith) Date: Tue Sep 23 10:13:01 2003 Subject: Possible bug in DDR SDRAM init code for VT8623? Message-ID: <3F705A49.2060100@abelon.com> I've been working on bringing up Linuxbios on a board which is based closely on the EPIA-M and I think I may have found a bug in the DDR SDRAM init code in src/northbridge/via/vt8623/raminit.inc The VIA Northbridge data sheet says that as part of the DDR init sequence you need to read from specific addresses on the bank but I think the registers to do these reads are not being set up properly which can cause the RAM test to fail. I adjusted a number of register settings to be the same as a sample Award Bios but it made no difference so I took a closer look at the DDR and found that %ecx was being set up with the memory location to read from instead of %esi. The diff for my fix is as follows: Index: src/northbridge/via/vt8623/raminit.inc =================================================================== RCS file: /cvsroot/freebios/freebios/src/northbridge/via/vt8623/raminit.inc,v retrieving revision 1.5 diff -r1.5 raminit.inc 85c85 < movl $0x2000, %ecx --- > movl $0x2000, %esi /* IAS changed from ecx to esi */ 89c89 < movl $0x800, %ecx --- > movl $0x800, %esi /* IAS changed from ecx to esi */ 119c119 < movl $0x350, %ecx --- > movl $0x350, %esi /* IAS changed from ecx to esi */ What is odd is that the original code works fine on the Via reference board (same design as EPIA-M) but when I try to run it on my customer board it fails until I make these changes. Does anyone with more knowledge than me of the Via chipsets have any ideas about this? Cheers Ian From rminnich at lanl.gov Tue Sep 23 10:25:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 10:25:01 2003 Subject: Possible bug in DDR SDRAM init code for VT8623? In-Reply-To: <3F705A49.2060100@abelon.com> Message-ID: I think you have found a bug, but we need to let andrew ip take a close look. I would say your patch is correct as well. ron From rminnich at lanl.gov Tue Sep 23 10:32:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 10:32:01 2003 Subject: the EPIA universe Message-ID: I find myself getting confused about all the EPIA boards and their configurations. Can someone help fill this in? name CPU Extension Speed RAM EPIA-M C3 3DNOW 800 Mhz SDRAM That's all I know :-) ron From niki.waibel at newlogic.com Tue Sep 23 10:47:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 23 10:47:00 2003 Subject: the EPIA universe In-Reply-To: Message-ID: <200309231509.h8NF95h4016783@enterprise2.newlogic.at> > I find myself getting confused about all the EPIA boards and their > configurations. > > Can someone help fill this in? > > name CPU Extension Speed RAM > EPIA-M C3 3DNOW 800 Mhz SDRAM EPIA-M C3 3DNOW 600 MHz SDRAM maybe this helps more: # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 599.892 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1183.74 From rminnich at lanl.gov Tue Sep 23 10:53:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 10:53:00 2003 Subject: the EPIA universe In-Reply-To: <200309231509.h8NF95h4016783@enterprise2.newlogic.at> Message-ID: On Tue, 23 Sep 2003, Niki Waibel wrote: name CPU Extension Speed RAM remarks EPIA-M C3 3DNOW 800 Mhz SDRAM EPIA-M C3 3DNOW 600 MHz SDRAM fanless > # cat /proc/cpuinfo > processor : 0 > vendor_id : CentaurHauls > cpu family : 6 > model : 7 > model name : VIA Samuel 2 > stepping : 3 > cpu MHz : 599.892 > cache size : 64 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow > bogomips : 1183.74 > From jay at remotepoint.com Tue Sep 23 11:00:01 2003 From: jay at remotepoint.com (jay) Date: Tue Sep 23 11:00:01 2003 Subject: Working motherboards In-Reply-To: References: Message-ID: <1064330522.7481.27.camel@grovenjl.local.rose-hulman.edu> Is the list of motherboards on the linuxbios status page up to date? I am just curious, since it seems like a lot of mainstream boards (asus, abit, etc) are not listed there, but I would expect them to be. Also, with the K8 support, what motherboard is that on? I'm thinking of getting an AMD-64 when the consumer-level chips come out, and I'd love to be able to try out linuxbios, if none of my motherboards are supported. Also, have any laptops been tried? I know that they're a nightmare of non-standard hardware, but I'm sort of curious. From moedeker at hmk-gmbh.de Tue Sep 23 11:16:01 2003 From: moedeker at hmk-gmbh.de (=?us-ascii?Q?Bernd_Modeker?=) Date: Tue Sep 23 11:16:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: Message-ID: <135968A4EEB54B43A96B269C80D3B2C59BF4@frontman.hmk.de> > > Is there anyone who solved this problem for SC1200? > > not yet. If you have a copy of the vgabios binary for that > hardware you > could try seeing if it would work. I tried the following bios which I extracted from insyde bios: sh-2.05b# ./testbios elpin.vga -d 94 running file elpin.vga No size specified. defaulting to 32k No base specified. defaulting to 0xc0000 No initial code segment specified. defaulting to 0xc000 No initial instruction pointer specified. defaulting to 0x0003 halt_sys: file ops.c, line 9836 halted sh-2.05b# What you see is NOTHING. At single stepping I saw that there is an PCI access to 80009400 for reading ID's. This access returns the wrong values. sh-2.05b# ./testbios elpin.vga -d 0x94 -t running file elpin.vga No size specified. defaulting to 32k No base specified. defaulting to 0xc0000 No initial code segment specified. defaulting to 0xc000 No initial instruction pointer specified. defaulting to 0x0003 Switching to single step mode. AX=0094 BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0005 NV UP DI PL NZ NA PO NC c000:0003 eb4b JMP 50 c000:3 - AX=0094 BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0052 NV UP DI PL NZ NA PO NC c000:0050 eb41 JMP 93 c000:50 - AX=0094 BX=0000 CX=0000 DX=0080 SP=fff8 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0094 NV UP DI PL NZ NA PO NC c000:0093 55 PUSH BP c000:93 - AX=0094 BX=0000 CX=0000 DX=0080 SP=fff6 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0096 NV UP DI PL NZ NA PO NC c000:0094 2bc0 SUB AX,AX c000:94 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff6 BP=0000 SI=0000 DI=0000 DS=0040 ES=0000 SS=0030 CS=c000 IP=0098 NV UP DI PL ZR NA PE NC c000:0096 8ed8 MOV DS,AX c000:96 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff6 BP=0000 SI=0000 DI=0000 DS=0000 ES=0000 SS=0030 CS=c000 IP=0099 NV UP DI PL ZR NA PE NC c000:0098 0e PUSH CS c000:98 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff4 BP=0000 SI=0000 DI=0000 DS=0000 ES=0000 SS=0030 CS=c000 IP=009a NV UP DI PL ZR NA PE NC c000:0099 07 POP ES c000:99 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff6 BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=009d NV UP DI PL ZR NA PE NC c000:009a e87300 CALL 0110 c000:9a - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff4 BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0111 NV UP DI PL ZR NA PE NC c000:0110 66 DATA: c000:110 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff4 BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0112 NV UP DI PL ZR NA PE NC c000:0111 50 PUSH EAX c000:111 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff0 BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0113 NV UP DI PL ZR NA PE NC c000:0112 66 DATA: c000:112 - AX=0000 BX=0000 CX=0000 DX=0080 SP=fff0 BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0114 NV UP DI PL ZR NA PE NC c000:0113 53 PUSH EBX c000:113 - AX=0000 BX=0000 CX=0000 DX=0080 SP=ffec BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0115 NV UP DI PL ZR NA PE NC c000:0114 52 PUSH DX c000:114 - AX=0000 BX=0000 CX=0000 DX=0080 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0118 NV UP DI PL ZR NA PE NC c000:0115 baf80c MOV DX,cf8 c000:115 - AX=0000 BX=0000 CX=0000 DX=0cf8 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0119 NV UP DI PL ZR NA PE NC c000:0118 66 DATA: c000:118 - AX=0000 BX=0000 CX=0000 DX=0cf8 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=011e NV UP DI PL ZR NA PE NC c000:0119 b800940080 MOV EAX,80009400 c000:119 - AX=9400 BX=0000 CX=0000 DX=0cf8 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=011f NV UP DI PL ZR NA PE NC c000:011e 66 DATA: c000:11e - AX=9400 BX=0000 CX=0000 DX=0cf8 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0120 NV UP DI PL ZR NA PE NC c000:011f ef OUT DX,EAX c000:11f - AX=9400 BX=0000 CX=0000 DX=0cf8 SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0123 NV UP DI PL ZR NA PE NC c000:0120 bafc0c MOV DX,cfc c000:120 - AX=9400 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0124 NV UP DI PL ZR NA PE NC c000:0123 66 DATA: c000:123 - AX=9400 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0125 NV UP DI PL ZR NA PE NC c000:0124 ed IN EAX,DX c000:124 - AX=4000 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0126 NV UP DI PL ZR NA PE NC c000:0125 66 DATA: c000:125 - Any advises? Bernd > The vga register problem is a mess, as the vendors rarely > want to help. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From steve at nexpath.com Tue Sep 23 11:19:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Sep 23 11:19:01 2003 Subject: epia800 In-Reply-To: References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> Message-ID: <3F706BA9.8030400@nexpath.com> Eric W. Biederman wrote: > Steve how does your 1.2G Caviar fail? Is it not detected or is the > problem something else? Everything works fine, it just gets the wrong data. I put in lots of printf's, it is using ide_read_sector_lba, all results are normal AFAICT. I printed out the sector (sector 0) that it read, it had about 50 initial values, then all zeros. The real sector 0 is pretty much all filled. I grep'ed for a couple of bytes from the bogus sector and they did not appear in the real sector, so I think all of the data is bogus, not just shifted or something. The cmd.device byte (=0xe0) (and the others in this structure) appear correct in comparing to ATA spec. Is there ever any confusion about what the first sector is (0 vs 1)? I could not find a specific statement in the ATA spec about this, but it is a long spec. I was going to force it to use ide_read_sector_chs but did not have time. I switched to using my CF drive and it worked fine, so I don't think it was cockpit trouble. -Steve From aip at cwlinux.com Tue Sep 23 11:32:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue Sep 23 11:32:01 2003 Subject: the EPIA universe In-Reply-To: ; from ron minnich on Tue, Sep 23, 2003 at 09:15:53AM -0600 References: <200309231509.h8NF95h4016783@enterprise2.newlogic.at> Message-ID: <20030923235410.A31053@mail.cwlinux.com> Hi, > name CPU Extension Speed RAM remarks > EPIA-M C3 3DNOW 800 Mhz SDRAM > EPIA-M C3 3DNOW 600 MHz SDRAM fanless I think all EPIA-M uses ddr, and EPIA/EPIA-V uses sdram. Also, any CPU less or equal to 600MHz doesn't come with fan. Furthermore, EPIA-M comes with MPEG-2 decoder. VIA has released source code for mpeg-2 is and also X driver recently. If you want to try mpeg-2 decoder, the easiest way is to use mplayer which just has got it supported. AFAIK, EPIA-M 10000 is able to play mpeg-2 even without using the hw decoder. -Andrew > > # cat /proc/cpuinfo > > processor : 0 > > vendor_id : CentaurHauls > > cpu family : 6 > > model : 7 > > model name : VIA Samuel 2 > > stepping : 3 > > cpu MHz : 599.892 > > cache size : 64 KB > > fdiv_bug : no > > hlt_bug : no > > f00f_bug : no > > coma_bug : no > > fpu : yes > > fpu_exception : yes > > cpuid level : 1 > > wp : yes > > flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow > > bogomips : 1183.74 > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From benkstein at math.tu-dresden.de Tue Sep 23 11:38:01 2003 From: benkstein at math.tu-dresden.de (Frank Benkstein) Date: Tue Sep 23 11:38:01 2003 Subject: the EPIA universe In-Reply-To: References: <200309231509.h8NF95h4016783@enterprise2.newlogic.at> Message-ID: <20030923180042.11b7ced7.benkstein@math.tu-dresden.de> On Tue, 23 Sep 2003 09:15:53 -0600 (MDT) ron minnich wrote: > On Tue, 23 Sep 2003, Niki Waibel wrote: > > name CPU Extension Speed RAM remarks > EPIA-M C3 3DNOW 800 Mhz SDRAM > EPIA-M C3 3DNOW 600 MHz SDRAM fanless EPIA-M C3 3DNOW 933 MHz DDR-SDRAM cat /proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 8 model name : VIA C3 Ezra stepping : 9 cpu MHz : 932.918 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1843.20 I just want to give LB a try in a few weeks or sth. Bye Frank Benkstein From niki.waibel at newlogic.com Tue Sep 23 11:41:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Tue Sep 23 11:41:00 2003 Subject: epia-m 600 -- still not working Message-ID: <200309231603.h8NG3Dh4023934@enterprise2.newlogic.at> any idea why linuxbios is not starting on the epia-m 600? i run memtest86 -- all tests (took about 24hours ;-) -> everyting ok. (run memtest86 from lilo). i also tried the patch of Ian Smith . do you have an idea how i can find out which asm line the stop happens? unfort i cannot use TX_STRING in c_start.c... niki From Michael at Fenner.org Tue Sep 23 12:02:00 2003 From: Michael at Fenner.org (Michael Fenner) Date: Tue Sep 23 12:02:00 2003 Subject: the EPIA universe References: <20030923153201.20184.54237.Mailman@nwn.definitive.org> Message-ID: > Date: Tue, 23 Sep 2003 23:54:10 +0800 > From: Andrew Ip > To: ron minnich > Cc: Niki Waibel , linuxbios at clustermatic.org > Subject: Re: the EPIA universe > > Hi, > > > name CPU Extension Speed RAM remarks > > EPIA-M C3 3DNOW 800 Mhz SDRAM > > EPIA-M C3 3DNOW 600 MHz SDRAM fanless > I think all EPIA-M uses ddr, and EPIA/EPIA-V uses sdram. Also, > any CPU less or equal to 600MHz doesn't come with fan. Furthermore, > EPIA-M comes with MPEG-2 decoder. VIA has released source code for > mpeg-2 is and also X driver recently. If you want to try mpeg-2 decoder, > the easiest way is to use mplayer which just has got it supported. > AFAIK, EPIA-M 10000 is able to play mpeg-2 even without using the hw > decoder. > > -Andrew > Hi Andrew, where did you get the information that mplayer now supports the mpeg-2 decoder for the epia-m? Couldn't find it anywhere..... Also I'm a little confused about the source for the mpeg-2 decoder - I just know that they support a precompiled version of xine (called VeXP) for some Linux distributions and the source of the lite version of the CLE266 drivers (without hw-mpeg2). Did I miss some good news here? thnax, Michael From rminnich at lanl.gov Tue Sep 23 12:03:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 12:03:00 2003 Subject: Working motherboards In-Reply-To: <1064330522.7481.27.camel@grovenjl.local.rose-hulman.edu> Message-ID: On Tue, 23 Sep 2003, jay wrote: > Is the list of motherboards on the linuxbios status page up to date? I > am just curious, since it seems like a lot of mainstream boards (asus, > abit, etc) are not listed there, but I would expect them to be. Also, > with the K8 support, what motherboard is that on? I'm thinking of > getting an AMD-64 when the consumer-level chips come out, and I'd love > to be able to try out linuxbios, if none of my motherboards are > supported. The goal here is to get to the point where vendors take on the responsibility for their own mainboards. I personally want out of this business of doing ports, I have a day job :-) The vendors should be able to do a good job with this, and our work would be assistance and testing. So the mainboards on the list are proof-of-concept, and we hope vendors will pick up on this. Note that Tyan is in fact a contributor, and they are offering linuxbios on several of their new K8 mainboards. You can ask for it with a mainboard. I need to add a 'vendor-supplied linuxbios' web page. ron From rminnich at lanl.gov Tue Sep 23 12:08:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 12:08:00 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <135968A4EEB54B43A96B269C80D3B2C59BF4@frontman.hmk.de> Message-ID: On Tue, 23 Sep 2003, Bernd Modeker wrote: > I tried the following bios which I extracted from insyde bios: > > sh-2.05b# ./testbios elpin.vga -d 94 > running file elpin.vga > No size specified. defaulting to 32k > No base specified. defaulting to 0xc0000 > No initial code segment specified. defaulting to 0xc000 > No initial instruction pointer specified. defaulting to 0x0003 > halt_sys: file ops.c, line 9836 > halted > sh-2.05b# that's annoying. I've tried to add more helpful output to the x86 emulator from X11 (such as all the messages above) but obviously I missed some important bits. can you decode this a bit for me? What is it looking for in terms of devid, and how is the pci read returning wrong values? ron From rminnich at lanl.gov Tue Sep 23 12:11:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 12:11:01 2003 Subject: the EPIA universe In-Reply-To: <20030923180042.11b7ced7.benkstein@math.tu-dresden.de> Message-ID: name CPU Extension Speed RAM remarks EPIA C3 3DNOW 800 Mhz SDRAM EPIA C3 3DNOW 600 MHz SDRAM fanless EPIA-M C3 3DNOW 933 MHz DDR-SDRAM Is this more accurate now? what is the EPIA[-M] 5000? ron From rminnich at lanl.gov Tue Sep 23 12:11:06 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 12:11:06 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309231603.h8NG3Dh4023934@enterprise2.newlogic.at> Message-ID: On Tue, 23 Sep 2003, Niki Waibel wrote: > any idea why linuxbios is not starting on the epia-m 600? > i run memtest86 -- all tests (took about 24hours ;-) -> everyting ok. > (run memtest86 from lilo). > i also tried the patch of Ian Smith . ok, so you did memtest86 as a payload and it worked? It's time to try XIP (execute in place) and see how it goes. rno From sbambach at gmx.net Tue Sep 23 12:12:00 2003 From: sbambach at gmx.net (Stefan Bambach) Date: Tue Sep 23 12:12:00 2003 Subject: the EPIA universe In-Reply-To: <20030923235410.A31053@mail.cwlinux.com> References: <200309231509.h8NF95h4016783@enterprise2.newlogic.at> <20030923235410.A31053@mail.cwlinux.com> Message-ID: <1064334878.10134.11.camel@ap-lnx-stefanb> Hi Andrew, > Hi, > > > name CPU Extension Speed RAM remarks > > EPIA-M C3 3DNOW 800 Mhz SDRAM > > EPIA-M C3 3DNOW 600 MHz SDRAM fanless > I think all EPIA-M uses ddr, and EPIA/EPIA-V uses sdram. Also, You are right. DDR RAM for epia-m and SDRAM for epia-v. They are existing with C3 and Eden CPUs und some with and some without fans. > any CPU less or equal to 600MHz doesn't come with fan. Furthermore, > EPIA-M comes with MPEG-2 decoder. VIA has released source code for > mpeg-2 is and also X driver recently. If you want to try mpeg-2 decoder, > the easiest way is to use mplayer which just has got it supported. > AFAIK, EPIA-M 10000 is able to play mpeg-2 even without using the hw > decoder. > > -Andrew > > > > # cat /proc/cpuinfo > > > processor : 0 > > > vendor_id : CentaurHauls > > > cpu family : 6 > > > model : 7 > > > model name : VIA Samuel 2 > > > stepping : 3 > > > cpu MHz : 599.892 > > > cache size : 64 KB > > > fdiv_bug : no > > > hlt_bug : no > > > f00f_bug : no > > > coma_bug : no > > > fpu : yes > > > fpu_exception : yes > > > cpuid level : 1 > > > wp : yes > > > flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow > > > bogomips : 1183.74 > > > > > > > _______________________________________________ > > Linuxbios mailing list > > Linuxbios at clustermatic.org > > http://www.clustermatic.org/mailman/listinfo/linuxbios From steve at nexpath.com Tue Sep 23 12:24:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Sep 23 12:24:00 2003 Subject: the EPIA universe In-Reply-To: References: <20030923153201.20184.54237.Mailman@nwn.definitive.org> Message-ID: <3F707B19.3020900@nexpath.com> Michael Fenner wrote: VIA has released source code for >>mpeg-2 is and also X driver recently. Hmmm... this guy went to a lot of trouble to reverse engineer the via mpeg driver. Did they release the source after he did this? http://www.ivor.it/cle266/ -Steve From justin at street-vision.com Tue Sep 23 12:42:00 2003 From: justin at street-vision.com (Justin Cormack) Date: Tue Sep 23 12:42:00 2003 Subject: Working motherboards In-Reply-To: References: Message-ID: <1064336631.30262.29.camel@lotte.street-vision.com> On Tue, 2003-09-23 at 17:26, ron minnich wrote: > Note that Tyan is in fact a contributor, and they are offering linuxbios > on several of their new K8 mainboards. You can ask for it with a > mainboard. Thats really great. Though I am *still* waiting for my Tyan boards to actually arrive. Maybe I will cancel my order and reorder with linuxbios. Is there a different part number, or how does one specify? Justin From rminnich at lanl.gov Tue Sep 23 12:42:16 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 12:42:16 2003 Subject: Working motherboards In-Reply-To: <1064336631.30262.29.camel@lotte.street-vision.com> Message-ID: On 23 Sep 2003, Justin Cormack wrote: > Thats really great. Though I am *still* waiting for my Tyan boards to > actually arrive. Maybe I will cancel my order and reorder with > linuxbios. Is there a different part number, or how does one specify? supported on the S2880 and S2885 ron From linuxbios at xdr.com Tue Sep 23 13:15:00 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Tue Sep 23 13:15:00 2003 Subject: EPIA-M serial port information Message-ID: <200309231737.h8NHbWEt003372@xdr.com> Based on some emails from Andrew I started poking around into the epia-m serial port problem. Here are my observations: The 9 pin internal serial port is part of the VT1211 chip, not the VT8235, or other chips with serial ports. Under linux all baud rates are 1/2 what they should be. So if I pick 115200, I get 57600. If I pick 19200, I get 9600, etc. I can fix linux with setserial /dev/ttyS0 baud_base 57600 Then the actual baud rate matches what I expect. 38400 and 115200 cannot be achieved though. Andrew says if he boots with Award and the warm boots into linuxbios, the serial port is 115200. On the epia-m motherboard near the VT1211 chip is a crystal oscillator labeled KTS24.5X1K, which suggests it is 24.5 mhz. The VT1211 spec calls for a 48 mhz clock. Don't know if this is the cause of the problem, VT1211 being driven by 1/2 speed clock. My guess is there is some register in the VT1211 that has to be tweaked to specify the serial port clock divisor. linuxbios doesn't touch this at all. award bios sets it to match the 24.5 mhz crystal. On cold startup the vt1211 defaults to assuming 48 mhz input clock. This explains all observations, but doesn't solve the problem... I just put a scope on pin 17 of the vt1211, it appears to be 48 mhz though so that blows that theory. From ts1 at tsn.or.jp Tue Sep 23 13:51:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 23 13:51:01 2003 Subject: the EPIA universe In-Reply-To: References: <20030923180042.11b7ced7.benkstein@math.tu-dresden.de> Message-ID: <20030923181332.GA14498@tsn.or.jp> On Tue, Sep 23, 2003 at 10:33:26AM -0600, ron minnich wrote: > name CPU Extension Speed RAM remarks > EPIA C3 3DNOW 800 Mhz SDRAM > EPIA C3 3DNOW 600 MHz SDRAM fanless > EPIA-M C3 3DNOW 933 MHz DDR-SDRAM > > Is this more accurate now? > > what is the EPIA[-M] 5000? name CPU Extension Speed RAM remarks EPIA 800 C3 3DNOW 800 Mhz SDRAM EPIA 5000 C3 3DNOW 533 MHz SDRAM fanless EPIA-M 10000 C3 SSE? 1000 MHz DDR-SDRAM EPIA-M 900 C3 3DNOW 933 MHz DDR-SDRAM EPIA-M 6000 C3 3DNOW 600 MHz DDR-SDRAM fanless ? -- Takeshi From jake at CS.Stanford.EDU Tue Sep 23 14:20:01 2003 From: jake at CS.Stanford.EDU (Jake Page) Date: Tue Sep 23 14:20:01 2003 Subject: the EPIA universe In-Reply-To: <20030923181332.GA14498@tsn.or.jp> Message-ID: On Wed, 24 Sep 2003, SONE Takeshi wrote: > name CPU Extension Speed RAM remarks > EPIA 800 C3 3DNOW 800 Mhz SDRAM > EPIA 5000 C3 3DNOW 533 MHz SDRAM fanless > EPIA-M 10000 C3 SSE? 1000 MHz DDR-SDRAM > EPIA-M 900 C3 3DNOW 933 MHz DDR-SDRAM > EPIA-M 6000 C3 3DNOW 600 MHz DDR-SDRAM fanless Even more fun: the EPIA-M 10000 may have either the Ezra core (same one used in the older M series - uses 3DNOW, etc) or the newer Nehemiah core (uses SSE, also has full speed FPU, which makes a big difference for things like MPEG decoding...) It's really annoying, AFAIK they use the same packaging, model number, etc - I had to boot up Linux and look at /proc/cpuinfo to tell them apart. -Jake From bgr at gw.linespeed.net Tue Sep 23 15:07:01 2003 From: bgr at gw.linespeed.net (Brian G. Rhodes) Date: Tue Sep 23 15:07:01 2003 Subject: the EPIA universe In-Reply-To: References: Message-ID: it's a samuel (II) core. you should list ones which work by the core. ezra, nehemiah, samuel. btw. I have an epia-m 9000 with sdram. any of the samuels should work with only passive cooling (as they're based on the centaur (sp?) cores). unicorn computer makes some wacky epia combinations if you want some more. Brian G Rhodes bgr at linespeed.net brhodes at visualcircuits.com +1 612-741-1191 On Tue, 23 Sep 2003, ron minnich wrote: > name CPU Extension Speed RAM remarks > EPIA C3 3DNOW 800 Mhz SDRAM > EPIA C3 3DNOW 600 MHz SDRAM fanless > EPIA-M C3 3DNOW 933 MHz DDR-SDRAM > > Is this more accurate now? > > what is the EPIA[-M] 5000? > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From moedeker at hmk-gmbh.de Tue Sep 23 15:09:00 2003 From: moedeker at hmk-gmbh.de (=?iso-8859-1?Q?Bernd_M=F6deker?=) Date: Tue Sep 23 15:09:00 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? References: Message-ID: <005d01c38209$88631fe0$0179a8c0@hmkhow2000> > > I tried the following bios which I extracted from insyde bios: > > > > sh-2.05b# ./testbios elpin.vga -d 94 > > running file elpin.vga > > No size specified. defaulting to 32k > > No base specified. defaulting to 0xc0000 > > No initial code segment specified. defaulting to 0xc000 > > No initial instruction pointer specified. defaulting to 0x0003 > > halt_sys: file ops.c, line 9836 > > halted > > sh-2.05b# > > that's annoying. I've tried to add more helpful output to the x86 emulator > from X11 (such as all the messages above) but obviously I missed some > important bits. > > > can you decode this a bit for me? What is it looking for in terms of > devid, and how is the pci read returning wrong values? the internal vga pci device at 0:12.4 should be found when you write 0x80009400 to pci index reg 0xcf8. After that the value 0x0504100b should be returned at 0xcfc as vendor id (0x100b) and device id (0x0504). After single stepping this return value AX is set to 0x4000 and not 0x100b. Unfortunaly EAX is not printed: c000:0124 ed IN EAX,DX c000:124 - AX=4000 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0126 NV UP DI PL ZR NA PE NC If I check this with the pciset tool I get the right values back. Also I tried to read these value back under InsydeBIOS with bootet DOS. Bernd > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Tue Sep 23 15:22:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 15:22:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <005d01c38209$88631fe0$0179a8c0@hmkhow2000> Message-ID: On Tue, 23 Sep 2003, Bernd M?deker wrote: > the internal vga pci device at 0:12.4 should be found when you write > 0x80009400 to pci index reg > 0xcf8. After that the value 0x0504100b should be returned at 0xcfc as vendor > id (0x100b) and device id (0x0504). > After single stepping this return value AX is set to 0x4000 and not 0x100b. > Unfortunaly EAX is not printed: > > c000:0124 ed IN EAX,DX > c000:124 - > AX=4000 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 > DI=0000 > DS=0000 ES=c000 SS=0030 CS=c000 IP=0126 NV UP DI PL ZR NA PE > NC > you're not going to get eax in an 8086. This is an issue. I wonder if there is an enable for the vga device that we are not setting. ron From rminnich at lanl.gov Tue Sep 23 15:24:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 15:24:00 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: Message-ID: On Tue, 23 Sep 2003, ron minnich wrote: > > c000:0124 ed IN EAX,DX no 66 prefix means it really is 16 bits, btw. Anyway, can you check and see if there is a vga enable? there almost always is in these chipsets. ron From moedeker at hmk-gmbh.de Tue Sep 23 15:30:01 2003 From: moedeker at hmk-gmbh.de (=?iso-8859-1?Q?Bernd_M=F6deker?=) Date: Tue Sep 23 15:30:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? References: Message-ID: <007701c3820c$90462380$0179a8c0@hmkhow2000> > > the internal vga pci device at 0:12.4 should be found when you write > > 0x80009400 to pci index reg > > 0xcf8. After that the value 0x0504100b should be returned at 0xcfc as vendor > > id (0x100b) and device id (0x0504). > > After single stepping this return value AX is set to 0x4000 and not 0x100b. > > Unfortunaly EAX is not printed: > > > > c000:0124 ed IN EAX,DX > > c000:124 - > > AX=4000 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 > > DI=0000 > > DS=0000 ES=c000 SS=0030 CS=c000 IP=0126 NV UP DI PL ZR NA PE > > NC > > > > you're not going to get eax in an 8086. This is an issue. ok this seems to be a fact > > I wonder if there is an enable for the vga device that we are not setting. I could'nt follow. What do you mean? Bernd From rminnich at lanl.gov Tue Sep 23 15:35:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 15:35:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <007701c3820c$90462380$0179a8c0@hmkhow2000> Message-ID: On Tue, 23 Sep 2003, Bernd M?deker wrote: > I could'nt follow. What do you mean? frequently, in the north bridge, there is a magic bit in some register in device 0:0.0 that enables the VGA hardware. If you don't set it, the VGA hardware will act like it is not there when you probe it. ron From moedeker at hmk-gmbh.de Tue Sep 23 15:56:01 2003 From: moedeker at hmk-gmbh.de (=?iso-8859-1?Q?Bernd_M=F6deker?=) Date: Tue Sep 23 15:56:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? References: Message-ID: <009e01c38210$1c19b400$0179a8c0@hmkhow2000> I forgot this here: c000:0123 66 DATA: c000:123 - AX=9400 BX=0000 CX=0000 DX=0cfc SP=ffea BP=0000 SI=0000 DI=0000 DS=0000 ES=c000 SS=0030 CS=c000 IP=0125 NV UP DI PL ZR NA PE NC > > c000:0124 ed IN EAX,DX > > no 66 prefix means it really is 16 bits, btw. So there is an prefix! > > Anyway, can you check and see if there is a vga enable? there almost > always is in these chipsets. The vga device is enabled. If I use devmem I can read the vendor and device ID and the enabled VGA device. PCI function 4 for this vga device is enabled. So the elpin vga bios should be able to read this ID's too. Bernd From stepan at suse.de Tue Sep 23 16:03:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 23 16:03:01 2003 Subject: the EPIA universe In-Reply-To: References: <20030923181332.GA14498@tsn.or.jp> Message-ID: <20030923202519.GA293@suse.de> * Jake Page [030923 20:42]: > On Wed, 24 Sep 2003, SONE Takeshi wrote: > > > name CPU Extension Speed RAM remarks > > EPIA 800 C3 3DNOW 800 Mhz SDRAM > > EPIA 5000 C3 3DNOW 533 MHz SDRAM fanless > > EPIA-M 10000 C3 SSE? 1000 MHz DDR-SDRAM > > EPIA-M 900 C3 3DNOW 933 MHz DDR-SDRAM > > EPIA-M 6000 C3 3DNOW 600 MHz DDR-SDRAM fanless > > > Even more fun: the EPIA-M 10000 may have either the Ezra core (same > one used in the older M series - uses 3DNOW, etc) or the newer Nehemiah > core (uses SSE, also has full speed FPU, which makes a big difference for > things like MPEG decoding...) I noticed at least the Nehemiah core does not work with the default SuSE kernels. It lacks the cmpxchg opcode (which should be there since 486 iirc). A kernel specially compiled for C3-2 worked fine. just my 0.02 Stefan -- Architecture Team SuSE Linux AG From tomfritz at direcpc.com Tue Sep 23 16:43:00 2003 From: tomfritz at direcpc.com (Thomas Fritz) Date: Tue Sep 23 16:43:00 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: <20030923025100.17470.77889.Mailman@nwn.definitive.org> References: <20030923025100.17470.77889.Mailman@nwn.definitive.org> Message-ID: <3F70B565.6070300@direcpc.com> I have access to a few WBTs at a surplus place, and I've dug up the specs on them: Cyrix Pentium clone - 266MHz up to 128MB SDRAM ports: PS/2 keyb/mouse, 2 USB 1.1, 2 serial, 1 parallel, 10/100 ethernet, and sound in/out the chipset(s) include a SuperIO 97317, and a CS5530 (which handles the soundblaster compatible sound and presumably the video). The board has an Award BIOS little square-like ROM, and a larger 8MB ROM which holds Windows CE. There are also various places on the board which could have had various optional features, but there is no IDE, floppy, etc...but I think if I solder on a PCI slot where it belongs I could hack some more funtionality onto it for testing. I've been thinking of how to go about hacking this thing, and the easiest method I'd like to try first: Burning a new ROM to replace the Windows CE version. I doubt this thing would be easy to flash the BIOS, if it even had that capability. I'm not looking for graphics, a text screen will be more than sufficient. On this, I have two questions: What's my chances for success (educated guesses?), and has anyone done something similar? From sbambach at gmx.net Tue Sep 23 16:50:01 2003 From: sbambach at gmx.net (Stefan Bambach) Date: Tue Sep 23 16:50:01 2003 Subject: the EPIA universe In-Reply-To: <20030923181332.GA14498@tsn.or.jp> References: <20030923180042.11b7ced7.benkstein@math.tu-dresden.de> <20030923181332.GA14498@tsn.or.jp> Message-ID: <1064351328.5731.33.camel@ap-xp1700.intra> And another one: It's the 860a from Lex Systems. It's based on the epia-v board with on board 12V power supply. The small blue box :-) 533MHz fanless # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 531.829 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1061.68 # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50) 00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) > On Tue, Sep 23, 2003 at 10:33:26AM -0600, ron minnich wrote: > > name CPU Extension Speed RAM remarks > > EPIA C3 3DNOW 800 Mhz SDRAM > > EPIA C3 3DNOW 600 MHz SDRAM fanless > > EPIA-M C3 3DNOW 933 MHz DDR-SDRAM > > > > Is this more accurate now? > > > > what is the EPIA[-M] 5000? > > name CPU Extension Speed RAM remarks > EPIA 800 C3 3DNOW 800 Mhz SDRAM > EPIA 5000 C3 3DNOW 533 MHz SDRAM fanless > EPIA-M 10000 C3 SSE? 1000 MHz DDR-SDRAM > EPIA-M 900 C3 3DNOW 933 MHz DDR-SDRAM > EPIA-M 6000 C3 3DNOW 600 MHz DDR-SDRAM fanless > > ? From ts1 at tsn.or.jp Tue Sep 23 17:46:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 23 17:46:01 2003 Subject: supporting the EPIA-M 10000 VGA [PMX:##] In-Reply-To: References: <6539.1064245433241.JavaMail.Administrator@smtp3> Message-ID: <20030923220802.GA849@tsn.or.jp> On Mon, Sep 22, 2003 at 10:18:41AM -0600, ron minnich wrote: > I just committed various patches that have allowed us here to use VGA on > the M800 s/M800/800/ ? I saw an old version of my fixes to idt.c and vgabios.c is commited. This version does not pass dev/busfn to the VGABIOS correctly. -- Takeshi From ts1 at tsn.or.jp Tue Sep 23 17:49:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 23 17:49:01 2003 Subject: unsupported int on Epia800 In-Reply-To: <2F482C75-ED57-11D7-B052-0003931B4D6A@gnat.ca> References: <2F482C75-ED57-11D7-B052-0003931B4D6A@gnat.ca> Message-ID: <20030923221146.GB849@tsn.or.jp> On Mon, Sep 22, 2003 at 05:47:54PM -0600, Nathanael Noblet wrote: > Hello, > I'm still not sure what is causing it yet. I know it happens when I > seem to turn on my epia board after it being off for awhile, while > looking only at the screen and not the serial console. > > I get these message > biosint: Unsupported int #0xff > ... register settings... > ... register settings... > biosint: Unsupported int #0xfc > ... register settings... > ... register settings... > biosint: Unsupported int #0xcd > ... register settings... > ... register settings... They are not bios calls. Looks like your VGABIOS went wild. Please try a cvs update, it now has some fixes to VGABIOS support. -- Takeshi From rminnich at lanl.gov Tue Sep 23 18:38:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 18:38:00 2003 Subject: supporting the EPIA-M 10000 VGA [PMX:##] In-Reply-To: <20030923220802.GA849@tsn.or.jp> Message-ID: On Wed, 24 Sep 2003, SONE Takeshi wrote: > I saw an old version of my fixes to idt.c and vgabios.c is commited. > This version does not pass dev/busfn to the VGABIOS correctly. send me the fix. I thought this was the right one. Sorry. ron From bgr at gw.linespeed.net Tue Sep 23 18:55:01 2003 From: bgr at gw.linespeed.net (Brian G. Rhodes) Date: Tue Sep 23 18:55:01 2003 Subject: the EPIA universe In-Reply-To: <20030923202519.GA293@suse.de> References: <20030923181332.GA14498@tsn.or.jp> <20030923202519.GA293@suse.de> Message-ID: nehemiah works with 586 compiled linux kernel. Brian G Rhodes bgr at linespeed.net brhodes at visualcircuits.com +1 612-741-1191 On Tue, 23 Sep 2003, Stefan Reinauer wrote: > * Jake Page [030923 20:42]: > > On Wed, 24 Sep 2003, SONE Takeshi wrote: > > > > > name CPU Extension Speed RAM remarks > > > EPIA 800 C3 3DNOW 800 Mhz SDRAM > > > EPIA 5000 C3 3DNOW 533 MHz SDRAM fanless > > > EPIA-M 10000 C3 SSE? 1000 MHz DDR-SDRAM > > > EPIA-M 900 C3 3DNOW 933 MHz DDR-SDRAM > > > EPIA-M 6000 C3 3DNOW 600 MHz DDR-SDRAM fanless > > > > > > Even more fun: the EPIA-M 10000 may have either the Ezra core (same > > one used in the older M series - uses 3DNOW, etc) or the newer Nehemiah > > core (uses SSE, also has full speed FPU, which makes a big difference for > > things like MPEG decoding...) > > I noticed at least the Nehemiah core does not work with the default SuSE > kernels. It lacks the cmpxchg opcode (which should be there since 486 > iirc). A kernel specially compiled for C3-2 worked fine. > > just my 0.02 > Stefan > > > -- > Architecture Team > SuSE Linux AG > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From aip at cwlinux.com Tue Sep 23 19:46:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue Sep 23 19:46:00 2003 Subject: the EPIA universe In-Reply-To: ; from Brian G. Rhodes on Tue, Sep 23, 2003 at 06:13:23PM -0500 References: <20030923181332.GA14498@tsn.or.jp> <20030923202519.GA293@suse.de> Message-ID: <20030924080818.A4429@mail.cwlinux.com> Hi, > nehemiah works with 586 compiled linux kernel. It might need 586 glibc also. When I hooked up a PIII RedHat, EPIA hangs after init. I had to intall from scratch. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From stuge-linuxbios at cdy.org Tue Sep 23 20:10:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue Sep 23 20:10:01 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: <3F70B565.6070300@direcpc.com> References: <20030923025100.17470.77889.Mailman@nwn.definitive.org> <3F70B565.6070300@direcpc.com> Message-ID: <20030924003128.GC8649@foo.birdnet.se> On Tue, Sep 23, 2003 at 05:04:37PM -0400, Thomas Fritz wrote: > I have access to a few WBTs at a surplus place, and I've dug up the > specs on them: > > Cyrix Pentium clone - 266MHz > up to 128MB SDRAM > ports: PS/2 keyb/mouse, 2 USB 1.1, 2 serial, 1 parallel, 10/100 > ethernet, and sound in/out > > the chipset(s) include a SuperIO 97317, and a CS5530 (which handles the > soundblaster compatible sound and presumably the video). Expect this to be a GX1+5530, or maybe even a Geode (SCx2xx) system. LinuxBIOS is running on both those platforms and there is some kind of support for the 97317 in the freebios tree, but findgrep yields nothing in freebios2, I guess it simply hasn't been ported over yet. > The board has an Award BIOS little square-like ROM, This is probably a regular flash ROM in a PLCC package. > and a larger 8MB ROM which holds Windows CE. What kind of ROM is this, exactly? Can you peel off the label and read what's printed on the chip(s)? > There are also various places on the board which could have had various > optional features, but there is no IDE, floppy, etc...but I think if I > solder on a PCI slot where it belongs I could hack some more > funtionality onto it for testing. The CS5530 and SCx2xx (which have the 5530 integrated) have IDE, but there may just not be a connector for it. The IDE pins may also be multiplexed away for some other use in this particular system. > I've been thinking of how to go about hacking this thing, and the > easiest method I'd like to try first: Burning a new ROM to replace the > Windows CE version. I doubt this thing would be easy to flash the BIOS, > if it even had that capability. Maybe, maybe not. With a little luck the HW designers have wired the flash memory to always be writable, given the right software commands of course. > I'm not looking for graphics, a text screen will be more than sufficient. Either should be possible. > On this, I have two questions: What's my chances for success (educated > guesses?), and has anyone done something similar? I'd say you'll succeed given time, you will have to learn the quirks of this particular system and then likely make a port of freebios2 to it. These two processes are usually concurrent. If it's an SCx2xx system, check out the nano stuff in the freebios tree, and port it to freebios2. :) //Peter From stuge-linuxbios at cdy.org Tue Sep 23 20:26:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue Sep 23 20:26:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <009e01c38210$1c19b400$0179a8c0@hmkhow2000> References: <009e01c38210$1c19b400$0179a8c0@hmkhow2000> Message-ID: <20030924004709.GD8649@foo.birdnet.se> On Tue, Sep 23, 2003 at 10:19:56PM +0200, Bernd M?deker wrote: > > Anyway, can you check and see if there is a vga enable? there almost > > always is in these chipsets. > The vga device is enabled. If I use devmem I can read the vendor and device > ID and the enabled VGA device. PCI function 4 for this vga device is > enabled. So the elpin vga bios should be able to read this ID's too. Maybe the BLDT and/or some revenging of the VGA VSM could point to the right bits. Also see Christer Weinigel's work in the nano port, although I don't remember if he had graphics up on it. I seem to recall it used the SC2200 which has an LCD driver as it's speciality. //Peter From stuge-linuxbios at cdy.org Tue Sep 23 20:48:00 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue Sep 23 20:48:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: <200309221646.h8MGku815465@nwn.definitive.org> References: <200309221646.h8MGku815465@nwn.definitive.org> Message-ID: <20030924010852.GA16965@foo.birdnet.se> On Mon, Sep 22, 2003 at 10:15:40PM +0530, amits at myrealbox.com wrote: > Hi , > > How do I extract the VGA BIOS from the Insyde ExpressROM??the same way as in > case of the EPIA will work? ANd in that case ... how can we find out IF it > uses some calls that are implemented in the underlying XpressROM BIOS ?? XpressROM is a minimalist BIOS sold by Insyde. XpressLOADER is another name for the BLDT, available from either Insyde or NSC. (I believe it's still NSC.) BLDT is the Boot Loader Development Toolkit and contains some building blocks for making a BIOS similar to the XpressROM but lacking a few features that may or may not be critical. ACPI and various legacy BIOS services e.g. The BLDT is (was) available free of charge and IIRC you're even allowed to develop open source software after reading it. Don't take my word for this though. See if you can get hold of the BLDT, I think it'll make things a lot easier than dealing with XpressROM, especially when what you really want to do is run LinuxBIOS. :) //Peter From rminnich at lanl.gov Tue Sep 23 20:52:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 23 20:52:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: <20030924004709.GD8649@foo.birdnet.se> Message-ID: On Wed, 24 Sep 2003, Peter Stuge wrote: > On Tue, Sep 23, 2003 at 10:19:56PM +0200, Bernd M?deker wrote: > > > Anyway, can you check and see if there is a vga enable? there almost > > > always is in these chipsets. > > The vga device is enabled. If I use devmem I can read the vendor and device > > ID and the enabled VGA device. PCI function 4 for this vga device is > > enabled. So the elpin vga bios should be able to read this ID's too. > > Maybe the BLDT and/or some revenging of the VGA VSM could point to the right > bits. > I am guessing bug in the testbios code, I'm just trying to narrow it down. ron From hansolofalcon at worldnet.att.net Tue Sep 23 20:55:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue Sep 23 20:55:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: <20030924010852.GA16965@foo.birdnet.se> Message-ID: <000801c38239$d343f9a0$0100a8c0@who5> Hello (again) from Gregg C Levine Perhaps. But NSC's webpage insists that they have indeed sold the entire line to AMD, and that presumably included software tools, and even development support. Meaning anyone who had bought a board the week before the event took place, would find themselves working with a different group. As for your claims, I don't know, I'm just commenting on the webpage. I can tell you, that it was badly laid out, and looked like something done by someone who was just starting out in that business, a far cry from all of the other things that they display online. Also, it did confirm what Brian brought our attention a while ago. ------------------- 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 Peter Stuge > Sent: Tuesday, September 23, 2003 9:09 PM > To: linuxbios at clustermatic.org > Subject: Re: NS Geode GX1 + CS5530 +PC 97317 superio > > On Mon, Sep 22, 2003 at 10:15:40PM +0530, amits at myrealbox.com wrote: > > Hi , > > > > How do I extract the VGA BIOS from the Insyde ExpressROM??the same way as > in > > case of the EPIA will work? ANd in that case ... how can we find out IF it > > uses some calls that are implemented in the underlying XpressROM BIOS ?? > > XpressROM is a minimalist BIOS sold by Insyde. > > XpressLOADER is another name for the BLDT, available from either Insyde or > NSC. (I believe it's still NSC.) > > BLDT is the Boot Loader Development Toolkit and contains some building > blocks for making a BIOS similar to the XpressROM but lacking a few features > that may or may not be critical. ACPI and various legacy BIOS services e.g. > > The BLDT is (was) available free of charge and IIRC you're even allowed to > develop open source software after reading it. Don't take my word for this > though. > > See if you can get hold of the BLDT, I think it'll make things a lot easier > than dealing with XpressROM, especially when what you really want to do is > run LinuxBIOS. :) > > > //Peter > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From stuge-linuxbios at cdy.org Tue Sep 23 23:10:00 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue Sep 23 23:10:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: <000801c38239$d343f9a0$0100a8c0@who5> References: <20030924010852.GA16965@foo.birdnet.se> <000801c38239$d343f9a0$0100a8c0@who5> Message-ID: <20030924033108.GA27244@foo.birdnet.se> On Tue, Sep 23, 2003 at 09:18:48PM -0400, Gregg C Levine wrote: > > -----Original Message----- > > > > XpressLOADER is another name for the BLDT, available from either > > Insyde or NSC. (I believe it's still NSC.) > > Perhaps. But NSC's webpage insists that they have indeed sold the > entire line to AMD, and that presumably included software tools, and > even development support. Right, I had known this if I hadn't been sending emails after a long day of powerfail recovery and stress. Thanks for refreshing my memory though! :) //Peter From hansolofalcon at worldnet.att.net Tue Sep 23 23:19:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue Sep 23 23:19:01 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: <20030924033108.GA27244@foo.birdnet.se> Message-ID: <001101c3824d$f01f9480$0100a8c0@who5> Hello (again) from Gregg C Levine Your welcome Peter! I know the feeling. I've had days like that. Besides. Ron feels I'm making a difference to our group, so I feel I should contribute stuff like that. ------------------- 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 Peter Stuge > Sent: Tuesday, September 23, 2003 11:31 PM > To: linuxbios at clustermatic.org > Subject: Re: NS Geode GX1 + CS5530 +PC 97317 superio > > On Tue, Sep 23, 2003 at 09:18:48PM -0400, Gregg C Levine wrote: > > > -----Original Message----- > > > > > > XpressLOADER is another name for the BLDT, available from either > > > Insyde or NSC. (I believe it's still NSC.) > > > > Perhaps. But NSC's webpage insists that they have indeed sold the > > entire line to AMD, and that presumably included software tools, and > > even development support. > > Right, I had known this if I hadn't been sending emails after a long day of > powerfail recovery and stress. Thanks for refreshing my memory though! :) > > > //Peter > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From niki.waibel at newlogic.com Wed Sep 24 04:03:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 24 04:03:01 2003 Subject: EPIA-M serial port information In-Reply-To: <200309231737.h8NHbWEt003372@xdr.com> Message-ID: <200309240826.h8O8Q9h4019194@enterprise2.newlogic.at> > Based on some emails from Andrew I started poking around into the > epia-m serial port problem. Here are my observations: > The 9 pin internal serial port is part of the VT1211 chip, not > the VT8235, or other chips with serial ports. > > Under linux all baud rates are 1/2 what they should be. So if I pick > 115200, I get 57600. If I pick 19200, I get 9600, etc. > > I can fix linux with > setserial /dev/ttyS0 baud_base 57600 > Then the actual baud rate matches what I expect. 38400 and 115200 cannot be > achieved though. > > Andrew says if he boots with Award and the warm boots into linuxbios, the > serial port is 115200. confirmed (epia-m @ 600mhz). if i power off / on the epia-m then i get the lower speed. > On the epia-m motherboard near the VT1211 chip is a crystal oscillator labeled > KTS24.5X1K, which suggests it is 24.5 mhz. The VT1211 spec calls for a 48 mhz > clock. Don't know if this is the cause of the problem, VT1211 being driven by > 1/2 speed clock. > > My guess is there is some register in the VT1211 that has to be tweaked to > specify the serial port clock divisor. linuxbios doesn't touch this at all. > award bios sets it to match the 24.5 mhz crystal. On cold startup the vt1211 > defaults to assuming 48 mhz input clock. This explains all observations, but > doesn't solve the problem... > > I just put a scope on pin 17 of the vt1211, it appears to be 48 mhz though so > that blows that theory. niki From stepan at suse.de Wed Sep 24 04:06:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 24 04:06:01 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: <20030924003128.GC8649@foo.birdnet.se> References: <20030923025100.17470.77889.Mailman@nwn.definitive.org> <3F70B565.6070300@direcpc.com> <20030924003128.GC8649@foo.birdnet.se> Message-ID: <20030924082818.GB1970@suse.de> * Peter Stuge [030924 02:31]: > On Tue, Sep 23, 2003 at 05:04:37PM -0400, Thomas Fritz wrote: > > The board has an Award BIOS little square-like ROM, > > This is probably a regular flash ROM in a PLCC package. > > > and a larger 8MB ROM which holds Windows CE. > > What kind of ROM is this, exactly? Can you peel off the label and read > what's printed on the chip(s)? probably a DiskOnChip, This looks like the GX1 board I have. Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From niki.waibel at newlogic.com Wed Sep 24 04:19:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 24 04:19:00 2003 Subject: epia-m 600 -- still not working In-Reply-To: Message-ID: <200309240842.h8O8g5h4021157@enterprise2.newlogic.at> On 23-Sep-2003 ron minnich wrote: > On Tue, 23 Sep 2003, Niki Waibel wrote: > >> any idea why linuxbios is not starting on the epia-m 600? >> i run memtest86 -- all tests (took about 24hours ;-) -> everyting ok. >> (run memtest86 from lilo). >> i also tried the patch of Ian Smith . > > ok, so you did memtest86 as a payload and it worked? no. executed memtest86 from lilo -- not as payload. as i sayed, the payload code is not executed / not reached. linuxbios seems to stop in c_start.s and it never reaches src/arch/i386/lib/hardwaremain.c (i think so, because there are some printk's in harwaremain which i never see on the serial console). > It's time to try XIP (execute in place) and see how it goes. xip? instead of copying to ram, execute the code directly from the rom? From aip at cwlinux.com Wed Sep 24 04:31:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Sep 24 04:31:01 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309240842.h8O8g5h4021157@enterprise2.newlogic.at>; from Niki Waibel on Wed, Sep 24, 2003 at 10:42:05AM +0200 References: <200309240842.h8O8g5h4021157@enterprise2.newlogic.at> Message-ID: <20030924165326.A12115@mail.cwlinux.com> Hi, > no. executed memtest86 from lilo -- not as payload. > as i sayed, the payload code is not executed / not reached. > linuxbios seems to stop in c_start.s and it never reaches > src/arch/i386/lib/hardwaremain.c (i think so, because there > are some printk's in harwaremain which i never see on the > serial console). You probably want to copy the 0:00.0 pci register setting to the raminit.inc. Most likly is the memory bank/type causing the problem. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From niki.waibel at newlogic.com Wed Sep 24 04:46:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 24 04:46:00 2003 Subject: epia-m 600 -- still not working In-Reply-To: <20030924165326.A12115@mail.cwlinux.com> Message-ID: <200309240909.h8O996h4024447@enterprise2.newlogic.at> i just got a romimage from ian smith (thanks a lot!). see this!!! === LinuxBIOS-1.0.0 Tue Sep 23 21:19:35 BST 2003 starting... Testing SDRAM : 00000000-0009ffff SDRAM fill: 0009ffff SDRAM verify: 0009ffff Done. Copying LinuxBIOS to ram. 000f0fd4 00004000 ffffffff Jumping to LinuxBIOS. 000f0fd0 00006c8c ffeef6ff 010f2efa 00406115 0410ea00 18b80010 00004000 010f2efa 00406115 4010ea00 00100000 000018b8 8ed88e00 LinuxBIOS-1.0.0 Tue Sep 23 21:19:35 BST 2003 rebooting... Finding PCI configuration type. PCI: Using configuration type 1 Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1106/3123] PCI: 00:01.0 [1106/b091] PCI: 00:0d.0 [1106/3044] PCI: 00:10.0 [1106/3038] PCI: 00:10.1 [1106/3038] PCI: 00:10.2 [1106/3038] PCI: 00:10.3 [1106/3104] PCI: 00:11.0 [1106/3177] PCI: 00:11.1 [1106/0571] PCI: 00:11.5 [1106/3059] PCI: 00:12.0 [1106/3065] PCI: 00:14.0 [8086/1229] PCI: pci_scan_bus for bus 1 PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done Allocating PCI resources... PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it PCI: 00:00.0 register 10(00000008), read-only ignoring it ASSIGN RESOURCES, bus 0 PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem PCI: 00:0d.0 10 <- [0xfeb01000 - 0xfeb017ff] mem PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io PCI: 00:10.0 20 <- [0x000018c0 - 0x000018df] io PCI: 00:10.1 20 <- [0x000018e0 - 0x000018ff] io PCI: 00:10.2 20 <- [0x00001c00 - 0x00001c1f] io PCI: 00:10.3 10 <- [0xfeb02000 - 0xfeb020ff] mem PCI: 00:11.1 20 <- [0x00001c20 - 0x00001c2f] io PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io PCI: 00:12.0 14 <- [0xfeb03000 - 0xfeb030ff] mem PCI: 00:14.0 10 <- [0xfeb00000 - 0xfeb00fff] mem PCI: 00:14.0 14 <- [0x00001880 - 0x000018bf] io PCI: 00:14.0 18 <- [0xfea00000 - 0xfeafffff] mem ASSIGNED RESOURCES, bus 0 done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 PCI: 00:01.0 cmd <- 07 PCI: 00:0d.0 cmd <- 83 PCI: 00:10.0 cmd <- 01 PCI: 00:10.1 cmd <- 01 PCI: 00:10.2 cmd <- 01 PCI: 00:10.3 cmd <- 02 PCI: 00:11.0 cmd <- 87 PCI: 00:11.1 cmd <- 07 PCI: 00:11.5 cmd <- 01 PCI: 00:12.0 cmd <- 83 PCI: 00:14.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized totalram: 127M 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: 64MB, type WB Setting variable MTRR 1, base: 64MB, range: 32MB, type WB Setting variable MTRR 2, base: 96MB, range: 16MB, type WB Setting variable MTRR 3, base: 112MB, range: 8MB, type WB Setting variable MTRR 4, base: 120MB, range: 4MB, type WB Setting variable MTRR 5, base: 124MB, range: 2MB, 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 : 0x03 Feature flags : 0x00803035 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Disabling local apic...done. CPU #0 Initialized Mainboard fixup Final mainboard fixup Southbridge fixup setting firewire Assigning IRQ 10 to 0:d.0 Readback = 10 setting usb Assigning IRQ 11 to 0:10.0 Readback = 11 Assigning IRQ 10 to 0:10.1 Readback = 10 Assigning IRQ 12 to 0:10.2 Readback = 12 Assigning IRQ 5 to 0:10.3 Readback = 5 setting ethernet Assigning IRQ 11 to 0:12.0 Readback = 11 setting pci slot Assigning IRQ 10 to 0:14.0 Readback = 10 setting vt8235 slot Assigning IRQ 5 to 0:11.1 Readback = 5 Assigning IRQ 12 to 0:11.5 Readback = 12 Checking IRQ routing tables... /home/ian/work/optos/linuxbios/cvs/freebios/src/arch/i386/lib/pirq_routing.c: 0 done. Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 00000674 checksum 40ff Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000ffff Cannot Load ELF Image === so it seems that mem config, copy to mem, mem itself and jump to mem are okay. maybe my compiler or the binutils have done some fuckup. niki On 24-Sep-2003 Andrew Ip wrote: > Hi, > >> no. executed memtest86 from lilo -- not as payload. >> as i sayed, the payload code is not executed / not reached. >> linuxbios seems to stop in c_start.s and it never reaches >> src/arch/i386/lib/hardwaremain.c (i think so, because there >> are some printk's in harwaremain which i never see on the >> serial console). > You probably want to copy the 0:00.0 pci register setting > to the raminit.inc. Most likly is the memory bank/type causing > the problem. > > -Andrew > > -- > Andrew Ip > Email: aip at cwlinux.com > Tel: (852) 2542 2046 > Fax: (852) 2542 2036 > Mobile: (852) 9201 9866 > > Cwlinux Limited > Unit 202B 2/F Lai Cheong Factory Building, > 479-479A Castle Peak Road, > Lai Chi Kok, Kowloon, > Hong Kong. > > For public pgp key, please obtain it from http://www.keyserver.net/en. -- niki w. waibel - system administrator @ newlogic technologies ag From aip at cwlinux.com Wed Sep 24 04:58:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Sep 24 04:58:01 2003 Subject: Possible bug in DDR SDRAM init code for VT8623? In-Reply-To: <3F705A49.2060100@abelon.com>; from Ian Smith on Tue, Sep 23, 2003 at 03:35:53PM +0100 References: <3F705A49.2060100@abelon.com> Message-ID: <20030924172111.C12225@mail.cwlinux.com> It is committed. Thanks, Ian. -Andrew On Tue, Sep 23, 2003 at 03:35:53PM +0100, Ian Smith wrote: > I've been working on bringing up Linuxbios on a board which is based > closely on the EPIA-M and I think I may have found a bug in the DDR > SDRAM init code in src/northbridge/via/vt8623/raminit.inc > > The VIA Northbridge data sheet says that as part of the DDR init > sequence you need to read from specific addresses on the bank but I > think the registers to do these reads are not being set up properly > which can cause the RAM test to fail. > > I adjusted a number of register settings to be the same as a sample > Award Bios but it made no difference so I took a closer look at the DDR > and found that %ecx was being set up with the memory location to read > from instead of %esi. > > The diff for my fix is as follows: > > Index: src/northbridge/via/vt8623/raminit.inc > =================================================================== > RCS file: > /cvsroot/freebios/freebios/src/northbridge/via/vt8623/raminit.inc,v > retrieving revision 1.5 > diff -r1.5 raminit.inc > 85c85 > < movl $0x2000, %ecx > --- > > movl $0x2000, %esi /* IAS changed from ecx to esi */ > 89c89 > < movl $0x800, %ecx > --- > > movl $0x800, %esi /* IAS changed from ecx to esi */ > 119c119 > < movl $0x350, %ecx > --- > > movl $0x350, %esi /* IAS changed from ecx to esi */ > > What is odd is that the original code works fine on the Via reference > board (same design as EPIA-M) but when I try to run it on my customer > board it fails until I make these changes. > > Does anyone with more knowledge than me of the Via chipsets have any > ideas about this? > > Cheers > > Ian > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From rimy2000 at hotmail.com Wed Sep 24 05:07:01 2003 From: rimy2000 at hotmail.com (elife elife) Date: Wed Sep 24 05:07:01 2003 Subject: Windows-based terminals - what can be done? Message-ID: Hi stepan, Have you let linuxbios works with VGA support in your GX1 board ? Best Regards! >From: Stefan Reinauer >To: linuxbios at clustermatic.org >Subject: Re: Windows-based terminals - what can be done? >Date: Wed, 24 Sep 2003 10:28:19 +0200 > >* Peter Stuge [030924 02:31]: > > On Tue, Sep 23, 2003 at 05:04:37PM -0400, Thomas Fritz wrote: > > > The board has an Award BIOS little square-like ROM, > > > > This is probably a regular flash ROM in a PLCC package. > > > > > and a larger 8MB ROM which holds Windows CE. > > > > What kind of ROM is this, exactly? Can you peel off the label and read > > what's printed on the chip(s)? > >probably a DiskOnChip, This looks like the GX1 board I have. > > >Best regards, > Stefan Reinauer > >-- >Architecture Team > SuSE Linux AG >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From rimy2000 at hotmail.com Wed Sep 24 05:11:01 2003 From: rimy2000 at hotmail.com (elife elife) Date: Wed Sep 24 05:11:01 2003 Subject: epia-m 600 -- still not working Message-ID: Maybe you can dump data in init_bytes() to ensure they are the payload you want. >From: Niki Waibel >Reply-To: Niki Waibel >To: Andrew Ip >CC: ron minnich , linuxbios at clustermatic.org >Subject: Re: epia-m 600 -- still not working >Date: Wed, 24 Sep 2003 11:09:06 +0200 (MEST) > >i just got a romimage from ian smith (thanks a lot!). >see this!!! >=== >LinuxBIOS-1.0.0 Tue Sep 23 21:19:35 BST 2003 starting... >Testing SDRAM : 00000000-0009ffff >SDRAM fill: >0009ffff >SDRAM verify: >0009ffff >Done. >Copying LinuxBIOS to ram. >000f0fd4 00004000 ffffffff >Jumping to LinuxBIOS. >000f0fd0 00006c8c ffeef6ff 010f2efa 00406115 0410ea00 18b80010 >00004000 010f2efa 00406115 4010ea00 00100000 000018b8 8ed88e00 >LinuxBIOS-1.0.0 Tue Sep 23 21:19:35 BST 2003 rebooting... >Finding PCI configuration type. >PCI: Using configuration type 1 >Scanning PCI bus...PCI: pci_scan_bus for bus 0 >PCI: 00:00.0 [1106/3123] >PCI: 00:01.0 [1106/b091] >PCI: 00:0d.0 [1106/3044] >PCI: 00:10.0 [1106/3038] >PCI: 00:10.1 [1106/3038] >PCI: 00:10.2 [1106/3038] >PCI: 00:10.3 [1106/3104] >PCI: 00:11.0 [1106/3177] >PCI: 00:11.1 [1106/0571] >PCI: 00:11.5 [1106/3059] >PCI: 00:12.0 [1106/3065] >PCI: 00:14.0 [8086/1229] >PCI: pci_scan_bus for bus 1 >PCI: pci_scan_bus returning with max=01 >PCI: pci_scan_bus returning with max=01 >done >Allocating PCI resources... >PCI: 00:00.0 register 10(00000008), read-only ignoring it >PCI: 00:00.0 register 10(00000008), read-only ignoring it >PCI: 00:00.0 register 10(00000008), read-only ignoring it >PCI: 00:00.0 register 10(00000008), read-only ignoring it >ASSIGN RESOURCES, bus 0 >PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io >PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem >PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem >PCI: 00:0d.0 10 <- [0xfeb01000 - 0xfeb017ff] mem >PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io >PCI: 00:10.0 20 <- [0x000018c0 - 0x000018df] io >PCI: 00:10.1 20 <- [0x000018e0 - 0x000018ff] io >PCI: 00:10.2 20 <- [0x00001c00 - 0x00001c1f] io >PCI: 00:10.3 10 <- [0xfeb02000 - 0xfeb020ff] mem >PCI: 00:11.1 20 <- [0x00001c20 - 0x00001c2f] io >PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io >PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io >PCI: 00:12.0 14 <- [0xfeb03000 - 0xfeb030ff] mem >PCI: 00:14.0 10 <- [0xfeb00000 - 0xfeb00fff] mem >PCI: 00:14.0 14 <- [0x00001880 - 0x000018bf] io >PCI: 00:14.0 18 <- [0xfea00000 - 0xfeafffff] mem >ASSIGNED RESOURCES, bus 0 >done. >Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06 >PCI: 00:01.0 cmd <- 07 >PCI: 00:0d.0 cmd <- 83 >PCI: 00:10.0 cmd <- 01 >PCI: 00:10.1 cmd <- 01 >PCI: 00:10.2 cmd <- 01 >PCI: 00:10.3 cmd <- 02 >PCI: 00:11.0 cmd <- 87 >PCI: 00:11.1 cmd <- 07 >PCI: 00:11.5 cmd <- 01 >PCI: 00:12.0 cmd <- 83 >PCI: 00:14.0 cmd <- 03 >done. >Initializing PCI devices... >PCI devices initialized >totalram: 127M >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: 64MB, type WB >Setting variable MTRR 1, base: 64MB, range: 32MB, type WB >Setting variable MTRR 2, base: 96MB, range: 16MB, type WB >Setting variable MTRR 3, base: 112MB, range: 8MB, type WB >Setting variable MTRR 4, base: 120MB, range: 4MB, type WB >Setting variable MTRR 5, base: 124MB, range: 2MB, 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 : 0x03 >Feature flags : 0x00803035 > > >MTRR check >Fixed MTRRs : Enabled >Variable MTRRs: Enabled > >Disabling local apic...done. >CPU #0 Initialized >Mainboard fixup >Final mainboard fixup >Southbridge fixup >setting firewire >Assigning IRQ 10 to 0:d.0 > Readback = 10 >setting usb >Assigning IRQ 11 to 0:10.0 > Readback = 11 >Assigning IRQ 10 to 0:10.1 > Readback = 10 >Assigning IRQ 12 to 0:10.2 > Readback = 12 >Assigning IRQ 5 to 0:10.3 > Readback = 5 >setting ethernet >Assigning IRQ 11 to 0:12.0 > Readback = 11 >setting pci slot >Assigning IRQ 10 to 0:14.0 > Readback = 10 >setting vt8235 slot >Assigning IRQ 5 to 0:11.1 > Readback = 5 >Assigning IRQ 12 to 0:11.5 > Readback = 12 >Checking IRQ routing tables... >/home/ian/work/optos/linuxbios/cvs/freebios/src/arch/i386/lib/pirq_routing.c: 0 >done. >Copying IRQ routing tables to 0xf0000...done. >Verifing priq routing tables copy at 0xf0000...failed >Wrote linuxbios table at: 00000500 - 00000674 checksum 40ff > >Welcome to elfboot, the open sourced starter. >January 2002, Eric Biederman. >Version 1.2 > > 37:init_bytes() - zkernel_start:0xfffc0000 zkernel_mask:0x0000ffff >Cannot Load ELF Image >=== > >so it seems that mem config, copy to mem, mem itself and jump to mem are okay. >maybe my compiler or the binutils have done some fuckup. > >niki > >On 24-Sep-2003 Andrew Ip wrote: > > Hi, > > > >> no. executed memtest86 from lilo -- not as payload. > >> as i sayed, the payload code is not executed / not reached. > >> linuxbios seems to stop in c_start.s and it never reaches > >> src/arch/i386/lib/hardwaremain.c (i think so, because there > >> are some printk's in harwaremain which i never see on the > >> serial console). > > You probably want to copy the 0:00.0 pci register setting > > to the raminit.inc. Most likly is the memory bank/type causing > > the problem. > > > > -Andrew > > > > -- > > Andrew Ip > > Email: aip at cwlinux.com > > Tel: (852) 2542 2046 > > Fax: (852) 2542 2036 > > Mobile: (852) 9201 9866 > > > > Cwlinux Limited > > Unit 202B 2/F Lai Cheong Factory Building, > > 479-479A Castle Peak Road, > > Lai Chi Kok, Kowloon, > > Hong Kong. > > > > For public pgp key, please obtain it from http://www.keyserver.net/en. > >-- >niki w. waibel - system administrator @ newlogic technologies ag >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ ???? MSN Explorer: http://explorer.msn.com/lccn From stepan at suse.de Wed Sep 24 05:20:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Wed Sep 24 05:20:00 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: References: Message-ID: <20030924094318.GD2075@suse.de> * elife elife [030924 11:30]: > Hi stepan, > Have you let linuxbios works with VGA support in your GX1 board ? No, I didn't get it working, but there were some reports that it can be done some time ago. Stefan -- Architecture Team SuSE Linux AG From ts1 at tsn.or.jp Wed Sep 24 06:08:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Wed Sep 24 06:08:00 2003 Subject: supporting the EPIA-M 10000 VGA [PMX:##] In-Reply-To: References: <20030923220802.GA849@tsn.or.jp> Message-ID: <20030924103031.GA29384@tsn.or.jp> On Tue, Sep 23, 2003 at 05:00:39PM -0600, ron minnich wrote: > On Wed, 24 Sep 2003, SONE Takeshi wrote: > > I saw an old version of my fixes to idt.c and vgabios.c is commited. > > This version does not pass dev/busfn to the VGABIOS correctly. > send me the fix. I thought this was the right one. Sorry. Attached. -- Takeshi -------------- next part -------------- A non-text attachment was scrubbed... Name: idt.c Type: text/x-csrc Size: 7631 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vgabios.c Type: text/x-csrc Size: 6517 bytes Desc: not available URL: From moedeker at hmk-gmbh.de Wed Sep 24 06:50:01 2003 From: moedeker at hmk-gmbh.de (=?iso-8859-1?Q?Bernd_M=F6deker?=) Date: Wed Sep 24 06:50:01 2003 Subject: Does anyone has text console or framebuffer working on SC1200 without VGA-BIOS ? In-Reply-To: Message-ID: <135968A4EEB54B43A96B269C80D3B2C5018A95@frontman.hmk.de> Hi all, after googleling for "xpressloader" I found some information about the vga architecture of SC1200. All known VGA bioses need an VSA-Bios which emulates the standard vga registers and mappings. So Linuxbios is not able to use vga at SC1200. Also the framebuffer driver nsc.o (v 2.77) needs this VSA1 oder VSA2 bios. The only way to find out of this mess may be the use of XFree86 V4.x which directly uses the SC1200 hardware. But I had this not tested - yet. Here is the very interesting link: http://www.larwe.com/technical/geode_linux.html Bernd > -----Original Message----- > From: ron minnich [mailto:rminnich at lanl.gov] > Sent: Tuesday, September 23, 2003 11:12 PM > To: Bernd M?deker > Subject: Re: Does anyone has text console or framebuffer working on > SC1200 without VGA-BIOS ? > > > make sure it is legal to send it before you send it. I don't want > something that is restricted in some way. > > Or else tell me where to get it. > > ron > From niki.waibel at newlogic.com Wed Sep 24 07:00:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 24 07:00:00 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309240909.h8O996h4024447@enterprise2.newlogic.at> Message-ID: <200309241122.h8OBMFh4011531@enterprise2.newlogic.at> okay. i found 2 reasons why linuxbios on my epia-m 600mhz was not booting. it stopped after the following msgs on the serial console: === LinuxBIOS-1.0.0 Wed Sep 24 13:12:11 CEST 2003 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. === reason a) in freebios-20030924/src/northbridge/via/vt8623/raminit.inc i switched 0x350 to 0x150, because i have a 512MByte, DDR, 133MHz, CL2 infineon memory. === /* 0x150 if CAS Latency 2 or 0x350 CAS Latency 2.5 */ movl $0x150, %esi movl %ds:(%esi), %eax === but this does *NOT* work!!! 0x350 is fine. reason b) again in freebios-20030924/src/northbridge/via/vt8623/raminit.inc the patch from ian (i think it is already in the CVS, but sourceforge seems to be slow/strange as usual) is necessary: === 85c85 < movl $0x2000, %ecx --- > movl $0x2000, %esi /* IAS changed from ecx to esi */ 89c89 < movl $0x800, %ecx --- > movl $0x800, %esi /* IAS changed from ecx to esi */ 119c119 < movl $0x350, %ecx --- > movl $0x350, %esi /* IAS changed from ecx to esi */ === in addition i can confirm that compilation of linuxbios with gcc-3.3.1 and binutils-2.14 is fine... thanks a lot, especially ron, andrew and ian, for your help! niki From niki.waibel at newlogic.com Wed Sep 24 07:51:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Wed Sep 24 07:51:01 2003 Subject: memory epia-m 127M != 512M Message-ID: <200309241214.h8OCE1h4017905@enterprise2.newlogic.at> i use a 512MByte mem module in the epia-m 600mhz and linuxbios sayes: === totalram: 127M === i modified src/northbridge/via/vt8623/northbridge.c === diff -u -N -r freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c freebios-20030924/src/northbridge/via/vt8623/north bridg e.c --- freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c 2003-06-29 18:23:58.000000000 +0200 +++ freebios-20030924/src/northbridge/via/vt8623/northbridge.c 2003-09-24 14:10:22.025680920 +0200 @@ -9,10 +9,14 @@ { unsigned long totalmem; unsigned char bank, mem, prevmem; +#if 0 // fix me later -- there are two more banks at 0x56 and 0x57 unsigned long firstbank = 0x5a, lastbank = 0x5d; +#endif + unsigned long banks[] = { 0x56, 0x57, 0x5a, 0x5b, 0x5c, 0x5d }; + const unsigned long nbanks = 6; + unsigned long i; u8 sma_status, sma_size, sma_size_bits; - u8 val; struct pci_dev *pcidev; @@ -28,8 +32,9 @@ else sma_size = 0x01 << sma_size_bits; - for(totalmem = mem = prevmem = 0, bank = firstbank; - bank <= lastbank; bank++) { + totalmem = mem = prevmem = 0; + for(i=0; i Message-ID: On Wed, 24 Sep 2003, Niki Waibel wrote: > instead of copying to ram, execute the code directly from the rom? yes indeed, the original way we used to run linuxbios. ron From rminnich at lanl.gov Wed Sep 24 09:39:41 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 24 09:39:41 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309240842.h8O8g5h4021157@enterprise2.newlogic.at> Message-ID: On Wed, 24 Sep 2003, Niki Waibel wrote: > no. executed memtest86 from lilo -- not as payload. ah, so we really don't know anything from that test. OK. ron From rminnich at lanl.gov Wed Sep 24 09:40:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 24 09:40:01 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309240909.h8O996h4024447@enterprise2.newlogic.at> Message-ID: what machine are you on, what install of what os? ron From rminnich at lanl.gov Wed Sep 24 09:50:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 24 09:50:01 2003 Subject: epia-m 600 -- still not working In-Reply-To: <200309241122.h8OBMFh4011531@enterprise2.newlogic.at> Message-ID: we need to really fix this epia platform. This juggling of constants is the wrong thing to do. If somebody has the time they need to go in and get rid of the magic numbers use the SPD properly. ron From aip at cwlinux.com Wed Sep 24 10:24:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Sep 24 10:24:01 2003 Subject: epia-m 600 -- still not working In-Reply-To: ; from ron minnich on Wed, Sep 24, 2003 at 08:12:57AM -0600 References: <200309241122.h8OBMFh4011531@enterprise2.newlogic.at> Message-ID: <20030924224636.A15747@mail.cwlinux.com> Hi, I will try to use Dave's sample code to fix it this weekend. Since I have noticed more and more people are using it, it definitly has to be fixed. -Andrew On Wed, Sep 24, 2003 at 08:12:57AM -0600, ron minnich wrote: > we need to really fix this epia platform. This juggling of constants is > the wrong thing to do. If somebody has the time they need to go in and get > rid of the magic numbers use the SPD properly. > > ron > -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From bgr at gw.linespeed.net Wed Sep 24 10:29:00 2003 From: bgr at gw.linespeed.net (Brian G. Rhodes) Date: Wed Sep 24 10:29:00 2003 Subject: NS Geode GX1 + CS5530 +PC 97317 superio In-Reply-To: <000801c38239$d343f9a0$0100a8c0@who5> References: <000801c38239$d343f9a0$0100a8c0@who5> Message-ID: They have to still support the chips they sold. They have stopped selling anything other than d3 gx1 processors as of june this year, but the dealer market is still flooded with older ones. what, what am I talking about. national never had support even when they said they had support. they're the sigma designs of cpu makers. Brian G Rhodes bgr at linespeed.net +1 612-741-1191 On Tue, 23 Sep 2003, Gregg C Levine wrote: > Hello (again) from Gregg C Levine > Perhaps. But NSC's webpage insists that they have indeed sold the > entire line to AMD, and that presumably included software tools, and > even development support. Meaning anyone who had bought a board the > week before the event took place, would find themselves working with a > different group. As for your claims, I don't know, I'm just commenting > on the webpage. I can tell you, that it was badly laid out, and looked > like something done by someone who was just starting out in that > business, a far cry from all of the other things that they display > online. Also, it did confirm what Brian brought our attention a while > ago. > ------------------- > 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 Peter Stuge > > Sent: Tuesday, September 23, 2003 9:09 PM > > To: linuxbios at clustermatic.org > > Subject: Re: NS Geode GX1 + CS5530 +PC 97317 superio > > > > On Mon, Sep 22, 2003 at 10:15:40PM +0530, amits at myrealbox.com wrote: > > > Hi , > > > > > > How do I extract the VGA BIOS from the Insyde ExpressROM??the same > way as > > in > > > case of the EPIA will work? ANd in that case ... how can we find > out IF it > > > uses some calls that are implemented in the underlying XpressROM > BIOS ?? > > > > XpressROM is a minimalist BIOS sold by Insyde. > > > > XpressLOADER is another name for the BLDT, available from either > Insyde or > > NSC. (I believe it's still NSC.) > > > > BLDT is the Boot Loader Development Toolkit and contains some > building > > blocks for making a BIOS similar to the XpressROM but lacking a few > features > > that may or may not be critical. ACPI and various legacy BIOS > services e.g. > > > > The BLDT is (was) available free of charge and IIRC you're even > allowed to > > develop open source software after reading it. Don't take my word > for this > > though. > > > > See if you can get hold of the BLDT, I think it'll make things a lot > easier > > than dealing with XpressROM, especially when what you really want to > do is > > run LinuxBIOS. :) > > > > > > //Peter > > _______________________________________________ > > 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 Wed Sep 24 12:29:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Wed Sep 24 12:29:00 2003 Subject: supporting the EPIA-M 10000 VGA [PMX:##] In-Reply-To: <20030924103031.GA29384@tsn.or.jp> Message-ID: David Hendriks has tested and I have committed these new idt.c and vgabios.c ron From sbambach at gmx.net Wed Sep 24 12:41:00 2003 From: sbambach at gmx.net (Stefan Bambach) Date: Wed Sep 24 12:41:00 2003 Subject: linuxbios compatiblity for cv860a (epia based) Message-ID: <1064423023.1709.29.camel@ap-lnx-stefanb> Hi, Can somebody say something about compatibility with linuxbios ? I need: - USB - VGA (framebuffer with epiafb :-)) - Sound - IDE for booting from CF - network (for LAN support) - 256MB RAM additional PS2 (keyboard/mouse) and serial for development. Any experiences with these nice boards ? If you need some dumps from 860a, tell my exactly what. I will send it then. Stefan From sbambach at gmx.net Wed Sep 24 12:49:01 2003 From: sbambach at gmx.net (Stefan Bambach) Date: Wed Sep 24 12:49:01 2003 Subject: BIOS Savior for cv860a (epia based) Message-ID: <1064423516.1714.39.camel@ap-lnx-stefanb> Hi Andrew, I'm searching for a working BIOS Savior for my epia based board. I have a 860a model, but the 860b and 860c are interesting too. see also http://www.lex.com.tw/case-light.htm and follow the links. There is a PLCC socket and a 2M Flash (AMIC a290021T). What exact model do I need ? Stefan From tomfritz at direcpc.com Wed Sep 24 18:55:01 2003 From: tomfritz at direcpc.com (Thomas Fritz) Date: Wed Sep 24 18:55:01 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: <20030924090701.24500.4114.Mailman@nwn.definitive.org> References: <20030924090701.24500.4114.Mailman@nwn.definitive.org> Message-ID: <3F721E90.2060100@direcpc.com> >> >>What kind of ROM is this, exactly? Can you peel off the label and read >>what's printed on the chip(s)? > > > probably a DiskOnChip, This looks like the GX1 board I have. > Peel off the labels? Shucks, I can't do that...it'd be against Microsoft policy or something... [scampers off to peel the labels] Hey, it IS a DiskOnChip!...are these things Read-Only, or can they be re-written? From hansolofalcon at worldnet.att.net Wed Sep 24 19:04:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed Sep 24 19:04:01 2003 Subject: Windows-based terminals - what can be done? In-Reply-To: <3F721E90.2060100@direcpc.com> Message-ID: <002f01c382f3$7d62da00$0100a8c0@who5> Hello from Gregg C Levine Thomas, where'd you find these things? You've got my curiosity piqued. And can you post a digital photo of the actual unit some place? ------------------- 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 Thomas Fritz > Sent: Wednesday, September 24, 2003 6:46 PM > To: linuxbios at clustermatic.org > Subject: Re: Windows-based terminals - what can be done? > > >> > >>What kind of ROM is this, exactly? Can you peel off the label and read > >>what's printed on the chip(s)? > > > > > > probably a DiskOnChip, This looks like the GX1 board I have. > > > > Peel off the labels? Shucks, I can't do that...it'd be against > Microsoft policy or something... > > [scampers off to peel the labels] > > Hey, it IS a DiskOnChip!...are these things Read-Only, or can they be > re-written? > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From tomfritz at direcpc.com Wed Sep 24 19:39:01 2003 From: tomfritz at direcpc.com (Thomas Fritz) Date: Wed Sep 24 19:39:01 2003 Subject: 8MB DiskOnChip Message-ID: <3F7229D8.6080403@direcpc.com> heh...asking questions without thinking.. [slaps forehead]...of COURSE it's writable! Now I just have the question...if I can install linux to the DOC, then I don't have to muck about with the BIOS, right? My calculus professor always said, "If you not want to make mistake, do nothing." Oh well...or should I say, Alright! More reading to be done! From NEWBELL7 at magicn.com Wed Sep 24 20:03:00 2003 From: NEWBELL7 at magicn.com (NEWBELL7 at magicn.com) Date: Wed Sep 24 20:03:00 2003 Subject: [FILO] prompt doesn't work... Message-ID: <7e6401c382fb$9a4bffe0$81cda8c0@magicn.net> Hi, long time no see. I did build a filo with default config. ( make & make ) serial debug message is like below. But I can't type any command. VGA Console prompt has also the same problem. My Board is likely to EPIA 5000. Does FILO use only PS/2 keyboard as Input Device Driver? FILO !!! Good Idea . Thanks ... from newbie. ======================================================================== == FILO version 0.2 ( newbell at VIPER ) Thu Sep 25 09:18:26 KST 2003 Press for default boot, or for boot prompt... timed out boot: hda1:/boot/kernel.elf Unknown filesystem type boot: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Wed Sep 24 23:40:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Sep 24 23:40:00 2003 Subject: A case for your epia Message-ID: http://www.idot.com/TheStore/Desktop/777spec.asp?Product.id=777&Cate.id=14&Product.status=green $45. So we can get our EPIA with linuxbios from cwlinux.com, and then load them into this case. Might be a way to go. if only we could get 1 Mbyte flash parts for EPIA ... ron From ebiederman at lnxi.com Thu Sep 25 00:21:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 25 00:21:01 2003 Subject: epia800 In-Reply-To: <20030923124941.GA7680@tsn.or.jp> References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <20030923124941.GA7680@tsn.or.jp> Message-ID: SONE Takeshi writes: > On Tue, Sep 23, 2003 at 02:27:08AM -0600, Eric W. Biederman wrote: > > Actually the FILO polled IDE derives most directly from etherboot 5.1. > > > > There are a couple of small differences but nothing that looked too > > substantial. The biggest is the ide_bus_floating() that attempts to > > quickly see if an IDE cable is absent. > > Yes, I took it from Etherboot 5.1. > I added floating bus detection, and also changed the soft reset code > to see if the drive asserts BSY. I have seen IDE cables with a memory so I am not at all certain about the floating detection. > > FILO does look good from what I have seen of it. > > I'm really glad to hear that from you. The one thing I would really like to see is it using the LinuxBIOS table to find motherboard devices. Before falling back to more conventional things like a pci scan. That way you don't need to guess where the hardware is. Right now this is a chicken and the egg problem because that information is not being exported but that is one of the next steps for the freebios2 tree. > > Before anyone can guess anything we need a lot more detailed bug > > report than what has been seen so far. > > > > Steve how does your 1.2G Caviar fail? Is it not detected or is the > > problem something else? > > I think his problem is something related with geometry. Not with > detection. > > I thought I had a similar WD drive in my junk box, and I looked for it > today, without success. Instead I've found a 250MB Conner(!) drive, > and it worked perfectly with FILO! > > > SONE do you really have a system that with no IDE disk has the BSY bit > > stuck high. Or is that just what happens when you scan PIO ports that > > are not connected to and IDE controller. > > On EPIA the BSY bit is low when drive is absent, and it is the only > real hardware I run FILO. However, it helps quickly skipping the > non-existent 3rd and 4th IDE controllers, as you pointed out. Right. But if there are better ways of detecting the hardware I would rather we use that. Eric From ebiederman at lnxi.com Thu Sep 25 00:28:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 25 00:28:01 2003 Subject: epia800 In-Reply-To: <3F706BA9.8030400@nexpath.com> References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <3F706BA9.8030400@nexpath.com> Message-ID: Steve Gehlbach writes: > Eric W. Biederman wrote: > > > Steve how does your 1.2G Caviar fail? Is it not detected or is the > > problem something else? > > Everything works fine, it just gets the wrong data. I put in lots of printf's, > it is using ide_read_sector_lba, all results are normal AFAICT. I printed out > the sector (sector 0) that it read, it had about 50 initial values, then all > zeros. The real sector 0 is pretty much all filled. I grep'ed for a couple of > bytes from the bogus sector and they did not appear in the real sector, so I > think all of the data is bogus, not just shifted or something. > > The cmd.device byte (=0xe0) (and the others in this structure) appear correct in > > comparing to ATA spec. Is there ever any confusion about what the first sector > is (0 vs 1)? I could not find a specific statement in the ATA spec about this, > but it is a long spec. > > I was going to force it to use ide_read_sector_chs but did not have time. > > I switched to using my CF drive and it worked fine, so I don't think it was > cockpit trouble. Right. My only other guess is that some of the lba48 support my be interacting in a strange way and causing problems. We always write the lba48 high registers but we don't set them in the lba case. It should not cause a problem. But drives are diverse enough we might find some strange bugs. At least we have not yet found a drive that we have spin up problems with yet. Eric From ts1 at cma.co.jp Thu Sep 25 03:31:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu Sep 25 03:31:01 2003 Subject: [FILO] prompt doesn't work... In-Reply-To: <7e6401c382fb$9a4bffe0$81cda8c0@magicn.net> References: <7e6401c382fb$9a4bffe0$81cda8c0@magicn.net> Message-ID: <20030925075358.GA5831@cma.co.jp> On Thu, Sep 25, 2003 at 09:26:03AM +0900, NEWBELL7 at magicn.com wrote: > I did build a filo with default config. ( make & make ) > serial debug message is like below. But I can't type any command. > VGA Console prompt has also the same problem. > > My Board is likely to EPIA 5000. > > Does FILO use only PS/2 keyboard as Input Device Driver? PS/2 (or AT) keyboard and serial port. They must be enabled by LinuxBIOS. For serial port, turn off all the flow control of your terminal. It's fully tested with my EPIA 5000, so if you have the same board, it should work. Though it could be possible that your LinuxBIOS is configured differently than mine. -- Takeshi From niki.waibel at newlogic.com Thu Sep 25 03:32:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Thu Sep 25 03:32:00 2003 Subject: A case for your epia In-Reply-To: Message-ID: <200309250754.h8P7sph4010116@enterprise2.newlogic.at> On 25-Sep-2003 Ronald G. Minnich wrote: > http://www.idot.com/TheStore/Desktop/777spec.asp?Product.id=777&Cate.id=14&Product.status=green > > $45. > > So we can get our EPIA with linuxbios from cwlinux.com, and then load > them into this case. Might be a way to go. > > if only we could get 1 Mbyte flash parts for EPIA ... i bought the cases from http://www.ditech.at/ search for itx -- you should get 4 results (2 different versions in 2 colors). one case looks like the one on top. the other case is the case we bought. i thought that there is no fan because it has an external power supply. instead there are 2 small fans. ron, have you bought the case you mention on top? what about the power supply noise? niki From ian at abelon.com Thu Sep 25 03:54:01 2003 From: ian at abelon.com (Ian Smith) Date: Thu Sep 25 03:54:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <200309241214.h8OCE1h4017905@enterprise2.newlogic.at> References: <200309241214.h8OCE1h4017905@enterprise2.newlogic.at> Message-ID: <6.0.0.22.2.20030925090334.029ac088@mail.abelon.com> Hi Niki, I was looking at this as well and I think there may be a couple of problems here. The first is that I think the comments in the code may be a bit misleading (apologies to the original author!) AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be set to the same value as 0x5D i.e. the DRAM ending address for your highest populated bank of memory. Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and 0x56 are set to 0x10, which I think would equate to 128MB as you are seeing. I think if you possibly remove the references to 0x56 and 0x57 in northbridge.c (and set the number of banks to 4), then set the values in raminit.inc to what you want i.e. 0x5A = 0x20 0x5B = 0x40 0x5C = 0x40 0x5D = 0x40 0x56 = 0x40 0x57 = 0x40 then the size detect code might just work. Of course if your 512MB module actually has two banks of memory then you might need to add some extra code to initialise the second bank (not sure about this though. I need to get this working for the project I'm working on (as well as getting banks 2 and 3 going too), but at the moment I'm trying to get the VGA working so it might be a few days before I will the time to do some proper investigation. Hope this helps anyway Cheers Ian At 13:14 24/09/2003, Niki Waibel wrote: >i use a 512MByte mem module in the epia-m 600mhz and linuxbios sayes: >=== >totalram: 127M >=== > >i modified src/northbridge/via/vt8623/northbridge.c >=== >diff -u -N -r >freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c >freebios-20030924/src/northbridge/via/vt8623/north >bridg >e.c >--- >freebios-20030924.old/src/northbridge/via/vt8623/northbridge.c >2003-06-29 18:23:58.000000000 +0200 >+++ freebios-20030924/src/northbridge/via/vt8623/northbridge.c 2003-09-24 >14:10:22.025680920 +0200 >@@ -9,10 +9,14 @@ > { > unsigned long totalmem; > unsigned char bank, mem, prevmem; >+#if 0 > // fix me later -- there are two more banks at 0x56 and 0x57 > unsigned long firstbank = 0x5a, lastbank = 0x5d; >+#endif >+ unsigned long banks[] = { 0x56, 0x57, 0x5a, 0x5b, 0x5c, 0x5d }; >+ const unsigned long nbanks = 6; >+ unsigned long i; > u8 sma_status, sma_size, sma_size_bits; >- u8 val; > > struct pci_dev *pcidev; > >@@ -28,8 +32,9 @@ > else > sma_size = 0x01 << sma_size_bits; > >- for(totalmem = mem = prevmem = 0, bank = firstbank; >- bank <= lastbank; bank++) { >+ totalmem = mem = prevmem = 0; >+ for(i=0; i+ bank = banks[i]; > pci_read_config_byte(pcidev, bank, &mem); > // sanity check. If the mem value is < prevmem, > // that is an error, so skip this step. >@@ -41,7 +46,7 @@ > totalmem += (mem - prevmem) * 16; > prevmem = mem; > } >- >+ > totalmem -= sma_size; > totalmem *= 1024; > #if 0 >=== > >but that did not help. > >this is no urgent problem, because 128M is enough for the system i want >to build. but it could be a problem for other people. > >niki >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From ts1 at cma.co.jp Thu Sep 25 04:10:01 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu Sep 25 04:10:01 2003 Subject: epia800 In-Reply-To: References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <3F706BA9.8030400@nexpath.com> Message-ID: <20030925083230.GB5831@cma.co.jp> On Wed, Sep 24, 2003 at 11:00:52PM -0600, Eric W. Biederman wrote: > Right. My only other guess is that some of the lba48 support my be interacting > in a strange way and causing problems. We always write the lba48 high > registers but we don't set them in the lba case. It should not cause a problem. Do you mean something like this: ==== --- ide.c.org 2003-08-26 20:53:10.000000000 +0900 +++ ide.c 2003-09-25 17:26:34.000000000 +0900 @@ -316,13 +316,15 @@ mdelay(50); } outb(cmd->feature, IDE_REG_FEATURE(ctrl)); - outb(cmd->sector_count2, IDE_REG_SECTOR_COUNT(ctrl)); + if (cmd->command == IDE_CMD_READ_SECTORS_EXT) { + outb(cmd->sector_count2, IDE_REG_SECTOR_COUNT(ctrl)); + outb(cmd->lba_low2, IDE_REG_LBA_LOW(ctrl)); + outb(cmd->lba_mid2, IDE_REG_LBA_MID(ctrl)); + outb(cmd->lba_high2, IDE_REG_LBA_HIGH(ctrl)); + } outb(cmd->sector_count, IDE_REG_SECTOR_COUNT(ctrl)); - outb(cmd->lba_low2, IDE_REG_LBA_LOW(ctrl)); outb(cmd->lba_low, IDE_REG_LBA_LOW(ctrl)); - outb(cmd->lba_mid2, IDE_REG_LBA_MID(ctrl)); outb(cmd->lba_mid, IDE_REG_LBA_MID(ctrl)); - outb(cmd->lba_high2, IDE_REG_LBA_HIGH(ctrl)); outb(cmd->lba_high, IDE_REG_LBA_HIGH(ctrl)); outb(cmd->command, IDE_REG_COMMAND(ctrl)); } ==== -- Takeshi From niki.waibel at newlogic.com Thu Sep 25 04:27:01 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Thu Sep 25 04:27:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <6.0.0.22.2.20030925090334.029ac088@mail.abelon.com> Message-ID: <200309250849.h8P8nNh4017202@enterprise2.newlogic.at> hi ian, > The first is that I think the comments in the code may be a bit misleading > (apologies to the original author!) > > AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be > set to the same value as 0x5D i.e. the DRAM ending address for your highest > populated bank of memory. > > Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and > 0x56 are set to 0x10, which I think would equate to 128MB as you are seeing. hmmm > I think if you possibly remove the references to 0x56 and 0x57 in > northbridge.c (and set the number of banks to 4), then set the values in > raminit.inc to what you want i.e. > > 0x5A = 0x20 > 0x5B = 0x40 > 0x5C = 0x40 > 0x5D = 0x40 > 0x56 = 0x40 > 0x57 = 0x40 > > then the size detect code might just work. > > Of course if your 512MB module actually has two banks of memory then you > might need to add some extra code to initialise the second bank (not sure > about this though. > > I need to get this working for the project I'm working on (as well as > getting banks 2 and 3 going too), all the work which has to be done (regarding this) is almost impossible without the knowledge of the registers. because of that i cannot help much ... i dont want to write wrong code just because of lack of information. > but at the moment I'm trying to get the > VGA working so it might be a few days before I will the time to do some > proper investigation. so we need to wait for you, because it seems that you know how to program the beast :) > Hope this helps anyway as i sayed -- this is not urgent for me. it is just a bit annoying that via (and also other companies) are really slowing down the process of developement. i dont see the point in doing this. any fully working software make the companies, who produce hardware, more famous -> more money. hiding information is not a good way in my opinion. niki From ts1 at cma.co.jp Thu Sep 25 04:27:09 2003 From: ts1 at cma.co.jp (SONE Takeshi) Date: Thu Sep 25 04:27:09 2003 Subject: epia800 In-Reply-To: References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <20030923124941.GA7680@tsn.or.jp> Message-ID: <20030925084954.GC5831@cma.co.jp> On Wed, Sep 24, 2003 at 10:54:02PM -0600, Eric W. Biederman wrote: > I have seen IDE cables with a memory so I am not at all certain > about the floating detection. I'm not sure about non-standard devices. I believe this is what the commercial BIOS does. Anyway FILO only touches the bus the user requests. > The one thing I would really like to see is it using the LinuxBIOS table > to find motherboard devices. Before falling back to more conventional > things like a pci scan. That way you don't need to guess where the > hardware is. Right now this is a chicken and the egg problem because > that information is not being exported but that is one of the next steps > for the freebios2 tree. It would be good. Especially for video parameters. We could fill the Linux parameters correctly, so even the vesafb would work eventually. For now FILO just assumes the devices are initialized by LB as the way FILO expects. -- Takeshi From ian at abelon.com Thu Sep 25 05:35:01 2003 From: ian at abelon.com (Ian Smith) Date: Thu Sep 25 05:35:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <200309250849.h8P8nNh4017202@enterprise2.newlogic.at> References: <200309250849.h8P8nNh4017202@enterprise2.newlogic.at> Message-ID: <3F72BC3F.2020605@abelon.com> Niki Waibel wrote: >hi ian, > > >>The first is that I think the comments in the code may be a bit misleading >>(apologies to the original author!) >> >>AIUI the registers at 0x56 and 0x57 (and 0x5E and 0x5F as well) should be >>set to the same value as 0x5D i.e. the DRAM ending address for your highest >>populated bank of memory. >> >>Looking through northbridge/via/vt8623/raminit.inc it looks like 0x56 and >>0x56 are set to 0x10, which I think would equate to 128MB as you are seeing. >> >> > >hmmm > > >>I think if you possibly remove the references to 0x56 and 0x57 in >>northbridge.c (and set the number of banks to 4), then set the values in >>raminit.inc to what you want i.e. >> >>0x5A = 0x20 >>0x5B = 0x40 >>0x5C = 0x40 >>0x5D = 0x40 >>0x56 = 0x40 >>0x57 = 0x40 >> >>then the size detect code might just work. >> Rats - got this wrong (no coffee yet today :-) The units are 16MB in these registers so 0x5A should be 0x10 and the other should be 0x20. Sorry for any confusion. Blows a hole in my theory about the 128MB being detected.... >>Of course if your 512MB module actually has two banks of memory then you >>might need to add some extra code to initialise the second bank (not sure >>about this though. >> >>I need to get this working for the project I'm working on (as well as >>getting banks 2 and 3 going too), >> >> > >all the work which has to be done (regarding this) is almost impossible >without the knowledge of the registers. > >because of that i cannot help much ... i dont want to write wrong code >just because of lack of information. > > >>but at the moment I'm trying to get the >>VGA working so it might be a few days before I will the time to do some >>proper investigation. >> >> > >so we need to wait for you, because it seems that you know >how to program the beast :) > I think I may have just disproved that theory :-) >>Hope this helps anyway >> >> > >as i sayed -- this is not urgent for me. > >it is just a bit annoying that via (and also other companies) >are really slowing down the process of developement. i dont see >the point in doing this. any fully working software make the >companies, who produce hardware, more famous -> more money. >hiding information is not a good way in my opinion. > It does seem odd that they are so secretive. I've worked with a lot of chip vendors, both bigger and smaller, and I can't recall any of them being so paranoid about their data sheets. >niki > Cheers Ian From stepan at suse.de Thu Sep 25 08:34:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 25 08:34:00 2003 Subject: arima hdama and bus 1 In-Reply-To: References: Message-ID: <20030925125700.GC30889@suse.de> * ron minnich [030909 01:53]: > What happens is that linuxbios properly scans and enables bus 1, but the > linux that boots never scans bus 1 at all. So something is not quite set > up right. More as I find it. I'm still having this problem on the Solo. Is there any fix meanwhile? Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Thu Sep 25 09:17:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 09:17:00 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <3F72BC3F.2020605@abelon.com> Message-ID: On Thu, 25 Sep 2003, Ian Smith wrote: > Blows a hole in my theory about the 128MB being detected.... sorry, but those registers you are mentioning have *zero* impact on size detection. That's not what's going on here. Size detect is via SPD. We wrote a lot of that code here 3 years ago, and it was a hack then in an attempt to get the 8601 to work at all. If you look at how it works now: // 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) So the ram size is set to 256MB per bank. Then we proceed to initialize all the DRAM as though it were there. It is sufficient for SDRAM to do this. It is probably not sufficient for DDR to do this. Then, later, in C, we size it up via SPD (I think SONE did this work?) and set the right values in. Anyone who is setting values in just by jamming things in registers is going at it the wrong way and is doomed to fail. There are complex problems with the 8601, such as buffer strength issues, that require more sophistication. The right thing to do here is cut to freebios2 ASAP and write all this in C. It's just too hard in assembly. ron From rminnich at lanl.gov Thu Sep 25 09:21:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 09:21:01 2003 Subject: arima hdama and bus 1 In-Reply-To: <20030925125700.GC30889@suse.de> Message-ID: On Thu, 25 Sep 2003, Stefan Reinauer wrote: > * ron minnich [030909 01:53]: > > What happens is that linuxbios properly scans and enables bus 1, but the > > linux that boots never scans bus 1 at all. So something is not quite set > > up right. More as I find it. > > I'm still having this problem on the Solo. Is there any fix meanwhile? gee. I thought it was just me. OK, that's my fun for next week, once I get done all the mess that came up this week. ron From aip at cwlinux.com Thu Sep 25 09:41:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu Sep 25 09:41:00 2003 Subject: memory epia-m 127M != 512M In-Reply-To: ; from ron minnich on Thu, Sep 25, 2003 at 07:40:06AM -0600 References: <3F72BC3F.2020605@abelon.com> Message-ID: <20030925220344.A29770@mail.cwlinux.com> Hi Ron, > The right thing to do here is cut to freebios2 ASAP and write all this in > C. It's just too hard in assembly. Is there any platform has been ported to freebios2 besides AMD64? Any porting guide for that? Is it as easy as running buildtarget to generate the build directory? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From stepan at suse.de Thu Sep 25 10:22:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Thu Sep 25 10:22:00 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <20030925220344.A29770@mail.cwlinux.com> References: <3F72BC3F.2020605@abelon.com> <20030925220344.A29770@mail.cwlinux.com> Message-ID: <20030925144452.GB32255@suse.de> * Andrew Ip [030925 16:03]: > > The right thing to do here is cut to freebios2 ASAP and write all this in > > C. It's just too hard in assembly. > Is there any platform has been ported to freebios2 besides AMD64? Any Some PPC machines are supported as well. > porting guide for that? Is it as easy as running buildtarget to generate > the build directory? yes. calling buildtarget and then doing make in the freshly created directory will build you a flashable image "linuxbios.rom" Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Thu Sep 25 11:21:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 11:21:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <20030925220344.A29770@mail.cwlinux.com> Message-ID: Let's just start. Andrew, I will try to populate a skeleton epia directory in freebios2, and we can start filling it in. ron From steve at nexpath.com Thu Sep 25 11:47:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Sep 25 11:47:00 2003 Subject: epia800 In-Reply-To: References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <3F706BA9.8030400@nexpath.com> Message-ID: <3F731569.10201@nexpath.com> Eric W. Biederman wrote: >>I was going to force it to use ide_read_sector_chs but did not have time. >> >>I switched to using my CF drive and it worked fine, so I don't think it was >>cockpit trouble. > > > Right. My only other guess is that some of the lba48 support my be interacting > in a strange way and causing problems. We always write the lba48 high > registers but we don't set them in the lba case. It should not cause a problem. > > But drives are diverse enough we might find some strange bugs. > > At least we have not yet found a drive that we have spin up problems with yet. I did some more testing. Forcing CHS mode did not help. I looked at the older LB code, and started to cut and paste some of its init code into the new code just as an experiment. So far no help. I noticed the busy/wait loop in the original LB code looks at the error register. I also notice in the new code the pio_data_in routine does not check the error bit, matter of fact, the error bit is never checked anywhere AFAICT. Interestingly, if you check the error bit in the status register (bit 0), it is set after the pio_set_registers() command for my 1.2G WD (in pio_data_in for READ SECTOR(S) ), but not for another drive that works (7.5G WD). I looked at the ATA-2 and ATA-5 specs and the error stuff seems to have changed a little. I have not had a chance to put in code to see just where the error bit gets set, but it seems that once it is set you cannot go on without clearing it or something. (The original LB code looks at the error register without checking the error bit in the status register. The later ATA specs seem to indicate the error register bits are not valid unless the error bit is set in the status register.) -Steve From rminnich at lanl.gov Thu Sep 25 12:04:59 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 12:04:59 2003 Subject: arima mainboard config Message-ID: I find this in the arima mainboard config: ## ROM_SIZE is the size of boot ROM that this board will use. option ROM_SIZE = 524288 This is the wrong place. ROM_SIZE should always be in the target config file, not the mainboard config file. Recall that we no longer allow multiple settings of options, as a way of avoiding the "where did it get set last" syndrome. You only get to set them once. (we also disallow set-after-use, BTW). You can default them. I also note that in Options.lb, we are currently defaulting ROM_SIZE to 262144, also a mistake (mine). So what we need to do: in src/config/Options.lb, ROM_SIZE should have no default value. If you really want a default size for ROM_SIZE in the mainboard config, then default ROM_SIZE = 524288 in the mainboard file that way, for all my arimas on which I am using 1 MB parts, I can set option ROM_SIZE = 1024*1024 in my target config file. If no objections, I am going to remove the default setting in Options.lb, make the mainboard ROM_SIZE settings defaults, so I can continue to set them in the target config files. thanks ron From rminnich at lanl.gov Thu Sep 25 12:23:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 12:23:00 2003 Subject: epia tree in V2 Message-ID: I'm putting together an EPIA tree in V2. Give me a couple days. If this works it's definitely what we want to do. It should work. ron From ebiederman at lnxi.com Thu Sep 25 12:55:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 25 12:55:00 2003 Subject: arima mainboard config In-Reply-To: References: Message-ID: ron minnich writes: > I find this in the arima mainboard config: > ## ROM_SIZE is the size of boot ROM that this board will use. > option ROM_SIZE = 524288 > > > > This is the wrong place. ROM_SIZE should always be in the target config > file, not the mainboard config file. > > Recall that we no longer allow multiple settings of options, as a way of > avoiding the "where did it get set last" syndrome. You only get to set > them once. (we also disallow set-after-use, BTW). > > You can default them. I also note that in Options.lb, we are currently > defaulting ROM_SIZE to 262144, also a mistake (mine). > > So what we need to do: > > in src/config/Options.lb, ROM_SIZE should have no default value. > > If you really want a default size for ROM_SIZE in the mainboard config, > then > > default ROM_SIZE = 524288 > in the mainboard file This looks like the way to go. In general a motherboard will have a standard ROM_SIZE, and it requires generating a new rev of a motherboard to change that. > that way, for all my arimas on which I am using 1 MB parts, I can set > option ROM_SIZE = 1024*1024 > in my target config file. > > If no objections, I am going to remove the default setting in Options.lb, > make the mainboard ROM_SIZE settings defaults, so I can continue to set > them in the target config files. That sounds like a good path forward. Eric From rminnich at lanl.gov Thu Sep 25 13:01:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 13:01:01 2003 Subject: adding epia Message-ID: I've added a few things for epia. epia folks please look in freebios2 at src/northbridge/via/vt8601 (not done yet) src/southbridge/via/vt8231 the big thing to look at in the southbridge is how it is set up. The previous code was really out of touch w.r.t. the way you're supposed to do these chips nowadays, so this modified version is worth reading. I'll try to get more done on the mainboard today/tomorrow. ron p.s. freebios2 learning curve is a bit steep, but once you get the hang of it, you will probably like it. It got complicated when the k8 went in. From rminnich at lanl.gov Thu Sep 25 13:04:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 13:04:00 2003 Subject: why are we still doing this? Message-ID: in arima/hdama/Config.lb ## ## Clean up the motherboard id strings ## option MAINBOARD_PART_NUMBER="HDAMA" option MAINBOARD_VENDOR="ARIMA" OK, the config tool will create this by default: MAINBOARD_PART_NUMBER="hdama" MAINBOARD_VENDOR="arima" why do we need to put this type of thing in the mainboard config file? just wondering ron From rminnich at lanl.gov Thu Sep 25 13:13:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 13:13:00 2003 Subject: arima mainboard config In-Reply-To: Message-ID: On 25 Sep 2003, Eric W. Biederman wrote: > > If no objections, I am going to remove the default setting in Options.lb, > > make the mainboard ROM_SIZE settings defaults, so I can continue to set > > them in the target config files. > > That sounds like a good path forward. committed. Also, I realized after committiing that I committed an auto.c with debug pumped up high, if this is a problem let me know. ron From linuxbios at xdr.com Thu Sep 25 13:40:01 2003 From: linuxbios at xdr.com (Dave Ashley) Date: Thu Sep 25 13:40:01 2003 Subject: CVS still broken Message-ID: <200309251802.h8PI2vho011150@xdr.com> Is this like a secret club where only members can contribute or view the actual code talked about? How come no one else has any trouble getting hold of the source or latest CVS, how come everyone else can check in code and presumably check out latest with no trouble? IT IS BROKEN!!!!!!!!! http://www.linuxbios.org/developer/download/index.html This is the page that says what to do to download. The CVS repository is maintained at SourceForge.net (project name "FreeBIOS"). You can download the daily snapshot of the entire source tree or use CVS directly: % cvs -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios login Hit return when it asks you for a password. Then checkout (or update) the freebios source tree: % cvs -z3 -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios When you actually try to do the first cvs login, this happens: cvs -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios login Logging in to :pserver:anonymous at cvs.freebios.sourceforge.net:2401/cvsroot/freebios CVS password: cvs [login aborted]: end of file from server (consult above messages if any) The daily snapshot link is broken: http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz What am I missing? -Dave From rminnich at lanl.gov Thu Sep 25 13:52:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 13:52:00 2003 Subject: CVS still broken In-Reply-To: <200309251802.h8PI2vho011150@xdr.com> Message-ID: you're not missing anything. Sourceforge is sucking big time. if it is not fixed soon, I'll be moving my projects. ron From ts1 at tsn.or.jp Thu Sep 25 14:32:01 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Thu Sep 25 14:32:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: References: <3F72BC3F.2020605@abelon.com> Message-ID: <20030925185521.GA4435@tsn.or.jp> On Thu, Sep 25, 2003 at 07:40:06AM -0600, ron minnich wrote: > On Thu, 25 Sep 2003, Ian Smith wrote: > > > Blows a hole in my theory about the 128MB being detected.... > > sorry, but those registers you are mentioning have *zero* impact on size > detection. That's not what's going on here. Size detect is via SPD. > > We wrote a lot of that code here 3 years ago, and it was a hack then in an > attempt to get the 8601 to work at all. > > If you look at how it works now: > > // 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) Just to clarify, Ron, people are talking about EPIA-M here. And the code snippet above is from vt8601/raminit.inc. EPIA-M doesn't use vt8601. EPIA and EPIA-M are two totally different boards (different chipsets, etc). People with EPIA are seemingly OK with my hack to the SDRAM code of 8601. However, EPIA-M users need to tweak the hardcoded magic numbers in the DDR code of vt8623. So, please open a epia-m directory, instead of epia, in the freebios2 tree. -- Takeshi From rminnich at lanl.gov Thu Sep 25 14:35:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 14:35:01 2003 Subject: memory epia-m 127M != 512M In-Reply-To: <20030925185521.GA4435@tsn.or.jp> Message-ID: On Fri, 26 Sep 2003, SONE Takeshi wrote: > EPIA and EPIA-M are two totally different boards (different chipsets, > etc). stupid ofme. I got mixed up because so many of the registers are the same. > So, please open a epia-m directory, instead of epia, in the freebios2 > tree. I'm going to do both. I don't have any epia-m just yet. I understand the EPIA, so I'll fight one battle at a time. ron From rminnich at lanl.gov Thu Sep 25 18:40:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 18:40:01 2003 Subject: change to config tool Message-ID: The config tool has been changed to allow 'default' statements in the mainboard file. Now, you can have default ROM_SIZE 512*1024 in the mainboard file, and over-ride that with (e.g.) option ROM_SIZE=1024*1024 in the target file. I've tested this and it works fine; it's now committed. thanks ron From gwatson at lanl.gov Thu Sep 25 19:30:01 2003 From: gwatson at lanl.gov (Greg Watson) Date: Thu Sep 25 19:30:01 2003 Subject: why are we still doing this? In-Reply-To: References: Message-ID: No need, since it's done automatically now. Greg At 11:26 AM -0600 25/9/03, ron minnich wrote: >in arima/hdama/Config.lb > >## >## Clean up the motherboard id strings >## >option MAINBOARD_PART_NUMBER="HDAMA" >option MAINBOARD_VENDOR="ARIMA" > > > >OK, the config tool will create this by default: >MAINBOARD_PART_NUMBER="hdama" >MAINBOARD_VENDOR="arima" > >why do we need to put this type of thing in the mainboard config file? > >just wondering > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From YhLu at tyan.com Thu Sep 25 19:47:01 2003 From: YhLu at tyan.com (YhLu) Date: Thu Sep 25 19:47:01 2003 Subject: why are we still doing this? Message-ID: <3174569B9743D511922F00A0C943142303466F92@TYANWEB> Then where can the config tool got that info to produce >MAINBOARD_PART_NUMBER="hdama" >MAINBOARD_VENDOR="arima" YH -----????----- ???: Greg Watson [mailto:gwatson at lanl.gov] ????: 2003?9?25? 16:53 ???: ron minnich; linuxbios at clustermatic.org ??: Re: why are we still doing this? No need, since it's done automatically now. Greg At 11:26 AM -0600 25/9/03, ron minnich wrote: >in arima/hdama/Config.lb > >## >## Clean up the motherboard id strings >## >option MAINBOARD_PART_NUMBER="HDAMA" >option MAINBOARD_VENDOR="ARIMA" > > > >OK, the config tool will create this by default: >MAINBOARD_PART_NUMBER="hdama" >MAINBOARD_VENDOR="arima" > >why do we need to put this type of thing in the mainboard config file? > >just wondering > >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 hansolofalcon at worldnet.att.net Thu Sep 25 21:09:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu Sep 25 21:09:00 2003 Subject: CVS still broken In-Reply-To: Message-ID: <002201c383ce$1a8f33c0$0100a8c0@who5> Hello from Gregg C Levine Well, according to the joker in charge of Source Forge, as a whole, CVS was supposed to be moved to a larger, and bigger box, starting sometime this week. Ron, here's a suggestion, keep collecting these complaints, make a note as to the date, and time of each complaint. If it isn't fixed, by say November say, then go ahead, and do so. But I think Source Forge will completely repair it by then. Personally I think there is way too much stuff stored in CVS, that hasn't been accessed in over a year, as opposed to active projects like ours. Dave, this is the second time you've posted this message, what was the actual message that CVS returned? Was it exactly what you've posted? Yes, keep complaining here. But also complain to the people at Source Forge, this is their problem not ours. ------------------- 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: Thursday, September 25, 2003 2:15 PM > To: Dave Ashley > Cc: linuxbios at clustermatic.org > Subject: Re: CVS still broken > > you're not missing anything. Sourceforge is sucking big time. > > if it is not fixed soon, I'll be moving my projects. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Thu Sep 25 21:24:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 21:24:01 2003 Subject: why are we still doing this? In-Reply-To: <3174569B9743D511922F00A0C943142303466F92@TYANWEB> Message-ID: On Thu, 25 Sep 2003, YhLu wrote: > Then where can the config tool got that info to produce > >MAINBOARD_PART_NUMBER="hdama" > >MAINBOARD_VENDOR="arima" The config tool produces it automatically from the name of the mainboard. In other words, when you say: mainboard arima/hdama The config tools internally creates the variables as such: MAINBOARD_PART_NUMBER="hdama" MAINBOARD_VENDOR="arima" it is all done for you. ron From rminnich at lanl.gov Thu Sep 25 21:27:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 21:27:00 2003 Subject: CVS still broken In-Reply-To: <002201c383ce$1a8f33c0$0100a8c0@who5> Message-ID: Yeah, but .... it's free. It's hard to complain too hard. ron From ebiederman at lnxi.com Thu Sep 25 22:26:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Sep 25 22:26:00 2003 Subject: why are we still doing this? In-Reply-To: References: Message-ID: ron minnich writes: > in arima/hdama/Config.lb > > ## > ## Clean up the motherboard id strings > ## > option MAINBOARD_PART_NUMBER="HDAMA" > option MAINBOARD_VENDOR="ARIMA" > > > > OK, the config tool will create this by default: > MAINBOARD_PART_NUMBER="hdama" > MAINBOARD_VENDOR="arima" > > why do we need to put this type of thing in the mainboard config file? > > just wondering The goal is to be able to match the original BIOS on the system so flashing tools can change the BIOS version and not flash if things don't match. The default is there so we still get something reasonable if you don't override the settings. I don't know how the interactions work with the new configuration tool. Eric From rminnich at lanl.gov Thu Sep 25 23:53:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Thu Sep 25 23:53:00 2003 Subject: freebios2 support for via epia: help requested. Message-ID: I'm putting the pieces together but this will go lots faster with help. If somebody can look at freebios2/src/via/southbridge/vt8231/vt8231_early_smbus.c and send me fixes for the actual correct code, that will save a lot of time. If I can toss these kinds of tasks out and get help, we should be somewhere next week, which would be nice, and with true SPD support, not the mess we have now. Then we can attack the -M. ron From rminnich at lanl.gov Fri Sep 26 00:29:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 00:29:01 2003 Subject: via epia Message-ID: OK, if you cd targets ./buildtarget epia/via -bash-2.05b$ cd targets/via/epia/epia/ -bash-2.05b$ make if (cd fallback; \ make linuxbios.rom)\ then true; else exit 1; fi; make[1]: Entering directory `/home/rminnich/src/bios/freebios2/targets/via/epia/epia/fallback' ./romcc -O ./auto.E > auto.inc . . . auto.c:58.57: 0x84d5768 copy Internal compiler error: bad variable access make[1]: *** [auto.inc] Error 134 make[1]: Leaving directory `/home/rminnich/src/bios/freebios2/targets/via/epia/epia/fallback' make: *** [fallback-rom] Error 1 -bash-2.05b$ oops, you can see there's an internal compiler error. This is all skeleton code -- mostly empty functions at this point. Debugging hints for romcc are welcome. I need help now. I'm done for the day, anyone wants to take a look, please do. This is our first "normal" freebios2 port, hence will have troubles, but I think we want to do this. C >= assembly. If somebody wants to help me automate the tarball build, at sourceforge, I can use the help. Seems to me I ought to be able to do this cvs -d /freebios/cvs_tree co automagically each night. But the cvs tree is no where to be found from my sourceforge login. But I'll gratefully take any help in getting the tarball build automated. thanks ron From niki.waibel at newlogic.com Fri Sep 26 06:00:00 2003 From: niki.waibel at newlogic.com (Niki Waibel) Date: Fri Sep 26 06:00:00 2003 Subject: CVS still broken In-Reply-To: Message-ID: <200309261022.h8QAMgh4021226@enterprise2.newlogic.at> > Yeah, but .... it's free. It's hard to complain too hard. i always start my update like this: $ while ! cvs update; do sleep 5; done normally after about 5 retries you get a connection. but i've had days in which 25 retries were done... niki From stepan at suse.de Fri Sep 26 07:56:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Sep 26 07:56:00 2003 Subject: config tool + tree enumeration In-Reply-To: References: Message-ID: <20030926121853.GA8249@suse.de> Hi, I have several non coherent ht devices in a chain, i.e. : CPU0 -- CPU1 or CPU2 -- CPU3 | | | 8131 CPU0 -- CPU2 | | | 8111 8111 8131 | 8131 The links to the non coherent devices are LDT1 or LDT2, not LDT0. Do I have to specify the "southbridges with Bus ID 1/2 then, since it's not on the first Link, or does it have to be 0, since it's the first south bridge? northbridge amd/amdk8 "mc0" pci 0:18.0 [..] southbridge amd/amd8131 "amd8131" pci 1:0.0 ^^^^^ [..] end southbridge amd/amd8111 "amd8111" pci 1:0.0 ^^^^^ [..] end end Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Fri Sep 26 11:52:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 11:52:00 2003 Subject: via/epia now builds Message-ID: I knew this would be a bit of work, but it is worth it as it is flushing out "K8 and SMP" assumptions in the tree. I really would appreciate it if somebody could look at the early smbus code. ron From YhLu at tyan.com Fri Sep 26 12:00:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 26 12:00:01 2003 Subject: config tool + tree enumeration Message-ID: <3174569B9743D511922F00A0C943142303466FC7@TYANWEB> Stefan, Change that to 1 seems no use. For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is linked to CPU0 link0. I have to manual to change src/device/hypertransport.c 's hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0". I think it works for your case to. Regards YH -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?26? 5:19 ???: linuxbios at clustermatic.org ??: config tool + tree enumeration Hi, I have several non coherent ht devices in a chain, i.e. : CPU0 -- CPU1 or CPU2 -- CPU3 | | | 8131 CPU0 -- CPU2 | | | 8111 8111 8131 | 8131 The links to the non coherent devices are LDT1 or LDT2, not LDT0. Do I have to specify the "southbridges with Bus ID 1/2 then, since it's not on the first Link, or does it have to be 0, since it's the first south bridge? northbridge amd/amdk8 "mc0" pci 0:18.0 [..] southbridge amd/amd8131 "amd8131" pci 1:0.0 ^^^^^ [..] end southbridge amd/amd8111 "amd8111" pci 1:0.0 ^^^^^ [..] end end Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Fri Sep 26 12:54:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 12:54:00 2003 Subject: via/epia Message-ID: OK, where we are is this: there is a freebios2 version for the via/epia. It builds. I have set it up so memory config *should* *be* what we have now, i.e. static. But this will get us to status quo, and then we can look at SPD etc. ron From rminnich at lanl.gov Fri Sep 26 13:00:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 13:00:01 2003 Subject: via/epia In-Reply-To: Message-ID: I could use a fragment of code that makes the uart sane. ron From rminnich at lanl.gov Fri Sep 26 13:20:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 13:20:01 2003 Subject: via/epia In-Reply-To: Message-ID: On Fri, 26 Sep 2003, ron minnich wrote: > I could use a fragment of code that makes the uart sane. never mind, done. ron From ebiederman at lnxi.com Fri Sep 26 16:18:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Sep 26 16:18:00 2003 Subject: epia800 In-Reply-To: <3F731569.10201@nexpath.com> References: <20030923005626.P64206-100000@www.missl.cs.umd.edu> <3F706BA9.8030400@nexpath.com> <3F731569.10201@nexpath.com> Message-ID: Steve Gehlbach writes: > Eric W. Biederman wrote: > > >>I was going to force it to use ide_read_sector_chs but did not have time. > >> > >>I switched to using my CF drive and it worked fine, so I don't think it was > >>cockpit trouble. > > Right. My only other guess is that some of the lba48 support my be > interacting > > > in a strange way and causing problems. We always write the lba48 high > > registers but we don't set them in the lba case. It should not cause a > problem. > > > But drives are diverse enough we might find some strange bugs. > > At least we have not yet found a drive that we have spin up problems with yet. > > > I did some more testing. Forcing CHS mode did not help. I looked at the older > LB code, and started to cut and paste some of its init code into the new code > just as an experiment. So far no help. > > I noticed the busy/wait loop in the original LB code looks at the error > register. I also notice in the new code the pio_data_in routine does not check > the error bit, matter of fact, the error bit is never checked anywhere AFAICT. > Interestingly, if you check the error bit in the status register (bit 0), it is > set after the pio_set_registers() command for my 1.2G WD (in pio_data_in for > READ SECTOR(S) ), but not for another drive that works (7.5G WD). I looked at > the ATA-2 and ATA-5 specs and the error stuff seems to have changed a little. I > > have not had a chance to put in code to see just where the error bit gets set, > but it seems that once it is set you cannot go on without clearing it or > something. Possibly. I believe I was not using the error bit because things were failing in other ways so I did not need the error bit, and I don't think CF drives support it. Eric From rminnich at lanl.gov Fri Sep 26 16:27:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 16:27:01 2003 Subject: V2 on EPIA Message-ID: comes up with POST 10. That's it. But hey, I didn't expect more yet ... this is a start :-) ron From rminnich at lanl.gov Fri Sep 26 16:39:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 16:39:00 2003 Subject: epia v2 Message-ID: up to postcode 12 rno From rminnich at lanl.gov Fri Sep 26 17:44:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 17:44:00 2003 Subject: V2 and via epia Message-ID: getting serial output. Dies after copy to ram. Gee, what a shock :-) ron From rminnich at lanl.gov Fri Sep 26 17:47:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 17:47:00 2003 Subject: V2 VIA EPIA output Message-ID: here is what I get: 0 LinuxBIOS-1.1.4.0Fallback Fri Sep 26 16:04:07 MDT 2003 starting... SMBus controller enabled vt8601 init starting 00000800 is the north vt8601 done LinuxBIOS-1.1.4.0Fallback Fri Sep 26 16:04:07 MDT 2003 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. That first '0' is just the early setup code for the southbridge serial. Then you can see the smbus controller, then the various 8601 gyrations (which don't actually do any good, it seems :0) ron From stepan at suse.de Fri Sep 26 17:50:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Fri Sep 26 17:50:01 2003 Subject: config tool + tree enumeration In-Reply-To: <3174569B9743D511922F00A0C943142303466FC7@TYANWEB> References: <3174569B9743D511922F00A0C943142303466FC7@TYANWEB> Message-ID: <20030926221138.GA12533@suse.de> * YhLu [030926 18:24]: > Stefan, > > Change that to 1 seems no use. > > For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is > linked to CPU0 link0. > > I have to manual to change src/device/hypertransport.c 's > hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0". > > I think it works for your case to. This did help indeed. Is there any good reason not to reverse the probing per default? Ron, Eric? If there is, I suggest we make this a config variable Stefan -- Architecture Team SuSE Linux AG From YhLu at tyan.com Fri Sep 26 17:55:01 2003 From: YhLu at tyan.com (YhLu) Date: Fri Sep 26 17:55:01 2003 Subject: config tool + tree enumeration Message-ID: <3174569B9743D511922F00A0C943142303467033@TYANWEB> It should work with Arima. And It works with S2880/S2882. If some MB connect link0 with 8131/8111, and connect link2 to 8151. So it will get troble again. So I add one MACRO define. We can add the option in config.lb of MB. Option HT_LINK_REVERSE_SCAN=1 Regards YH -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?26? 15:12 ???: YhLu ??: linuxbios at clustermatic.org ??: Re: config tool + tree enumeration * YhLu [030926 18:24]: > Stefan, > > Change that to 1 seems no use. > > For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is > linked to CPU0 link0. > > I have to manual to change src/device/hypertransport.c 's > hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0". > > I think it works for your case to. This did help indeed. Is there any good reason not to reverse the probing per default? Ron, Eric? If there is, I suggest we make this a config variable Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Fri Sep 26 18:24:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 18:24:00 2003 Subject: config tool + tree enumeration In-Reply-To: <20030926221138.GA12533@suse.de> Message-ID: On Sat, 27 Sep 2003, Stefan Reinauer wrote: > This did help indeed. Is there any good reason not to reverse the > probing per default? Ron, Eric? I'm going to defer to Eric on this, as I am not sure. ron From rminnich at lanl.gov Fri Sep 26 18:30:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 18:30:00 2003 Subject: V2 via/epia: stuck on north bridge. Message-ID: OK, here is where I am. Here is the start of the key function in src/northbridge/via/vt8601/raminit.c static void sdram_set_registers(const struct mem_controller *ctrl) { static const uint16_t raminit_ma_reg_table[] = { /* Values for MA type register to try */ 0x0000, 0x8088, 0xe0ee, 0xffff // end mark }; device_t north = 0; uint8_t c, r; print_err("vt8601 init starting\n"); north = pci_locate_device(PCI_ID(0x1106, 0x8601), 0); print_err_hex32(north); print_err(" is the north\n"); print_err_hex16(pci_read_config16(north, 0)); print_err(" "); print_err_hex16(pci_read_config16(north, 2)); print_err("\r\n"); // memory clk enable. We are not using ECC pci_write_config8(north,0x78, 0x01); print_err_hex8(pci_read_config8(north, 0x78)); . . . Here's what is going wrong. LinuxBIOS-1.1.4.0Fallback Fri Sep 26 16:44:17 MDT 2003 starting... SMBus controller enabled vt8601 init starting 00000800 is the north 1106 8601 00 That 00 is the result of reading register 78. Note that I tried to set it to 1. Somehow, none of my config writes to any register are working. Not one. The reads read back fine. That 1106/8601 you see is the result of a config read from the north bridge. But the writes all fail. Any idea why this would be? Seems like something is locked somehow. I've looked at the assembly code and it actually looks ok. This is pretty odd. The sequence of writes is taken directly from the V1 code. here's a dump of the north bridge after ALL the writes have been tried. 00:06 11 01 86 07 00 30 02 00 00 04 06 00 00 01 00 10:00 00 00 00 00 00 00 00 00 00 00 00 f0 00 00 00 20:f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30:00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 40:00 00 00 22 00 00 00 00 00 00 00 00 00 00 00 00 50:00 00 00 00 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:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: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 One thing I definitely don't understand: why is the north 00000800? I would have expected it to be 0. But it works: reads from 'north' return sensible values. Still ... thanks ron From rminnich at lanl.gov Fri Sep 26 18:33:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 18:33:00 2003 Subject: bug in pci_locate_device? Message-ID: interesting. This: north = pci_locate_device(PCI_ID(0x1106, 0x8601), 0); returned: 00000800 Which is Wrong. And the 8601 reads ok, but writes fail in config space. Once I just set it to 0, things got a lot better! But it still fails :-) ron From aod at ponto-i.net Fri Sep 26 18:39:01 2003 From: aod at ponto-i.net (Andre Dias) Date: Fri Sep 26 18:39:01 2003 Subject: sis740 Message-ID: <001101c38482$225952c0$0705a8c0@laptop> Has anyone tried using linuxbios with SiS740/SiS962L chipset? (eg, pcchips new m810dlu series) ======================== Andre Dias Gerente Ponto-i Equipamentos e Servi?os www.ponto-i.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From aod at ponto-i.net Fri Sep 26 18:41:12 2003 From: aod at ponto-i.net (Andre Dias) Date: Fri Sep 26 18:41:12 2003 Subject: keyboard idle - sis730 Message-ID: <001601c38482$35318ac0$0705a8c0@laptop> Dear fellows, I use linuxbios with m810 but sometimes, when I am not typing on the keyboard (when it is idle), the keyboard no longer responds (otherwise it works ok). Did you have such problem? Any solution, say disable something in kernel? Thanks in advance ======================== Andre Dias Gerente Ponto-i Equipamentos e Servi?os www.ponto-i.net From rminnich at lanl.gov Fri Sep 26 19:03:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Fri Sep 26 19:03:00 2003 Subject: V2 via epia Message-ID: Closer. I'm getting through all of the 8601 setup. But the values are bogus: Good VIA! 00: 06 11 01 06 06 00 90 a2 05 00 00 06 00 40 00 00 10: 08 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 a0 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: ac 08 80 00 00 00 20 20 80 00 10 20 20 20 20 20 60: 3f ff ff f0 e4 e4 e4 00 42 ac 65 0d 08 7f 00 00 70: c0 88 ec 0c 0e 81 52 00 01 f0 00 00 00 00 00 00 80: 00 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 03 02 00 07 00 00 00 00 08 02 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 01 01 00 42 00 b0 00 00 00 00 Bad VIA! Bad! Bad doggy! 00:06 11 01 06 06 00 90 22 05 00 00 06 00 00 00 00 10:08 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 a0 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:ac 08 80 00 00 00 ff ff 00 00 ff ff ff ff ff ff 60:3f 00 00 00 e4 e4 e4 00 42 ac 65 0d 08 7f 00 00 70:00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00 80:00 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 00 20 00 03 02 00 07 00 00 00 00 08 02 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 01 01 00 00 00 00 00 00 00 00 ah well. I can ship my tree to those of you who want it again. We're working on a solution to the CVS problem, and unlike the sourceforge solutions, we think this one will actually work. So hang in there, we hope next week. ron From rminnich at lanl.gov Sat Sep 27 00:08:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sat Sep 27 00:08:00 2003 Subject: V2 via/epia Message-ID: I think I've got the last kinks out on 8601; we'll find out monday. ron From kevin at koconnor.net Sat Sep 27 01:10:00 2003 From: kevin at koconnor.net (Kevin O'Connor) Date: Sat Sep 27 01:10:00 2003 Subject: Working with tsop flash Message-ID: <20030927053257.GA7910@arizona.localdomain> Hi, I have a motherboard that I would like to get linuxbios working on. Unfortunately, it has a TSOP flash part that is soldered directly onto it. I am concerned that if I write to the flash I may turn the unit into a "brick". Has anyone had any experience with removing a surface mounted flash TSOP part, and replacing it with a ZIF socket? If I understand it correctly, I should be able to heat up the leads of the current flash (melting the existing solder), extract the flash part, then solder on a zif socket (http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/), and then finally use an eprom programmer on the existing tsop flash chip if it ever gets flashed incorrectly. Is this correct - anyone here done this before? Is this procedure very tricky (can one new to soldering expect to succeed at it)? Any advice would be appreciated, -Kevin -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ From agnew at cs.umd.edu Sat Sep 27 02:13:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Sat Sep 27 02:13:00 2003 Subject: Working with tsop flash In-Reply-To: <20030927053257.GA7910@arizona.localdomain> Message-ID: <20030927023359.Q95135-100000@www.missl.cs.umd.edu> Hi Kevin. I am skeptical that a beginner solderer could pull that off. It's very very tiny work. However, a couple of us have contacted the following gentleman, and his company gets the job done well and cheaply (expect to pay a few hundred, which is preferred to a few dead motherboards). Henry Ho of Century Technology, Inc. hho * century-technology * com 650 583 8908 There's no problem using an eprom programmer if you write a bad flash, but its easier to just have a spare tsop flash chip (intel firmware hubs and standard flash chips aren't interchangable however). - Adam Agnew On Sat, 27 Sep 2003, Kevin O'Connor wrote: > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered directly onto it. > I am concerned that if I write to the flash I may turn the unit into a > "brick". > > Has anyone had any experience with removing a surface mounted flash TSOP > part, and replacing it with a ZIF socket? If I understand it correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/), > and then finally use an eprom programmer on the existing tsop flash chip if > it ever gets flashed incorrectly. Is this correct - anyone here done this > before? Is this procedure very tricky (can one new to soldering expect to > succeed at it)? > > Any advice would be appreciated, > -Kevin > > -- > ------------------------------------------------------------------------ > | Kevin O'Connor "BTW, IMHO we need a FAQ for | > | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | > ------------------------------------------------------------------------ > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From sc at flagen.com Sat Sep 27 03:38:00 2003 From: sc at flagen.com (David Hendricks) Date: Sat Sep 27 03:38:00 2003 Subject: sis740 In-Reply-To: <001101c38482$225952c0$0705a8c0@laptop> References: <001101c38482$225952c0$0705a8c0@laptop> Message-ID: <20030926211449.69967b1d.sc@flagen.com> IIRC, the Elitegroup K7SEM is supported. On Fri, 26 Sep 2003 20:01:35 -0300 "Andre Dias" wrote: > Has anyone tried using linuxbios with SiS740/SiS962L chipset? (eg, > pcchips new m810dlu series) > > > ======================== > Andre Dias > Gerente > Ponto-i Equipamentos e Servi?os > www.ponto-i.net > > From spidermantm at freenet.de Sat Sep 27 10:20:01 2003 From: spidermantm at freenet.de (spidermantm at freenet.de) Date: Sat Sep 27 10:20:01 2003 Subject: MSI ??? Message-ID: Hello ? am new to this mailinglist. does anybody know about linuxbios and MSI mainboards ? thanks for hint. regards. spidey. -- 60% Onlinekosten sparen! Jetzt Premium Mitglied bei freenet.de werden und mit dem Tarifnavigator guenstiger surfen. http://www.freenet.de/tipp/premium/tarif/index.html From steve at nexpath.com Sat Sep 27 13:01:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Sat Sep 27 13:01:00 2003 Subject: Working with tsop flash In-Reply-To: <20030927053257.GA7910@arizona.localdomain> References: <20030927053257.GA7910@arizona.localdomain> Message-ID: <3F75C81D.9000709@nexpath.com> Kevin O'Connor wrote: > > Has anyone had any experience with removing a surface mounted flash TSOP > part, and replacing it with a ZIF socket? > I am an experienced solderer but with a bad case of middle age eyes. I do have good equipment, a zoom microscope, hot air solder/desolder tool, Metcal soldering iron. Here is a link about replacing the TSOP with a ZIF, by Andrew "bunny" Huang of Xbox fame: http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html. I tried this, and it worked (for a while), but here are the problems. The TSOP chip itself is so delicate, all you have to do is drop it on the carpet, and it will bend the pins. This requires a few minutes under the microscope to straighten them out. Getting it to make contact in the programmer requires patience, one little pin out of place, and it won't program. Removing the TSOP is the easy part. The ZIF socket is very difficult to solder in, because you don't have good access to the pins, they are under it. And the socket material melts at solder temperature (or just above) so it is easy to melt the socket with the solder tool as you solder it in. Further, unless you use glue, the ONLY thing holding the socket on the board are the surface mount traces, which are tiny. After a few insertions, the mechanical forces tend to lift traces. I eventually pulled up a couple of traces from the forces of removing and inserting the chip in the socket. The only way I saved the board was by unsoldering the socket, soldering in the chip, and running a couple of bridge wires to patch the broken traces. Others may have had better luck, but this was my experience. -Steve From pyro at linuxlabs.com Sat Sep 27 13:55:01 2003 From: pyro at linuxlabs.com (steven james) Date: Sat Sep 27 13:55:01 2003 Subject: Working with tsop flash In-Reply-To: <20030927053257.GA7910@arizona.localdomain> Message-ID: Greetings, That's one of those things that sounds easy enough in theory, but in practice isn't. I would strongly recommend hiring someone to take care of that for you. G'day, sjames On Sat, 27 Sep 2003, Kevin O'Connor wrote: > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered directly onto it. > I am concerned that if I write to the flash I may turn the unit into a > "brick". > > Has anyone had any experience with removing a surface mounted flash TSOP > part, and replacing it with a ZIF socket? If I understand it correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/), > and then finally use an eprom programmer on the existing tsop flash chip if > it ever gets flashed incorrectly. Is this correct - anyone here done this > before? Is this procedure very tricky (can one new to soldering expect to > succeed at it)? > > Any advice would be appreciated, > -Kevin > > -- -------------------------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 adam at cfar.umd.edu Sat Sep 27 14:04:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Sat Sep 27 14:04:01 2003 Subject: Working with tsop flash In-Reply-To: <3F75C81D.9000709@nexpath.com> Message-ID: <20030927143007.O99663-100000@www.missl.cs.umd.edu> > I tried this, and it worked (for a while), but here are the problems. > The TSOP chip itself is so delicate, all you have to do is drop it on > the carpet, and it will bend the pins. I will second that. If possible after you unsolder TSOP, try to install adapter for PLCC socket instead of TSOP socket. That will make your life much easier in long run. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From bgr at gw.linespeed.net Sat Sep 27 17:01:01 2003 From: bgr at gw.linespeed.net (Brian G. Rhodes) Date: Sat Sep 27 17:01:01 2003 Subject: Working with tsop flash In-Reply-To: <20030927053257.GA7910@arizona.localdomain> References: <20030927053257.GA7910@arizona.localdomain> Message-ID: There are quite a few places who will do it for you. BTW inc. comes to mind. Probably cost you 20 bucks. But if you have some soldering pliers, and aren't worried about losing a board if you really muck it up, it's worth a try. Brian G Rhodes bgr at linespeed.net brhodes at visualcircuits.com +1 612-741-1191 On Sat, 27 Sep 2003, Kevin O'Connor wrote: > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered directly onto it. > I am concerned that if I write to the flash I may turn the unit into a > "brick". > > Has anyone had any experience with removing a surface mounted flash TSOP > part, and replacing it with a ZIF socket? If I understand it correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/), > and then finally use an eprom programmer on the existing tsop flash chip if > it ever gets flashed incorrectly. Is this correct - anyone here done this > before? Is this procedure very tricky (can one new to soldering expect to > succeed at it)? > > Any advice would be appreciated, > -Kevin > > -- > ------------------------------------------------------------------------ > | Kevin O'Connor "BTW, IMHO we need a FAQ for | > | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | > ------------------------------------------------------------------------ > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From aod at ponto-i.net Sat Sep 27 19:48:01 2003 From: aod at ponto-i.net (Andre Dias) Date: Sat Sep 27 19:48:01 2003 Subject: sis740 Message-ID: <003601c38554$ff1f8a30$6616dcc8@laptop> K7SEM is sis730, in fact is a clone of M810LMR Elitegroup, Asrock and Pcchips are the same company. Btw, I use K7SEM with linuxbios and its OK (except by the keyboard idle sometimes) ======================== Andre Dias Gerente Ponto-i Equipamentos e Servi?os www.ponto-i.net -----Mensagem original----- De: linuxbios-admin at clustermatic.org [mailto:linuxbios-admin at clustermatic.org] Em nome de David Hendricks Enviada em: s?bado, 27 de setembro de 2003 01:15 Para: linuxbios at clustermatic.org Assunto: Re: sis740 IIRC, the Elitegroup K7SEM is supported. On Fri, 26 Sep 2003 20:01:35 -0300 "Andre Dias" wrote: > Has anyone tried using linuxbios with SiS740/SiS962L chipset? (eg, > pcchips new m810dlu series) > > > ======================== > Andre Dias > Gerente > Ponto-i Equipamentos e Servi?os > www.ponto-i.net > > _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From linuxbios at techfreakz.net Sun Sep 28 04:59:00 2003 From: linuxbios at techfreakz.net (Alex Scarbro) Date: Sun Sep 28 04:59:00 2003 Subject: sis740 In-Reply-To: <003601c38554$ff1f8a30$6616dcc8@laptop> Message-ID: <2003928102216.593950@techfreakz> An HTML attachment was scrubbed... URL: From root at hamburg.de Sun Sep 28 06:02:01 2003 From: root at hamburg.de (Felix) Date: Sun Sep 28 06:02:01 2003 Subject: Working with tsop flash In-Reply-To: <20030927053257.GA7910@arizona.localdomain>; from kevin@koconnor.net on Sat, Sep 27, 2003 at 07:32:57 +0200 References: <20030927053257.GA7910@arizona.localdomain> Message-ID: <20030928102113.GA1147@synapse.pentanet> On 09/27/2003 07:32:57 AM, Kevin O'Connor wrote: > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered directly > onto > it. > I am concerned that if I write to the flash I may turn the unit into > a > "brick". > > Has anyone had any experience with removing a surface mounted flash > TSOP > part, and replacing it with a ZIF socket? If I understand it > correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/), > and then finally use an eprom programmer on the existing tsop flash > chip if > it ever gets flashed incorrectly. Is this correct - anyone here done > this > before? Is this procedure very tricky (can one new to soldering > expect to > succeed at it)? > > Any advice would be appreciated, > -Kevin > > -- > > ------------------------------------------------------------------------ > | Kevin O'Connor "BTW, IMHO we need a FAQ for > | > | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" > | > > ------------------------------------------------------------------------ > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > what about "stacking" another flash part right over it, unsolder the chip-select pins, connect both of them to a switch ---> home made bios saviour. take a look at the data sheets, it might work. Felix From rminnich at lanl.gov Sun Sep 28 11:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Sep 28 11:07:00 2003 Subject: sis740 In-Reply-To: <2003928102216.593950@techfreakz> Message-ID: On Sun, 28 Sep 2003, Alex Scarbro wrote: > ??? If the K7SEM is working, then could someone please update the K7SEM > howto with the correct information, as by following the existing howto, > my K7SEM freezes at "Setting MTTR...UC".? It's not working. My next step after EPIA is the K7SEM, since it doesn't seem to be getting fixed. ron From aip at cwlinux.com Sun Sep 28 11:25:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sun Sep 28 11:25:00 2003 Subject: sis740 In-Reply-To: <2003928102216.593950@techfreakz>; from Alex Scarbro on Sun, Sep 28, 2003 at 10:22:16AM +0100 References: <003601c38554$ff1f8a30$6616dcc8@laptop> <2003928102216.593950@techfreakz> Message-ID: <20030928234901.A5888@mail.cwlinux.com> Hi, Have you tried to disable ecc checking? You probably can find the patch in the list archive. -Andrew On Sun, Sep 28, 2003 at 10:22:16AM +0100, Alex Scarbro wrote: -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From aip at cwlinux.com Sun Sep 28 12:25:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sun Sep 28 12:25:01 2003 Subject: Outstanding problems on K7SEM, EPIA and EPIA-M Message-ID: <20030929004849.A6587@mail.cwlinux.com> Hi, Would someone help me to fill these information in? Board Problem Solution K7SEM ECC code problem Add an option to disable ecc support EPIA ?? EPIA-M DDR setup Add SPD detection code -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en. From rminnich at lanl.gov Sun Sep 28 12:53:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Sep 28 12:53:00 2003 Subject: Outstanding problems on K7SEM, EPIA and EPIA-M In-Reply-To: <20030929004849.A6587@mail.cwlinux.com> Message-ID: On Mon, 29 Sep 2003, Andrew Ip wrote: > Board Problem Solution > K7SEM ECC code problem Add an option to disable ecc support That EPIA code has artifacts from our 3-years-ago hack. Let's just do this right and move to V2. It's amost done for EPIA. > EPIA DRAM code is wrong Move to V2; add SPD code > EPIA-m " Move to V2; Add SPD detection code ron From ian at abelon.com Sun Sep 28 12:56:01 2003 From: ian at abelon.com (Ian Smith) Date: Sun Sep 28 12:56:01 2003 Subject: Outstanding problems on K7SEM, EPIA and EPIA-M In-Reply-To: <20030929004849.A6587@mail.cwlinux.com> References: <20030929004849.A6587@mail.cwlinux.com> Message-ID: <6.0.0.22.2.20030928181636.02a39670@mail.abelon.com> At 17:48 28/09/2003, Andrew Ip wrote: >Hi, > >Would someone help me to fill these information in? > >Board Problem Solution >K7SEM ECC code problem Add an option to disable ecc support >EPIA ?? >EPIA-M DDR setup Add SPD detection code Unless I've missed a HOWTO somewhere, the EPIA-M build needs some work on the video initialisation to work with the Via VGA BIOS. Looks like there has been a fair bit done on this for EPIA but not EPIA-M. >-Andrew Cheers Ian From ebiederman at lnxi.com Sun Sep 28 18:05:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Sep 28 18:05:01 2003 Subject: config tool + tree enumeration In-Reply-To: References: Message-ID: ron minnich writes: > On Sat, 27 Sep 2003, Stefan Reinauer wrote: > > > This did help indeed. Is there any good reason not to reverse the > > probing per default? Ron, Eric? > > I'm going to defer to Eric on this, as I am not sure. I'm running slow in replying. But I don't see why scanning busses in any particular order should matter. And until I have a reason I don't see the point, in making a change. Mostly I suspect this is a matter of keeping the irq tables in sync, or something similar where hard codes don't match the dynamic assignments. And if that is the case we need to dig and do a good fix instead of papering over the problem. Eric From rminnich at lanl.gov Sun Sep 28 19:32:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Sun Sep 28 19:32:01 2003 Subject: config tool + tree enumeration In-Reply-To: Message-ID: On 28 Sep 2003, Eric W. Biederman wrote: > Mostly I suspect this is a matter of keeping the irq tables > in sync, or something similar where hard codes don't match the dynamic > assignments. And if that is the case we need to dig and do a good fix > instead of papering over the problem. the PIRQ thing is on my list, and we have all here agreed on most of the solution, given me another week. Yes, papering over is BAD. ron From stepan at suse.de Mon Sep 29 04:54:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 04:54:01 2003 Subject: config tool + tree enumeration In-Reply-To: References: Message-ID: <20030929091756.GA20738@suse.de> * Eric W. Biederman [030929 00:38]: > And until I have a reason I don't see the point, in making > a change. Hm. You are right. With some more tests I found out that this solution only fixes the problem occasionally. It seems that the chance that it works is higher with the number of tries. Really weird. > Mostly I suspect this is a matter of keeping the irq tables > in sync, or something similar where hard codes don't match the dynamic > assignments. And if that is the case we need to dig and do a good fix > instead of papering over the problem. If LinuxBIOS hangs during CPU/Northbridge enumeration, can this really be a matter of irq tables? I thought that they are touched quite a while later in the setup process. I suspect it might be connected to the highest bus number set in the default resource map, but I did not try more in this direction yet. Additionally I have Linux moaning that the irq table contains entries for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS find really well, only Linux refuses to see it. Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Mon Sep 29 05:46:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 29 05:46:00 2003 Subject: config tool + tree enumeration In-Reply-To: <20030929091756.GA20738@suse.de> References: <20030929091756.GA20738@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030929 00:38]: > > And until I have a reason I don't see the point, in making > > a change. > > Hm. You are right. With some more tests I found out that this > solution only fixes the problem occasionally. It seems that > the chance that it works is higher with the number of tries. > Really weird. > > > Mostly I suspect this is a matter of keeping the irq tables > > in sync, or something similar where hard codes don't match the dynamic > > assignments. And if that is the case we need to dig and do a good fix > > instead of papering over the problem. > > If LinuxBIOS hangs during CPU/Northbridge enumeration, can this > really be a matter of irq tables? No. My problem is that I don't have a good data point on what the problem is. And the fact that the problem is not even consistent is very peculiar. > I thought that they are touched quite a while later in the setup process. Yes, much later. Hard codes in the irq tables are one of the things that could cause problems if the busses were enumerated in a different order. But not until the kernel has been loaded. > I suspect it might be connected to the highest bus number set in > the default resource map, but I did not try more in this direction > yet. But it is not consistent? And what you are hangs. Very, very weird. And this is not with SST chips? > Additionally I have Linux moaning that the irq table contains entries > for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS > find really well, only Linux refuses to see it. And that is also very strange. I need to start synchronizing my tree with the public one, now that it seems to be working. And I have some romcc cleanups to do. I finally have the core infrastructure in place for making inline optional, which should help a lot on the size issues. Eric From stepan at suse.de Mon Sep 29 06:47:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 06:47:01 2003 Subject: config tool + tree enumeration In-Reply-To: References: <20030929091756.GA20738@suse.de> Message-ID: <20030929111113.GA21129@suse.de> * Eric W. Biederman [030929 12:19]: > > I suspect it might be connected to the highest bus number set in > > the default resource map, but I did not try more in this direction > > yet. > > But it is not consistent? iirc default_resource_map sets the highest bus number to 0xff, so it should be above what we ever need. Finding the real highest bus number is not possible until after the enumeration anyways, is it? > And what you are hangs. Very, very weird. And this is not with > SST chips? I've been using an SST 49LF040 (the one that is per default in all Quartets and Khepris), but I guess it's unrelatet this time. I had no boot trouble so far with the 040 type, only trouble while flashing. The boot trouble was solely on the 080 type. But this might be coincidence. > And that is also very strange. I need to start synchronizing my > tree with the public one, now that it seems to be working. And I have > some romcc cleanups to do. I finally have the core infrastructure in > place for making inline optional, which should help a lot on the size > issues. This would be great, especially helping to test the SMP configurations with the Winbond 256k flash parts I have to see if that changes the problem. Stefan -- Architecture Team SuSE Linux AG From nick.jarmany at densitron.co.uk Mon Sep 29 08:30:01 2003 From: nick.jarmany at densitron.co.uk (Nick Jarmany) Date: Mon Sep 29 08:30:01 2003 Subject: Working with tsop flash Message-ID: Kevin, In my experience of this type of SMD work, the most critcical issue is preserving the pads on the motherboard. Usually attempts to desolder parts whilst preserving them for re-use generally result in damage/weakening of the PCB. To prevent this the best way is to sacrifice the soldered on part, minimising heat damage to the PCB. Use a sharp scalpel and with a controlled hand and steady force, run the pount of the blade over the chip pins along the line where they meet the chip body. Repeating this multiple times will eventually result in the chip legs becoming severed without any undue stress having been applied. Repeat this process with the other side and lift the chip body clear. Now you are left with two rows of renundant pins! Use a hot iron with a broad tip and a good deal of solder. Put the iron on the pins and quicky apply solder. While feeding in solder, move iron over balance of the pins. With the whole lot molten you should be able to wipe off all the junk easily and quickly. The trick is speed - do not hesitate or loiter on anything for more than a second. Use plenty of solder and drag the "heap" quickly off the end. The surface tension of the ball of molten solder will bring everything with it, including any solder bridges between pads. If after this you still have some shorts, use more solder and remove by dragging a ball of molten solder steadily over the pads, adding fresh solder to the ball as you go. The best way to remove solder is with more solder! The mistake many people make with close-pitch SMD components is to use micro sized iron tips and spend ages on individual pins under microscopes. The best tactic is actually the reverse - large tip (good heat transfer), lots of solder and deal with all the pins in one operation. Our production staff can hand solder a 100-pin PQFP in under 5 seconds this way, with no shorts! Using this technique should give you the best chance of undamaged pads onto which you can solder your socket/emulator. Good luck! Nick > -----Original Message----- > From: linuxbios-admin at clustermatic.org > [mailto:linuxbios-admin at clustermatic.org]On Behalf Of Kevin O'Connor > Sent: 27 September 2003 06:33 > To: linuxbios at clustermatic.org > Subject: Working with tsop flash > > > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered > directly onto it. > I am concerned that if I write to the flash I may turn the unit into a > "brick". > > Has anyone had any experience with removing a surface mounted > flash TSOP > part, and replacing it with a ZIF socket? If I understand it > correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sock ets/tsop/), and then finally use an eprom programmer on the existing tsop flash chip if it ever gets flashed incorrectly. Is this correct - anyone here done this before? Is this procedure very tricky (can one new to soldering expect to succeed at it)? Any advice would be appreciated, -Kevin -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin at koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon Sep 29 09:27:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 09:27:00 2003 Subject: config tool + tree enumeration In-Reply-To: <20030929091756.GA20738@suse.de> Message-ID: On Mon, 29 Sep 2003, Stefan Reinauer wrote: > Additionally I have Linux moaning that the irq table contains entries > for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS > find really well, only Linux refuses to see it. well at least now I know it is Linux, and I'm not going nuts. Really odd problem. ron From stepan at suse.de Mon Sep 29 09:36:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 09:36:01 2003 Subject: config tool + tree enumeration In-Reply-To: References: <20030929091756.GA20738@suse.de> Message-ID: <20030929135929.GA22362@suse.de> * ron minnich [030929 15:50]: > On Mon, 29 Sep 2003, Stefan Reinauer wrote: > > > Additionally I have Linux moaning that the irq table contains entries > > for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS > > find really well, only Linux refuses to see it. > > well at least now I know it is Linux, and I'm not going nuts. > > Really odd problem. Andi Kleen stated that this is a result from wrong pirq- and acpi tables. Additionally, does Linux parse the mptable to find out about it's busses? If so, can anybody give a hint how to write a working mptable.c? Best regards, Stefan Reinauer -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 29 09:41:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 09:41:01 2003 Subject: config tool + tree enumeration In-Reply-To: <20030929135929.GA22362@suse.de> Message-ID: On Mon, 29 Sep 2003, Stefan Reinauer wrote: > Andi Kleen stated that this is a result from wrong pirq- and acpi > tables. OK, what version linux are they using for this statement. PIRQ doesn't come into the picture for a long time. ACPI I have not seen in the PCI parsing on my kernels. If they have broken PCI direct bus scanning then they have done a bad thing. Are you sure Andi knowns how all this stuff works? ron From rminnich at lanl.gov Mon Sep 29 10:22:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 10:22:00 2003 Subject: V2 and via/epia Message-ID: looks like RAM is up! Now I get to this: Enumerating: VIA vt8601 Northbridge Enumerating: VIA vt8231 Enumerating buses...PCI: pci_scan_bus for bus 1 PCI: 01:18.0 [ffff/ffff] enabled PCI: 01:18.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.1 No device operations PCI: 01:18.2 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.2 No device operations PCI: 01:18.3 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.3 No device operations PCI: pci_scan_bus for bus 2 PCI: 02:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:00.0 No device operations PCI: 02:00.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:00.1 No device operations PCI: 02:01.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:01.0 No device operations PCI: 02:01.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:01.1 No device operations Time for SPEW :-) ron From rminnich at lanl.gov Mon Sep 29 11:20:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 11:20:01 2003 Subject: v2 and epia Message-ID: OK, I am now almost at the limit of my understanding :-) I need to set up the device_operations for the 8601. Here is the mainboard config that is relevant. northbridge via/vt8601 "vt8601" pci 0:0.0 pci 0:1.0 southbridge via/vt8231 "vt8231" pci 0:11.0 pci 0:11.1 pci 0:11.2 pci 0:11.3 pci 0:11.4 pci 0:11.5 pci 0:11.6 pci 0:12.0 register "enable_usb" = "0" register "enable_native_ide" = "1" register "enable_com_ports" = "1" register "enable_keyboard" = "0" register "enable_nvram" = "1" end end Now there is nothing special about the 8601 enumeration wise. So I was hoping to do this: static void enumerate(struct chip *chip) { extern struct device_operations default_pci_ops_bus; chip_enumerate(chip); chip->dev->ops = &default_pci_ops_bus; } struct chip_control northbridge_via_vt8601_control = { .enumerate = enumerate, .name = "VIA vt8601 Northbridge", }; and static void enumerate(struct chip *chip) { extern struct device_operations default_pci_ops_bus; chip_enumerate(chip); chip->dev->ops = &default_pci_ops_bus; } struct chip_control southbridge_via_vt8231_control = { .enumerate = enumerate, enable: southbridge_init, name: "VIA vt8231" }; Which, basically, doesn't work :-( Things look OK for a while ... ========================================================================= PCI: Using configuration type 1 Enumerating: VIA vt8601 Northbridge malloc Enter, size 252, free_mem_ptr 00013a88 malloc 0x00013a88 path PCI: 00:00.0 malloc Enter, size 252, free_mem_ptr 00013b84 malloc 0x00013b84 path PCI: 00:01.0 Enumerating: VIA vt8231 malloc Enter, size 252, free_mem_ptr 00013c80 malloc 0x00013c80 path PCI: 00:11.0 malloc Enter, size 252, free_mem_ptr 00013d7c malloc 0x00013d7c path PCI: 00:11.1 malloc Enter, size 252, free_mem_ptr 00013e78 malloc 0x00013e78 path PCI: 00:11.2 malloc Enter, size 252, free_mem_ptr 00013f74 malloc 0x00013f74 path PCI: 00:11.3 malloc Enter, size 252, free_mem_ptr 00014070 malloc 0x00014070 path PCI: 00:11.4 malloc Enter, size 252, free_mem_ptr 0001416c malloc 0x0001416c path PCI: 00:11.5 malloc Enter, size 252, free_mem_ptr 00014268 malloc 0x00014268 path PCI: 00:11.6 malloc Enter, size 252, free_mem_ptr 00014364 malloc 0x00014364 path PCI: 00:12.0 Allocating resources... Unknown device path type: -926076609 compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Unknown device path type: 80564 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 Unknown device path type: 81068 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 doe compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 0 compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: e compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 =========================================================================== you can see they go to pieces at the end. I'd like to have it such that if there is no enumerate struct member, the "right things" happen. Any advice on the best way to do this? I'm still working out the static/dynamic stuff on V2, and clearly have got it wrong. Anyway I'm still digging ... ron From rminnich at lanl.gov Mon Sep 29 11:23:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 11:23:00 2003 Subject: v2 epia mainboard.c Message-ID: thought I should include this ... static struct device_operations mainboard_operations = { .read_resources = root_dev_read_resources, .set_resources = root_dev_set_resources, .enable_resources = enable_childrens_resources, .init = 0, .scan_bus = pci_scan_bridge, .enable = 0, }; static void enumerate(struct chip *chip) { struct chip *child; dev_root.ops = &mainboard_operations; chip->dev = &dev_root; chip->bus = 0; for(child = chip->children; child; child = child->next) { child->bus = &dev_root.link[0]; } } struct chip_control mainboard_via_epia_control = { .enumerate = enumerate, .name = "VIA EPIA mainboard ", }; From rminnich at lanl.gov Mon Sep 29 11:42:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 11:42:00 2003 Subject: OK, in spite of all the problems Message-ID: via epia on linuxbios2 just loaded etherboot! ron From YhLu at tyan.com Mon Sep 29 12:16:01 2003 From: YhLu at tyan.com (YhLu) Date: Mon Sep 29 12:16:01 2003 Subject: config tool + tree enumeration Message-ID: <3174569B9743D511922F00A0C943142303467064@TYANWEB> Stefan, >It's bus 1, that LinuxBIOS and OpenBIOS >find really well, only Linux refuses to see it. Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? Regards YH. -----????----- ???: Stefan Reinauer [mailto:stepan at suse.de] ????: 2003?9?29? 2:18 ???: Eric W. Biederman ??: ron minnich; YhLu; linuxbios at clustermatic.org ??: Re: config tool + tree enumeration * Eric W. Biederman [030929 00:38]: > And until I have a reason I don't see the point, in making > a change. Hm. You are right. With some more tests I found out that this solution only fixes the problem occasionally. It seems that the chance that it works is higher with the number of tries. Really weird. > Mostly I suspect this is a matter of keeping the irq tables > in sync, or something similar where hard codes don't match the dynamic > assignments. And if that is the case we need to dig and do a good fix > instead of papering over the problem. If LinuxBIOS hangs during CPU/Northbridge enumeration, can this really be a matter of irq tables? I thought that they are touched quite a while later in the setup process. I suspect it might be connected to the highest bus number set in the default resource map, but I did not try more in this direction yet. Additionally I have Linux moaning that the irq table contains entries for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS find really well, only Linux refuses to see it. Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 29 12:35:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 12:35:01 2003 Subject: more on V2 and epia Message-ID: Filling in the blanks ... First all functions of a device save function 0 get this error: PCI: 00:11.1 missing read_resources seems like a bug. So there looks like a problem for functions other than 0. Bridges don't have a path that is named: @???: bus 0000bc6c, bridge 00000100, type_mask 0x100, type 0x13a44 .:.: bus 00013ad4, bridge 00000100, type_mask 0x100, type 0x139a8 <.: bus 00013ccc, bridge 00000100, type_mask 0x100, type 0x13924 compute_allocate_resources has a bug in that it references a variable 'dev' before it is set. Oddly enough, gcc did not flag this error. I am trying to figure out where this really should be. It's the printk at the top: printk_spew("%s compute_allocate_%s: base: %08lx size: \ %08lx align: %d gran: %d\n", dev_path(dev), (bridge->flags & IORESOURCE_IO)? "io": (bridge->flags & IORESOURCE_PREFETCH)? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); dev is not set at this point. ron From rminnich at lanl.gov Mon Sep 29 12:38:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 12:38:01 2003 Subject: config tool + tree enumeration In-Reply-To: <3174569B9743D511922F00A0C943142303467064@TYANWEB> Message-ID: On Mon, 29 Sep 2003, YhLu wrote: > Stefan, > > >It's bus 1, that LinuxBIOS and OpenBIOS > >find really well, only Linux refuses to see it. > > Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? that's not the problem. The problem is that linux does not see bus 1 at all. ron From YhLu at tyan.com Mon Sep 29 12:41:00 2003 From: YhLu at tyan.com (YhLu) Date: Mon Sep 29 12:41:00 2003 Subject: config tool + tree enumeration Message-ID: <3174569B9743D511922F00A0C94314230346706C@TYANWEB> Ron, In s2880, If I don't change the 0 to 1. I will get two copy of bus1 devices in the Linux. In S2885, it is OK, if I don't change it. In Arima, You still can not see bus1 device now? Regards Yinghai Lu -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?9?29? 10:00 ???: YhLu ??: Stefan Reinauer; Eric W. Biederman; linuxbios at clustermatic.org ??: Re: config tool + tree enumeration On Mon, 29 Sep 2003, YhLu wrote: > Stefan, > > >It's bus 1, that LinuxBIOS and OpenBIOS > >find really well, only Linux refuses to see it. > > Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? that's not the problem. The problem is that linux does not see bus 1 at all. ron From rminnich at lanl.gov Mon Sep 29 12:43:38 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 12:43:38 2003 Subject: V2 and epia Message-ID: I really think that if you are working on EPIA-*, you should make the cut to V2. I need the help. The port is going to be a much better job, and we won't have to keep fighting hacks in assembly code. Things that need looking at right now: - vt8231 early spd code - pci bus set up - northbridge and southbridge enumeration I feel very strongly that if we get EPIA done, EPIA-M will be pretty easy. So please consider making the move. ron From rminnich at lanl.gov Mon Sep 29 12:47:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 12:47:01 2003 Subject: config tool + tree enumeration In-Reply-To: <3174569B9743D511922F00A0C94314230346706C@TYANWEB> Message-ID: On Mon, 29 Sep 2003, YhLu wrote: > In Arima, You still can not see bus1 device now? exactly. I think there is a simple problem with bridge configuration, I'm not sure what. The EPIA is showing me that there is work left to do on this. ron From a.mimms at f5.com Mon Sep 29 13:50:01 2003 From: a.mimms at f5.com (Alan Mimms) Date: Mon Sep 29 13:50:01 2003 Subject: config tool + tree enumeration Message-ID: Hello Lu, Is there anything in CVS yet for K8 CPU support? I didn't see anything a week or so ago. The AMD folks say it's there and "production level". ? Thanks. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501 -----Original Message----- From: YhLu [mailto:YhLu at tyan.com] Sent: Monday, September 29, 2003 10:06 AM To: ron minnich Cc: Stefan Reinauer; Eric W. Biederman; linuxbios at clustermatic.org Subject: Re: config tool + tree enumeration Ron, In s2880, If I don't change the 0 to 1. I will get two copy of bus1 devices in the Linux. In S2885, it is OK, if I don't change it. In Arima, You still can not see bus1 device now? Regards Yinghai Lu -----????----- ???: ron minnich [mailto:rminnich at lanl.gov] ????: 2003?9?29? 10:00 ???: YhLu ??: Stefan Reinauer; Eric W. Biederman; linuxbios at clustermatic.org ??: Re: config tool + tree enumeration On Mon, 29 Sep 2003, YhLu wrote: > Stefan, > > >It's bus 1, that LinuxBIOS and OpenBIOS > >find really well, only Linux refuses to see it. > > Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? that's not the problem. The problem is that linux does not see bus 1 at all. ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Mon Sep 29 13:53:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 13:53:01 2003 Subject: V2 issue Message-ID: not sure why yet but ... all functions other than 0 are not having their OPS set correctly. ron From YhLu at tyan.com Mon Sep 29 13:55:46 2003 From: YhLu at tyan.com (YhLu) Date: Mon Sep 29 13:55:46 2003 Subject: config tool + tree enumeration Message-ID: <3174569B9743D511922F00A0C943142303467098@TYANWEB> Alan, K8 support is in freebios2 instead. Regards YH. -----????----- ???: Alan Mimms [mailto:a.mimms at f5.com] ????: 2003?9?29? 11:14 ???: YhLu; ron minnich ??: Stefan Reinauer; Eric W. Biederman; linuxbios at clustermatic.org ??: RE: config tool + tree enumeration Hello Lu, Is there anything in CVS yet for K8 CPU support? I didn't see anything a week or so ago. The AMD folks say it's there and "production level". ? Thanks. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501 From stepan at suse.de Mon Sep 29 14:07:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 14:07:01 2003 Subject: V2 issue In-Reply-To: References: Message-ID: <20030929183127.GA24853@suse.de> * ron minnich [030929 20:15]: > not sure why yet but ... all functions other than 0 are not having their > OPS set correctly. Ron, Eric, can you confirm that your MPTable is correct for the Arima Hdama? Looking into /usr/src/linux/arch/x86_64/kernel/pci-pc.c at function pci_scan_mptable(): If there is an MP Table, and it does not contain the bus, it will not be scanned. Besides that it looks like setting pci=lastbus= makes Linux scan all the busses up to bus . Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 29 14:45:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 14:45:00 2003 Subject: V2 issue In-Reply-To: <20030929183127.GA24853@suse.de> Message-ID: On Mon, 29 Sep 2003, Stefan Reinauer wrote: > * ron minnich [030929 20:15]: > > not sure why yet but ... all functions other than 0 are not having their > > OPS set correctly. > > Ron, Eric, can you confirm that your MPTable is correct for the Arima > Hdama? yes, I have booted SMP on the HDAMA using the SMP table from sourceforge. Works fine. > > Looking into /usr/src/linux/arch/x86_64/kernel/pci-pc.c at function > pci_scan_mptable(): > > If there is an MP Table, and it does not contain the bus, it will not be > scanned. Besides that it looks like setting pci=lastbus= makes > Linux scan all the busses up to bus . well, that's a bad development. But at least you have solved the mystery, almost. Why do my bus 1 tg3s' work in SMP and not non-SMP if my mptable doesn't have bus 1? ron From stepan at suse.de Mon Sep 29 15:01:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 15:01:01 2003 Subject: V2 issue In-Reply-To: References: <20030929183127.GA24853@suse.de> Message-ID: <20030929192514.GB24981@suse.de> * ron minnich [030929 21:08]: > > Ron, Eric, can you confirm that your MPTable is correct for the Arima > > Hdama? > > yes, I have booted SMP on the HDAMA using the SMP table from sourceforge. > Works fine. But you have no devices on bus 1, right? Are the devices on the other busses there? > > Looking into /usr/src/linux/arch/x86_64/kernel/pci-pc.c at function > > pci_scan_mptable(): > > > > If there is an MP Table, and it does not contain the bus, it will not be > > scanned. Besides that it looks like setting pci=lastbus= makes > > Linux scan all the busses up to bus . > > well, that's a bad development. But at least you have solved the mystery, > almost. Linux tries to rely on the information firmware provides. Not that this is always a good thing, but there are chipsets where free probing of the bus just hangs the machine hard (I know that happens at least on the X-Box) So having a careful default probably makes sense from an OS perspective. The decision whether to trust hardware vendors or firmware vendors is just a matter of taste I bet :) And of the fact that Firmware can be fixed with a recompile ;-) > Why do my bus 1 tg3s' work in SMP and not non-SMP if my mptable doesn't > have bus 1? They work means that they work under Linux, or with etherboot? I suspect that the interrupt routing is somewhat different on SMP and non-smp as well but thats just a wild guess. Looking at AMD64's pci-irq.c I could start wondering why it contains entries for the Intel PIIX and the Via 82C586 IRQ routers but not for the 8111 ;) But hey, there's a lot of flexibility in that highlevel kind of programming Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 29 15:08:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 15:08:01 2003 Subject: V2 issue In-Reply-To: <20030929192514.GB24981@suse.de> Message-ID: On Mon, 29 Sep 2003, Stefan Reinauer wrote: > But you have no devices on bus 1, right? Are the devices on the other > busses there? ah, you are right. The only working thing I've done has been with no devices on bus 1. I forgot. > > Linux tries to rely on the information firmware provides. Not that this > is always a good thing, but there are chipsets where free probing of the > bus just hangs the machine hard (I know that happens at least on the > X-Box) happening now on the EPIA, due to problems in V2 PCI code I don't quite understand yet. ron From rminnich at lanl.gov Mon Sep 29 15:12:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 15:12:00 2003 Subject: v2 epia Message-ID: this is bad: Read config 32 bus 1,devfn 0x0,reg 0x18,val 0xffffffff 1:0.0 register 18.l is all ffffffff. Very bad, it should be 010100 Stefan, what was that about hardware bugs again? ron From stepan at suse.de Mon Sep 29 15:51:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 15:51:01 2003 Subject: mptables and missing devices Message-ID: <20030929201513.GA25232@suse.de> Hi, is there a reason why the mptable creation uses dev_find_slot() to find the bridges instead of dev_find_device()? Since it does not even check whether the device it finds is the one it wants this sounds rather dangerous. Taking the PCI_CLASS field into regard, it should be possible to search for all bridges in the system and generate the necessary mptable entries from the information gathered from the devices (SUBORDINATE_BUS, SECONDARY_BUS) Am I digging in the dark? Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Mon Sep 29 15:55:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 15:55:01 2003 Subject: v2 epia In-Reply-To: References: Message-ID: <20030929201859.GB25232@suse.de> * ron minnich [030929 21:36]: > > this is bad: > Read config 32 bus 1,devfn 0x0,reg 0x18,val 0xffffffff > > 1:0.0 register 18.l is all ffffffff. Very bad, it should be 010100 > > Stefan, what was that about hardware bugs again? What device is that? Can you read the rest of the registers? Is the command field set to enable config space read? Stefan -- Architecture Team SuSE Linux AG From rminnich at lanl.gov Mon Sep 29 16:02:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 16:02:00 2003 Subject: V2 EPIA FIXED! Message-ID: Here's what I had to do. First, though, let me say: the new linuxbios architecture, while hard to get the hang of (learning curve) is very powerful. You can have a mainboard-specific pci scan function, and that's what I needed. I may put this as a generic thing into the pci device code. See below for how it works. Basically, for your mainboard, you provide a function that scans the root of the "mainboard PCI" tree. ron Here goes ================ #include #include #include #include #include #include #include #include "chip.h" static int mainboard_scan_bus(device_t root, int maxbus) { int retval; printk_spew("%s: root %p maxbus %d\n", __FUNCTION__, root, maxbus); retval = pci_scan_bus(root->bus, 0, 0xff, maxbus); printk_spew("DONE %s: return %d\n", __FUNCTION__, maxbus); return maxbus; } static struct device_operations mainboard_operations = { .read_resources = root_dev_read_resources, .set_resources = root_dev_set_resources, .enable_resources = enable_childrens_resources, .init = 0, .scan_bus = mainboard_scan_bus, .enable = 0, }; static void enumerate(struct chip *chip) { struct chip *child; dev_root.ops = &mainboard_operations; chip->dev = &dev_root; chip->bus = 0; for(child = chip->children; child; child = child->next) { child->bus = &dev_root.link[0]; } } struct chip_control mainboard_via_epia_control = { .enumerate = enumerate, .name = "VIA EPIA mainboard ", }; From rminnich at lanl.gov Mon Sep 29 16:06:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 16:06:01 2003 Subject: mptables and missing devices In-Reply-To: <20030929201513.GA25232@suse.de> Message-ID: overall, we have some work to do on PCI, so my guess is that you are not digging in the dark at all, Stefan. ron From rminnich at lanl.gov Mon Sep 29 16:08:38 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 16:08:38 2003 Subject: v2 epia In-Reply-To: <20030929201859.GB25232@suse.de> Message-ID: On Mon, 29 Sep 2003, Stefan Reinauer wrote: > * ron minnich [030929 21:36]: > > > > this is bad: > > Read config 32 bus 1,devfn 0x0,reg 0x18,val 0xffffffff > > > > 1:0.0 register 18.l is all ffffffff. Very bad, it should be 010100 > > > > Stefan, what was that about hardware bugs again? > > What device is that? Can you read the rest of the registers? > Is the command field set to enable config space read? my mistake, see next message. ron From stepan at suse.de Mon Sep 29 16:55:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 16:55:00 2003 Subject: mptables and missing devices In-Reply-To: <20030929201513.GA25232@suse.de> References: <20030929201513.GA25232@suse.de> Message-ID: <20030929211927.GA25581@suse.de> * Stefan Reinauer [030929 22:15]: > Hi, > > is there a reason why the mptable creation uses dev_find_slot() > to find the bridges instead of dev_find_device()? Since it does > not even check whether the device it finds is the one it wants > this sounds rather dangerous. > > Taking the PCI_CLASS field into regard, it should be possible to > search for all bridges in the system and generate the necessary > mptable entries from the information gathered from the devices > (SUBORDINATE_BUS, SECONDARY_BUS) /* define bus and isa numbers */ for(bus_num = 0; bus_num < bus_isa; bus_num++) { smp_write_bus(mc, bus_num, "PCI "); } smp_write_bus(mc, bus_isa, "ISA "); Is this an internal convention, a hardware rule or just common sense that the ISA bus is the last bus in the mptable? An ISA bus has no bus number in the PCI view of things, does it? I assume that the ISA compatibility interrupts handling is the same on all platforms that have ISA, is it? /* ISA backward compatibility interrupts */ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_isa, 0x00, 0x02, 0x00); ... Local interrupts are probably one per CPU: /* Standard local interrupt assignments */ What's the way to find out the number of CPUs while writing the mptable? The HDAMA has no AGP slot.. is this a left over, or is it good for something? /* AGP Slot */ The interrupt src entries for the different PCI slots confuse me a bit.. Is there a way to find out in the system how many pci slots a bridge has, or should the bridge entry in the config file get an entry similar to: register "slots" = 2 Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Mon Sep 29 16:59:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 29 16:59:00 2003 Subject: V2 EPIA FIXED! In-Reply-To: References: Message-ID: ron minnich writes: > Here's what I had to do. First, though, let me say: the new linuxbios > architecture, while hard to get the hang of (learning curve) is very > powerful. > > You can have a mainboard-specific pci scan function, and that's what I > needed. I may put this as a generic thing into the pci device code. > > See below for how it works. Basically, for your mainboard, you provide a > function that scans the root of the "mainboard PCI" tree. Hmm. I am curious why the default did not take. See: devices/root_device.c All you should need is included below. And potentially we can have a generic enumeration function in root_device.c that does the rest of it as well. The Opteron has rather special needs so it needs to override the defaults, but the VIA EPIA should not. Eric > ================ > > #include > #include > #include > #include > #include > > #include > #include > #include "chip.h" > > static void enumerate(struct chip *chip) > { > struct chip *child; > chip->dev = &dev_root; > chip->bus = 0; > for(child = chip->children; child; child = child->next) { > child->bus = &dev_root.link[0]; > } > } > struct chip_control mainboard_via_epia_control = { > .enumerate = enumerate, > .name = "VIA EPIA mainboard ", > }; From ebiederman at lnxi.com Mon Sep 29 17:15:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 29 17:15:00 2003 Subject: mptables and missing devices In-Reply-To: <20030929211927.GA25581@suse.de> References: <20030929201513.GA25232@suse.de> <20030929211927.GA25581@suse.de> Message-ID: Stefan Reinauer writes: > * Stefan Reinauer [030929 22:15]: > > Hi, > > > > is there a reason why the mptable creation uses dev_find_slot() > > to find the bridges instead of dev_find_device()? Since it does > > not even check whether the device it finds is the one it wants > > this sounds rather dangerous. In the case of a specific motherboard it is safe, as long as all of the upper level bridges are taken into account. dev_find_device, is worse because you may have two devices with the same vendor and device id. It is on the todo list to generate all of this by walking the device tree. What we have now is a place holder that let's LinuxBIOS work until we have generic code that will work for everyone. > > Taking the PCI_CLASS field into regard, it should be possible to > > search for all bridges in the system and generate the necessary > > mptable entries from the information gathered from the devices > > (SUBORDINATE_BUS, SECONDARY_BUS) > > /* define bus and isa numbers */ > for(bus_num = 0; bus_num < bus_isa; bus_num++) { > smp_write_bus(mc, bus_num, "PCI "); > } > smp_write_bus(mc, bus_isa, "ISA "); > > Is this an internal convention, a hardware rule or just common sense > that the ISA bus is the last bus in the mptable? An ISA bus has no > bus number in the PCI view of things, does it? Right. A lot of this was modeled on how existing mptables are setup. I am not certain there needs to be a 1-1 mapping from bus numbers on the pci bus to other bus numbers but it can't hurt. And the ISA can pretty much go anywhere else. > I assume that the ISA compatibility interrupts handling is the same on > all platforms that have ISA, is it? > /* ISA backward compatibility interrupts */ > smp_write_intsrc(mc, mp_ExtINT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > bus_isa, 0x00, 0x02, 0x00); > ... Almost. Interrupts off of the LPC/ISA bus are the same because the bus generates them. PCI interrupts that are routed through 8259 also vary. I think the irq controller can also vary. Although it may be special cased. > Local interrupts are probably one per CPU: > /* Standard local interrupt assignments */ > What's the way to find out the number of CPUs while writing the mptable? > > The HDAMA has no AGP slot.. is this a left over, or is it good for > something? > /* AGP Slot */ It must be left over. I have it yanked out of my tree. After I finish catching up on my email I will start synching the tress and kill it. > The interrupt src entries for the different PCI slots confuse me a bit.. > Is there a way to find out in the system how many pci slots a bridge > has, or should the bridge entry in the config file get an entry similar to: > register "slots" = 2 We should probably hang a ``slot'' device of the device tree to model this. All pci bridges have a maximum of 32 devices behind them. And we need to know which ones are actually devices. Eric From stepan at suse.de Mon Sep 29 17:24:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Mon Sep 29 17:24:00 2003 Subject: mptables and missing devices In-Reply-To: References: <20030929201513.GA25232@suse.de> <20030929211927.GA25581@suse.de> Message-ID: <20030929214748.GA25687@suse.de> * Eric W. Biederman [030929 23:48]: > > > is there a reason why the mptable creation uses dev_find_slot() > > > to find the bridges instead of dev_find_device()? Since it does > > > not even check whether the device it finds is the one it wants > > > this sounds rather dangerous. > > In the case of a specific motherboard it is safe, as long as all of > the upper level bridges are taken into account. dev_find_device, > is worse because you may have two devices with the same vendor > and device id. But you can give it a starting point, and you probably want entries for both of them anyways...? > It is on the todo list to generate all of this by walking the device > tree. What we have now is a place holder that let's LinuxBIOS work > until we have generic code that will work for everyone. Ok.. I think it's pretty easy doable if the bus number registers of the bridges are filled reliably. Is this the case? > > Is this an internal convention, a hardware rule or just common sense > > that the ISA bus is the last bus in the mptable? An ISA bus has no > > bus number in the PCI view of things, does it? > > Right. A lot of this was modeled on how existing mptables are setup. > I am not certain there needs to be a 1-1 mapping from bus numbers on > the pci bus to other bus numbers but it can't hurt. And the ISA can > pretty much go anywhere else. Hanging it at the end of the list should not hurt then as it keeps all the rest of constant. > > /* ISA backward compatibility interrupts */ > > smp_write_intsrc(mc, mp_ExtINT, > > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > > bus_isa, 0x00, 0x02, 0x00); > > ... > > Almost. Interrupts off of the LPC/ISA bus are the same because the bus > generates them. PCI interrupts that are routed through 8259 also vary. > I think the irq controller can also vary. Although it may be special > cased. So the above works only if you use an ioapic? at least for opteron/linux this is always the case. Linux/x86_64 wont boot with no ioapic enabled. > It must be left over. I have it yanked out of my tree. After I finish > catching up on my email I will start synching the tress and kill it. please do!! ;) > > The interrupt src entries for the different PCI slots confuse me a bit.. > > Is there a way to find out in the system how many pci slots a bridge > > has, or should the bridge entry in the config file get an entry similar to: > > register "slots" = 2 > > We should probably hang a ``slot'' device of the device tree to model this. this is in the openfirmware kind of view a device node vs node property consideration. Does a single slot need more information than the fact that it's there? > All pci bridges have a maximum of 32 devices behind them. And we need to know > which ones are actually devices. We get that information during bus enumeration already, don't we? Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Mon Sep 29 17:42:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Sep 29 17:42:00 2003 Subject: mptables and missing devices In-Reply-To: <20030929214748.GA25687@suse.de> References: <20030929201513.GA25232@suse.de> <20030929211927.GA25581@suse.de> <20030929214748.GA25687@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030929 23:48]: > > > > is there a reason why the mptable creation uses dev_find_slot() > > > > to find the bridges instead of dev_find_device()? Since it does > > > > not even check whether the device it finds is the one it wants > > > > this sounds rather dangerous. > > > > In the case of a specific motherboard it is safe, as long as all of > > the upper level bridges are taken into account. dev_find_device, > > is worse because you may have two devices with the same vendor > > and device id. > > But you can give it a starting point, and you probably want entries for > both of them anyways...? > > > It is on the todo list to generate all of this by walking the device > > tree. What we have now is a place holder that let's LinuxBIOS work > > until we have generic code that will work for everyone. > > Ok.. I think it's pretty easy doable if the bus number registers of the > bridges are filled reliably. Is this the case? Yes. And the bus number values are also in the device tree. Which is where it would be better to read them from. Just in case we have a non-standard pci bus. Like the Opteron's multiple host bridges off of one cpu. > > > Is this an internal convention, a hardware rule or just common sense > > > that the ISA bus is the last bus in the mptable? An ISA bus has no > > > bus number in the PCI view of things, does it? > > > > Right. A lot of this was modeled on how existing mptables are setup. > > I am not certain there needs to be a 1-1 mapping from bus numbers on > > the pci bus to other bus numbers but it can't hurt. And the ISA can > > pretty much go anywhere else. > > Hanging it at the end of the list should not hurt then as it keeps all > the rest of constant. Yes. > > > /* ISA backward compatibility interrupts */ > > > smp_write_intsrc(mc, mp_ExtINT, > > > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > > > bus_isa, 0x00, 0x02, 0x00); > > > ... > > > > Almost. Interrupts off of the LPC/ISA bus are the same because the bus > > generates them. PCI interrupts that are routed through 8259 also vary. > > I think the irq controller can also vary. Although it may be special > > cased. > > So the above works only if you use an ioapic? at least for opteron/linux > this is always the case. Linux/x86_64 wont boot with no ioapic enabled. Yes. The MPtables are IOAPIC specific. > > It must be left over. I have it yanked out of my tree. After I finish > > catching up on my email I will start synching the tress and kill it. > > please do!! ;) > > > > The interrupt src entries for the different PCI slots confuse me a bit.. > > > Is there a way to find out in the system how many pci slots a bridge > > > has, or should the bridge entry in the config file get an entry similar to: > > > register "slots" = 2 > > > > We should probably hang a ``slot'' device of the device tree to model this. > > this is in the openfirmware kind of view a device node vs node property > consideration. Does a single slot need more information than the fact > that it's there? Yes. Which the irq routing information. > > All pci bridges have a maximum of 32 devices behind them. And we need to know > > > which ones are actually devices. > > We get that information during bus enumeration already, don't we? For the most part yes. But an empty slot won't show up. So at least in the hot-plug case we need to force it's information to be present. Saying to much is better than saying to little. Eric From rminnich at lanl.gov Mon Sep 29 18:15:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Mon Sep 29 18:15:01 2003 Subject: V2 EPIA FIXED! In-Reply-To: Message-ID: On 29 Sep 2003, Eric W. Biederman wrote: > All you should need is included below. And potentially we can have > a generic enumeration function in root_device.c that does the rest > of it as well. yes, we should. The default did not take, but I will take a look. ron From agnew at cs.umd.edu Mon Sep 29 21:39:00 2003 From: agnew at cs.umd.edu (Adam Agnew) Date: Mon Sep 29 21:39:00 2003 Subject: Linux Boot In Under 200ms In-Reply-To: Message-ID: <20030929220342.I9930-100000@www.missl.cs.umd.edu> This shouldn't slip under anyone's radar. Not that it would, being on slashdot and all. Slashdot Headline: "Software Tweak Makes Linux Boot In Under 200ms" http://developers.slashdot.org/developers/03/09/30/003209.shtml?tid=106&tid=185&tid=190 - Adam A. From stepan at suse.de Tue Sep 30 05:20:01 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 30 05:20:01 2003 Subject: mptables and missing devices In-Reply-To: References: <20030929201513.GA25232@suse.de> <20030929211927.GA25581@suse.de> <20030929214748.GA25687@suse.de> Message-ID: <20030930094351.GB27352@suse.de> * Eric W. Biederman [030930 00:16]: > > Ok.. I think it's pretty easy doable if the bus number registers of the > > bridges are filled reliably. Is this the case? > > Yes. And the bus number values are also in the device tree. Which > is where it would be better to read them from. Just in case we have > a non-standard pci bus. Like the Opteron's multiple host bridges > off of one cpu. ack > > this is in the openfirmware kind of view a device node vs node property > > consideration. Does a single slot need more information than the fact > > that it's there? > > Yes. Which the irq routing information. This information is also held in the pirq table. Can it be generated from there or are there other caveats? It would be nice if a new board only needs an adapted pirq table, no matter whether it provides an mptable or not. Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Tue Sep 30 05:54:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 30 05:54:00 2003 Subject: static_devices.c Message-ID: <20030930101807.GA28079@suse.de> Hi, the amd64 boards all have the "static_devices.c" file but it is not used by any of them, instead the resulting object file is commented out in the config file. Can it safely be removed, or will this code come back to life? I also saw there are some old config method files lying around. Using the old config method is discouraged. Is there anything speaking against removing these files? Keeping no obsolete files in the tree makes it a lot easier to get into the code for new developers. Thus, if there are no major reasons against this, I will drop those files in a while. Stefan -- Architecture Team SuSE Linux AG From stepan at suse.de Tue Sep 30 06:17:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 30 06:17:00 2003 Subject: Reboot after setting MTRRs Message-ID: <20030930104039.GA28254@suse.de> Hi, the latest AMD Solo builds reboot after setting variable MTRRs: mmio_base: 3670016KB totalram: 256M Initializing CPU #0 cpufixup RAM: 0x00040000 KB Enabling cache... Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-88) type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 256MB, type WB Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.4.0-Fallback Di Sep 30 12:19:45 CEST 2003 rebooting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: NSC 87360 This did not happen until somewhen after 1.1.4 What could cause this? It does not happen on other machines as far as I can tell... :-(((( Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Tue Sep 30 07:24:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 30 07:24:01 2003 Subject: static_devices.c In-Reply-To: <20030930101807.GA28079@suse.de> References: <20030930101807.GA28079@suse.de> Message-ID: Stefan Reinauer writes: > Hi, > > the amd64 boards all have the "static_devices.c" file but it > is not used by any of them, instead the resulting object file > is commented out in the config file. > > Can it safely be removed, or will this code come back to life? Yes. This was a precursor to some of the more interesting things that happened with the device tree. I kept including it and playing with it and for some reason everyone cloned it. Now that we have settled on how to build the tree statically this file can totally go away. > I also saw there are some old config method files lying around. > Using the old config method is discouraged. Is there anything speaking > against removing these files? We probably want to, but if we could wait just a little bit I would appreciate it. I have been stabilizing and I really have not switched over yet. I think I am ready to but it is nice (at least in theory) to do a comparison build the old way still. > Keeping no obsolete files in the tree makes it a lot easier to get into > the code for new developers. Thus, if there are no major reasons against > this, I will drop those files in a while. Sounds reasonable. If you will delay just a little bit on the old configuration stuff at least for the hdama I would appreciate it. Before we are done and decide we are 2.0 I totally agree it all needs to die. Eric From ebiederman at lnxi.com Tue Sep 30 07:26:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 30 07:26:01 2003 Subject: Reboot after setting MTRRs In-Reply-To: <20030930104039.GA28254@suse.de> References: <20030930104039.GA28254@suse.de> Message-ID: Stefan Reinauer writes: > Hi, > > the latest AMD Solo builds reboot after setting variable MTRRs: > > mmio_base: 3670016KB > totalram: 256M > Initializing CPU #0 > cpufixup RAM: 0x00040000 KB > Enabling cache... > Setting fixed MTRRs(0-88) type: UC > Setting fixed MTRRs(0-88) type: WB > DONE fixed MTRRs > Setting variable MTRR 0, base: 0MB, range: 256MB, type WB > Copying LinuxBIOS to ram. > Jumping to LinuxBIOS. > LinuxBIOS-1.1.4.0-Fallback Di Sep 30 12:19:45 CEST 2003 rebooting... > Finding PCI configuration type. > PCI: Using configuration type 1 > Enumerating: AMD K8 Northbridge > Enumerating: AMD K8 > Enumerating: NSC 87360 > > This did not happen until somewhen after 1.1.4 > > What could cause this? It does not happen on other machines as far as I > can tell... :-(((( No current clue, except I know I need to get a pile of bug fixes in there. I can imagine the bug fixes improperly executed triggering this but just mtrrs triggering this I don't know. I guess this is when I would start instrumenting the code to see where it dies. Do you have a working fallback image? Eric From stepan at suse.de Tue Sep 30 07:34:00 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 30 07:34:00 2003 Subject: static_devices.c In-Reply-To: References: <20030930101807.GA28079@suse.de> Message-ID: <20030930115743.GA29259@suse.de> * Eric W. Biederman [030930 13:58]: > > the amd64 boards all have the "static_devices.c" file but it > > is not used by any of them, instead the resulting object file > > is commented out in the config file. > > > > Can it safely be removed, or will this code come back to life? > > Yes. This was a precursor to some of the more interesting things > that happened with the device tree. I kept including it and playing > with it and for some reason everyone cloned it. Now that we have > settled on how to build the tree statically this file can totally > go away. ok. I wiped those out now. > > I also saw there are some old config method files lying around. > > Using the old config method is discouraged. Is there anything speaking > > against removing these files? > > We probably want to, but if we could wait just a little bit I would > appreciate it. I have been stabilizing and I really have not switched > over yet. I think I am ready to but it is nice (at least in theory) > to do a comparison build the old way still. > Sounds reasonable. If you will delay just a little bit on the old > configuration stuff at least for the hdama I would appreciate it. > Before we are done and decide we are 2.0 I totally agree it all needs > to die. Ok. Since the spread files are needed for building on the hdama, I'll leave all of them in for now. The files I'm talking about are these: src/cpu/k7/Config src/cpu/k8/Config src/cpu/p5/Config src/cpu/p6/Config src/lib/Config src/pmc/altimus/mpc7410/Config src/rom/Config src/arch/ppc/lib/Config src/arch/ppc/boot/Config src/arch/ppc/Config src/arch/i386/lib/Config src/arch/i386/smp/Config src/arch/i386/boot/Config src/arch/i386/Config src/boot/Config src/pc80/ide/Config src/pc80/Config src/console/Config src/devices/Config src/northbridge/amd/amdk8/Config src/northbridge/motorola/mpc107/Config src/superio/NSC/pc97307/Config src/config/Config src/southbridge/amd/amd8111/Config src/southbridge/amd/amd8131/Config src/southbridge/amd/amd8151/Config src/southbridge/winbond/w83c553/Config src/stream/Config src/mainboard/tyan/s2880/Config src/mainboard/tyan/s2882/Config src/mainboard/tyan/s2885/Config src/mainboard/arima/hdama/Config src/mainboard/motorola/sandpoint/Config src/mainboard/motorola/sandpoint/flash/Config src/mainboard/motorola/sandpoint/nvram/Config Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Tue Sep 30 07:40:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 30 07:40:01 2003 Subject: mptables and missing devices In-Reply-To: <20030930094351.GB27352@suse.de> References: <20030929201513.GA25232@suse.de> <20030929211927.GA25581@suse.de> <20030929214748.GA25687@suse.de> <20030930094351.GB27352@suse.de> Message-ID: Stefan Reinauer writes: > * Eric W. Biederman [030930 00:16]: > > > Ok.. I think it's pretty easy doable if the bus number registers of the > > > bridges are filled reliably. Is this the case? > > > > Yes. And the bus number values are also in the device tree. Which > > is where it would be better to read them from. Just in case we have > > a non-standard pci bus. Like the Opteron's multiple host bridges > > off of one cpu. > > ack > > > > this is in the openfirmware kind of view a device node vs node property > > > consideration. Does a single slot need more information than the fact > > > that it's there? > > > > Yes. Which the irq routing information. > > This information is also held in the pirq table. Can it be generated > from there or are there other caveats? The pirq routing information has a slightly different flavor and slightly different rules but in principle we want to generate it from the same tree as well. > It would be nice if a new board > only needs an adapted pirq table, no matter whether it provides an > mptable or not. There are boards that a pirq routing table simply does not work for, because not all interrupts go through the pirq router. For those boards we either we need to just go through the mptable, or we need to pre route the irqs and fill in the routing in pci space. Pre routing the irqs is the most compatible with multiple kernels and OS's. Even in cases where pirq tables work there are not forced correspondences from how an irq line is routed into a pirq router and an ioapic. So we probably need separate routing information from irq lines to the ioapics and to the pirq routers. With the possibility for older boards of no router being present at all. What is required in LinuxBIOS is enough information to do the routing ourselves. Once we get that we can figure out how to export that information via the LinuxBIOS table, the mptable, and pirq table. I am tempted at that point to move the mptable and pirq table generation code into mkelfImage, and to start looking at having the kernel support the LinuxBIOS table directly. But for now need a way to represent that information. Eric From stepan at suse.de Tue Sep 30 07:40:10 2003 From: stepan at suse.de (Stefan Reinauer) Date: Tue Sep 30 07:40:10 2003 Subject: Reboot after setting MTRRs In-Reply-To: References: <20030930104039.GA28254@suse.de> Message-ID: <20030930120359.GA29557@suse.de> * Eric W. Biederman [030930 14:00]: > Stefan Reinauer writes: > > > What could cause this? It does not happen on other machines as far as I > > can tell... :-(((( > > No current clue, except I know I need to get a pile of bug > fixes in there. I can imagine the bug fixes improperly executed > triggering this but just mtrrs triggering this I don't know. Seeing those fixes in the main tree would be pretty helpful i bet ;-) > I guess this is when I would start instrumenting the code to see > where it dies. Do you have a working fallback image? I have an old tree I can use to build one. I'll have a look.. Stefan -- Architecture Team SuSE Linux AG From ebiederman at lnxi.com Tue Sep 30 07:41:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 30 07:41:01 2003 Subject: Linux Boot In Under 200ms In-Reply-To: <20030929220342.I9930-100000@www.missl.cs.umd.edu> References: <20030929220342.I9930-100000@www.missl.cs.umd.edu> Message-ID: Adam Agnew writes: > This shouldn't slip under anyone's radar. Not that it would, being on > slashdot and all. > > Slashdot Headline: "Software Tweak Makes Linux Boot In Under 200ms" > http://developers.slashdot.org/developers/03/09/30/003209.shtml?tid=106&tid=185&tid=190 Have you found the patches yet. This sounds like the old technique of making everything modular so that init will start faster. Eric From rminnich at lanl.gov Tue Sep 30 09:37:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 09:37:00 2003 Subject: V2 committers Message-ID: I notice a lot of see-sawing on Config.lb files. Please consider having multiple Config files for a given target. So, for example, you could have arima/hdama/Config.etherboot.lb arima/hdama/Config.kernel.lb and so on. Each Config tool should build to a different target directory, to make multiple concurrent builds easy. The the buildtarget tool can default to /Config.lb, but a user can also specify (in future) / ron From rminnich at lanl.gov Tue Sep 30 09:39:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 09:39:01 2003 Subject: static_devices.c In-Reply-To: <20030930101807.GA28079@suse.de> Message-ID: On Tue, 30 Sep 2003, Stefan Reinauer wrote: > Can it safely be removed, or will this code come back to life? I am convinced that code is dead. > I also saw there are some old config method files lying around. > Using the old config method is discouraged. Is there anything speaking > against removing these files? I no longer create them (e.g. Epia has none) and I encourage their removal. I would like to see them go. ron From rminnich at lanl.gov Tue Sep 30 09:43:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 09:43:01 2003 Subject: mptables and missing devices In-Reply-To: Message-ID: On 30 Sep 2003, Eric W. Biederman wrote: > There are boards that a pirq routing table simply does not work > for, because not all interrupts go through the pirq router. For those > boards we either we need to just go through the mptable, or we > need to pre route the irqs and fill in the routing in pci space. > Pre routing the irqs is the most compatible with multiple kernels and > OS's. still worse, there are those cases (Linux) where the interpretation of PIRQ is broken (e.g. for Geode). So I've reluctantly come to the conclusion that LinuxBIOS should do this routing. > Once we get that we can figure out how to export that information > via the LinuxBIOS table, the mptable, and pirq table. I am tempted at > that point to move the mptable and pirq table generation code into > mkelfImage, and to start looking at having the kernel support the > LinuxBIOS table directly. we need to leave them in LinuxBIOS, I think, so that I can continue to support 9load, plan 9, and all the other systems that want to read PIRQ. I would hate to see mkelfImage get too complicated, as I need to be able to generate these elf Images on systems that have no GNUbin utilities. ron From zmiller at cs.wisc.edu Tue Sep 30 09:46:01 2003 From: zmiller at cs.wisc.edu (Zachary Miller) Date: Tue Sep 30 09:46:01 2003 Subject: "best" supported hardware Message-ID: <20030930090950.C13393@cs.wisc.edu> hi all, i'm new to this list although i have some experience with linuxbios. about a year ago (somewhere in the 2.4.12 kernel era) i got everything working no problem on a matsonic/ms7308e motherboard, with a disk-on-chip filesystem and all. my boot time from power off is about 6 seconds until the mp3 player kicks in. i must say i'm very impressed! it seems that many more types of motherboards are now listed as stable since i last checked. sure, i could go and look up the specs of every single one, and i probably will, but i thought i would suggest putting some basic specs for each on the status page or perhaps an entry in the faq that answers my basic question: which of the "stable" motherboards supports the fastest processor? cheers, -zach From rminnich at lanl.gov Tue Sep 30 09:57:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 09:57:01 2003 Subject: "best" supported hardware In-Reply-To: <20030930090950.C13393@cs.wisc.edu> Message-ID: On Tue, 30 Sep 2003, Zachary Miller wrote: > which of the "stable" motherboards supports the fastest processor? money is no object? Go to Tyan, they'll sell you a supported (by Tyan!) K8 mobo TODAY. ron From rminnich at lanl.gov Tue Sep 30 11:13:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 11:13:00 2003 Subject: Reboot after setting MTRRs In-Reply-To: <20030930104039.GA28254@suse.de> Message-ID: I think at this point I'm hanging on Eric's merge, because anything I do could well got lost in that shuffle. ron From rminnich at lanl.gov Tue Sep 30 12:02:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 12:02:00 2003 Subject: snapshots (fwd) Message-ID: Thanks to Stefan Reinauer we now have a fix for the linuxbios sourceforge problems. You can now get snapshots at: http://snapshots.linuxbios.org/. Thanks to the OpenBIOS organization too for setting up this excellent facility. sourceforge may someday be fixed but we can't wait. Now all you VIA EPIA hackers: no excuses! there's you snapshot! ron From rminnich at lanl.gov Tue Sep 30 12:07:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 12:07:00 2003 Subject: VIA EPIA SPD Message-ID: I'm getting a bad feeling about SPD on EPIA. I have tried to scan SPD on both a normal bios and linuxbios, and I don't get any real data back. The SMBUS hardware all acts correctly, but on linuxbios every SPD byte reads back as 0, and on the normal bios every spd byte reads back as 3. now, on earlier VIA platforms I have had, SPD has only been connected to one slot, not all slots. I have some concern that SPD is not wired at all on EPIA. VIA had expressed concern to me about the many errors in low-end SEEROMs used on DRAM, and felt that SPD was not always a good way to go. Can anyone out there confirm or deny my speculation on SPD on EPIA? SPD scan code available on request. ron From ebiederman at lnxi.com Tue Sep 30 12:08:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Sep 30 12:08:00 2003 Subject: mptables and missing devices In-Reply-To: References: Message-ID: ron minnich writes: > On 30 Sep 2003, Eric W. Biederman wrote: > > > There are boards that a pirq routing table simply does not work > > for, because not all interrupts go through the pirq router. For those > > boards we either we need to just go through the mptable, or we > > need to pre route the irqs and fill in the routing in pci space. > > Pre routing the irqs is the most compatible with multiple kernels and > > OS's. > > still worse, there are those cases (Linux) where the interpretation of > PIRQ is broken (e.g. for Geode). So I've reluctantly come to the > conclusion that LinuxBIOS should do this routing. > > > Once we get that we can figure out how to export that information > > via the LinuxBIOS table, the mptable, and pirq table. I am tempted at > > that point to move the mptable and pirq table generation code into > > mkelfImage, and to start looking at having the kernel support the > > LinuxBIOS table directly. > > we need to leave them in LinuxBIOS, I think, so that I can continue to > support 9load, plan 9, and all the other systems that want to read PIRQ. I > would hate to see mkelfImage get too complicated, as I need to be able to > generate these elf Images on systems that have no GNUbin utilities. mkelfImage 2.x does not have a binutils requirement, except when it is built. mkelfImage 2.x is a standalone C binary. Removing the non native interface from the core is something I'm playing with. It is not something I care about much either was as long as we have a good native interface. But it should not much matter if we actually pre route the irqs. As suggested for the Geode. In addition if we have maintain a subset of the kernel that understands native LinuxBIOS tables then we define the proper interpretation of the tables and we can say who has the correct interpretation. But I totally agree this is something we need to move forward slowly with. Eric From ts1 at tsn.or.jp Tue Sep 30 13:39:00 2003 From: ts1 at tsn.or.jp (SONE Takeshi) Date: Tue Sep 30 13:39:00 2003 Subject: VIA EPIA SPD In-Reply-To: References: Message-ID: <20030930180252.GA25252@tsn.or.jp> Thanks a lot for your work on EPIA. On Tue, Sep 30, 2003 at 10:30:45AM -0600, ron minnich wrote: > > I'm getting a bad feeling about SPD on EPIA. > > I have tried to scan SPD on both a normal bios and linuxbios, and I don't > get any real data back. The SMBUS hardware all acts correctly, but on > linuxbios every SPD byte reads back as 0, and on the normal bios every spd > byte reads back as 3. > > now, on earlier VIA platforms I have had, SPD has only been connected to > one slot, not all slots. I have some concern that SPD is not wired at all > on EPIA. VIA had expressed concern to me about the many errors in low-end > SEEROMs used on DRAM, and felt that SPD was not always a good way to go. > > Can anyone out there confirm or deny my speculation on SPD on EPIA? Looks like lm-sensors can read SPD on EPIA. black:~$ ls /proc/sys/dev/sensors/eeprom-i2c-1-50/ 00 10 20 30 40 50 60 70 80 90 a0 b0 c0 d0 e0 f0 black:~$ cat /proc/sys/dev/sensors/eeprom-i2c-1-50/* 128 8 4 13 10 1 64 0 1 117 84 0 130 8 0 1 143 4 6 1 1 0 14 117 84 0 0 15 15 15 37 64 21 8 21 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 18 137 0 0 0 0 0 0 0 0 0 51 50 77 88 54 52 85 45 49 51 51 0 51 50 77 88 56 0 0 0 0 0 2 9 17 194 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 100 246 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 I think it uses i2c-viapro I2C driver to talk to the EEPROM. black:~$ lsmod Module Size Used by Not tainted i2c-viapro 3728 0 (unused) eeprom 3508 0 snd 24168 0 soundcore 3108 0 [snd] fbcon-cfb32 3648 0 (unused) fbcon-cfb24 4128 0 (unused) fbcon-cfb16 3872 0 (unused) fbcon-cfb8 3264 0 (unused) fbgen 2740 0 (unused) vt8231 6884 0 (unused) i2c-proc 6928 0 [eeprom vt8231] i2c-isa 1096 0 (unused) i2c-core 13928 0 [i2c-viapro eeprom vt8231 i2c-proc i2c-isa] via-rhine 12936 1 mii 2160 0 [via-rhine] rtc 5916 0 (autoclean) black:~$ -- Takeshi From svante.signell at telia.com Tue Sep 30 13:48:01 2003 From: svante.signell at telia.com (Svante Signell) Date: Tue Sep 30 13:48:01 2003 Subject: Level 2 cache activation code? Message-ID: <1064945574.1446.789.camel@em2.my.own.domain> Hello, I have recently upgraded my dual MSI-6120 from 2xCeleron (Mendocino) 300 at 450MHz with 2xMSI-6905 slot 370 to slot 1 adapters to one Celeron2 1.3GHz (Tualatin) using a Slot-T adapter card. The plan is to equip the mobo with 2xPIII or preferably 2xVIA C3 Nehemiah (when SMP capable). The problem is that the latest MSI BIOS (v2.0) for the mobo does not support Coppermine/Tualatin processors. The single GNU/Linux kernels boot without problems but _extremely_ slowly, at least with a speed reduction by a factor 10. hdparm -tT gives around 20/2 compared with 250/25 with the Mendocino CPU(s). For example uncompressing the kernel takes minute(s) compared to seconds. After some trials and web searching I suspect that the problem is with the level 2 cache not activated by the BIOS. I see the you have code in the linuxbios for activating caches. i) Does this code work for 440BX motherboards? ii) Is it possible to extract this code and try out after the kernel has booted (slowly), to verify my assumption? iii) Is there some other tool available for cache activation? iv) One interesting continuation would be to try to replace the MSI (AMI) BIOS with linuxbios, but as a first step I think this would be a little risky. Any ideas? Thanks, Svante From rminnich at lanl.gov Tue Sep 30 13:52:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 13:52:00 2003 Subject: A limit in V2 for PCI setup Message-ID: In v2, it is pretty much impossible to do PCI setup BEFORE the PCI scan is called and device trees are built. Sometimes, however, you need to be able to work on PCI before the scan, e.g. to enable certain functions. I don't want this code in mainboard auto.c -- that's a bad way to go. See the below comment. /* we need to do things in this function so that PCI scan will find * them. One problem here is that we can't use ANY of the new device * stuff. This work here precedes all that. * Fundamental problem with linuxbios V2 architecture. * You can't do pci control in the C code without having done a PCI scan. * But in some cases you need to to pci control in the c code before doing * a PCI scan. But you can't use arch/romcc_io.h (the code you need) * because * that has functions with the same name but different type signatures * (e.g. device_t is a struct in C code, and is an unsigned long in * romcc code). * This needs to get fixed. We need low-level pci scans * in the C code. */ I think my fix is to make a copy of romcc_io.h, with different names and type signatures, for use by functions that need to work with PCI before the PCI scan has been done. comments welcome. I'll do this after lunch unless I hear strong counterarguments that will get me what I need. Thanks ron From rminnich at lanl.gov Tue Sep 30 13:54:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 13:54:01 2003 Subject: VIA EPIA SPD In-Reply-To: <20030930180252.GA25252@tsn.or.jp> Message-ID: anybody want to send me that code and see what might be working right in it? thanks ron From gwatson at lanl.gov Tue Sep 30 14:45:00 2003 From: gwatson at lanl.gov (Greg Watson) Date: Tue Sep 30 14:45:00 2003 Subject: A limit in V2 for PCI setup In-Reply-To: References: Message-ID: in V1 I used to call the pci ops directly, e.g. extern pci_ops pci_direct; pci_direct.read_dword(...); Presumably this will work in V2 as well. Greg At 12:16 PM -0600 30/9/03, ron minnich wrote: >In v2, it is pretty much impossible to do PCI setup BEFORE the PCI scan is >called and device trees are built. Sometimes, however, you need to be able >to work on PCI before the scan, e.g. to enable certain functions. I don't >want this code in mainboard auto.c -- that's a bad way to go. > >See the below comment. > >/* we need to do things in this function so that PCI scan will find > * them. One problem here is that we can't use ANY of the new device > * stuff. This work here precedes all that. > * Fundamental problem with linuxbios V2 architecture. > * You can't do pci control in the C code without having done a PCI scan. > * But in some cases you need to to pci control in the c code before doing > * a PCI scan. But you can't use arch/romcc_io.h (the code you need) > * because > * that has functions with the same name but different type signatures > * (e.g. device_t is a struct in C code, and is an unsigned long in > * romcc code). > * This needs to get fixed. We need low-level pci scans > * in the C code. > */ > >I think my fix is to make a copy of romcc_io.h, with different names and >type signatures, for use by functions that need to work with PCI before >the PCI scan has been done. > >comments welcome. I'll do this after lunch unless I hear strong >counterarguments that will get me what I need. > >Thanks > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Tue Sep 30 16:28:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 16:28:00 2003 Subject: V2 and EPIA Message-ID: OK, I just loaded from flash. Next step is to fix the PIRQ, then look at SPD and memory setup. The fix, for now, is this in auto.c static void enable_mainboard_devices(void) { device_t dev; /* dev 0 for southbridge */ dev = pci_locate_device(PCI_ID(0x1106,0x8231), 0); if (dev == PCI_DEV_INVALID) { die("Southbridge not found!!!\n"); } pci_write_config8(dev, 0x50, 7); pci_write_config8(dev, 0x51, 0xff); } This is a mainboard-specific setting for the VIA EPIA. and in main: static void main(void) { unsigned long x; /* init_timer();*/ outb(5, 0x80); enable_vt8231_serial(); enable_mainboard_devices(); uart_init(); console_init(); . . . So at the moment I am loading from FLASH! Ethernet is up, etc: Linux is happy. Just need PIRQ. ron From rminnich at lanl.gov Tue Sep 30 19:11:00 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 19:11:00 2003 Subject: Level 2 cache activation code? In-Reply-To: <1064945574.1446.789.camel@em2.my.own.domain> Message-ID: On Tue, 30 Sep 2003, Svante Signell wrote: > i) Does this code work for 440BX motherboards? it's processor-dependent, 440bx or not is not an issue. > ii) Is it possible to extract this code and try out after the kernel has > booted (slowly), to verify my assumption? yes, we tested it that way. You can try it. > iii) Is there some other tool available for cache activation? Not sure. > iv) One interesting continuation would be to try to replace the MSI > (AMI) BIOS with linuxbios, but as a first step I think this would be a > little risky. well, so far, given the track record of many of these BIOSes, I'm not sure how risky that is ... ron From randall at tdl.com Tue Sep 30 19:19:01 2003 From: randall at tdl.com (Randall H. Craig) Date: Tue Sep 30 19:19:01 2003 Subject: V2 and EPIA In-Reply-To: References: Message-ID: <200309301742.50566.randall@tdl.com> Thanks for all of your efforts, you seem to be making quick progress. I would like to try v2 out next week. Is there any documentation on the V2 build procedure? I know I sound like an idiot but what does the acronym SPD stand for? Cheers, Randall From rminnich at lanl.gov Tue Sep 30 21:44:01 2003 From: rminnich at lanl.gov (ron minnich) Date: Tue Sep 30 21:44:01 2003 Subject: V2 VIA EPIA Message-ID: OK, I've committed code that turns on shadow dram in F segment, so PIRQ will work; also committed what should be working SMBUS code in vt8231_early_smbus.c; now the fun begins. I could use advice on: - what SMBUS bytes we need to care about - what we should program the north with using those bytes. - how to do it. Which is to say, I think I know, but let's get this done in a speedy fashion. Momentum is on our side here. The EPIA will be a good demo platform. Why this sudden burst of EPIA work from me? Two reasons: - I want to encourage people to look at V2, so we need a demo system less complex than the K8 systems. - We are teaching a tutorial on linuxbios, bproc, etc. and will be doing it hands-on with a roomful of EPIAs, 2 or 3 per tutorial attendee. See: http://lacsi.lanl.gov/symposium/agenda.shtml Come if you want. You can see how we build clusters that boot in seconds. The software we're showing is the same stuff that is running on our 1024-node Pink cluster, and will run on our 1408-node K8 cluster. ron From randall at tdl.com Tue Sep 30 22:28:00 2003 From: randall at tdl.com (Randall H. Craig) Date: Tue Sep 30 22:28:00 2003 Subject: V2 VIA EPIA Build Errors In-Reply-To: References: Message-ID: <200309302052.27568.randall@tdl.com> At the end of the compilation, I get this. gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o nm -n linuxbios | sort > linuxbios.map objcopy -O binary linuxbios linuxbios.strip gcc -o buildrom /home/randall/src/linuxbios/freebios2/util/buildrom/buildrom.c ./buildrom linuxbios.strip linuxbios.rom ../../../../tg3--ide_disk.zelf 0x10000 0x20000 ../../../../tg3--ide_disk.zelf: No such file or directory make[1]: *** [linuxbios.rom] Error 2 make[1]: Leaving directory `/home/randall/src/linuxbios/freebios2/targets/via/epia/epia/fallback' make: *** [fallback-rom] Error 1 tg3--ide-disk.zelf was never built. Is this missing: from the buildrom output, tg3--ide-disk.zelf is supposed to be the payload. Any ideas? From randall at tdl.com Tue Sep 30 22:36:01 2003 From: randall at tdl.com (Randall H. Craig) Date: Tue Sep 30 22:36:01 2003 Subject: V2 VIA EPIA Build Errors In-Reply-To: <200309302052.27568.randall@tdl.com> References: <200309302052.27568.randall@tdl.com> Message-ID: <200309302059.45725.randall@tdl.com> On Tue September 30 2003 8:52 pm, Randall H. Craig wrote: > > tg3--ide-disk.zelf was never built. Is this missing: > > from the buildrom output, tg3--ide-disk.zelf is supposed to be the payload. > > Any ideas? I am guessing that this is an etherboot image. What is the pci.ids for the ethernet device? Cheers, Randall From bari at onelabs.com Tue Sep 30 23:06:00 2003 From: bari at onelabs.com (Bari Ari) Date: Tue Sep 30 23:06:00 2003 Subject: V2 and EPIA In-Reply-To: <200309301742.50566.randall@tdl.com> References: <200309301742.50566.randall@tdl.com> Message-ID: <3F7A4AE7.8050103@onelabs.com> Randall H. Craig wrote: > > I know I sound like an idiot but what does the acronym SPD stand for? serial presence detect (SPD) You can read about it here: http://www.intel.com/technology/memory/pc133sdram/spec/spdsd12b.htm http://www.simmtester.com/page/news/showpubnews.asp?num=101 Bari