From rminnich at lanl.gov Sat Feb 1 00:42:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 1 00:42:00 2003 Subject: giving the user a boot option In-Reply-To: <3E3A96C9.1020300@integraltech.com> Message-ID: Is this assuming you have booted linux, or you want to boot linux from a bootloader that you give a command line option to? I actually implemented a little mod to linux that lets you modify the command line as it boots up, if you hit (e.g.) a space bar at the right time. I found no interest in the Linux community, but it is a trivial thing to write. ron From rminnich at lanl.gov Sat Feb 1 00:57:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 1 00:57:01 2003 Subject: sourceforge cvs and wrong web page In-Reply-To: <3E3AE649.3080109@manoweb.com> Message-ID: thanks for the correction. I just tried that script the other day and it worked, did something change? ron From rminnich at lanl.gov Sat Feb 1 01:00:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 1 01:00:01 2003 Subject: keyboard enable In-Reply-To: <3E0445DC000291CA@hudson.vtr.net> Message-ID: There is and I forget it, and I'm still on travel, can someone out there help (Andrew Ip are you there) ron From aip at cwlinux.com Sat Feb 1 10:16:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sat Feb 1 10:16:01 2003 Subject: keyboard enable In-Reply-To: <3E0445DC000291CA@hudson.vtr.net>; from gonzapata@vtr.net on Fri, Jan 31, 2003 at 08:36:40PM -0300 References: <3E0445DC000291CA@hudson.vtr.net> Message-ID: <20030201233303.A18623@mail.cwlinux.com> Gonzalo, > Hi, I wanna know if there is a parameter for the config file of linuxbios > to active the keyboard, everything works fine except that i don't have keyboard. I think it is enabled by default. However, if you have the following, then keyboard will be disabled. option NO_KEYBOARD=1 -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From aip at cwlinux.com Sat Feb 1 10:19:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sat Feb 1 10:19:00 2003 Subject: pc chips 810 In-Reply-To: <3E3A537B.5010504@manoweb.com>; from Alessio Sangalli on Fri, Jan 31, 2003 at 11:44:11AM +0100 References: <3E3984C5.4090002@manoweb.com> <20030131082042.B3877@mail.cwlinux.com> <3E3984C5.4090002@manoweb.com> <3E3A537B.5010504@manoweb.com> Message-ID: <20030201233507.B18623@mail.cwlinux.com> > # > # General setup > # > CONFIG_NET=y > CONFIG_PCI=y > # CONFIG_PCI_GOBIOS is not set > # CONFIG_PCI_GODIRECT is not set > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_ISA=y > CONFIG_PCI_NAMES=y You may want to change pci probing to direct only. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From steve at nexpath.com Sat Feb 1 14:38:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sat Feb 1 14:38:00 2003 Subject: giving the user a boot option In-Reply-To: <20030131132537.B66184-100000@www.missl.cs.umd.edu> Message-ID: > > > Well, u could put grub or lilo on flash, either of them works with > > > linuxbios. The space may be big tight though. > > > > Maybe I'm missing something here, but I don't understand how > you do this. > > Grub and lilo require a legacy BIOS. > > LinuxBIOS + ADLO + BOCHS BIOS + ( LILO | GRUB ) > > Adam Seems like a lot of complexity, and I am kind of a zealot against real mode. Has anyone considered writing the disk/video interface for Grub, to replace the BIOS calls? Looking at the Grub code the BIOS calls seem pretty isolated, and most of the code (I think) is already in linuxbios in some form or another (although vga is there for only a couple of boards right now). I for one would like a general bootloader, and Grub is pretty neat. -Steve From alesan at manoweb.com Sat Feb 1 16:14:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sat Feb 1 16:14:00 2003 Subject: pc chips 810 In-Reply-To: <3E3984C5.4090002@manoweb.com> References: <3E3984C5.4090002@manoweb.com> <20030131082042.B3877@mail.cwlinux.com> <3E3984C5.4090002@manoweb.com> <3E3A537B.5010504@manoweb.com> <20030201233507.B18623@mail.cwlinux.com> Message-ID: <3E3C3D0B.8020205@manoweb.com> Andrew Ip wrote: > You may want to change pci probing to direct only. Thank you I've set this and a correct root parameter on mkelfimage and now it works!!! thank you bye as From alesan at manoweb.com Sat Feb 1 16:26:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sat Feb 1 16:26:01 2003 Subject: how can linuxbios load an image from ide Message-ID: <3E3C3FC6.3090504@manoweb.com> Hi. Now my pcchips 810 is working with IDE boot. I've used the ftp.cwlinux.com rom images and mkelfimage to generate a suitable kernel. It was put on the first partition of the hdd with 'kernel' as a name. I would like to understand how can linuxbios, find a kernel image on a ext2 filesystem and load it? What if I user reiserfs or XFS? About cwlinux rom: do you think it's possible to gain some more seconds on the boot if I build a custom image of the ROM, leaving out unnecessary options? About sis730 framebuffer: is it possible to set a resolution like 1280x768? thank you as From alesan at manoweb.com Sat Feb 1 16:38:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sat Feb 1 16:38:01 2003 Subject: acpi shutdown + cool logo + nvram Message-ID: <3E3C42A9.60508@manoweb.com> Is it possible to shutdown the pc with an actual powerdown with linuxbios on a pcchips810? I've flashed linuxbios from cwlinux.com (I boot from an IDE hard disk) and I've enabled acpi on the kernel. However the command 'halt' didn't shutdown the machine. I had to keep pressed the power switch few seconds for it to turn off. Is it allowed to insert a custom logo, instead of the tux one which is displayed on the first seconds of the boot? Which file is the definition of the logo, and is it the same format of the kernel? Is it possible to set the nvram values to have the pc being powered up at a specific time using nvram-wakeup or similar programs? Sorry for the massive amount of questions but linuxbios is *very* cool! bye as From adam at cfar.umd.edu Sat Feb 1 16:52:01 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Sat Feb 1 16:52:01 2003 Subject: giving the user a boot option In-Reply-To: Message-ID: <20030201172033.V67841-100000@www.missl.cs.umd.edu> > > LinuxBIOS + ADLO + BOCHS BIOS + ( LILO | GRUB ) > Seems like a lot of complexity, and I am kind of a zealot against real mode. > Has anyone considered writing the disk/video interface for Grub, to replace > the BIOS calls? Looking at the Grub code the BIOS calls seem pretty > isolated, and most of the code (I think) is already in linuxbios in some > form or another (although vga is there for only a couple of boards right > now). I for one would like a general bootloader, and Grub is pretty neat. Yes. I agree it is complex. We have given it fairly a bit of though and if you want to support legacy applications then it is pretty much about the only way to do this. Sure we could go LinuxBIOS version of grub, but unless you add "legacy application support" it won't help you with booting anything else other than linux. So while it may fit with your particular problem, usefullness of such hack won't be as big as one could expect. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From alesan at manoweb.com Sat Feb 1 16:53:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sat Feb 1 16:53:00 2003 Subject: acpi shutdown + cool logo + nvram In-Reply-To: <3E3C42A9.60508@manoweb.com> References: <3E3C42A9.60508@manoweb.com> Message-ID: <3E3C460C.5090809@manoweb.com> Alessio Sangalli wrote: > Is it allowed to insert a custom logo, instead of the tux one which is > displayed on the first seconds of the boot? Which file is the definition > of the logo, and is it the same format of the kernel? pergaps I've found it, grepping the source: on pcchips787.config I read: # # 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 should be copied to the build directory # addaction linuxbios.rom dd if=$(TOP)/src/pc80/linuxbioslogo.pcx of=linuxbios.rom bs=1 seek=4 conv=notrunc; addaction linuxbios.rom perl -e '@a=stat "$(TOP)/src/pc80/linuxbioslogo.pcx";$$a=pack("L",$$a[7]); print $$a' | dd of=l inuxbios.rom bs=1 conv=notrunc are there particular restrictions on the image properties? width/height, bit depth...? bye thank you as From steve at nexpath.com Sat Feb 1 17:41:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sat Feb 1 17:41:00 2003 Subject: acpi shutdown + cool logo + nvram In-Reply-To: <3E3C460C.5090809@manoweb.com> Message-ID: > are there particular restrictions on the image properties? width/height, > bit depth...? > > bye > thank you > as The logo file is a pcx file, indexed color (256 colors) 640 x400, depth 8bits. I created it with gimp, but I need to try and remember how. The one thing I remember is that only the first 16 entries in the palette are used. So if you have an image with a larger palette you have to convert it and gimp will do it. But I can't seem to remember how I did it off hand... I will think about it and post a note when I remember or maybe some else can rediscover it. -Steve From stuge-linuxbios at cdy.org Sat Feb 1 23:06:01 2003 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sat Feb 1 23:06:01 2003 Subject: giving the user a boot option In-Reply-To: References: <20030131132537.B66184-100000@www.missl.cs.umd.edu> Message-ID: <20030202042200.GA32112@foo.birdnet.se> On Sat, Feb 01, 2003 at 12:10:25PM -0800, Steve M. Gehlbach wrote: > > > Maybe I'm missing something here, but I don't understand how you do > > > this. > > > Grub and lilo require a legacy BIOS. > > > > LinuxBIOS + ADLO + BOCHS BIOS + ( LILO | GRUB ) > > Seems like a lot of complexity, and I am kind of a zealot against real mode. > Has anyone considered writing the disk/video interface for Grub, to replace > the BIOS calls? The tiara project has done this. Made a version of grub that didn't need the legacy BIOS that is. http://sourceforge.net/projects/utcboot/ //Peter From rminnich at lanl.gov Sat Feb 1 23:23:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 1 23:23:01 2003 Subject: pc chips 810 In-Reply-To: <3E3C3D0B.8020205@manoweb.com> Message-ID: can you write your experiences up for us? I will put them on the web page if they are helpful to others. ron From alesan at manoweb.com Sun Feb 2 06:34:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 06:34:01 2003 Subject: pc chips 810 In-Reply-To: References: Message-ID: <3E3D0692.1040905@manoweb.com> Ronald G. Minnich wrote: > can you write your experiences up for us? I will put them on the web page > if they are helpful to others. sure, I will. I would like to be able to build my own flash image, however, and give instructions on how change the logo etc. bye, as From alesan at manoweb.com Sun Feb 2 09:57:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 09:57:00 2003 Subject: kernel config for linuxbios Message-ID: <3E3D3623.9050207@manoweb.com> Hi. I've examined kernel patches freebios/src/kernel_patches and the patched kernel 2.4.20 avaiable at cwlinux.com. I've noticed that there is a way to configure linuxbios support and linuxbios power management if I apply linux-2.4.19-sis.patch to a vanilla 2.4.19. On the other hand, cwlinux's kernel has some great patches (like preemptive kernel) and a 2.4.20 version, but no "linuxbios support". Which one should I use? perhaps it's only a matter to apply linux-2.4.19-sis.patch to a 2.4.20 kernel (some work is needed) to have the best kernel for linuxbios. bye thank you as From russell at abc9986.demon.co.uk Sun Feb 2 10:39:01 2003 From: russell at abc9986.demon.co.uk (russell at abc9986.demon.co.uk) Date: Sun Feb 2 10:39:01 2003 Subject: Via EPIA Message-ID: I've spent tha last couple of days working on an EPIA motherboard. I currently have a build that will warm boot provided the initial boot was with the original bios. On a cold boot the kernel crashed at diffrent stages. I see some errors relating to the ram setup, and Linuxbios is only finding 64Meg I have 256meg! Could someone please tell me what i need to do to get the RAM configured correctly. Thanks Russell From alesan at manoweb.com Sun Feb 2 11:29:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 11:29:01 2003 Subject: kernel config for linuxbios In-Reply-To: <3E3D3623.9050207@manoweb.com> References: <3E3D3623.9050207@manoweb.com> Message-ID: <3E3D4BC0.2010404@manoweb.com> Alessio Sangalli wrote: > Hi. I've examined kernel patches freebios/src/kernel_patches and the > patched kernel 2.4.20 avaiable at cwlinux.com. a deeper analisys showed me that both vanilla 2.4.19 and 2.4.20 don't have a well supported sis framebuffer; however, 2.4.19 with sis patch and 2.4.20-cwlinux have all the files to support it. However I can't find a configuration key for the linuxbios powermanagement on 2.4.20-cwlinux. Is it enabled by default? bye & thank you as From alesan at manoweb.com Sun Feb 2 13:41:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 13:41:00 2003 Subject: treoubles building a linuxbios rom Message-ID: <3E3D6A8E.9030206@manoweb.com> Hi. I'm trying to configure and build a linuxbios rom to boot from IDE hard drive on a pcchips 810 motherboard. I'm using kernel 2.4.20-cwlinux with the attached configuration; the sources are located in /usr/src/linux I've checked out the latest freebios from sf.net; I also wrote the attached config file (why isn't the cgi script on the web pages working?). Pay attention this is my very first config file so it will be full of mistakes and omissions, I can't do any better by now. when I give the following command I get the output: # python NLBConfig.py pcchips.config ~/linuxbios/freebios/ Creating directory /root/linuxbios/build/pcchips Will place Makefile, crt0.S, etc. in /root/linuxbios/build/pcchips Process config file: /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/Config Now Process the i386 base files Added ldscript init file: /root/linuxbios/freebios/src/arch/i386/config/ldscript.base Process config file: /root/linuxbios/freebios/src/config/Config Process config file: /root/linuxbios/freebios/src/lib/Config Process config file: /root/linuxbios/freebios/src/boot/Config Process config file: /root/linuxbios/freebios/src/rom/Config Process config file: /root/linuxbios/freebios/src/pc80/Config Process config file: /root/linuxbios/freebios/src/pc80/ide/Config Process config file: /root/linuxbios/freebios/src/arch/i386/Config Process config file: /root/linuxbios/freebios/src/arch/i386/boot/Config Process config file: /root/linuxbios/freebios/src/arch/i386/lib/Config ===> Warning: /root/linuxbios/build/pcchips.config:6 /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/Config:1 /root/linuxbios/freebios/src/arch/i386/config/make.base:47 /root/linuxbios/freebios/src/arch/i386/Config:2 /root/linuxbios/freebios/src/arch/i386/lib/Config:11: makerule for target 'c_start.s' is replacing previous defintion in file /root/linuxbios/freebios/src/arch/i386/lib/Config Process config file: /root/linuxbios/freebios/src/arch/i386/smp/Config Added mainboard init file: cpu/i386/entry16.inc Added mainboard init file: cpu/i386/entry32.inc Added ldscript init file: /root/linuxbios/freebios/src/cpu/i386/entry16.lds Added ldscript init file: /root/linuxbios/freebios/src/cpu/i386/entry32.lds Added mainboard init file: superio/sis/950/setup_serial.inc Added mainboard init file: pc80/serial.inc Added mainboard init file: arch/i386/lib/console.inc Added mainboard init file: cpu/k7/earlymtrr.inc Process config file: /root/linuxbios/freebios/src/northsouthbridge/sis/730/Config ===> Warning: /root/linuxbios/build/pcchips.config:6 /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/Config:12 /root/linuxbios/freebios/src/northsouthbridge/sis/730/Config:1: Invalid option specifcation: SIS730 assuming you meant SIS730=1 Added ram init file: northsouthbridge/sis/730/raminit.inc Process config file: /root/linuxbios/freebios/src/cpu/p5/Config Process config file: /root/linuxbios/freebios/src/cpu/p6/Config Process config file: /root/linuxbios/freebios/src/cpu/k7/Config Process config file: /root/linuxbios/freebios/src/cpu/k7/Config Creating /root/linuxbios/build/pcchips/Makefile.settings Creating /root/linuxbios/build/pcchips/Makefile Creating /root/linuxbios/build/pcchips/crt0_includes.h Creating /root/linuxbios/build/pcchips/nsuperio.c Creating /root/linuxbios/build/pcchips/LinuxBIOSDoc.config I have many warnings. However a pcchips directory is created and it contains: # ls -R pcchips pcchips: LinuxBIOSDoc.config Makefile Makefile.settings crt0_includes.h nsuperio.c I enter the dir and give a 'make' command: # make Makefile:480: warning: overriding commands for target `c_start.o' Makefile:465: warning: ignoring old commands for target `c_start.o' Makefile:513: warning: overriding commands for target `keyboard.o' Makefile:417: warning: ignoring old commands for target `keyboard.o' Makefile:534: warning: overriding commands for target `cpufixup.o' Makefile:531: warning: ignoring old commands for target `cpufixup.o' cp /root/linuxbios/freebios/src/arch/i386/config/crt0.base crt0.S gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s crt0.s: Assembler messages: crt0.s:1554: Warning: indirect jmp without `*' gcc ... -o ide_fill_inbuf.o /root/linuxbios/freebios/src/rom/ide_fill_inbuf.c /root/linuxbios/freebios/src/rom/ide_fill_inbuf.c: In function `ide_read': /root/linuxbios/freebios/src/rom/ide_fill_inbuf.c:60: warning: unused variable `j' /root/linuxbios/freebios/src/rom/ide_fill_inbuf.c:60: warning: unused variable `i' /root/linuxbios/freebios/src/rom/ide_fill_inbuf.c:59: warning: unused variable `result' gcc ... -o linuxbiosmain.o /root/linuxbios/freebios/src/lib/linuxbiosmain.c gcc ... -o linuxpci.o /root/linuxbios/freebios/src/lib/linuxpci.c /root/linuxbios/freebios/src/lib/linuxpci.c:13: warning: `rcsid' defined but not used gcc ... -o newpci.o /root/linuxbios/freebios/src/lib/newpci.c /root/linuxbios/freebios/src/lib/newpci.c:14: warning: `rcsid' defined but not used gcc ... -o clog2.o /root/linuxbios/freebios/src/lib/clog2.c gcc ... -o printk.o /root/linuxbios/freebios/src/lib/printk.c /root/linuxbios/freebios/src/lib/printk.c:9: warning: `rcsid' defined but not used gcc ... -o serial_subr.o /root/linuxbios/freebios/src/lib/serial_subr.c /root/linuxbios/freebios/src/lib/serial_subr.c:2: warning: `rcsid' defined but not used gcc ... -o video_subr.o /root/linuxbios/freebios/src/lib/video_subr.c gcc ... -o subr.o /root/linuxbios/freebios/src/lib/subr.c /root/linuxbios/freebios/src/lib/subr.c:8: warning: `rcsid' defined but not used gcc ... -o vsprintf.o /root/linuxbios/freebios/src/lib/vsprintf.c /root/linuxbios/freebios/src/lib/vsprintf.c:13: warning: `rcsid' defined but not used gcc ... -o memset.o /root/linuxbios/freebios/src/lib/memset.c gcc ... -o memcpy.o /root/linuxbios/freebios/src/lib/memcpy.c gcc ... -o memcmp.o /root/linuxbios/freebios/src/lib/memcmp.c gcc ... -o malloc.o /root/linuxbios/freebios/src/lib/malloc.c gcc ... -o do_inflate.o /root/linuxbios/freebios/src/lib/do_inflate.c In file included from /root/linuxbios/freebios/src/lib/do_inflate.c:67: /root/linuxbios/freebios/src/lib/inflate.c: In function `gunzip': /root/linuxbios/freebios/src/lib/inflate.c:1100: warning: value computed is not used /root/linuxbios/freebios/src/lib/inflate.c:1101: warning: value computed is not used /root/linuxbios/freebios/src/lib/inflate.c:1102: warning: value computed is not used gcc ... -o delay.o /root/linuxbios/freebios/src/lib/delay.c gcc ... -o compute_ip_checksum.o /root/linuxbios/freebios/src/lib/compute_ip_checksum.c gcc ... -o version.o /root/linuxbios/freebios/src/lib/version.c gcc ... -o keyboard.o /root/linuxbios/freebios/src/pc80/keyboard.c /root/linuxbios/freebios/src/pc80/keyboard.c:2: warning: `rcsid' defined but not used gcc ... -o mc146818rtc.o /root/linuxbios/freebios/src/pc80/mc146818rtc.c /root/linuxbios/freebios/src/pc80/mc146818rtc.c: In function `rtc_init': /root/linuxbios/freebios/src/pc80/mc146818rtc.c:139: warning: unused variable `i' gcc ... -o isa-dma.o /root/linuxbios/freebios/src/pc80/isa-dma.c gcc ... -o i8259.o /root/linuxbios/freebios/src/pc80/i8259.c gcc ... -o beep.o /root/linuxbios/freebios/src/pc80/beep.c gcc ... -o vga_load_regs.o /root/linuxbios/freebios/src/pc80/vga_load_regs.c gcc ... -o font_8x16.o /root/linuxbios/freebios/src/pc80/font_8x16.c gcc ... -o vga_set_mode.o /root/linuxbios/freebios/src/pc80/vga_set_mode.c gcc ... -o vga_load_pcx.o /root/linuxbios/freebios/src/pc80/vga_load_pcx.c gcc ... -o ide.o /root/linuxbios/freebios/src/pc80/ide/ide.c gcc ... -o boot.o /root/linuxbios/freebios/src/arch/i386/boot/boot.c gcc ... -o linuxbios_table.o /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c: In function `lb_strings': /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c:122: warning: assignment from incompatible pointer type /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c: In function `write_linuxbios_table': /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c:230: warning: unused variable `rec_src' /root/linuxbios/freebios/src/arch/i386/boot/linuxbios_table.c:230: warning: unused variable `rec_dest' gcc ... -o i386_subr.o /root/linuxbios/freebios/src/arch/i386/lib/i386_subr.c gcc ... -o params.o /root/linuxbios/freebios/src/arch/i386/lib/params.c /root/linuxbios/freebios/src/arch/i386/lib/params.c:30: warning: `rcsid' defined but not used gcc ... -o hardwaremain.o /root/linuxbios/freebios/src/arch/i386/lib/hardwaremain.c /root/linuxbios/freebios/src/arch/i386/lib/hardwaremain.c:32: warning: `rcsid' defined but not used gcc ... -o c_start.o c_start.s c_start.s: Assembler messages: c_start.s:330: Warning: using `%eax' instead of `%ax' due to `l' suffix gcc ... -o pirq_routing.o /root/linuxbios/freebios/src/arch/i386/lib/pirq_routing.c gcc ... -o southbridge.o /root/linuxbios/freebios/src/northsouthbridge/sis/730/southbridge.c /root/linuxbios/freebios/src/northsouthbridge/sis/730/southbridge.c: In function `ide_fixup': /root/linuxbios/freebios/src/northsouthbridge/sis/730/southbridge.c:92: warning: unused variable `delay' /root/linuxbios/freebios/src/northsouthbridge/sis/730/southbridge.c: At top level: /root/linuxbios/freebios/src/northsouthbridge/sis/730/southbridge.c:26: warning: `rcsid' defined but not used gcc ... -o northbridge.o /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c: In function `sizeram': /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c:128: warning: return from incompatible pointer type /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c: In function `framebuffer_on': /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c:138: warning: `return' with a value, in function returning void /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c: At top level: /root/linuxbios/freebios/src/northsouthbridge/sis/730/northbridge.c:25: warning: `rcsid' defined but not used gcc ... -o superio_sis_950.o /root/linuxbios/freebios/src/superio/sis/950/superio.c /root/linuxbios/freebios/src/superio/sis/950/superio.c:2: warning: `rcsid' defined but not used gcc ... -o nsuperio.o nsuperio.c gcc ... -o mainboard.o /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/mainboard.c gcc ... -o irq_tables.o /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:21: warning: excess elements in array initializer /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:21: warning: (near initialization for `intel_irq_routing_table.slots') /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:23: warning: excess elements in array initializer /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:23: warning: (near initialization for `intel_irq_routing_table.slots') /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:25: warning: excess elements in array initializer /root/linuxbios/freebios/src/mainboard/pcchips/m810lmr/irq_tables.c:25: warning: (near initialization for `intel_irq_routing_table.slots') gcc ... -o cpuid.o /root/linuxbios/freebios/src/cpu/p5/cpuid.c /root/linuxbios/freebios/src/cpu/p5/cpuid.c:3: warning: `rcsid' defined but not used gcc ... -o microcode.o /root/linuxbios/freebios/src/cpu/p6/microcode.c /root/linuxbios/freebios/src/cpu/p6/microcode.c:7: warning: `rcsid' defined but not used gcc ... -o mtrr.o /root/linuxbios/freebios/src/cpu/p6/mtrr.c /root/linuxbios/freebios/src/cpu/p6/mtrr.c: In function `set_var_mtrr': /root/linuxbios/freebios/src/cpu/p6/mtrr.c:132: warning: unused variable `tmp' /root/linuxbios/freebios/src/cpu/p6/mtrr.c: At top level: /root/linuxbios/freebios/src/cpu/p6/mtrr.c:29: warning: `rcsid' defined but not used gcc ... -o l2_cache.o /root/linuxbios/freebios/src/cpu/p6/l2_cache.c /root/linuxbios/freebios/src/cpu/p6/l2_cache.c:33: warning: `rcsid' defined but not used gcc ... -o cpufixup.o /root/linuxbios/freebios/src/cpu/k7/cpufixup.c rm -f linuxbios.a ar cr linuxbios.a crt0.o linuxbiosmain.o linuxpci.o newpci.o clog2.o printk.o serial_subr.o video_subr.o subr.o vsprintf.o memset.o memcpy.o memcmp.o malloc.o do_inflate.o delay.o compute_ip_checksum.o version.o keyboard.o mc146818rtc.o isa-dma.o i8259.o beep.o vga_load_regs.o font_8x16.o vga_set_mode.o vga_load_pcx.o ide.o boot.o linuxbios_table.o i386_subr.o params.o hardwaremain.o c_start.o pirq_routing.o c_start.o southbridge.o northbridge.o superio_sis_950.o nsuperio.o mainboard.o irq_tables.o keyboard.o cpuid.o microcode.o mtrr.o l2_cache.o cpufixup.o cpufixup.o gcc -nostdlib -r -o linuxbios_c.o c_start.o ide_fill_inbuf.o linuxbios.a /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/libgcc.a perl -e 'foreach $var (split(" ", $ENV{VARIABLES})) { if ($ENV{$var} =~ m/^(0x[0-9a-fA-F]+|0[0-7]+|[0-9]+)$/) { print "$var = $ENV{$var};\n"; }}' > ldoptions gcc -nostdlib -nostartfiles -static -o linuxbios_c -T /root/linuxbios/freebios/src/config/linuxbios_c.ld linuxbios_c.o linuxbios_c.o: In function `mdelay': linuxbios_c.o(.text+0xa99): undefined reference to `udelay' collect2: ld returned 1 exit status make: *** [linuxbios_c] Error 1 I'm not able to build a rom successfully :( bye as -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios-2.4.20-cwlinux.config URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pcchips.config URL: From steve at nexpath.com Sun Feb 2 14:06:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sun Feb 2 14:06:01 2003 Subject: treoubles building a linuxbios rom In-Reply-To: <3E3D6A8E.9030206@manoweb.com> Message-ID: > gcc -nostdlib -nostartfiles -static -o linuxbios_c -T > /root/linuxbios/freebios/src/config/linuxbios_c.ld linuxbios_c.o > linuxbios_c.o: In function `mdelay': > linuxbios_c.o(.text+0xa99): undefined reference to `udelay' > collect2: ld returned 1 exit status > make: *** [linuxbios_c] Error 1 > > I'm not able to build a rom successfully :( > > as Try adding to the config: option CONFIG_UDELAY_TSC=1 and see if this won't correct the undefined reference to udelay. -Steve From alesan at manoweb.com Sun Feb 2 14:15:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 14:15:00 2003 Subject: treoubles building a linuxbios rom In-Reply-To: References: Message-ID: <3E3D72A3.1070702@manoweb.com> Steve M. Gehlbach wrote: > Try adding to the config: > > option CONFIG_UDELAY_TSC=1 > > and see if this won't correct the undefined reference to udelay. thank you! it works now. I have a 'romimage' file which I think it's the one I should flash. I'm not sure, however, about the correctness of the options there in the config file. Where can I read the actual documentation of the various options? bye thank you as From steve at nexpath.com Sun Feb 2 15:18:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sun Feb 2 15:18:00 2003 Subject: treoubles building a linuxbios rom In-Reply-To: <3E3D72A3.1070702@manoweb.com> Message-ID: > I'm not sure, however, about the correctness of the options there in the > config file. Where can I read the actual documentation of the various > options? > > as The documentation on config options is pretty sparce, mostly in the code itself. Look at the other config files (in freebios/src/mainboard/.../config.example and also in freebios/util/config/*), and of course, read the C code. I use a find/grep alias a lot to find config options and how they are used (alias findit='find . | xargs grep 2>/dev/null'). We need more documentation for linuxbios; right now it is not a project where you can just type "make" and flash a rom without digging into the code a little (IMHO). The best bet if you don't want to spend some time on it, is to buy a board from cwlinux. And, of course, if you come up to speed and want to help out, I'm sure Ron would welcome a howto.html file. -Steve From steve at nexpath.com Sun Feb 2 15:44:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sun Feb 2 15:44:00 2003 Subject: giving the user a boot option In-Reply-To: <20030201172033.V67841-100000@www.missl.cs.umd.edu> Message-ID: > Yes. I agree it is complex. We have given it fairly a bit of though and if > you want to support legacy applications then it is pretty much about the > only way to do this. > > Sure we could go LinuxBIOS version of grub, but unless you add "legacy > application support" it won't help you with booting anything else other > than linux. So while it may fit with your particular problem, usefullness > of such hack won't be as big as one could expect. > > -- > Adam Sulmicki Well, I certainly did not mean to imply ADLO or BOCHS was complex unnecessarily. These are brilliant developments that greatly advance the capabilities of the open source community. My point was that I am only focused on booting linux, and so the legacy BIOS is just flash baggage after linux gets going. Grub offers some booting flexibility that I need, and since it is C code, also is more easily customized for some other things I need to do during boot (embedded application). So the interest in a non-BIOS adaptation (I prefer that word to "hack"). It doesn't really matter to me if it has wide interest or not, as long as it solves my purposes and doesn't take too long to do and isn't really stupid for some reason or other. I just wanted to see if it was already done or there was a giant flaw in my thinking. Based on a previous post, perhaps the tiara project may have already done it, so I am going to check that out. Thanks for your excellent work on ADLO and mods to BOCHS-BIOS. -Steve From alesan at manoweb.com Sun Feb 2 16:15:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 16:15:00 2003 Subject: treoubles building a linuxbios rom In-Reply-To: References: Message-ID: <3E3D8ED1.1070206@manoweb.com> Steve M. Gehlbach wrote: > The documentation on config options is pretty sparce, mostly in the code > itself. Look at the other config files (in ok > freebios/src/mainboard/.../config.example and also in > freebios/util/config/*), and of course, read the C code. I use a > find/grep > alias a lot to find config options and how they are used (alias > findit='find > . | xargs grep 2>/dev/null'). isn't it the same "grep -r XXX ."?! > We need more documentation for linuxbios; right now it is not a project > where you can just type "make" and flash a rom without digging into > the code > a little (IMHO). I understand. In the future, something like kernel's or lirc's config menus would be great. WHy isn't the web-configuration tool working? Is it an outdated tool or do you only have to correctly configure cgi access? > The best bet if you don't want to spend some time on it, > is to buy a board from cwlinux. And, of course, if you come up to > speed and > want to help out, I'm sure Ron would welcome a howto.html file. my company had my request to buy few motherboard from cwlinux. However they like to write a lot of papers and to prepare budget reports for anything. I've already used cwlinux great ROM images, and I have a pcchips motherboard bought by myself in an exibition working with linuxbios. I'm very interested in this project and I would like to understand it and contribute, if possible. Now I will dig a bit into the code and configuration samples. When I'll have enough knowledge I will try some experiments and I will write down some web pages on how to do it. Something like my other 'howto' about lirc ( http://www.manoweb.com/alesan/lirc ). I like good, detailed documentation and I hope to write something like this for my experience with linuxbios. I invite everybody, if they can, to answer to the many questions I've written in the list. Each piece of information I can gather will find its way on the howto...! bye! as From steve at nexpath.com Sun Feb 2 17:00:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sun Feb 2 17:00:01 2003 Subject: troubles building a linuxbios rom In-Reply-To: <3E3D8ED1.1070206@manoweb.com> Message-ID: > > findit='find > > . | xargs grep 2>/dev/null'). > > isn't it the same "grep -r XXX ."?! Yup, this is the same (actually better). I wasn't aware of the grep -r switch; it is not on all unices (eg, SunOS, Unixware). I'm kind of an old Unix person and only learn the newer ways when someone points it out. Thanks for the tip. > WHy isn't the web-configuration tool working? Is it an outdated tool or > do you only have to correctly configure cgi access? Ron can answer better but I think no one has gotten around to it. > Each piece of information I can gather will find > its way on the howto...! > Great! -Steve From alesan at manoweb.com Sun Feb 2 17:48:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Sun Feb 2 17:48:01 2003 Subject: troubles building a linuxbios rom In-Reply-To: References: Message-ID: <3E3DA476.7000902@manoweb.com> Steve M. Gehlbach wrote: > Yup, this is the same (actually better). I wasn't aware of the grep -r > switch; it is not on all unices (eg, SunOS, Unixware). I'm kind of an :) bye as From rminnich at lanl.gov Sun Feb 2 18:13:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun Feb 2 18:13:00 2003 Subject: kernel config for linuxbios In-Reply-To: <3E3D3623.9050207@manoweb.com> Message-ID: we need to get our minor patches into the cwlinux tree. These minor patches support power off etc. for sis chips. ron From rminnich at lanl.gov Sun Feb 2 18:16:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun Feb 2 18:16:00 2003 Subject: treoubles building a linuxbios rom In-Reply-To: Message-ID: On Sun, 2 Feb 2003, Steve M. Gehlbach wrote: > option CONFIG_UDELAY_TSC=1 then we need to see which mainboard config is incorrect. Sorry about this. ron From rminnich at lanl.gov Sun Feb 2 18:17:59 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun Feb 2 18:17:59 2003 Subject: treoubles building a linuxbios rom In-Reply-To: <3E3D8ED1.1070206@manoweb.com> Message-ID: On Sun, 2 Feb 2003, Alessio Sangalli wrote: > WHy isn't the web-configuration tool working? Is it an outdated tool or > do you only have to correctly configure cgi access? nobody had time to make it go. We're shorthanded ... ron From spyro at f2s.com Sun Feb 2 19:23:01 2003 From: spyro at f2s.com (Ian Molton) Date: Sun Feb 2 19:23:01 2003 Subject: PC chips SIS video. Message-ID: <20030203003935.069ba26f.spyro@f2s.com> Hi. I know this isnt quite the right place to ask, but the PC chips mobos seem popular with linuxbios people. Can anyone tell me how to get the VGA chip used on these boards (SiS 6235) to work under X-windows? The 6236 seems to be supported, but almost nothing is mentioned of the 6235. I have gotten 8 bit colour to work using VESA but need truecolour for video playback. HELP! :-) (feel free to reply offlist so this doesnt stray off topic :-) From gonzapata at vtr.net Sun Feb 2 20:53:01 2003 From: gonzapata at vtr.net (gonzapata at vtr.net) Date: Sun Feb 2 20:53:01 2003 Subject: root command line Message-ID: <3E0445DC0002A32E@hudson.vtr.net> Hi. i have problems trying to root the doc, on the config file for the python program i put the "root=/dev/nftla1 console=ttyS0,115200 console=tty0 single" command line i made all the images to burn on the doc and when i try to boot with that file system (on nftla1) kernel pacnic appears cuz is trying to root on nftlA1 but i configured for the "nftla1". i have the devices for the both nftlA and nftla but it does works. I look at the Makefile, Makefile.setting and the linuxbiosmain.c and i think is all right. I couldn't find where is the cmdline that is trying to root the kernel. HELP!!!!! i'm going crazy... i really don't know where to look to change the root parameter to root from nftla1 (where is the filesystem that i'm trying to boot) .... Thanx Gonzalo "Going crazy" Zapata. From steve at nexpath.com Sun Feb 2 23:01:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Sun Feb 2 23:01:01 2003 Subject: cape shutdown + cool logo + nvram In-Reply-To: Message-ID: > > are there particular restrictions on the image properties? width/height, > > bit depth...? > > > > bye > > thank you > > as > > The logo file is a pcx file, indexed color (256 colors) 640 x400, depth > 8bits. I created it with gimp, but I need to try and remember > how. The one > thing I remember is that only the first 16 entries in the palette > are used. I looked into this a little further and I guess I should have made some notes. But it appears that the file was created with Adobe Photoshop rather than gimp, but I don't recall exactly why. At any rate, the decoding is setup to use a palette of 256, but with only 16 colors used since there are only 4 bit planes for this graphics mode. However, there appears to be a difference of opinion about which end of the palette to use, Photoshop uses the upper end, and gimp appears to use the lower end (when converted to 16 colors). I wrote the code to use the upper end of the palette (Photoshop). I think the code should work with either, so either gimp or Photoshop could be used. I'll try to put the changes in the code in the next few days. In gimp, the menu is image->mode->indexed and then set the palette to 16 colors. Then save the file as .pcx. This won't display until I fix the code, though. For now, you can load the result into Photoshop, convert to RGB, then convert back to index color (select custom palette), and save it, and this should display. The .pcx file standard is at http://www.whisqu.se/per/docs/graphics57.htm. -Steve From aip at cwlinux.com Mon Feb 3 01:41:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 3 01:41:01 2003 Subject: Via EPIA In-Reply-To: ; from russell@abc9986.demon.co.uk on Sun, Feb 02, 2003 at 03:55:43PM +0000 References: Message-ID: <20030203145801.A3839@mail.cwlinux.com> Russell, > On a cold boot the kernel crashed at diffrent stages. > I see some errors relating to the ram setup, and Linuxbios is only finding 64Meg I have 256meg! > Could someone please tell me what i need to do to get the RAM configured correctly. I think it is a bug. I'll take a look. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From aip at cwlinux.com Mon Feb 3 01:44:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 3 01:44:01 2003 Subject: kernel config for linuxbios In-Reply-To: <3E3D3623.9050207@manoweb.com>; from Alessio Sangalli on Sun, Feb 02, 2003 at 04:15:47PM +0100 References: <3E3D3623.9050207@manoweb.com> Message-ID: <20030203150001.B3839@mail.cwlinux.com> > On the other hand, cwlinux's kernel has some great patches (like > preemptive kernel) and a 2.4.20 version, but no "linuxbios support". kernel-source-linuxbios-2.4.20-CWLINUX_1.i386.rpm should contain sis patch 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. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From alesan at manoweb.com Mon Feb 3 03:33:00 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Mon Feb 3 03:33:00 2003 Subject: kernel config for linuxbios In-Reply-To: <3E3D3623.9050207@manoweb.com> References: <3E3D3623.9050207@manoweb.com> <20030203150001.B3839@mail.cwlinux.com> Message-ID: <3E3E2D90.30105@manoweb.com> Andrew Ip wrote: > >On the other hand, cwlinux's kernel has some great patches (like > >preemptive kernel) and a 2.4.20 version, but no "linuxbios support". > > kernel-source-linuxbios-2.4.20-CWLINUX_1.i386.rpm should contain sis patch > already. Yes I have that exact file; I've compared the directory entries for the sis video framebuffer and I saw it was patched; however, in linux-2.4.19-linuxbios there is a specific menu' entry for linuxbios support: Sound ---> USB support ---> Bluetooth support ---> Kernel hacking ---> LinuxBIOS ---> --- Load an Alternate Configuration File Save Configuration to an Alternate File while in 2.4.20-cwlinux I can't find it. I was wondering if it was enabled by default. That menu, in 2.4.19-linuxbios contains: <*> LinuxBIOS Support (NEW) Linuxbios Options ---> and Linuxbios options is: [*] Linuxbios Power Management support? (NEW) [*] S SIS 503 support? (NEW) [ ] P PIIX4E support? (NEW) bye! thank you as -- How to build a lirc receiver http://www.manoweb.com/alesan/lirc From prl-linuxbios at sychron.com Mon Feb 3 08:19:00 2003 From: prl-linuxbios at sychron.com (prl-linuxbios at sychron.com) Date: Mon Feb 3 08:19:00 2003 Subject: giving the user a boot option In-Reply-To: Your message of "Sun, 02 Feb 2003 13:16:48 PST." Message-ID: > My point was that I am only focused on booting linux, and so the legacy BIOS > is just flash baggage after linux gets going. Grub offers some booting > flexibility that I need, and since it is C code, also is more easily > customized for some other things I need to do during boot (embedded > application). Linuxbios + Etherboot, surely? You can give the command line by hand from the serial console or via DHCP. Start off with the NFS root, administered remotely. Then populate the disk and for subsequent disk boots, Etherboot has an IDE driver. No direct support for SCSI controllers, but I think you'll be hard pressed to get that without legacy BIOS. Eric Biederman ported Etherboot directly to LinuxBIOS, so no legacy BIOS needed. It's mostly C and Ken Yap is talking about embedding lua (www.lua.org), so now would be a good time to talk about what customisation you need. From rminnich at lanl.gov Mon Feb 3 19:10:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 3 19:10:01 2003 Subject: mainboard sub-type support Message-ID: We have a mainboard called the p4dpe-g2. It seems to be almost identical to the p4dpe. I was faced with several options: - have a directory named p4dpe and a directory p4dpe-g2, with almost identical files - Have a directory for the p4dpe, with #ifdef G2 in many files - an interesting trick that works: have a directory p4dpe, and a directory p4dpe/g2 Populate p4dpe/g2 with the files: cmos.layout, Config, mainboard.c, irq_tables.c, and mptable.c in other words, the files that will change with mainboard revs anyway This last option works. The only change to the config file to build a -g2 motherboard is to change the line: mainboard supermicro/p4dpe to mainboard supermicro/p4dpe/g2 Now this is kind of interesting. For a vendor like supermicro that spins lots of boards that are very similar, we can take this further: have supermicro/mainboard/p4d/pr for the p4dpr and supermicro/mainboard/p4d/pe for the p4dpe. These are similar boards, lots of shared code, and this structure shows that. Comments? is this good, bad, or indifferent? ron From jerj at coplanar.net Tue Feb 4 11:24:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue Feb 4 11:24:01 2003 Subject: mainboard sub-type support In-Reply-To: References: Message-ID: <1044376905.1828.14.camel@contact.skynet.coplanar.net> Will the shared code/common files still be in p4d/, and be referenced or included by the config/other files in p4d/{pe,pe-g2}? If so it makes perfect sense. There could also be a mailboard/common/ dir for files (if any) common across more than one mfr's mainboard. On Mon, 2003-02-03 at 19:27, Ronald G. Minnich wrote: > We have a mainboard called the p4dpe-g2. It seems to be almost identical > to the p4dpe. > > I was faced with several options: > - have a directory named p4dpe and a directory p4dpe-g2, with > almost identical files > > - Have a directory for the p4dpe, with #ifdef G2 in many files > > - an interesting trick that works: > have a directory p4dpe, and a directory p4dpe/g2 > Populate p4dpe/g2 with the files: > cmos.layout, Config, mainboard.c, irq_tables.c, and mptable.c > in other words, the files that will change with mainboard revs > anyway > > This last option works. The only change to the config file to build a -g2 > motherboard is to change the line: > mainboard supermicro/p4dpe > to > mainboard supermicro/p4dpe/g2 > > > Now this is kind of interesting. For a vendor like supermicro that spins > lots of boards that are very similar, we can take this further: have > supermicro/mainboard/p4d/pr > for the p4dpr > and > supermicro/mainboard/p4d/pe > for the p4dpe. These are similar boards, lots of shared code, and this > structure shows that. > > Comments? is this good, bad, or indifferent? > > ron > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Jeremy Jackson From rminnich at lanl.gov Tue Feb 4 11:34:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 4 11:34:00 2003 Subject: mainboard sub-type support In-Reply-To: <1044376905.1828.14.camel@contact.skynet.coplanar.net> Message-ID: On 4 Feb 2003, Jeremy Jackson wrote: > Will the shared code/common files still be in p4d/, and be referenced or > included by the config/other files in p4d/{pe,pe-g2}? If so it makes > perfect sense. yes, and it works really well. I'm going to flash the image I created from this scheme and let you know. For the moment I'll leave it at the p4dpe and p4dep/g2 variant, I want to see if I get any other comments. Thanks Jeremy! ron From jerj at coplanar.net Tue Feb 4 11:48:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue Feb 4 11:48:00 2003 Subject: mainboard sub-type support In-Reply-To: References: Message-ID: <1044378346.1859.34.camel@contact.skynet.coplanar.net> It would also be best to avoid copying whole files. It's the whole pass-by-value vs pass-by-reference argument. Copy whole file is a nightmare for maintenance, while #including stuff like cmos layout could break a system being upgraded. Shouldn't p4dpe/Config and p4dpr/Config contain only the parts that differ? ie: [jjackson at thunderdome supermicro]$ diff p4dpe/Config p4dpr/Config 58c58 < mainboardinit mainboard/supermicro/p4dpe/pci_clk_reset.inc --- > mainboardinit mainboard/supermicro/p4dpr/pci_clk_reset.inc 66c66 < mainboardinit mainboard/supermicro/p4dpe/select_i2c_spd.inc --- > mainboardinit mainboard/supermicro/p4dpr/select_i2c_spd.inc 74c74 < mainboardinit mainboard/supermicro/p4dpe/mainboard_raminit.inc --- > mainboardinit mainboard/supermicro/p4dpr/mainboard_raminit.inc 94c94 < #object devices.o --- > object devices.o 225c225 < option MAINBOARD_PART_NUMBER=P4DP6 --- > option MAINBOARD_PART_NUMBER=P4DPR And then #include at start or end p4d/Config_common or some such. Is there an #include like statement for Config files? You could always make one, or does the order of the entries count here? I've seen OOP guys go nuts about proper code factoring, and aside from being seen as fascist, they have really clean code. On Tue, 2003-02-04 at 11:51, Ronald G. Minnich wrote: > On 4 Feb 2003, Jeremy Jackson wrote: > > > Will the shared code/common files still be in p4d/, and be referenced or > > included by the config/other files in p4d/{pe,pe-g2}? If so it makes > > perfect sense. > > yes, and it works really well. > > I'm going to flash the image I created from this scheme and let you know. > > For the moment I'll leave it at the p4dpe and p4dep/g2 variant, I want to > see if I get any other comments. > > Thanks Jeremy! > > ron -- Jeremy Jackson From rminnich at lanl.gov Tue Feb 4 12:27:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 4 12:27:00 2003 Subject: mainboard sub-type support In-Reply-To: <1044378346.1859.34.camel@contact.skynet.coplanar.net> Message-ID: On 4 Feb 2003, Jeremy Jackson wrote: > It would also be best to avoid copying whole files. It's the whole > pass-by-value vs pass-by-reference argument. Copy whole file is a > nightmare for maintenance, while #including stuff like cmos layout could > break a system being upgraded. sure. > And then #include at start or end p4d/Config_common or some such. remember, including is the basis of the config tool. So yes you can do something like this. I'm still working out all the details. ron From p.richards at overclockers.cl Tue Feb 4 13:05:00 2003 From: p.richards at overclockers.cl (Paulo Richards) Date: Tue Feb 4 13:05:00 2003 Subject: DoC question Message-ID: <1044382909.3842.2.camel@Valkyrie> Maybe it's offtopic (sorry for that), but i don't know other list to ask this question. How many time can you burn a DoC? Thanx Paulo Richards From jefight at hotmail.com Tue Feb 4 13:49:00 2003 From: jefight at hotmail.com (Jeffrey Knight) Date: Tue Feb 4 13:49:00 2003 Subject: 440BX Message-ID: Some questions from a newbie .... I have an Intel motherboard with PII and a MP440BX PCI chipset. I know that I can do a software upgrade my BIOS using the iflash.exe util from intel. I'm trying to figure out if I can make linuxBios work. The motherboard is listed as supported. There's no docs under freebios\freebios\HOWTO\ for 440BX; is building for the 440BX analogous to building for the L440GX? (I see the l440bx-test12.config file in the util directory.) Thinking that steps for 440BX might be similar to those for L440GX, I followed the HOWTO for L440GX and grabbed a 2.4.0-test12 kernel. But according to the HOWTO for L440GX, I need to patch the kernel with: freebios\src\kernel_patches\linux-2.4.0-test12-l440gx.patch which doesn't exist. Yet according to the HOWTO at \freebios\src\kernel_patches\HOWTO: "For 440BX users: irq_route.diff is Tyson Sawyer's patch to properly handle LINUXBIOS kernels. It has been tested on 2.4.0-test6 kernels." ... so should I use a 2.4.0-test6 instead of a 2.4.0-test12 kernel, and patch it with irq_route.diff for a 440BX? Thanks for your help! Jeff _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From rminnich at lanl.gov Tue Feb 4 15:16:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 4 15:16:01 2003 Subject: 440BX In-Reply-To: Message-ID: On Tue, 4 Feb 2003, Jeffrey Knight wrote: > There's no docs under freebios\freebios\HOWTO\ for 440BX; is building for > the 440BX analogous to building for the L440GX? (I see the > l440bx-test12.config file in the util directory.) yes, it is very similar. I would welcome suggestions on how to write up a procedure that will work across all the motherboards. I'm stumped. Flowchart? now sure. > followed the HOWTO for L440GX and grabbed a 2.4.0-test12 kernel. > But according to the HOWTO for L440GX, I need to patch the kernel with: > freebios\src\kernel_patches\linux-2.4.0-test12-l440gx.patch > which doesn't exist. that's my fault, sorry. If you want just get a 2.4.20 kernel at cwlinux.com, it should work fine. > Yet according to the HOWTO at \freebios\src\kernel_patches\HOWTO: > "For 440BX users: irq_route.diff is Tyson Sawyer's patch to properly handle > LINUXBIOS kernels. It has been tested on 2.4.0-test6 kernels." > ... so should I use a 2.4.0-test6 instead of a 2.4.0-test12 kernel, and > patch it with irq_route.diff for a 440BX? I'm sorry those docs are so out of data. If you are willing to suffer through getting this going and can send me updated docs you would really be helping us out. ron From pyro at linuxlabs.com Tue Feb 4 16:28:00 2003 From: pyro at linuxlabs.com (steven james) Date: Tue Feb 4 16:28:00 2003 Subject: DoC question In-Reply-To: <1044382909.3842.2.camel@Valkyrie> Message-ID: Greetings, M-Sys claims 1,000,000 erase/write cycles. G'day, sjames On 4 Feb 2003, Paulo Richards wrote: > Maybe it's offtopic (sorry for that), but i don't know other list to ask > this question. > > How many time can you burn a DoC? > > Thanx > > Paulo Richards > > _______________________________________________ > 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 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From hansolofalcon at worldnet.att.net Tue Feb 4 22:57:00 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Tue Feb 4 22:57:00 2003 Subject: DoC question In-Reply-To: Message-ID: <001a01c2cccd$2e6f4000$5bb7580c@who5> Hello again from Gregg C Levine Now the question becomes, "How can I obtain one, as an engineering sample?". If I can obtain them at small quantity prices, then I will. ------------------- 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 steven james > Sent: Tuesday, February 04, 2003 4:46 PM > To: Paulo Richards > Cc: linuxbios at clustermatic.org > Subject: Re: DoC question > > Greetings, > > M-Sys claims 1,000,000 erase/write cycles. > > G'day, > sjames > > > On 4 Feb 2003, Paulo Richards wrote: > > > Maybe it's offtopic (sorry for that), but i don't know other list to ask > > this question. > > > > How many time can you burn a DoC? > > > > Thanx > > > > Paulo Richards > > > > _______________________________________________ > > 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 701 > the original linux labs atlanta.ga.us 30303 > -since 1995 http://www.linuxlabs.com > office 404.577.7747 fax 404.577.7743 > ---------------------------------------------------------------------- - > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From alesan at manoweb.com Wed Feb 5 06:56:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Wed Feb 5 06:56:01 2003 Subject: X and linuxbios Message-ID: <3E410043.1050209@manoweb.com> Are there known problems with XFree86 and linuxbios? I use a pcchips motherboard with linuxbios from cwlinux.com, and when I start Xfree86 it says 'v_bios not found' and refuses to start. Any hints? -- How to build a lirc receiver http://www.manoweb.com/alesan/lirc From rminnich at lanl.gov Wed Feb 5 10:13:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 5 10:13:00 2003 Subject: objcopy -O binary behaviour Message-ID: this is interesting and I just hit it. objcopy -O binary appears to be rounding the output to the page size. So, in some cases, your binary will GROW, not shrink, when you do this: objcopy -O binary linuxbios linuxbios.strip So for example I have a 46024-byte linuxbios, which grows to 49152 bytes AFTER it is stripped. most inconvenient. I'm trying to figure out what makes this happen. It's not a great thing, however. Even older objcopy's do it, e.g. 2.13.90.2 does it, but so does 2.11.90.0.8 I love BFD but somedays I think it wants to kill me. ron From felix at allot.com Wed Feb 5 10:19:00 2003 From: felix at allot.com (Felix Radensky) Date: Wed Feb 5 10:19:00 2003 Subject: Booting VxWorks from LinuxBios Message-ID: <3E412FA2.3090201@allot.com> Hi, folks I'm trying to boot our VxWorks based application from using LinuxBios. On our board we have 512K Flash and 16M CF. VxWorks image is several megs in size, so I put it on CF. I use linuxbios and VxWorks boot loader, which is essentially a stripped down VxWorks kernel with 32-byte a.out header removed, to create a flash romimage. The idea is to let linuxbios load VxWorks boot loader into memory and let it load VxWorks from CF. Essentially, I've simply mimicked the romimage creation steps, just instead of linux kernel I use VxWorks bootloader. I can see that bootloader is successfully uncompressed into RAM, but nothing happens after I jump to it's code. According to VxWorks docs, bootloader should be copied to address 0x8000. I've tried to modify do_inflate.c and linuxbiosmain.c to load and jump to this address, but gunzip returned error. Now the question. Do you think this approach can work, or I am I doing something entirely wrong ? Should I convert a.out image of VxWorks bootloader into binary image. Can I modify linuxbios code to allow VxWorks boot loader to be loaded at 0x8000 ? Any other ideas will be much appreciated. TIA. Felix. From rminnich at lanl.gov Wed Feb 5 10:27:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 5 10:27:00 2003 Subject: more on objcopy Message-ID: ok, I think objcoyp is doing the right thing. Whew! Here are the sections: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .rom PROGBITS ffff4000 001000 002400 00 AX 0 0 8 [ 2] .payload PROGBITS ffff6400 003400 0049b3 00 WA 0 0 1 [ 3] .reset PROGBITS fffffff0 007ff0 000010 00 A 0 0 1 [ 4] .id PROGBITS ffffffd3 007fd3 00001d 00 A 0 0 1 [ 5] .text PROGBITS fffffff0 007ff0 000000 00 AX 0 0 4 [ 6] .data PROGBITS fffffff0 007ff0 000000 00 WA 0 0 4 [ 7] .bss NOBITS fffffff0 008ff0 000000 00 WA 0 0 4 [ 8] .shstrtab STRTAB 00000000 008ff0 000045 00 0 0 1 [ 9] .symtab SYMTAB 00000000 0091f0 0010e0 10 10 bf 4 [10] .strtab STRTAB 00000000 00a2d0 0010f8 00 0 0 1 The .rom starts at 0xffff4000, which gives you a 49152-byte section. I think the .ldscript is giving a fixed-size linuxbios without regard to how big it actually is, which means tuning via things like max log message etc. is no longer a real option. It also means my etherboot, which is 17K, no longer fits together with linuxbios into 64K. OK, back to the drawing board :-) ron From rminnich at lanl.gov Wed Feb 5 11:30:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 5 11:30:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <3E412FA2.3090201@allot.com> Message-ID: On Wed, 5 Feb 2003, Felix Radensky wrote: > Now the question. Do you think this approach can work, or I am > I doing something entirely wrong ? it can work. Are you sure you have RAM turned on correctly? Is there some way you can use mkelfImage to build a better image? > Can I modify linuxbios code to allow VxWorks boot loader to be loaded > at 0x8000 ? sure, but I recommend you cut over to and elfImage. ron From stutts at innocon.com Wed Feb 5 11:46:01 2003 From: stutts at innocon.com (Christopher Stutts) Date: Wed Feb 5 11:46:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <3E412FA2.3090201@allot.com> References: <3E412FA2.3090201@allot.com> Message-ID: <1044464661.11655.62.camel@powerbrick.innocon.com> On Wed, 2003-02-05 at 10:37, Felix Radensky wrote: > Hi, folks > > I'm trying to boot our VxWorks based application from using > LinuxBios. On our board we have 512K Flash and 16M CF. > VxWorks image is several megs in size, so I put it on CF. > > I use linuxbios and VxWorks boot loader, which is essentially > a stripped down VxWorks kernel with 32-byte a.out header > removed, to create a flash romimage. The idea is to let linuxbios > load VxWorks boot loader into memory and let it load VxWorks > from CF. > > Essentially, I've simply mimicked the romimage creation steps, > just instead of linux kernel I use VxWorks bootloader. > > I can see that bootloader is successfully uncompressed into RAM, > but nothing happens after I jump to it's code. According to VxWorks > docs, bootloader should be copied to address 0x8000. I've tried to > modify > do_inflate.c and linuxbiosmain.c to load and jump to this address, > but gunzip returned error. > > Now the question. Do you think this approach can work, or I am > I doing something entirely wrong ? > > Should I convert a.out image of VxWorks bootloader into binary image. > > Can I modify linuxbios code to allow VxWorks boot loader to be loaded > at 0x8000 ? > > Any other ideas will be much appreciated. > I did this experiment once, except I executed the full-up vxWorks kernel instead of the bootloader. I believe that in addition to jumping to 8000h physical, I needed to switch to real mode, and that the segment:offset needed to be 800:0. //copy 1 flash page to vxworks start address memcpy((void *)0x8000, (void *)0xfffe0000, 0x20000); //patch the code in flashOSBootasm() /* Code to be run at 0x800:0 expects real mode, so flashOSBootasm() performs a 2 part mode switch. The 1st part is loading all segment regs with 16-bit segments, including jumping to a 16-bit code segment in protected mode. The GDT in intel_start32.S has a selector 0x28 with base 0xf0000 & limit 0xffff. 0x28 therefore maps to the BIOS, but offsets are exactly 0xf0000 lower than in a flat segment. There is a jmp 28:0000 instruction in flashOSBootasm(), followed immediately by the flat32 offset of the actual code to be jumped to. So right here, we get a pointer to the code to be jumped to, read that address embedded in the 4 bytes preceding the code, and copy the low 2 bytes to the jump instruction in the x bytes preceding _that_. You really have to trace through the code with an ICE to see what really happens. The 2nd part of the mode switch, after the cr0 reg is changed, is the jump to a real-mode segment offset address. */ pc = (unsigned char *)offset_patch_address; //553 pc2 = pc; pc -= (0x553 - 0x549); pc2 -= (0x553 - 0x54f); //unprotect the bios in shadow ram c = csreadc(0x59); cswritec(0x59, c | 0x20); pc[0] = pc2[0]; pc[1] = pc2[1]; __asm__("wbinvd"); //do not write protect, we lose the changes! What the hell! // cswritec(0x59, c); flashOSBootasm(); } Unfortunately I can't find the asm code. Still looking. From stutts at innocon.com Wed Feb 5 11:51:01 2003 From: stutts at innocon.com (Christopher Stutts) Date: Wed Feb 5 11:51:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <1044464661.11655.62.camel@powerbrick.innocon.com> References: <3E412FA2.3090201@allot.com> <1044464661.11655.62.camel@powerbrick.innocon.com> Message-ID: <1044464965.11656.65.camel@powerbrick.innocon.com> Asm part of jump from Linuxbios to vxWorks -------------- next part -------------- // // cpmasm.S // // Performs real-mode switch and then jump to code copied to flash at 0x800:0. // (VxWorks startup code expects a 0 offset, so 0:0x8000 is verboten.) // Mode switch is two part: loading all seg registers with 16-bit segments, then // jumping to realmode segment. GDT in intel_start32.S contains a 16-bit data segment // 0x30 & a 16-bit code segment 0x28. 0x28:0 = 0xf0000 physical. The jump to // 0x28:offset_patch_address requires a far jump with a 16-bit offset, which the assembler // doesn't do. The offset there fore is patched before we get executed by some C code. .text // .code32 .global flashOSBootasm flashOSBootasm: //Load all data segment regs with a 16-bit segment mov $0x30,%ax mov %ax,%ds mov %ax,%es mov %ax,%fs mov %ax,%gs mov %ax,%ss //Jump to a 16-bit code segment ljmp $0x28,$0x00000000 .global offset_patch_address .long offset_patch_address offset_patch_address: movl %cr0, %eax //mov eax,cr0 and $0xfffffffe,%eax //and eax,0ffffffFEh movl %eax,%cr0 //Switch back to real-mode without resetting .global PROTECTION_DISABLED PROTECTION_DISABLED: .code16 //Load all data segments regs with 0 until realmode code sets them mov $0,%ax nop nop mov %ax,%ds mov %ax,%es mov %ax,%fs mov %ax,%ss mov %ax,%gs //opcode for real-mode jump to 800:0 .byte 0xea,0,0,0,0x8 .code32 From felix at allot.com Wed Feb 5 11:58:00 2003 From: felix at allot.com (Felix Radensky) Date: Wed Feb 5 11:58:00 2003 Subject: Booting VxWorks from LinuxBios References: <3E412FA2.3090201@allot.com> <1044464661.11655.62.camel@powerbrick.innocon.com> <1044464965.11656.65.camel@powerbrick.innocon.com> Message-ID: <3E4146E1.6070301@allot.com> Hi, Christopher Thanks a lot for the code. I really appreciate it ! Did you modify the linuxbios itself to allow VxWorks to be loaded at 8000h. I guess I have to modify ldscript.ld but i don't know how. Thanks a lot. Felix. Christopher Stutts wrote: >Asm part of jump from Linuxbios to vxWorks > > > > > >------------------------------------------------------------------------ > >// >// cpmasm.S >// >// Performs real-mode switch and then jump to code copied to flash at 0x800:0. >// (VxWorks startup code expects a 0 offset, so 0:0x8000 is verboten.) >// Mode switch is two part: loading all seg registers with 16-bit segments, then >// jumping to realmode segment. GDT in intel_start32.S contains a 16-bit data segment >// 0x30 & a 16-bit code segment 0x28. 0x28:0 = 0xf0000 physical. The jump to >// 0x28:offset_patch_address requires a far jump with a 16-bit offset, which the assembler >// doesn't do. The offset there fore is patched before we get executed by some C code. > > > .text >// .code32 > > .global flashOSBootasm >flashOSBootasm: > >//Load all data segment regs with a 16-bit segment > mov $0x30,%ax > mov %ax,%ds > mov %ax,%es > mov %ax,%fs > mov %ax,%gs > mov %ax,%ss > >//Jump to a 16-bit code segment > ljmp $0x28,$0x00000000 > >.global offset_patch_address >.long offset_patch_address >offset_patch_address: > > movl %cr0, %eax //mov eax,cr0 > and $0xfffffffe,%eax //and eax,0ffffffFEh > movl %eax,%cr0 //Switch back to real-mode without resetting > >.global PROTECTION_DISABLED >PROTECTION_DISABLED: > >.code16 > >//Load all data segments regs with 0 until realmode code sets them > mov $0,%ax > nop > nop > mov %ax,%ds > mov %ax,%es > mov %ax,%fs > mov %ax,%ss > mov %ax,%gs > >//opcode for real-mode jump to 800:0 > .byte 0xea,0,0,0,0x8 > .code32 > > From pyro at linuxlabs.com Wed Feb 5 12:09:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed Feb 5 12:09:01 2003 Subject: more on objcopy In-Reply-To: Message-ID: Greetings, The size in the ldscripts is controlled by ROM_IMAGE_SIZE in the mainboard config file. With care, it should be changable, but there is a good bit of magic in there (I'm trying to get rid of some of that in the boards I have, but it is slow going and some of it is hard to get rid of). Of course, if the selected size is too small, bad things happen (I don't know if it will build a broken image, or just fail to build). The thing is, a build where ionly the actual size needed gets used presents some real problems for getting target addresses right. G'day, sjames On Wed, 5 Feb 2003, Ronald G. Minnich wrote: > ok, I think objcoyp is doing the right thing. Whew! > > Here are the sections: > [Nr] Name Type Addr Off Size ES Flg Lk > Inf Al > [ 0] NULL 00000000 000000 000000 00 0 > 0 0 > [ 1] .rom PROGBITS ffff4000 001000 002400 00 AX 0 > 0 8 > [ 2] .payload PROGBITS ffff6400 003400 0049b3 00 WA 0 > 0 1 > [ 3] .reset PROGBITS fffffff0 007ff0 000010 00 A 0 > 0 1 > [ 4] .id PROGBITS ffffffd3 007fd3 00001d 00 A 0 > 0 1 > [ 5] .text PROGBITS fffffff0 007ff0 000000 00 AX 0 > 0 4 > [ 6] .data PROGBITS fffffff0 007ff0 000000 00 WA 0 > 0 4 > [ 7] .bss NOBITS fffffff0 008ff0 000000 00 WA 0 > 0 4 > [ 8] .shstrtab STRTAB 00000000 008ff0 000045 00 0 > 0 1 > [ 9] .symtab SYMTAB 00000000 0091f0 0010e0 10 10 > bf 4 > [10] .strtab STRTAB 00000000 00a2d0 0010f8 00 0 > 0 1 > > The .rom starts at 0xffff4000, which gives you a 49152-byte section. > > I think the .ldscript is giving a fixed-size linuxbios without regard to > how big it actually is, which means tuning via things like max log > message etc. is no longer a real option. It also means my etherboot, which > is 17K, no longer fits together with linuxbios into 64K. > > OK, back to the drawing board :-) > > 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 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From stutts at innocon.com Wed Feb 5 12:14:01 2003 From: stutts at innocon.com (Christopher Stutts) Date: Wed Feb 5 12:14:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <3E4146E1.6070301@allot.com> References: <3E4146E1.6070301@allot.com> Message-ID: <1044466360.12927.12.camel@powerbrick.innocon.com> On Wed, 2003-02-05 at 12:16, Felix Radensky wrote: > Hi, Christopher > > Thanks a lot for the code. I really appreciate it ! > Did you modify the linuxbios itself to allow VxWorks > to be loaded at 8000h. I guess I have to modify ldscript.ld > but i don't know how. > > Thanks a lot. > > Felix. Two years ago(?), working from an old tarball on a 430TX-based board, I threw the quoted C code in where the jump to the linux kernel normally goes, and apparently I modified the GDT as well. The experiment convinced us to go this route for our PIII BX board running a different RTOS instead of buying a BIOS solely for its SDRAM init, pci enumeration, & disk boot capabilities. If there is a cleaner switch to real mode available now, use it. (You can see that I was patching code in ram in order to jump to a 16-bit protected mode segment, and that the chipset wasn't entirely cooperating.) You might also look to see if there is a protected mode entry point to your vxWorks code. I don't know if that is feasible or not. We haven't done vxWorks for 2 years, and only a couple printed manuals were saved from the Great Purge. -- From russell at abc9986.demon.co.uk Wed Feb 5 13:21:01 2003 From: russell at abc9986.demon.co.uk (russell at abc9986.demon.co.uk) Date: Wed Feb 5 13:21:01 2003 Subject: Via EPIA Message-ID: I'm having some trouble getting SDRAM to work on this mother board. I have a 256mb DIMM From the data sheet its 32M x 8bit ( 8M x 8-bit X 4 Bank) CL3 PC133 I just can't get it to boot it crashed at the following Initializing PCI devices... PCI devices initialized sizeram: returning 0x3fc00 KB totalram: 64M Initializing CPU #0 Enabling cache... Setting fixed MTRRs(0-88) type: UC I have the vt8601 Datasheet from VIA's website and i've changed what i think needed changing. Does any one have the BIOS porting guide for this chipset? Is it possible to redo the ram setup code using SPD data? any help or code examples would be most welcome. Cheers Russell From rminnich at lanl.gov Wed Feb 5 14:23:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 5 14:23:00 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <3E4146E1.6070301@allot.com> Message-ID: if you folks figure out vxworks from linuxbios and write it up I can put it in the FAQ ron From tulonja at koti.soon.fi Thu Feb 6 10:40:01 2003 From: tulonja at koti.soon.fi (Jarmo Tulonen) Date: Thu Feb 6 10:40:01 2003 Subject: Tiger MPX Message-ID: <200302061600.h16G0KA20023@smtp2.sooninternet.net> Hello I'm still struggling with the Tyan Tiger MPX (aka S2466). I tested this time with the programs I downloaded from ftp.lnxi.com, compiling from the tar packet and using etherboot 5.1.5 as payload. It loads the kernel from the tftp server but when it should jump to the kernel, it just dies. I also tried with the pre-made rom image from the rpm-package, with the same result. If I load etherboot from floppy, it gets the kernel from the tftp server and starts it up ok. Any ideas how to proceed ? Regards : Jarmo From rminnich at lanl.gov Thu Feb 6 11:43:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 6 11:43:01 2003 Subject: Tiger MPX In-Reply-To: <200302061600.h16G0KA20023@smtp2.sooninternet.net> Message-ID: I have not yet bought an MPX, but when I get one I will give this a try. Steve James is the expert on this i think. ron From ebiederman at lnxi.com Thu Feb 6 13:13:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 13:13:00 2003 Subject: more on objcopy In-Reply-To: References: Message-ID: steven james writes: > Greetings, > > The size in the ldscripts is controlled by ROM_IMAGE_SIZE in the mainboard > config file. With care, it should be changable, but there is a good bit of > magic in there (I'm trying to get rid of some of that in the boards I > have, but it is slow going and some of it is hard to get rid of). > > Of course, if the selected size is too small, bad things happen (I don't > know if it will build a broken image, or just fail to build). It will just fail to build. So it is safe to set ROM_IMAGE_SIZE arbitrarily small. > The thing is, a build where ionly the actual size needed gets used > presents some real problems for getting target addresses right. Thinking about it the only way that might work is to link the entire rom image into a .o file. And then compute what the start address would need to be. And then do a final link to the rom image. Eric From ebiederman at lnxi.com Thu Feb 6 13:23:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 13:23:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > if you folks figure out vxworks from linuxbios and write it up I can put > it in the FAQ For this and possibly for the plan9 support I will except patches to mkelfImage. As of version 2.0 it has an infrastructure that allows for adding code for various targets. And the code is all in C so it is fast. ftp://ftp.lnxi.com/pub/src/mkelfImage/ Basically to load vxworks at 0x8000 you just need an ELF header that says load me here. And probably a bit of adapter code that switches from 32bit protected mode to 64bit protected mode. Eric From ebiederman at lnxi.com Thu Feb 6 13:31:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 13:31:01 2003 Subject: [ANNOUNCE] mkelfImage-2.2 Message-ID: mkelfImage 2.2 is a bug fix release, available at: ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.2.tar.gz rpm -bb mkelfImage-2.2.tar.gz builds a binary rpm. In some cases when working with the latest versions of etherboot the i386 stub code would get confused and use the wrong table address. The result is that the kernel image would just hang. That problem is now fixed. Eric From ebiederman at lnxi.com Thu Feb 6 15:02:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 15:02:00 2003 Subject: Tiger MPX In-Reply-To: <200302061600.h16G0KA20023@smtp2.sooninternet.net> References: <200302061600.h16G0KA20023@smtp2.sooninternet.net> Message-ID: Jarmo Tulonen writes: > Hello > > I'm still struggling with the Tyan Tiger MPX (aka S2466). > I tested this time with the programs I downloaded from > ftp.lnxi.com, compiling from the tar packet and using > etherboot 5.1.5 as payload. It loads the kernel from the > tftp server but when it should jump to the kernel, it just dies. > I also tried with the pre-made rom image from the > rpm-package, with the same result. > If I load etherboot from floppy, it gets the kernel from > the tftp server and starts it up ok. > Any ideas how to proceed ? I can think of two possibilities. 1) You don't have serial console support in your kernel, or it is not properly configured so you do not see what is going on. 2) You may have run into the recent mkelfImage bug, that I just fixed. Eric From tulonja at koti.soon.fi Thu Feb 6 15:20:01 2003 From: tulonja at koti.soon.fi (Jarmo Tulonen) Date: Thu Feb 6 15:20:01 2003 Subject: Tiger MPX In-Reply-To: References: <200302061600.h16G0KA20023@smtp2.sooninternet.net> Message-ID: <200302062040.h16KeBA27844@smtp2.sooninternet.net> On Thursday 06 February 2003 22:20, Eric W. Biederman wrote: > Jarmo Tulonen writes: > > Hello > > > > I'm still struggling with the Tyan Tiger MPX (aka S2466). > > I tested this time with the programs I downloaded from > > ftp.lnxi.com, compiling from the tar packet and using > > etherboot 5.1.5 as payload. It loads the kernel from the > > tftp server but when it should jump to the kernel, it just dies. > > I also tried with the pre-made rom image from the > > rpm-package, with the same result. > > If I load etherboot from floppy, it gets the kernel from > > the tftp server and starts it up ok. > > Any ideas how to proceed ? > > I can think of two possibilities. > 1) You don't have serial console support in your kernel, > or it is not properly configured so you do not see what is going on. > 2) You may have run into the recent mkelfImage bug, that I just fixed. > > > Eric Hello I just got it to work. My problem was that I was generating the kernel image with mkelf-linux and not with mkelfImage. (Actually I did try also mkelfImage at some phase but then I didn't have the console=ttyS0 option appended. So it worked but I didn't know it :-) Thank you for your reply Jarmo From ebiederman at lnxi.com Thu Feb 6 16:05:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 16:05:01 2003 Subject: giving the user a boot option In-Reply-To: References: Message-ID: prl-linuxbios at sychron.com writes: > > My point was that I am only focused on booting linux, and so the legacy BIOS > > is just flash baggage after linux gets going. Grub offers some booting > > flexibility that I need, and since it is C code, also is more easily > > customized for some other things I need to do during boot (embedded > > application). > > Linuxbios + Etherboot, surely? > > You can give the command line by hand from the serial console or via > DHCP. Start off with the NFS root, administered remotely. Then populate > the disk and for subsequent disk boots, Etherboot has an IDE driver. No > direct support for SCSI controllers, but I think you'll be hard pressed > to get that without legacy BIOS. And you can set LinuxBIOS options to say you want to boot off of the network of off of local IDE. As for SCSI if you want it writing an etherboot driver should not be too bad... > Eric Biederman ported Etherboot directly to LinuxBIOS, so no legacy BIOS > needed. It's mostly C and Ken Yap is talking about embedding lua > (www.lua.org), so now would be a good time to talk about what > customisation you need. I think that is mostly with regards to network loaded code, from mknbi/mkelfImage or similiar. Eric From pyro at linuxlabs.com Thu Feb 6 19:12:00 2003 From: pyro at linuxlabs.com (steven james) Date: Thu Feb 6 19:12:00 2003 Subject: [commit] Support for Intel se7501cw2 Message-ID: Greetings, I've just committed support for the 533MHz FSB version of Intel Clearwater and the E7501 northbridge. It's not well tested yet, but it does etherboot the kernel. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From ebiederman at lnxi.com Thu Feb 6 20:02:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 6 20:02:01 2003 Subject: Tiger MPX In-Reply-To: <200302062040.h16KeBA27844@smtp2.sooninternet.net> References: <200302061600.h16G0KA20023@smtp2.sooninternet.net> <200302062040.h16KeBA27844@smtp2.sooninternet.net> Message-ID: Jarmo Tulonen writes: > > Hello > > I just got it to work. My problem was that I was generating > the kernel image with mkelf-linux and not with mkelfImage. Yes.... mkelf-linux works but it does not understand LinuxBIOS at all... > (Actually I did try also mkelfImage at some phase but then I didn't > have the console=ttyS0 option appended. So it worked but I > didn't know it :-) > > Thank you for your reply Eric From hansolofalcon at worldnet.att.net Thu Feb 6 20:21:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu Feb 6 20:21:01 2003 Subject: mkelfImage-2.2 and the kernel exec source code, and the elfboot toolkit Message-ID: <001401c2ce49$d0371340$8baf580c@who5> Hello from Gregg C Levine Eric a number of questions have arisen. First of all, in the readme files for the kernel exec source code, you recommend that I obtain the elfboot toolkit. The suggested reason, is that its because there is a client for the kexec function inside it. Obviously the make elfImage version that you just supplied is the recommended version so that's not a problem. But what finally happened with the elfboot toolkit? For that matter, is any work being done regarding the kexec source code? ------------------- 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 ) From steve at nexpath.com Thu Feb 6 23:42:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Thu Feb 6 23:42:00 2003 Subject: giving the user a boot option In-Reply-To: Message-ID: > > > Grub offers some booting > > > flexibility that I need, and since it is C code, also is more easily > > > customized for some other things I need to do during boot (embedded > > > application). > > > > Linuxbios + Etherboot, surely? > I missed this reply earlier because my mail server died :-(. Couple of Q's about etherboot: Does it support the text vga screen/keyboard without a legacy BIOS? I am not clear on how you specify the boot drive, maybe -DDEFAULT_BOOTFILE=/dev/hda? Can it boot Linux from a particular partition (/dev/hda1) or only from the beginning of the disk (I assume scanning for an elfimage)? My product must boot without a network connection, and requires vga console/keyboard. -Steve From russell at abc9986.demon.co.uk Fri Feb 7 06:11:01 2003 From: russell at abc9986.demon.co.uk (Russell Gower) Date: Fri Feb 7 06:11:01 2003 Subject: Via EPIA - Success References: Message-ID: <003a01c2ce9c$22bc9700$0f01a8c0@winxp> Ok, I now have my Via EPIA 5000 booting into Linux :-) The Image from cwLinux wouldn't work for me. After a couple of days and countless chip swaps I've got it working with SDRAM detection using the code in borthbridge/via/vt8601/raminitspd.inc I've tested it with 2 diffrent DIMMS one 128mb and one 256m. Its actually reporting 9mb less, I think 8mb of that is SMA memory set aside for the framebuffer ( which i'm not using ) the other 1mb i'm not sure but would this be the memory from 0x00000000 -> 0x000a0000? It's passed 7 passes of MEMTEST so i think it's pretty stable, for me at least. Any way it works for me so I can now concentrate on the rest of my application, a car based MP3 player. How do I submit my modification, assuming you wan't them of course! Russell From michal at jaskolski.net Fri Feb 7 06:53:00 2003 From: michal at jaskolski.net (=?Windows-1250?B?TWljaGGz?=) Date: Fri Feb 7 06:53:00 2003 Subject: Chaintech 5TDM2 Message-ID: <382134148.20030207131027@jaskolski.net> Hi there ! I've got a quiestion to ask. Is there any possibility that Chaintech 5TDM2 will be supported by LinuxBIOS ?? I have a problem with 32GB HDD capacity limit, and turning off HDD in BIOS and booting Linux from floppy doesn't suit me. Do you have any ideas?? Thx for any help. Michael aka EmDzej. From 04.Vaughan.Diarmid at exmouthcollege.devon.sch.uk Fri Feb 7 08:35:01 2003 From: 04.Vaughan.Diarmid at exmouthcollege.devon.sch.uk (Diarmid Vaughan) Date: Fri Feb 7 08:35:01 2003 Subject: Disk on Chip for a Jetway 694TAS Socket 370 motherboard ????? Message-ID: <8DBD824609860746A6873D8CF21840FF2148E8@pennyman.exmouthcollege.devon.sch.uk> Hello, I am looking for a Disk On Chip and ZIF socket for my type of Motherboard. My BIOS chip has 2 sides with 7-pins and 2 sides with 9-pins. If anyone can help me with this I would be grateful because I am interested in the LinuxBIOS project. Motherboard - Jetway 694TAS socket 370 with a VIA chipset. E-MAIL - 04.vaughan.diarmid at exmouthcollege.devon.sch.uk Thanks for reading my message From rminnich at lanl.gov Fri Feb 7 09:35:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 7 09:35:00 2003 Subject: Via EPIA - Success In-Reply-To: <003a01c2ce9c$22bc9700$0f01a8c0@winxp> Message-ID: On Fri, 7 Feb 2003, Russell Gower wrote: > How do I submit my modification, assuming you wan't them of course! send me output of diff -u. Talk to Andrew Ip about what might have gone wrong. He is the current expert on that board. ron From rminnich at lanl.gov Fri Feb 7 09:37:06 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 7 09:37:06 2003 Subject: Chaintech 5TDM2 In-Reply-To: <382134148.20030207131027@jaskolski.net> Message-ID: On Fri, 7 Feb 2003, [Windows-1250] Micha? wrote: > Is there any possibility that Chaintech 5TDM2 will be supported by > LinuxBIOS ?? there are way too many boards out there. Send lspci. ron From rminnich at lanl.gov Fri Feb 7 09:41:02 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 7 09:41:02 2003 Subject: Disk on Chip for a Jetway 694TAS Socket 370 motherboard ????? In-Reply-To: <8DBD824609860746A6873D8CF21840FF2148E8@pennyman.exmouthcollege.devon.sch.uk> Message-ID: On Fri, 7 Feb 2003, Diarmid Vaughan wrote: > Motherboard - Jetway 694TAS socket 370 with a VIA chipset. what via chipset? ron From aip at cwlinux.com Fri Feb 7 09:46:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri Feb 7 09:46:01 2003 Subject: Via EPIA - Success In-Reply-To: <003a01c2ce9c$22bc9700$0f01a8c0@winxp>; from Russell Gower on Fri, Feb 07, 2003 at 11:29:11AM -0000 References: <003a01c2ce9c$22bc9700$0f01a8c0@winxp> Message-ID: <20030207230350.A1731@mail.cwlinux.com> Sounds great. Just send the patch to the list. I can put that in the cvs. Thanks. Good work. -Andrew On Fri, Feb 07, 2003 at 11:29:11AM -0000, Russell Gower wrote: > Ok, > I now have my Via EPIA 5000 booting into Linux :-) > > The Image from cwLinux wouldn't work for me. > > After a couple of days and countless chip swaps I've got it working with > SDRAM detection using the code in borthbridge/via/vt8601/raminitspd.inc > > I've tested it with 2 diffrent DIMMS one 128mb and one 256m. Its actually > reporting 9mb less, I think 8mb of that is SMA memory set aside for the > framebuffer ( which i'm not using ) the other 1mb i'm not sure but would > this be the memory from 0x00000000 -> 0x000a0000? > > It's passed 7 passes of MEMTEST so i think it's pretty stable, for me at > least. > > Any way it works for me so I can now concentrate on the rest of my > application, a car based MP3 player. > > How do I submit my modification, assuming you wan't them of course! > > Russell > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From jefight at hotmail.com Fri Feb 7 11:12:01 2003 From: jefight at hotmail.com (Jeffrey Knight) Date: Fri Feb 7 11:12:01 2003 Subject: more 440BX fun Message-ID: I still haven't had any luck getting linuxBIOS to work, but with the knowledge that my motherboard should be supported, I'm not giving up! I tried following the instructions at cwlinux.com for installing linuxBIOS, but they're so completely different than the instructions in the HOWTO directory of the linuxBIOS code directory, I got pretty confused. Plus, all they seem to offer is .rpm's which is less than helpful. So back to following the steps for l440gx (although my motherboard is a l440Bx) ... The first thing I did was configure by running the python script. This looked fine (I attached the output) but when I go to the l440bx directory (that the configure scipt creates) and do: #make I get the following: root at krs1:/home/freebios/util/config/l440bx # make Makefile:554: warning: overriding commands for target 'c_start.o' Makefile:539: warning: ignoring old commands for target 'c_start.o' gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s gcc ... -o crt0.o crt0.s crt0.s: Assembler messages: crt0.s:662: Error: suffix or operands invalid for 'cmp' crt0.s::2028: Warning: Indirect jmp without '*' make: *** [crt0.o] Error 1 Does that mean anything to anyone? My config file looks good, and i pointing to the correct vmlinux, although there's nothing special about my kernel (it's not patched since I don't see a l440bx patch in the patches directory). The l440bx config file says something about using a specific kernel, but since Ron said to just grab the latest kernel code from cwlinux, I take it I can ignore that. My understanding is once I get this to make correctly, I do a "make phlash" all that's left to do is use (in my case) intel's bios update util (iflash.exe) to update my flash with the new linuxBIOS. Am I close to being on the right track? Thanks! Jeff >From: "Ronald G. Minnich" >To: Jeffrey Knight >CC: linuxbios at clustermatic.org >Subject: Re: 440BX >Date: Tue, 4 Feb 2003 13:33:17 -0700 (MST) > >On Tue, 4 Feb 2003, Jeffrey Knight wrote: > > > There's no docs under freebios\freebios\HOWTO\ for 440BX; is building >for > > the 440BX analogous to building for the L440GX? (I see the > > l440bx-test12.config file in the util directory.) > >yes, it is very similar. > >I would welcome suggestions on how to write up a procedure that will work >across all the motherboards. I'm stumped. Flowchart? now sure. > > > followed the HOWTO for L440GX and grabbed a 2.4.0-test12 kernel. > > But according to the HOWTO for L440GX, I need to patch the kernel with: > > freebios\src\kernel_patches\linux-2.4.0-test12-l440gx.patch > > which doesn't exist. > >that's my fault, sorry. If you want just get a 2.4.20 kernel at >cwlinux.com, it should work fine. > > > Yet according to the HOWTO at \freebios\src\kernel_patches\HOWTO: > > "For 440BX users: irq_route.diff is Tyson Sawyer's patch to properly >handle > > LINUXBIOS kernels. It has been tested on 2.4.0-test6 kernels." > > ... so should I use a 2.4.0-test6 instead of a 2.4.0-test12 kernel, and > > patch it with irq_route.diff for a 440BX? > >I'm sorry those docs are so out of data. If you are willing to suffer >through getting this going and can send me updated docs you would really >be helping us out. > >ron _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -------------- next part -------------- A non-text attachment was scrubbed... Name: LINUXBIOS.python.output Type: application/octet-stream Size: 3017 bytes Desc: not available URL: From rminnich at lanl.gov Fri Feb 7 17:29:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 7 17:29:00 2003 Subject: p4dpe/g2 committed Message-ID: I have just commited the p4dpe-g2 variant of the p4dpe, structured as src/mainboard/supermicro/p4dpe/g2 I have built and tested this technique and it works fine for both fallback and normal modes, and two sample .config files are included in the directory. So we now have a standard way to handle mainboard variants. Both the mptable and irq_table had to change for the -g2 ron From ebiederman at lnxi.com Fri Feb 7 19:05:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 7 19:05:01 2003 Subject: [ANNOUNCE] mkelfImage-2.3 Message-ID: mkelfImage 2.3 is a bug fix release, available at: ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.3.tar.gz rpm -bb mkelfImage-2.3.tar.gz builds a binary rpm. This release disables debugging code that can crash some itaniums. Eric From riskin at 263.net Fri Feb 7 20:32:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Fri Feb 7 20:32:00 2003 Subject: Some problems about linuxbios on m758lmr+ Message-ID: <20030208014817.C0C2D1C34B@smtp.x263.net> Hi,All, Firstly,my Linux (the kernel version is 2.2.14) can't find my sis900 net adapter integrated in m758lmr+ mainboard.Are there some options in config files need to be enabled? Secondly,the interruption number of the net adapter( rtl8139 ) in PCI sockets is zero,so it doesn't work. Thanks for your help. riskin From rminnich at lanl.gov Sat Feb 8 00:36:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 8 00:36:00 2003 Subject: Some problems about linuxbios on m758lmr+ In-Reply-To: <20030208014817.C0C2D1C34B@smtp.x263.net> Message-ID: On Sat, 8 Feb 2003 riskin at 263.net wrote: > Secondly,the interruption number of the net adapter( rtl8139 ) in PCI > sockets is zero,so it doesn't work. we don't really support kernels that old (yet) ron From dkotian3 at vsnl.net Sat Feb 8 02:40:01 2003 From: dkotian3 at vsnl.net (dkotian3 at vsnl.net) Date: Sat Feb 8 02:40:01 2003 Subject: LinuxBios development SDK or tools, are there any of them Message-ID: <20030208082625.280051FADA@bom6.vsnl.net.in> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From jerj at coplanar.net Sat Feb 8 11:13:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Sat Feb 8 11:13:00 2003 Subject: [ANNOUNCE] mkelfImage-2.3 In-Reply-To: References: Message-ID: <1044721925.3740.82.camel@contact.skynet.coplanar.net> On Fri, 2003-02-07 at 19:23, Eric W. Biederman wrote: > mkelfImage 2.3 is a bug fix release, available at: > ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.3.tar.gz > > rpm -bb mkelfImage-2.3.tar.gz builds a binary rpm. Wouldn't rpmbuild -tb be less confusing for RH8.0 users? > > This release disables debugging code that can crash some itaniums. > > Eric > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Jeremy Jackson From jerj at coplanar.net Sat Feb 8 11:18:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Sat Feb 8 11:18:00 2003 Subject: Chaintech 5TDM2 In-Reply-To: <382134148.20030207131027@jaskolski.net> References: <382134148.20030207131027@jaskolski.net> Message-ID: <1044722071.3740.85.camel@contact.skynet.coplanar.net> On Fri, 2003-02-07 at 07:10, Micha? wrote: > Hi there ! > > I've got a quiestion to ask. > Is there any possibility that Chaintech 5TDM2 will be supported by > LinuxBIOS ?? > I have a problem with 32GB HDD capacity limit, and turning off HDD in What is the limit? Does the BIOS freeze when the HDD is enabled in BIOS? Have you checked for a newer BIOS from chaintech? What about a 32G clip jumper on the HDD, or a small crappy hdd to boot from? > BIOS and booting Linux from floppy doesn't suit me. > Do you have any ideas?? > > Thx for any help. > > > Michael aka EmDzej. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Jeremy Jackson From rminnich at lanl.gov Sat Feb 8 11:22:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 8 11:22:01 2003 Subject: LinuxBios development SDK or tools, are there any of them In-Reply-To: <20030208082625.280051FADA@bom6.vsnl.net.in> Message-ID: What I can do is create a "skeleton" of your motherboard in the linuxbios tree, complete with source files in place, and then you fill it in with working code. I hope you are comfortable with programming north bridges, please study some of them to make sure you know basically what to do. Sound oK? if so, send me mainboard vendor and name, and I'll set it up. ron From michal at jaskolski.net Sat Feb 8 12:26:01 2003 From: michal at jaskolski.net (=?iso-8859-2?Q?Micha=B3_Jask=F3lski?= aka EmDzej) Date: Sat Feb 8 12:26:01 2003 Subject: Chaintech 5TDM2 In-Reply-To: <1044722071.3740.85.camel@contact.skynet.coplanar.net> References: <382134148.20030207131027@jaskolski.net> <1044722071.3740.85.camel@contact.skynet.coplanar.net> Message-ID: <20030208174358.GA15887@jaskolski.net> On Sat, Feb 08, 2003 at 11:34:31AM -0500, Jeremy Jackson wrote: > What is the limit? Does the BIOS freeze when the HDD is enabled in > BIOS? Have you checked for a newer BIOS from chaintech? > What about a 32G clip jumper on the HDD, or a small crappy hdd to boot > from? Yes, BIOS freezes while trying to detect HDD (it does not if HDD id disabled) ...and as for the clip jumper now it's wired ...there's no newer BIOS, i have the newest (may 1998) ...additional hdd to boot from - yes you're right I'll do so if there'll be no other way ;) PS. Sorry for all those polish stuff :] -- Pozdrawiam, Micha? emdzej at toya.net.pl michal at jaskolski.net GG: 86447 Jabber: michal at jaskolski.net ---------------------------- "Uczony jest cz?owiekiem, kt?ry wie o rzeczach nie znanych innym i nie ma poj?cia o tym, co znaj? wszyscy." [Einstein Albert] From jake at CS.Stanford.EDU Sat Feb 8 13:28:00 2003 From: jake at CS.Stanford.EDU (Jake Page) Date: Sat Feb 8 13:28:00 2003 Subject: ms7308e pirq issues Message-ID: Hi, For some reason with the latest LinuxBIOS CVS sources Linux is having trouble with PCI IRQs. I'm using the same old Matsonic MS7308E that has worked in the past. Same thing happens with the irq_tables.c in CVS and one that I generate with getpir. I pasted relevent messages from LB, etherboot, and Linux below. The 'verifying pirq routing table failed' line seems suspicious to me... but I haven't looked at it much yet - I know a lot of people use this or similar board, anyone seen something like this before? Thanks, Jake From rminnich at lanl.gov Sat Feb 8 15:05:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sat Feb 8 15:05:00 2003 Subject: ms7308e pirq issues In-Reply-To: Message-ID: disable CONFIG_COMPRESS option CONFIG_COMPRESS=0 and let me know. ron From john-at-thinman at nyc.rr.com Sat Feb 8 19:53:01 2003 From: john-at-thinman at nyc.rr.com (John van Vlaaderen) Date: Sat Feb 8 19:53:01 2003 Subject: Via EPIA - Success (o/t comments, hopes) In-Reply-To: <20030207230350.A1731@mail.cwlinux.com> Message-ID: <58E986AE-3BCB-11D7-AB4B-003065F15622@nyc.rr.com> Hi, I have been talking to vendors about this board, including the 12v power supply people (car batt == ups). Global economy being what it is, and the need for a cheap business box extreme, I am wondering out loud if VIA might be a political target for the VgaBIOS ?? Also, lightweight cheapo boards only make sense if they support legacy keyboards and mice for emerging markets, and much of the USA. If memory serves correctly, the board only wants USB. For clusters they make sense w/ serial, gigabit ethernet, DoC and lots of memory and nothing else. On that topic, politically again, if the global VGA standard might be extended to XVGA, 800X600. I will be talking to UNESCO soon, they have 60,000,000 USD to blow on our toys. Maybe they can create a unified technology effort to bootstrap the global economy, LinuxBIOS at the core of it. I am going try to sway VIA your way through (via??) their distributors. Please send comments -- if you have any -- or suggestions for other boards/makers that I should target w/ good advice (or political arm twisting or whatever) On behalf of the plane Earth I think I can say, great work. John On Friday, February 7, 2003, at 10:03 AM, Andrew Ip wrote: > Sounds great. Just send the patch to the list. I can put that in the > cvs. > Thanks. Good work. > > -Andrew > > On Fri, Feb 07, 2003 at 11:29:11AM -0000, Russell Gower wrote: >> Ok, >> I now have my Via EPIA 5000 booting into Linux :-) >> >> The Image from cwLinux wouldn't work for me. >> >> After a couple of days and countless chip swaps I've got it working >> with >> SDRAM detection using the code in borthbridge/via/vt8601/raminitspd.inc >> >> I've tested it with 2 diffrent DIMMS one 128mb and one 256m. Its >> actually >> reporting 9mb less, I think 8mb of that is SMA memory set aside for the >> framebuffer ( which i'm not using ) the other 1mb i'm not sure but >> would >> this be the memory from 0x00000000 -> 0x000a0000? >> >> It's passed 7 passes of MEMTEST so i think it's pretty stable, for me >> at >> least. >> >> Any way it works for me so I can now concentrate on the rest of my >> application, a car based MP3 player. >> >> How do I submit my modification, assuming you wan't them of course! >> >> Russell >> >> >> _______________________________________________ >> Linuxbios mailing list >> Linuxbios at clustermatic.org >> http://www.clustermatic.org/mailman/listinfo/linuxbios > > -- > Andrew Ip > Email: aip at cwlinux.com > Tel: (852) 2542 2046 > Fax: (852) 2542 2036 > Mobile: (852) 9201 9866 > > Cwlinux Limited > Unit 202B 2/F Lai Cheong Factory Building, > 479-479A Castle Peak Road, > Lai Chi Kok, Kowloon, > Hong Kong. > > Tel: (852)2542 2046 > Fax: (852)2542 2036 > > For public pgp key, please obtain it from http://www.keyserver.net/en. > CXN, Inc. Contact: john at thinman.com President, The Linux Society http://groups.yahoo.com/group/linux-society/join linux society distro -> http://www.thinman.com/eLSD/readme ThinMan is a registered trademark of CXN, Inc. From riskin at 263.net Sun Feb 9 04:15:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Sun Feb 9 04:15:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030209093200.9BD141BC0B@smtp.x263.net> Hi!All, My rtl8139 NIC IRQ is 0 on m758lmr+ mainboard. I used getpir to get new irq_table.c,but the IRQ still is 0. Who can tell me what should I do? Thanks. LinuxBIOS-1.0.0 Sat Feb 8 23:31:46 HKT 2003 starting... Copying LinuxBIOS to ram. POST: 0x39, TSC Lo: 3, Hi: 3 LinuxBIOS-1.0.0 Sat Feb 8 23:31:46 HKT 2003 booting... POST: 0x40, TSC Lo: 55, Hi: 55 Finding PCI configuration type. PCI: Using configuration type 1 POST: 0x5f, TSC Lo: 44912, Hi: 44912 handle_superio start, s 0000d240 nsuperio 1 s->super 0000e578 handle_superio Pass 0, check #0, s 0000d240 s->super 0000e578 handle_superio: Pass 0, Superio SiS 950 handle_superio port 0x0, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: pci_scan_bus for bus 0 POST: 0x24, TSC Lo: 0, Hi: 0 PCI: 00:00.0 [1039/0630] PCI: 00:00.1 [1039/5513] PCI: 00:01.0 [1039/0008] PCI: 00:01.1 [1039/0900] PCI: 00:01.2 [1039/7001] PCI: 00:01.3 [1039/7001] PCI: 00:01.4 [1039/7018] PCI: 00:01.6 [1039/7013] PCI: 00:02.0 [1039/0001] PCI: 00:0d.0 [10ec/8139] PCI: 00:0f.0 [13f6/0111] PCI: 00:0f.1 [13f6/0211] POST: 0x25, TSC Lo: -1, Hi: -1 PCI: pci_scan_bus for bus 1 POST: 0x24, TSC Lo: 0, Hi: 0 PCI: 01:00.0 [1039/6300] POST: 0x25, TSC Lo: -1, Hi: -1 PCI: pci_scan_bus returning with max=01 POST: 0x55, TSC Lo: 40, Hi: 40 PCI: pci_scan_bus returning with max=01 POST: 0x55, TSC Lo: 40, Hi: 40 done POST: 0x66, TSC Lo: 5, Hi: 5 POST: 0x70, TSC Lo: 60036, Hi: 60036 totalram: 126M Initializing CPU #0 Updating microcode microcode_info: sig = 0x00000686 pf=0x00000010 rev = 0x00000000 POST: 0x60, TSC Lo: 64, Hi: 64 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 POST: 0x6a, TSC Lo: 18, Hi: 18 done. Max cpuid index : 2 Vendor ID : GenuineIntel Processor Type : 0x00 Processor Family : 0x06 Processor Model : 0x08 Processor Mask : 0x00 Processor Stepping : 0x06 Feature flags : 0x0383fbff Cache/TLB descriptor values: 1 reads required Desc 0x01 : Instr TLB: 4KB pages, 4-way set assoc, 32 entries Desc 0x02 : Instr TLB: 4MB pages, fully assoc, 2 entries Desc 0x03 : Data TLB: 4KB pages, 4-way set assoc, 64 entries Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x41 : L2 Unified cache: 128K bytes, 4-way set assoc, 32 byte line size Desc 0x08 : Inst cache: 16K bytes, 4-way set assoc, 32 byte line size Desc 0x04 : Data TLB: 4MB pages, 4-way set assoc, 8 entries Desc 0x0c : Data cache: 16K bytes, 2-way or 4-way set assoc, 32 byte line size POST: 0x92, TSC Lo: 1, Hi: 1 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled POST: 0x93, TSC Lo: 1, Hi: 1 Configuring L2 cache...CPU signature of 680 so no L2 cache configuration Enable Cache done. Disabling local apic...done. POST: 0x9b, TSC Lo: 6, Hi: 6 CPU #0 Initialized POST: 0x75, TSC Lo: 0, Hi: 0 POST: 0x77, TSC Lo: 117, Hi: 117 Allocating PCI resources... PCI: 00:0f.0 register 10(0000ff01), read-only ignoring it PCI: 00:0f.1 register 10(0000ffc1), read-only ignoring it PCI: 00:0f.0 register 10(0000ff01), read-only ignoring it PCI: 00:0f.1 register 10(0000ffc1), read-only ignoring it PCI: 00:0f.0 register 10(0000ff01), read-only ignoring it PCI: 00:0f.1 register 10(0000ffc1), read-only ignoring it PCI: 00:0f.0 register 10(0000ff01), read-only ignoring it PCI: 00:0f.1 register 10(0000ffc1), read-only ignoring it ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0xf8000000 - 0xfbffffff] mem PCI: 00:00.1 10 <- [0x00003090 - 0x00003097] io PCI: 00:00.1 14 <- [0x000030b0 - 0x000030b3] io PCI: 00:00.1 18 <- [0x000030a0 - 0x000030a7] io PCI: 00:00.1 1c <- [0x000030c0 - 0x000030c3] io PCI: 00:00.1 20 <- [0x00003080 - 0x0000308f] io PCI: 00:01.1 10 <- [0x00002000 - 0x000020ff] io PCI: 00:01.1 14 <- [0xfc100000 - 0xfc100fff] mem PCI: 00:01.2 10 <- [0xfc101000 - 0xfc101fff] mem PCI: 00:01.3 10 <- [0xfc102000 - 0xfc102fff] mem PCI: 00:01.4 10 <- [0x00002400 - 0x000024ff] io PCI: 00:01.4 14 <- [0xfc103000 - 0xfc103fff] mem PCI: 00:01.6 10 <- [0x00002800 - 0x000028ff] io PCI: 00:01.6 14 <- [0x00003000 - 0x0000307f] io PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io PCI: 00:0d.0 10 <- [0x00002c00 - 0x00002cff] io PCI: 00:0d.0 14 <- [0xfc104000 - 0xfc1040ff] mem Allocating VGA resource done. POST: 0x88, TSC Lo: 6, Hi: 6 Enabling PCI resourcess...PCI: 00:00.0 cmd <- 07 PCI: 00:00.1 cmd <- 01 PCI: 00:01.0 cmd <- 0c PCI: 00:01.1 cmd <- 03 PCI: 00:01.2 cmd <- 02 PCI: 00:01.3 cmd <- 02 PCI: 00:01.4 cmd <- 03 PCI: 00:01.6 cmd <- 01 PCI: 00:02.0 cmd <- 07 PCI: 00:0d.0 cmd <- 03 PCI: 00:0f.0 cmd <- 80 PCI: 00:0f.1 cmd <- 00 PCI: 01:00.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized POST: 0x89, TSC Lo: 24, Hi: 24 POST: 0x91, TSC Lo: 137, Hi: 137 POST: 0x92, TSC Lo: 251, Hi: 251 Enabled in SIS 503 regs 0x40 and 0x45 Now try to turn off shadow device for SiS 630 is 0x12b6c Shadow memory disabled in SiS 630 POST: 0x00, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 POST: 0x04, TSC Lo: 2, Hi: 2 handle_superio start, s 0000d240 nsuperio 1 s->super 0000e578 handle_superio Pass 1, check #0, s 0000d240 s->super 0000e578 handle_superio: Pass 1, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 1, done #0 handle_superio done PCCHIPS m758lmr+ (and similar)...Remapping IRQ on southbridge for OLD_KERNEL_HACK Entering the initregs process Southbridge fixup done for SIS 503 POST: 0xec, TSC Lo: 35, Hi: 35 handle_superio start, s 0000d240 nsuperio 1 s->super 0000e578 handle_superio Pass 2, check #0, s 0000d240 s->super 0000e578 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 POST: 0x9a, TSC Lo: 20, Hi: 20 Checking IRQ routing tables.../opt/cwlinux/freebios/src/arch/i386/lib/pirq_routing.c: 23:check_pirq_routing_table() - irq_routing_table located at: 0x0000ac80 done. Copying IRQ routing tables to 0xf0000...done. POST: 0x96, TSC Lo: 983168, Hi: 983168 Wrote linuxbios table at: 00000500 - 00000690 checksum 4dfd Jumping to linuxbiosmain()... POST: 0xed, TSC Lo: 30, Hi: 30 Welcome to start32, the open sourced starter. This space will eventually hold more diagnostic information. January 2000, James Hendricks, Dale Webster, and Ron Minnich. Version 0.1 ......... ........ Jumping to boot code POST: 0xfe, TSC Lo: 21, Hi: 21 Linux version 2.2.14-5.0 (root at Grow) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #42 Tue Jan 14 11:59:11 CST 2003 Ignoring bogus EBDA pointer 3FFF000 Detected 634784426 Hz processor. Console: colour EGA 80x25 Calibrating delay loop... 634.06 BogoMIPS Memory: 99624k/128000k available (1308k kernel code, 416k reserved, 1588k data, 64k init, 0k bigmem) Dentry hash table entries: 262144 (order 9, 2048k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium III (Coppermine) stepping 06 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch (rgooch at atnf.csiro.au) PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Enabling I/O for device 00:78 PCI: Enabling I/O for device 00:79 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 131072 bhash 65536) Linux IP multicast router 0.06 plus PIM-SM Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS<4>keyboard: Too many NACKs -- noisy kbd cable? keyboard: Too many NACKs -- noisy kbd cable? MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A pty: 256 Unix98 ptys configured apm: BIOS not found. Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 26000K size SIS5513: IDE controller on PCI bus 00 dev 01 SIS5513: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x3080-0x3087, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x3088-0x308f, BIOS settings: hdc:pio, hdd:pio hd0: C/H/S=0/0/0 from BIOS ignored hd0: C/H/S=0/0/0 from BIOS ignored hd0: C/H/S=0/0/0 from BIOS ignored Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 raid5: measuring checksumming speed raid5: MMX detected, trying high-speed MMX checksum routines pII_mmx : 1474.470 MB/sec p5_mmx : 1565.148 MB/sec 8regs : 1090.422 MB/sec 32regs : 619.887 MB/sec using fastest function: p5_mmx (1565.148 MB/sec) scsi : 0 hosts. scsi : detected total. md.c: sizeof(mdp_super_t) = 4096 Partition check: RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 25000 blocks [1 disk] into ram disk... done. autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 64k freed fl: Flash disk driver for DiskOnChip fl: DOC device(s) found: 1 fla: fla1 fl: partition: 0: start_sect: 0, nr_sects: 6d90 Fl_blk_size[]: 36c8kb fl: partition: 1: start_sect: 2, nr_sects: 6d7a Fl_blk_size[]: 36bdkb fl: partition: 2: start_sect: 0, nr_sects: 0 Fl_blk_size[]: 0kb fl: partition: 3: start_sect: 0, nr_sects: 0 Fl_blk_size[]: 0kb fla: fla1 sis900.c: v1.06.11 4/30/2002 eth0: SiS 900 PCI Fast Ethernet at 0xb000, IRQ 11, 00:e0:06:09:ff:ff. eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using transceiver found at address 1 as default The PCI BIOS has not enabled the device at 0/88! Updating PCI command 0003->0007. rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html eth1: RealTek RTL8139 Fast Ethernet at 0x2c00, IRQ 0, 00:e0:4c:43:42:c5. ....... From felix at allot.com Sun Feb 9 04:28:00 2003 From: felix at allot.com (Felix Radensky) Date: Sun Feb 9 04:28:00 2003 Subject: Booting VxWorks from LinuxBios References: Message-ID: <3E46236E.2000301@allot.com> Eric W. Biederman wrote: >Basically to load vxworks at 0x8000 you just need an ELF >header that says load me here. > Is this going to work even if LinuxBios itself uses memory at 0x8000 ? In my current setup (without USE_ELF_BOOT) decompression of VxWorks boot loader fails at 0x8000 but succedes at 0x100000. Can elfboot handle compressed images ? I'll gladly provide a patch for mkelfimage, but I'll need some basic guidance, as I'm not familiar with internals of ELF format. Eric, can you please recommend some docs and code to look at, so I can get familiar with the format. > And probably a bit >of adapter code that switches from 32bit protected mode >to 64bit protected mode. > > > > This sounds a bit cryptic to me. Can you please elaborate on that. Thanks. Felix. From aip at cwlinux.com Sun Feb 9 04:43:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sun Feb 9 04:43:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030209093200.9BD141BC0B@smtp.x263.net>; from riskin@263.net on Sun, Feb 09, 2003 at 05:26:43PM +0800 References: <20030209093200.9BD141BC0B@smtp.x263.net> Message-ID: <20030209180053.A22941@mail.cwlinux.com> > My rtl8139 NIC IRQ is 0 on m758lmr+ mainboard. > I used getpir to get new irq_table.c,but the IRQ still is 0. > Who can tell me what should I do? > Thanks. Have you set kernel to use direct pci probe? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From ebiederman at lnxi.com Sun Feb 9 12:39:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Feb 9 12:39:01 2003 Subject: [ANNOUNCE] mkelfImage-2.3 In-Reply-To: <1044721925.3740.82.camel@contact.skynet.coplanar.net> References: <1044721925.3740.82.camel@contact.skynet.coplanar.net> Message-ID: Jeremy Jackson writes: > On Fri, 2003-02-07 at 19:23, Eric W. Biederman wrote: > > mkelfImage 2.3 is a bug fix release, available at: > > ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.3.tar.gz > > > > rpm -bb mkelfImage-2.3.tar.gz builds a binary rpm. > Wouldn't rpmbuild -tb be less confusing for RH8.0 users? Right. I was thinking -tb.... Eric From ebiederman at lnxi.com Sun Feb 9 12:54:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Sun Feb 9 12:54:01 2003 Subject: Booting VxWorks from LinuxBios In-Reply-To: <3E46236E.2000301@allot.com> References: <3E46236E.2000301@allot.com> Message-ID: Felix Radensky writes: > Eric W. Biederman wrote: > > >Basically to load vxworks at 0x8000 you just need an ELF > > header that says load me here. > Is this going to work even if LinuxBios itself uses memory > at 0x8000 ? Essentially yes, it will either work or refuse to load. I do not think the LinuxBIOS tables extend that far up into memory which is the only case it would refuse to load the image for. The LinuxBIOS code itself is copied to the top of memory before the image is loaded, so it does not get in the way. > In my current setup (without USE_ELF_BOOT) > decompression of VxWorks boot loader fails at 0x8000 but > succedes at 0x100000. > > Can elfboot handle compressed images ? Yes, you put a self decompresser in the image. > I'll gladly provide a patch for mkelfimage, but I'll need > some basic guidance, as I'm not familiar with internals > of ELF format. Eric, can you please recommend some > docs and code to look at, so I can get familiar with the format. First there is nothing special about mkelfImage. It is just a repository for the code to convert various types of images into a format the elf loader can handle. For each different image type there is a whole different set of code. The easy reference to come by is /usr/include/elf.h Basically there is an ELF header Elf32_Ehdr/Elf64_Ehdr followed by a program header. Elf32_Phdr/Elf64_Phdr. Followed by the data to load into memory. The Ehdr reports what kind of elf image you have 32bit or 64bit, little endian or big endian, which architecture the code is for where the entry point is, and how many phdrs you have. Each phdr describes a chunk of the image, and specifies where in memory to load it. The ELF structures are a little verbose, but not prohibitively so, and allow a clean way of specifying what to load and where. The elf loader is simply a mechanism where the LinuxBIOS can provide a fixed interface, and the rest of the OS's can come to that one interface with just a little bit of glue code. > > And probably a bit > >of adapter code that switches from 32bit protected mode > >to 64bit protected mode. > > > > > > > This sounds a bit cryptic to me. Can you please elaborate on that. Don't worry about it, I am working on Hammer stuff at the moment, and parts of my brainstorming on how to handle the issues raised by a 64bit port keep spilling out... Eric From riskin at 263.net Sun Feb 9 19:54:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Sun Feb 9 19:54:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030210011059.0146C1BE7F@smtp.x263.net> Hi,Andrew >Have you set kernel to use direct pci probe? I have set "any" mode to probe pci devices. riskin From jerj at coplanar.net Sun Feb 9 20:13:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Sun Feb 9 20:13:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030210011059.0146C1BE7F@smtp.x263.net> References: <20030210011059.0146C1BE7F@smtp.x263.net> Message-ID: <1044840680.15657.12.camel@contact.skynet.coplanar.net> On Sun, 2003-02-09 at 20:05, riskin at 263.net wrote: > Hi,Andrew > > >Have you set kernel to use direct pci probe? > > I have set "any" mode to probe pci devices. That could be a problem since "any" mode tries PC BIOS calls first, which LinuxBIOS doesn't have. you should be using direct. > > riskin > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios -- Jeremy Jackson From aip at cwlinux.com Sun Feb 9 22:06:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sun Feb 9 22:06:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <1044840680.15657.12.camel@contact.skynet.coplanar.net>; from Jeremy Jackson on Sun, Feb 09, 2003 at 08:31:20PM -0500 References: <20030210011059.0146C1BE7F@smtp.x263.net> <1044840680.15657.12.camel@contact.skynet.coplanar.net> Message-ID: <20030210112431.D29644@mail.cwlinux.com> > That could be a problem since "any" mode tries PC BIOS calls first, > which LinuxBIOS doesn't have. Exactly. The kernel log also doesn't show that it has found pirq table. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From rminnich at lanl.gov Sun Feb 9 22:13:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun Feb 9 22:13:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030210011059.0146C1BE7F@smtp.x263.net> Message-ID: On Mon, 10 Feb 2003 riskin at 263.net wrote: > Hi,Andrew > > >Have you set kernel to use direct pci probe? > > I have set "any" mode to probe pci devices. always use direct for linuxbios. If it still won't work set CONFIG_COMPRESS to 0 (or did you do this already) ron From riskin at 263.net Sun Feb 9 23:43:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Sun Feb 9 23:43:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030210050009.C66601C076@smtp.x263.net> Ok,I will try it by setting "direct" mode. My linuxbios version don't support CONFIG_COMPRESS option. I have get it from the cwlinux packages. So,I have checked out the latest cvs version,but I failed to compile it successfully. The file "Liuxbios_c.o" failed to resolve symbol "console_tx_al" and "console_tx_hex8" in the "_start" function when my linker linked these files.Maybe somewhere goes wrong. From riskin at 263.net Mon Feb 10 01:30:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Mon Feb 10 01:30:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030210064525.BF1A71C276@smtp.x263.net> Hi,ron This is my config file. Thanks. riskin # Sample config file for PCCHIPS m758lmr+ with DoC Millennium (as root) # This will make a target directory of m758lmr+ target /opt/cwlinux/buildrom/m758lmr+ # PCCHIPS m758lmr+ mainboard pcchips/m758lmr+ # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # enable debugging support option DEBUG=1 # enable serial post for debugging option SERIAL_POST=1 # set default consol loglevel option DEFAULT_CONSOLE_LOGLEVEL=9 # enable floppy support # option MUST_ENABLE_FLOPPY # enable keyboard support # option NO_KEYBOARD # use ELF boot # option USE_ELF_BOOT=1 # enable RAM test # option RAMTEST # PIRQ tables option HAVE_PIRQ_TABLE=1 # I8259 INITITIAL option I8259=1 # don't use old kernel hack option OLD_KERNEL_HACK=1 # Enable MicroCode update and L2 Cache init for PII and PIII option UPDATE_MICROCODE=1 option CONFIGURE_L2_CACHE=1 option ENABLE_FIXED_AND_VARIABLE_MTRRS=1 # Use the internal VGA frame buffer device #option HAVE_FRAMEBUFFER=1 # Path to your kernel (vmlinux) linux /opt/cwlinux/linux option DISABLE_INTERNAL_DEVICES=0 option CONFIG_COMPRESS=0 #support loading initrd option LOAD_INITRD_FROM_MIL=1 # Kernel command line parameters # enable serial console commandline auto BOOT_IMAGE=Image root=100 ramdisk=26000 console=ttyS0,115200 console=tty0 BOOTSTEP=0 BOOTDEVICE=fla1 #commandline root=/dev/ram0 ramdisk=14000 init=/linuxrc console=ttyS0,115200 console=tty0 #commandline root=/dev/nftla1 console=ttyS0,115200 console=tty0 video=sisfb:640x480-8 at 60,font:VGA8x16 # disable serial console #commandline root=/dev/nftla1 console=/dev/tty5 CONSOLE=/dev/tty5 video=sisfb:640x480-8 at 60,font:VGA8x16 docipl northsouthbridge/sis/630/ipl.S #option USE_DOC_2000_TSOP=1 option USE_DOC_MIL=1 From riskin at 263.net Mon Feb 10 01:50:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Mon Feb 10 01:50:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030210070619.85DA91C247@smtp.x263.net> Hi,ron Sorry,the correct config is updated. This is my config file and I writed 0x7c00 to registers to enable all embedded devices. I also added the support of loading initrd.gz from DOC.(LOAD_INITRD_FROM_MIL) Thanks. riskin # Sample config file for PCCHIPS m758lmr+ with DoC Millennium (as root) # This will make a target directory of m758lmr+ target /opt/cwlinux/buildrom/m758lmr+ # PCCHIPS m758lmr+ mainboard pcchips/m758lmr+ # Enable Serial Console for debugging option SERIAL_CONSOLE=1 # enable debugging support option DEBUG=1 # enable serial post for debugging option SERIAL_POST=1 # set default consol loglevel option DEFAULT_CONSOLE_LOGLEVEL=9 # enable floppy support # option MUST_ENABLE_FLOPPY # enable keyboard support # option NO_KEYBOARD # use ELF boot # option USE_ELF_BOOT=1 # enable RAM test # option RAMTEST # PIRQ tables option HAVE_PIRQ_TABLE=1 # I8259 INITITIAL option I8259=1 # don't use old kernel hack option OLD_KERNEL_HACK=1 # Enable MicroCode update and L2 Cache init for PII and PIII option UPDATE_MICROCODE=1 option CONFIGURE_L2_CACHE=1 option ENABLE_FIXED_AND_VARIABLE_MTRRS=1 # Use the internal VGA frame buffer device #option HAVE_FRAMEBUFFER=1 # Path to your kernel (vmlinux) linux /opt/cwlinux/linux option DISABLE_INTERNAL_DEVICES=1 #support loading initrd option LOAD_INITRD_FROM_MIL=1 # Kernel command line parameters # enable serial console commandline auto BOOT_IMAGE=Image root=100 ramdisk=26000 console=ttyS0,115200 console=tty0 BOOTSTEP=0 BOOTDEVICE=fla1 #commandline root=/dev/ram0 ramdisk=14000 init=/linuxrc console=ttyS0,115200 console=tty0 #commandline root=/dev/nftla1 console=ttyS0,115200 console=tty0 video=sisfb:640x480-8 at 60,font:VGA8x16 # disable serial console #commandline root=/dev/nftla1 console=/dev/tty5 CONSOLE=/dev/tty5 video=sisfb:640x480-8 at 60,font:VGA8x16 docipl northsouthbridge/sis/630/ipl.S #option USE_DOC_2000_TSOP=1 option USE_DOC_MIL=1 From riskin at 263.net Mon Feb 10 03:14:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Mon Feb 10 03:14:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030210083119.DE9B51C3FC@smtp.x263.net> Hi,ron Which version is stable and latest ? Thanks. riskin From rminnich at lanl.gov Mon Feb 10 09:59:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 10 09:59:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030210083119.DE9B51C3FC@smtp.x263.net> Message-ID: On Mon, 10 Feb 2003 riskin at 263.net wrote: > Which version is stable and latest ? always the one from cvs. ron From rminnich at lanl.gov Mon Feb 10 10:44:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 10 10:44:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030210070619.85DA91C247@smtp.x263.net> Message-ID: this is a problem with some recent changes to the build process and I don't know what it is yet. It also depends on version of as. version 2.11.90.0.8 gives this for crt0.o: 00000342 ? console0 00000188 ? console_test 000001c7 ? console_tx_al 00000220 ? console_tx_hex32 000001db ? console_tx_hex8 00000325 ? console_tx_string note ? 2.13.90.0.2 replaces the ? with 't'. In either case the symbols end up undefined. I think some changes were made to some platforms but not globally. CONFIG_COMPRESS on or off does not help. I'll keep looking. I'm going to try to set up regression test build here because we keep getting changes that break builds, and that's inconvient. ron From p.richards at overclockers.cl Mon Feb 10 15:19:00 2003 From: p.richards at overclockers.cl (Paulo Richards) Date: Mon Feb 10 15:19:00 2003 Subject: DoC Error Message-ID: <200302101736.09561.p.richards@overclockers.cl> ioctl(MEMGETINFO): Inappropriate ioctl for device What does this means?, The DoC was working ok, (i used to be able to erase, format, burn, etc), but after i change the kernel (for the Cwlinux developer one), it's stop working, i can't erase (seems ok, but don't erase), format (give me the mentioned error), and not burn. I change back the kernel to my old one, and the same error happens. So, what happend? I'm forgetting somethig (i don't think so, i'm doing the same than before), or the DoC blows up? Thanx Paulo Richards From rsmith at bitworks.com Mon Feb 10 15:53:00 2003 From: rsmith at bitworks.com (Richard Smith) Date: Mon Feb 10 15:53:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: References: Message-ID: <3E48150B.3010706@bitworks.com> Ronald G. Minnich wrote: > this is a problem with some recent changes to the build process and I > don't know what it is yet. > I have this issue as well. If I remove SERIAL_POST from my config files then it builds. Note thats _remove_ not set =0. ./arch/i386/include/arch/intel.h seems to be the offending section for me. It has a #if SERIAL_POST blah.. CALLSP(console_tx_al) blah... CALLSP(console_tx_hex8) #else ; send to port 80 like normal. #endif Which means it hasen't been updated to the OPTION=1 system correct? So regardless if SERIAL_POST 1 or 0 this will be built. Perhaps there is a dependancy thats not making it into some of thie builds? From rminnich at lanl.gov Mon Feb 10 16:13:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 10 16:13:01 2003 Subject: DoC Error In-Reply-To: <200302101736.09561.p.richards@overclockers.cl> Message-ID: On Mon, 10 Feb 2003, Paulo Richards wrote: > So, what happend? I'm forgetting somethig (i don't think so, i'm doing the > same than before), or the DoC blows up? did you set write enable? ron From p.richards at overclockers.cl Mon Feb 10 18:16:01 2003 From: p.richards at overclockers.cl (Paulo Richards) Date: Mon Feb 10 18:16:01 2003 Subject: DoC Error In-Reply-To: References: Message-ID: <200302102033.05069.p.richards@overclockers.cl> On Monday 10 February 2003 18:32, Ronald G. Minnich wrote: > did you set write enable? > > ron I think it's enable, but i'm not pretty sure were exactly enable write suport (kernel modules for the mtd devices? doc nftl support??, flash on utility?) Could you be more specific please, i'll apreciate. Thanx Paulo Richards From rminnich at lanl.gov Mon Feb 10 18:23:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 10 18:23:00 2003 Subject: DoC Error In-Reply-To: <200302102033.05069.p.richards@overclockers.cl> Message-ID: On Mon, 10 Feb 2003, Paulo Richards wrote: > I think it's enable, but i'm not pretty sure were exactly enable write suport > (kernel modules for the mtd devices? doc nftl support??, flash on utility?) > Could you be more specific please, i'll apreciate. what chipset again? ron From p.richards at overclockers.cl Mon Feb 10 18:42:01 2003 From: p.richards at overclockers.cl (Paulo Richards) Date: Mon Feb 10 18:42:01 2003 Subject: DoC Error In-Reply-To: References: Message-ID: <200302102059.44444.p.richards@overclockers.cl> On Monday 10 February 2003 20:42, Ronald G. Minnich wrote: > what chipset again? > > > ron i'm working with a pcchips m810lmr and a DoC Millennium thanx Paulo From riskin at 263.net Tue Feb 11 04:54:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Tue Feb 11 04:54:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030211101218.399991BED1@smtp.x263.net> Hi,ron The IRQ of sis900 NIC embedded in the mainboad isn't zero,and it can work normally.But the IRQ of rtl8139 NIC in pci sockets (including socket #1, socket #2,socket #3 ) is zero.It seems that these devices are not configed by the kernel,either I set "direct" or "any" mode to probe pci devices. lspci: 00:00.0 Class 0600: 1039:0630 (rev 30) 00:00.1 Class 0101: 1039:5513 (rev d0) 00:01.0 Class 0601: 1039:0008 00:01.1 Class 0200: 1039:0900 (rev 84) 00:01.2 Class 0c03: 1039:7001 (rev 07) 00:01.3 Class 0c03: 1039:7001 (rev 07) 00:01.4 Class 0401: 1039:7018 (rev 02) 00:01.6 Class 0703: 1039:7013 (rev a0) 00:02.0 Class 0604: 1039:0001 00:0b.0 Class 0200: 10ec:8139 (rev 10) 00:0f.0 Class 0401: 13f6:0111 (rev 10) 00:0f.1 Class 0780: 13f6:0211 (rev 20) 01:00.0 Class 0300: 1039:6300 (rev 21) I am confused by it. From rminnich at lanl.gov Tue Feb 11 09:16:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 09:16:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030211101218.399991BED1@smtp.x263.net> Message-ID: On Tue, 11 Feb 2003 riskin at 263.net wrote: > The IRQ of sis900 NIC embedded in the mainboad isn't zero,and it can work > normally.But the IRQ of rtl8139 NIC in pci sockets (including socket #1, > socket #2,socket #3 ) is zero.It seems that these devices are not configed > by the kernel,either I set "direct" or "any" mode to probe pci devices. oh, wait, is this 2.2 kernel? I forget now. ron From rminnich at lanl.gov Tue Feb 11 10:08:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 10:08:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <3E48150B.3010706@bitworks.com> Message-ID: On Mon, 10 Feb 2003, Richard Smith wrote: > Ronald G. Minnich wrote: > > this is a problem with some recent changes to the build process and I > > don't know what it is yet. > If I remove SERIAL_POST from my config files then it builds. Note thats > _remove_ not set =0. > > ./arch/i386/include/arch/intel.h seems to be the offending section for me. > > It has a > > #if SERIAL_POST > > blah.. > CALLSP(console_tx_al) that's a good thing to know but a side-effect. I think the real problem is that the definitions of console_tx_al etc. should have a .globl with them and they don't. I'm going to try that. ron From rminnich at lanl.gov Tue Feb 11 10:14:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 10:14:00 2003 Subject: build problem for console_tx_al problem. Message-ID: This is interesting but not fun. Consider the file: ./src/arch/i386/lib/console.inc When I build now I get: linuxbios_c.o: In function `_start': linuxbios_c.o(.text+0x28): undefined reference to `console_tx_al' linuxbios_c.o(.text+0x35): undefined reference to `console_tx_hex8' linuxbios_c.o(.text+0x42): undefined reference to `console_tx_al' linuxbios_c.o(.text+0x7b): undefined reference to `console_tx_al' linuxbios_c.o(.text+0x88): undefined reference to `console_tx_hex8' linuxbios_c.o(.text+0x95): undefined reference to `console_tx_al' linuxbios_c.o(.text+0xa9): undefined reference to `console_tx_al' linuxbios_c.o(.text+0xb6): undefined reference to `console_tx_hex8' linuxbios_c.o(.text+0xc3): undefined reference to `console_tx_al' OK, let's try this: .globl console_tx_al console_tx_al: etc. etc. Now when I build I get: linuxbios.a(crt0.o): In function `_start': crt0.o(.rom.text+0x27): multiple definition of `_start' c_start.o(.text+0x0): first defined here What the @@@@? Well, what happened, is that the .o was pulled out of linuxbios.a since a symbol in that .o was used. But _start was also defined in there, with the result that we get the multiple definition problem. This looks like an outgrowth of the CONFIG_COMPRESS stuff; more as I learn it. ron From rminnich at lanl.gov Tue Feb 11 10:26:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 10:26:01 2003 Subject: linuxbios build problems Message-ID: I am going to continue on this but it will be slow, I have a lot going on. The basic problem as I see it is that there is a little more magic in the build process than it can stand, and specific platforms are breaking. In c_start.S and the constructed crt0.S there is a symbol called _start. Same name. There are also, in these files, a set of symbols that on some builds are needed for that build. So we need the .o from both files in some builds. But the conflicting _start symbols are causing trouble. Simple attempts to change the name of the start symbol (e.g. change _start in crt0.S to _machine_reset_start) lead to a host of other undefined symbols, since once the _start is undefined, that file is not pulled in and the symbols in that file are not resolved. I would rather not get into 'weak' symbols in assembly code files. Anyway, if anyone gets a chance to look at this and has some ideas ... let me know. But we need to fix this situation. ron From rminnich at lanl.gov Tue Feb 11 10:49:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 10:49:01 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On Tue, 11 Feb 2003, Ronald G. Minnich wrote: > In c_start.S and the constructed crt0.S there is a symbol called _start. > Same name. There are also, in these files, a set of symbols that on some > builds are needed for that build. So we need the .o from both files in > some builds. But the conflicting _start symbols are causing trouble. more summary: the problem is limited to those cases where someone wants to use SERIAL_POST. Seems pretty fixable. ron From minuo at mac.com Tue Feb 11 15:06:01 2003 From: minuo at mac.com (Nicholas Ault) Date: Tue Feb 11 15:06:01 2003 Subject: LinuxBIOS for fast boots Message-ID: <3E495C2B.5070301@mac.com> Hi, Curious to know: What do you think of the C3 offerings from cwlinux? Specifically I am looking to start quickly, so I am wanting to get a board pre-installed. I like best the M787CL+ boards with the 1Ghz C3 processor. I guess my real question is: Should I be looking at a DOC model or the "Local Disk" model which doesn't use a DOC(correct?)? I do and don't want just a turn key board, so I want one that works now, but I would like to be able to work on it or change things as I get more associated with the linuxbios. Can the non-DOC boards be flashed? Also, fast boot time is the key for me; which mode would be the best, and should I look at a different board/processor? Would CF->IDE adapter with the boot system on it help with this? Thanks! --minuo minuo at mac.com From drwho8 at worldnet.att.net Tue Feb 11 17:25:00 2003 From: drwho8 at worldnet.att.net (Gregg C Levine) Date: Tue Feb 11 17:25:00 2003 Subject: sourceforge cvs and wrong web page References: <3E3AE649.3080109@manoweb.com> Message-ID: <04f501c2d21f$193de0e0$a4b5580c@who5> Hello again from Gregg C Levine Sorry I'm late commenting. Been busy with other work. Sorry! It happens that the entry on the sourceforge web page, is indeed correct. Quite correct, as my e-mail address would say. I've been downloading stuff from CVS on sourceforge, for roughly two and half years now, nearly three, and that's exactly how I've done it. And if you were to check the web pages that the site puts up for CVS retrieval, they explain it that you need to go, down that route, actually they substitute project name for our project, but it is the exact same idea. Why? Did it work for you, otherwise? Gregg C Levine drwho8 at worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase. ----- Original Message ----- From: "Alessio Sangalli" To: Sent: Friday, January 31, 2003 4:10 PM Subject: sourceforge cvs and wrong web page > Hi. On http://www.linuxbios.org/developer/download/index.html you show > the commands to checkout linuxbioss from sourceforge cvs: > > cvs -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios > login > > cvs-z3 > -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios co > freebios > > this is wrong and "cvs.sourceforge.net" should be used (or you won't be > able to download anything). > > bye > as > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From riskin at 263.net Tue Feb 11 19:28:01 2003 From: riskin at 263.net (riskin at 263.net) Date: Tue Feb 11 19:28:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030212004542.01F7A1BBA3@smtp.x263.net> Hi,ron, >oh, wait, is this 2.2 kernel? I forget now. Yes. The kernel version is 2.2.14. Thanks. riskin From ollie at sis.com.tw Tue Feb 11 22:02:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Tue Feb 11 22:02:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030212004542.01F7A1BBA3@smtp.x263.net> References: <20030212004542.01F7A1BBA3@smtp.x263.net> Message-ID: <1045019668.1409.3.camel@ollie> On Wed, 2003-02-12 at 08:40, riskin at 263.net wrote: > Hi,ron, > > >oh, wait, is this 2.2 kernel? I forget now. > > Yes. The kernel version is 2.2.14. > > Thanks. > I don't think the 2.2.x kernel can set up IRQs correctly. Can you try 2.4.x kernel first ? -- ollie lho From rminnich at lanl.gov Tue Feb 11 22:14:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 11 22:14:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030212004542.01F7A1BBA3@smtp.x263.net> Message-ID: On Wed, 12 Feb 2003 riskin at 263.net wrote: > Hi,ron, > > >oh, wait, is this 2.2 kernel? I forget now. > > Yes. The kernel version is 2.2.14. I can't help you then. 2.2 just won't do the right things for IRQs. We're going to have to get linuxbios to set this stuff up. I made a first stab but ran out of time, will have to try again later. ron From ebiederman at lnxi.com Tue Feb 11 23:25:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 11 23:25:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On Wed, 12 Feb 2003 riskin at 263.net wrote: > > > Hi,ron, > > > > >oh, wait, is this 2.2 kernel? I forget now. > > > > Yes. The kernel version is 2.2.14. > > I can't help you then. 2.2 just won't do the right things for IRQs. 2.2 was o.k. with an SMP kernel, and an MP table in LinuxBIOS. The other cases it failed with. We were just happy when we could load 2.2 and we quickly switched to 2.3.x. The 2.4.x kernel code for assigning interrupts from irqs is not to bad, if you want to look at putting it into LinuxBIOS to support your 2.2.x kernel.... > We're going to have to get linuxbios to set this stuff up. > > I made a first stab but ran out of time, will have to try again > later. The interesting variant which is coming up is MSI. Interrupts over the pci bus, as specified in pci 2.3, pci-x 2.0 and pci-express. The interrupt story keeps getting more complicated, not less... Eric From steve at nexpath.com Wed Feb 12 00:00:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 00:00:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: Message-ID: > > > > Yes. The kernel version is 2.2.14. > > I can't help you then. 2.2 just won't do the right things for IRQs. > > We're going to have to get linuxbios to set this stuff up. > > I made a first stab but ran out of time, will have to try again later. > > ron I was able to get 2.2 IRQs to work with the stpc. Look at src/mainboard/stpc/consumer2/mainboard.c. The rest of the file is code to avoid a kernel patch for a non-supported router (in 2.4). -Steve From steve at nexpath.com Wed Feb 12 00:11:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 00:11:01 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: > > In c_start.S and the constructed crt0.S there is a symbol > called _start. > > Same name. There are also, in these files, a set of symbols that on some > > builds are needed for that build. So we need the .o from both files in > > some builds. But the conflicting _start symbols are causing trouble. > > more summary: the problem is limited to those cases where someone > wants to > use SERIAL_POST. > > Seems pretty fixable. > > ron Any more ideas on this? I chased it around a bit but there sure seems to be a symbol conflict on _start. -Steve From steve at nexpath.com Wed Feb 12 02:00:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 02:00:01 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: > > more summary: the problem is limited to those cases where someone > > wants to > > use SERIAL_POST. > > > > Seems pretty fixable. > > > > Any more ideas on this? I chased it around a bit but there sure > seems to be > a symbol conflict on _start. > Okay I see the point, these are separate pieces of code. Looks like the post is inlined unless SERIAL_POST is set, at which point console_tx_al is called in crt0. The address of console_tx_al is not fixed at the point c_start.o is linked. Not easy to fix, maybe someone else has some ideas. -Steve From ebiederman at lnxi.com Wed Feb 12 02:03:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 02:03:00 2003 Subject: linuxbios build problems In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > I am going to continue on this but it will be slow, I have a lot going on. > > The basic problem as I see it is that there is a little more magic in the > build process than it can stand, and specific platforms are breaking. > > In c_start.S and the constructed crt0.S there is a symbol called _start. > Same name. Yes but in different binaries. c_start.S and crt0.S should never be linked together. There is one binary that is all of the code before ram is initialized. And another that is code after ram is initialized. > There are also, in these files, a set of symbols that on some > builds are needed for that build. So we need the .o from both files in > some builds. But the conflicting _start symbols are causing trouble. How? What links them together? > Simple attempts to change the name of the start symbol (e.g. change _start > in crt0.S to _machine_reset_start) lead to a host of other undefined > symbols, since once the _start is undefined, that file is not pulled in > and the symbols in that file are not resolved. > > I would rather not get into 'weak' symbols in assembly code files. > > Anyway, if anyone gets a chance to look at this and has some ideas ... let > me know. But we need to fix this situation. I need to see what the real problem that is linking together two different binaries before I can give a good suggestion. Eric From ebiederman at lnxi.com Wed Feb 12 02:04:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 02:04:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <1044840680.15657.12.camel@contact.skynet.coplanar.net> References: <20030210011059.0146C1BE7F@smtp.x263.net> <1044840680.15657.12.camel@contact.skynet.coplanar.net> Message-ID: Jeremy Jackson writes: > On Sun, 2003-02-09 at 20:05, riskin at 263.net wrote: > > Hi,Andrew > > > > >Have you set kernel to use direct pci probe? > > > > I have set "any" mode to probe pci devices. > > That could be a problem since "any" mode tries PC BIOS calls first, > which LinuxBIOS doesn't have. But it only can try them if a pcbios table is present which is also absent so "any" mode should be safe under LinuxBIOS. Eric From ebiederman at lnxi.com Wed Feb 12 02:07:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 02:07:00 2003 Subject: build problem for console_tx_al problem. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > This is interesting but not fun. > > Consider the file: > ./src/arch/i386/lib/console.inc > > When I build now I get: > linuxbios_c.o: In function `_start': > linuxbios_c.o(.text+0x28): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x35): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0x42): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x7b): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x88): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0x95): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0xa9): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0xb6): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0xc3): undefined reference to `console_tx_al' It looks like serial.inc or whatever the lowlevel console include is not included. Why the reference have all become lower case is beyond me. > OK, let's try this: > .globl console_tx_al > console_tx_al: > etc. etc. > > Now when I build I get: > > linuxbios.a(crt0.o): In function `_start': > crt0.o(.rom.text+0x27): multiple definition of `_start' > c_start.o(.text+0x0): first defined here > > What the @@@@? > > Well, what happened, is that the .o was pulled out of linuxbios.a since a > symbol in that .o was used. But _start was also defined in there, with the > result that we get the multiple definition problem. It looks like you put the .globl in another part and the fact that we are even looking in linuxbios.a may be a problem. > This looks like an outgrowth of the CONFIG_COMPRESS stuff; more as I learn > it. The later failures yes but not the original. Eric From ebiederman at lnxi.com Wed Feb 12 02:44:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 02:44:00 2003 Subject: linuxbios build problems In-Reply-To: References: Message-ID: "Steve M. Gehlbach" writes: > > > more summary: the problem is limited to those cases where someone > > > wants to > > > use SERIAL_POST. > > > > > > Seems pretty fixable. > > > > > > > Any more ideas on this? I chased it around a bit but there sure > > seems to be > > a symbol conflict on _start. > > > > Okay I see the point, these are separate pieces of code. Looks like the > post is inlined unless SERIAL_POST is set, at which point console_tx_al is > called in crt0. The address of console_tx_al is not fixed at the point > c_start.o is linked. Not easy to fix, maybe someone else has some ideas. O.k. I believe I see what is going on. When CONFIG_COMPRESS was introduced intel_chip_post simply yielded a post code. So it was safe to call it both from both binaries. Then someone modified intel_chip_post to change it's behavior when SERIAL_POST is called to output the post code to the serial port. That is so bad, and broken. It breaks the compile of c_start.S because it attempts to call code in another binary. It potentially breaks all callers of intel_chip_post because the set of registers stomped has gone from %al to: %eax %esp %edx Extremely unexpected. If we want post codes to show up on the serial port even from the assembly code we need to introduce another macro, and carefully replace the users of intel_chip_post. Rather than change the calling conventions of intel_chip_post. So for the short term the proper fix is to revert the recent change to intel_chip_post.... Eric From aip at cwlinux.com Wed Feb 12 02:52:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Feb 12 02:52:01 2003 Subject: build problem for console_tx_al problem. In-Reply-To: ; from Ronald G. Minnich on Tue, Feb 11, 2003 at 08:32:34AM -0700 References: Message-ID: <20030212161033.A32471@mail.cwlinux.com> Ron, > This is interesting but not fun. > Consider the file: > ./src/arch/i386/lib/console.inc > > When I build now I get: > linuxbios_c.o: In function `_start': > linuxbios_c.o(.text+0x28): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x35): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0x42): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x7b): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0x88): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0x95): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0xa9): undefined reference to `console_tx_al' > linuxbios_c.o(.text+0xb6): undefined reference to `console_tx_hex8' > linuxbios_c.o(.text+0xc3): undefined reference to `console_tx_al' > OK, let's try this: > .globl console_tx_al > console_tx_al: > etc. etc. It's related to src/arch/i386/include/arch/intel.h which I checked in for EPIA. I have removed those changes. It should build now. Sorry guys, I should have double check this. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From rminnich at lanl.gov Wed Feb 12 09:18:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 09:18:00 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On Tue, 11 Feb 2003, Steve M. Gehlbach wrote: > > more summary: the problem is limited to those cases where someone > > wants to > > use SERIAL_POST. > Any more ideas on this? I chased it around a bit but there sure seems to be > a symbol conflict on _start. ideas but not time, but I have a kludgy fix that will work for now; I'll try to commit today. ron From rminnich at lanl.gov Wed Feb 12 09:22:59 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 09:22:59 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On 12 Feb 2003, Eric W. Biederman wrote: > Yes but in different binaries. c_start.S and crt0.S should never be linked > together. agreed. But they seem to be ending up in linuxbios.a, and that's part of the problem. > There is one binary that is all of the code before ram is > initialized. And another that is code after ram is initialized. understood. > How? What links them together? the makefile. > I need to see what the real problem that is linking together two different > binaries before I can give a good suggestion. This will happen for the ms7308 mainboards if SERIAL_POST is defined. ron From rminnich at lanl.gov Wed Feb 12 09:27:26 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 09:27:26 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On 12 Feb 2003, Eric W. Biederman wrote: > Then someone modified intel_chip_post to change it's behavior > when SERIAL_POST is called to output the post code to the serial port. OK, will the guilty party please confess to me in private no need to bother the list :-) > If we want post codes to show up on the serial port even from the assembly > code we need to introduce another macro, and carefully replace the users > of intel_chip_post. Rather than change the calling conventions of > intel_chip_post. ok. I'll do that. But I'm not sure it is a good idea to have a common linuxbios.a for both the compressed image and the initial image. The error was very hard for people to understand. At least this is what I think is going on, since symbols from one image were referenced from another, and the only way I could see this happening was that the 1st and 2nd stage symbols were all in the one .a comments? ron From rminnich at lanl.gov Wed Feb 12 09:29:38 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 09:29:38 2003 Subject: build problem for console_tx_al problem. In-Reply-To: <20030212161033.A32471@mail.cwlinux.com> Message-ID: On Wed, 12 Feb 2003, Andrew Ip wrote: > It's related to src/arch/i386/include/arch/intel.h which I checked in > for EPIA. I have removed those changes. It should build now. Sorry guys, > I should have double check this. > it's why being a committer is a double-edged sword. One little mistake and ... :-) thanks for fixing this, andrew. ron From ebiederman at lnxi.com Wed Feb 12 10:01:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 10:01:01 2003 Subject: linuxbios build problems In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 12 Feb 2003, Eric W. Biederman wrote: > > > Then someone modified intel_chip_post to change it's behavior > > when SERIAL_POST is called to output the post code to the serial port. > > OK, will the guilty party please confess to me in private no need to > bother the list :-) > > > If we want post codes to show up on the serial port even from the assembly > > code we need to introduce another macro, and carefully replace the users > > of intel_chip_post. Rather than change the calling conventions of > > intel_chip_post. > > ok. I'll do that. > > But I'm not sure it is a good idea to have a common linuxbios.a for both > the compressed image and the initial image. The error was very hard for > people to understand. At least this is what I think is going on, since > symbols from one image were referenced from another, and the only way I > could see this happening was that the 1st and 2nd stage symbols were all > in the one .a > > comments? I am not certain this is happening. I guess we need to track down the multiple _start issue and see how that was triggered. In general everything in the 1st stage is included into crt0.S, so it has no need to look at linuxbios.a. So if something needs to happen it should just be a small tweak of the rules. Ron you added a global to crt0.S and crt0.o was then linked with the 2nd stage. I guess the bug is that somehow crt0.o is being added to linuxbios.a. That looks like a leftover from before CONFIG_COMPRESS. O.k. I have tracked the problem down. crt0.o is being manually added to OBJECTS-1 by util/config/NLBConfig.py. And OBJECTS-1 is used to populate linuxbios.a So we should be able to change one line of code and the multiple _start issue will go away. Part of the problem was is that someone was using 1st stage defines in the 2nd stage, which is quiet unexpected. intel_chip_post is possibly the one define that is safe to use both places. Eric From rminnich at lanl.gov Wed Feb 12 11:13:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 11:13:01 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On 12 Feb 2003, Eric W. Biederman wrote: > Part of the problem was is that someone was using 1st stage defines > in the 2nd stage, which is quiet unexpected. intel_chip_post is > possibly the one define that is safe to use both places. no argument that it was a mistake in what the person did, my only concern was that so many (me too!) got so confused :-) I love the compressed 2nd stage ... you were right, the shrinkage is very useful. My fallback now does log level 9 (!) and still fits in 40k! ron From sanjuresearch at hotmail.com Wed Feb 12 11:54:00 2003 From: sanjuresearch at hotmail.com (Sanjay lal) Date: Wed Feb 12 11:54:00 2003 Subject: questions Message-ID: hello, I had a few questions regarding linuxbios: 1) Does it support tftpboot,bootp etc? 2) Does it support GDB stubs for debugging? 3) Are there any licensing issues involved if used? Any information is of great help. thanks in advance Sanju _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From stutts at innocon.com Wed Feb 12 12:14:01 2003 From: stutts at innocon.com (Christopher Stutts) Date: Wed Feb 12 12:14:01 2003 Subject: questions In-Reply-To: References: Message-ID: <1045071229.9994.11.camel@powerbrick.innocon.com> On Wed, 2003-02-12 at 12:13, Sanjay lal wrote: > > 2) Does it support GDB stubs for debugging? If you shell out the bucks for an x86 JTAG ICE from American Arium and compile with -gdwarf-2, you can do source level debug. From steve at nexpath.com Wed Feb 12 12:17:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 12:17:00 2003 Subject: vga/pcx file additions In-Reply-To: Message-ID: Ron: I sent some diffs to you the other day for vga etc. that don't seem to be in the repository yet. Should I send them to you again? The changes expanded the vga splash screen file formats and also added STATUS files to the two motherboards I support. -Steve From rminnich at lanl.gov Wed Feb 12 12:19:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 12:19:00 2003 Subject: questions In-Reply-To: Message-ID: On Wed, 12 Feb 2003, Sanjay lal wrote: > 3) Are there any licensing issues involved if used? GPL. If you use it you have to release any mainboard support you write back to the source tree. ron From steve at nexpath.com Wed Feb 12 12:23:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 12:23:00 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: > On 12 Feb 2003, Eric W. Biederman wrote: > > > Part of the problem was is that someone was using 1st stage defines > > in the 2nd stage, which is quiet unexpected. intel_chip_post is > > possibly the one define that is safe to use both places. > > no argument that it was a mistake in what the person did, my only concern > was that so many (me too!) got so confused :-) > > I love the compressed 2nd stage ... you were right, the shrinkage is very > useful. My fallback now does log level 9 (!) and still fits in 40k! > > ron Maybe we could set a #define STAGE2 at the top of c_start.S, and ifdef in intel.h on STAGE2. The serial posts are useful to me since I am a holdout on getting a PCI post board. -Steve From rminnich at lanl.gov Wed Feb 12 12:27:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 12:27:00 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: On Wed, 12 Feb 2003, Steve M. Gehlbach wrote: > Maybe we could set a #define STAGE2 at the top of c_start.S, and ifdef in > intel.h on STAGE2. The serial posts are useful to me since I am a holdout > on getting a PCI post board. that and the fact that POST cards won't even work in some new motherboards. ron From rminnich at lanl.gov Wed Feb 12 12:33:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 12:33:01 2003 Subject: vga/pcx file additions In-Reply-To: Message-ID: yes, please resend, I'm sorry. ron From alesan at manoweb.com Wed Feb 12 14:38:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Wed Feb 12 14:38:01 2003 Subject: ecs k7som + other supported chipsets Message-ID: <3E4AA759.5040507@manoweb.com> Is there any support for ecs k7som (sis 740) or other DDR athlon motherboards? unfortunately pchips 810 has only 2 pci slots, and we need three. I can easily find newer motherboards with DDR chipsets here, that's why I ask about linuxbios support for those. What is the difference between t30d and 730s? are they both supported? The ideal solution would be a motherboard with integrated digital audio, but I think only VIA chipsets offer this. How is the situation from this point of view? bye as -- How to build a lirc receiver http://www.manoweb.com/alesan/lirc From rminnich at lanl.gov Wed Feb 12 15:41:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 12 15:41:01 2003 Subject: supermicro p4dpe-g2 Message-ID: I have just committed a better mptable for the supermicro p4dpe-g2 This fixed a minor problem with a PCI slot IRQ setup. This board now has correct PIRQ and MPTABLE support. ron From rsmith at bitworks.com Wed Feb 12 17:51:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Wed Feb 12 17:51:01 2003 Subject: SPD issues In-Reply-To: References: Message-ID: <3E4AD3F3.9050405@bitworks.com> Ok. Under the excellent guidance of Ron I finally got LinuxBIOS to boot on our custom 440bx board by hardcoding the right values into the DRB and page size registers. The problem seems to be that linuxBIOS dosen't detect the RAM properly in row 0. Its seems to be setting it up at row 1. I've been trying to use dump_spd_registers to see if I can figure out whats going on but all I seem to get is something more or less like the following: dimm 50 dimm 51 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 I've played with SMBUS_MEM_DEVICE_START but I still just get 04's. What's the standard adress for the spd info? If this is truly what linuxbios is getting back from the spd then I can see why its confused. From adam at cfar.umd.edu Wed Feb 12 17:55:00 2003 From: adam at cfar.umd.edu (Adam Sulmicki) Date: Wed Feb 12 17:55:00 2003 Subject: questions In-Reply-To: Message-ID: <20030212182919.X22696-100000@www.missl.cs.umd.edu> > I had a few questions regarding linuxbios: > 1) Does it support tftpboot,bootp etc? yes, but not directly. you will have to place 'etherboot' on top of LinuxBIOS. But then that's the idea. That is : having an modular bios. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From ebiederman at lnxi.com Wed Feb 12 18:16:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 12 18:16:00 2003 Subject: linuxbios build problems In-Reply-To: References: Message-ID: "Steve M. Gehlbach" writes: > > On 12 Feb 2003, Eric W. Biederman wrote: > > > > > Part of the problem was is that someone was using 1st stage defines > > > in the 2nd stage, which is quiet unexpected. intel_chip_post is > > > possibly the one define that is safe to use both places. > > > > no argument that it was a mistake in what the person did, my only concern > > was that so many (me too!) got so confused :-) > > > > I love the compressed 2nd stage ... you were right, the shrinkage is very > > useful. My fallback now does log level 9 (!) and still fits in 40k! > > > > ron > > Maybe we could set a #define STAGE2 at the top of c_start.S, and ifdef in > intel.h on STAGE2. The serial posts are useful to me since I am a holdout > on getting a PCI post board. And I have one but have never actually used it. intel_chip_post cannot be modified to output to the serial port. That requires more registers, making it an unsafe transformation. The result would likely be mysterious breakage instead of the obvious breakage we see now. Having an alternative macro that we use where it is safe is a reasonable solution. And for that we can simply not place it in c_start.S Eric From steve at nexpath.com Wed Feb 12 19:07:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 19:07:01 2003 Subject: linuxbios build problems In-Reply-To: Message-ID: > > Maybe we could set a #define STAGE2 at the top of c_start.S, > and ifdef in > > intel.h on STAGE2. The serial posts are useful to me since I > am a holdout > > on getting a PCI post board. > > And I have one but have never actually used it. > > intel_chip_post cannot be modified to output to the serial port. That > requires more registers, making it an unsafe transformation. > > The result would likely be mysterious breakage instead of the obvious > breakage we see now. > > Having an alternative macro that we use where it is safe is a reasonable > solution. And for that we can simply not place it in c_start.S > > Eric Right, it doesn't seem like we will get a serial post output in c_start.S without a lot of work. But it is nice to have it everywhere else. I thought a STAGE2 define in intel.h and c_start.S would help document the fact that stage2 was "different" and be a minimal change. I suppose we should also keep in mind that the post macro is only two lines of code... -Steve From riskin at 263.net Wed Feb 12 20:43:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Wed Feb 12 20:43:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030213015858.5AC581BCB0@smtp.x263.net> ----- Original Message ----- From: "(Eric W. Biederman)" To: "Ronald G. Minnich" Cc: , Sent: 2003-02-12 20:44:11 Subject: Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard >2.2 was o.k. with an SMP kernel, and an MP table in LinuxBIOS. The >other cases it failed with. We were just happy when we could load 2.2 >and we quickly switched to 2.3.x. The 2.4.x kernel code for assigning >interrupts from irqs is not to bad, if you want to look at putting >it into LinuxBIOS to support your 2.2.x kernel.... > >> We're going to have to get linuxbios to set this stuff up. >> >> I made a first stab but ran out of time, will have to try again >> later. > >The interesting variant which is coming up is MSI. Interrupts >over the pci bus, as specified in pci 2.3, pci-x 2.0 and pci-express. > >The interrupt story keeps getting more complicated, not less... > >Eric Does your mainboad support APIC? I think that if The SMP kernel is ok,the mainboard must support APIC. If the mainboad doesn't support APIC,maybe the kernel need support IRQ route table. But the 2.2.x kernel doesn't support parsing the IRQ route table supplied by LinuxBIOS. But the mainboad(sis630 chip set) used by me doesn't support it,according to ollie.( ollie at sis.com.tw) Is the sis630 chip set wired as following? * INTA INTB INTC INTD * ---------------------------- * slot 1: dev=0x9 wiring: PIRQ_C PIRQ_D PIRQ_A PIRQ_B * slot 2: dev=0xb wiring: PIRQ_B PIRQ_C PIRQ_D PIRQ_A * slot 3: dev=0xd wiring: PIRQ_A PIRQ_B PIRQ_C PIRQ_D In "freebios/src/northsouthbridge/sis/630/southbridge.c" ......... #ifdef OLD_KERNEL_HACK struct pci_dev *pcidev; pcidev = pci_find_device(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, (void *)NULL); if (pcidev != NULL) { printk_info("Remapping IRQ on southbridge for OLD_KERNEL_HACK\n"); // remap IRQ for PCI -- this is exactly what the BIOS does now. pci_write_config_byte(pcidev, 0x42, 0xa); pci_write_config_byte(pcidev, 0x43, 0xb); pci_write_config_byte(pcidev, 0x44, 0xc); } // ethernet fixup. This should all work, and doesn't, yet. // so we hack it for now. // need a manifest constant for the enet device. pcidev = pci_find_device(PCI_VENDOR_ID_SI, 0x0900, (void *)NULL); if (pcidev != NULL) { u32 bar0 = 0xb001; // set the BAR 0 to 0xb000. Safe, high value, known good. // pci config set doesn't work for reasons we don't understand. pci_write_config_dword(pcidev, PCI_BASE_ADDRESS_0, bar0); // Make sure bus mastering is on. The tried-and-true probe in linuxpci.c // doesn't set this for some reason. pci_write_config_byte(pcidev, PCI_COMMAND, PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); // set the interrupt to 'b' pci_write_config_byte(pcidev, PCI_INTERRUPT_LINE, 0xb); } else { printk_err("Can't find ethernet interface\n"); } #endif /* OLD_KERNEL_HACK */ ........ So, I modified mainboard.c in "freebios/src/mainboard/pcchips/m758lmr+" as following: /**********************************************************************/ #include #include #include #include #include #include #define IRQ1 11 #define IRQ2 12 #define IRQ3 10 #define CONFIG_CMD(bus,devfn, where) (0x80000000 | (bus << 16) | (devfn << 8) | (where & ~3)) #define INTERRUPT_PIN 0x3d #define INTERRUPT_LINE 0x3c #define BUS 0 extern struct irq_routing_table intel_irq_routing_table; void mainboard_fixup(void) { } static int pci_conf1_read_config_word(unsigned char bus, int devfn, int where, u16 * value) { outl(CONFIG_CMD(bus, devfn, where), 0xCF8); *value = inw(0xCFC + (where & 2)); return 0; } static int pci_conf1_write_config_byte(unsigned char bus, int devfn, int where, u8 value) { outl(CONFIG_CMD(bus, devfn, where), 0xCF8); outb(value, 0xCFC + (where & 3)); return 0; } static int pci_conf1_read_config_byte(unsigned char bus, int devfn, int where, u8 * value) { outl(CONFIG_CMD(bus, devfn, where), 0xCF8); *value = inb(0xCFC + (where & 3)); return 0; } // // calculate the irq_tables checksum // int calc_checksum(struct irq_routing_table *rt) { long i; u8 *addr,sum2=0; addr= (u8 *) rt; for (i=0;isize;i++) sum2 += addr[i]; return(sum2); } static void pci_irq_route_fixup() { u8 pin, devfn, irq, irq_written, stpc_reg; u8 irq_list[] = { IRQ1, IRQ2, IRQ3 }; // pirq(slot,pin); slot[0:2] pin[0:3] u8 pirq[3][4] = { {2,3,0,1},{1,2,3,0},{0,1,2,3}}; u16 vendor_id, mask; int i,j; printk_debug("pci_irq_route_fixup()\n"); mask = (1< pin %d\n",0x9+i,pin); pin--; // we start at 0: pin 0-3 -> INTA-D // get the next irq in our list irq = irq_list[j++]; // program the pci registers pci_conf1_write_config_byte(BUS,devfn,INTERRUPT_LINE,irq); pci_conf1_read_config_byte(BUS,devfn,INTERRUPT_LINE,&irq_written); printk_debug("sis630 pci_irq_route_fixup(): wrote pci INTERRUPT_LINE for dev 0x%x -> irq %d (%d)\n", PCI_SLOT(devfn),irq,irq_written); // set the routing table // The 0xf0 causes linux to consider the irq hard-wired and use the link value // as the actual irq, so it does not need a router for the stpc. // Otherwise a kernel patch would be needed to add the stpc router into arch/i386/kernel/pci-irq.c intel_irq_routing_table.slots[i+2].irq[pin].link = irq | 0xf0; intel_irq_routing_table.slots[i+2].irq[pin].bitmap = mask; printk_debug("irq routing_table.slots[%d].irq[%d].link,mask = 0x%x,0x%x\n",i+2,pin, intel_irq_routing_table.slots[i+2].irq[pin].link, intel_irq_routing_table.slots[i+2].irq[pin].bitmap ); } // // Now... // set the checksum in the routing table; // intel_irq_routing_table.checksum = 0; intel_irq_routing_table.checksum = -calc_checksum( (struct irq_routing_table *) &intel_irq_routing_table); printk_debug("sis630 pci_irq_route_fixup(): checksum calculated= 0x%x\n",intel_irq_routing_table.checksum); printk_debug("sis630 pci_irq_route_fixup complete.\n"); } void final_mainboard_fixup(void) { void final_southbridge_fixup(void); void final_superio_fixup(void); printk_info("PCCHIPS m758lmr+ (and similar)..."); final_southbridge_fixup(); pci_irq_route_fixup(); #ifndef USE_NEW_SUPERIO_INTERFACE final_superio_fixup(); #endif } /************************************************/ Then,I pluged my RTL8139 NIC into slot#1(PCI1). After my box started,the IRQ of RTL8139 is 11. But when I did "ping",I got following messages: /**************************************************/ #ifconfig eth1 192.168.0.165 up eth1: RTL8139 Interrupt line blocked, status 1. #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 21 packets transmitted, 0 packets received, 100% packet loss #neighbour table overflow neighbour table overflow neighbour table overflow #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 20 packets transmitted, 0 packets received, 100% packet loss #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. neighbour table overflow neighbour table overflow neighbour table overflow --- 192.168.0.1 ping statistics --- 21 packets transmitted, 0 packets received, 100% packet loss #neighbour table overflow neighbour table overflow neighbour table overflow ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 14 packets transmitted, 0 packets received, 100% packet loss #eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. neighbour table overflow neighbour table overflow neighbour table overflow #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 15 packets transmitted, 0 packets received, 100% packet loss #eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. neighbour table overflow #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 17 packets transmitted, 0 packets received, 100% packet loss #NET: 2 messages suppressed. neighbour table overflow eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 14 packets transmitted, 0 packets received, 100% packet loss #NET: 2 messages suppressed. neighbour table overflow ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. --- 192.168.0.1 ping statistics --- 20 packets transmitted, 0 packets received, 100% packet loss #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. --- 192.168.0.1 ping statistics --- 21 packets transmitted, 0 packets received, 100% packet loss #NET: 5 messages suppressed. neighbour table overflow eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. --- 192.168.0.1 ping statistics --- 21 packets transmitted, 0 packets received, 100% packet loss #NET: 2 messages suppressed. neighbour table overflow neighbour table overflow eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: RTL8139 Interrupt line blocked, status 5. --- 192.168.0.1 ping statistics --- 18 packets transmitted, 0 packets received, 100% packet loss #ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) from 192.168.0.165 : 72(100) bytes of data. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 8 dirty entry 4. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. /*************************************************/ The critical messages are: eth1: RTL8139 Interrupt line blocked, status 1. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 8 dirty entry 4. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. eth1: Transmit timeout, status 0c 0005 media 18. eth1: Tx queue start entry 4 dirty entry 0. Could you give me some advice to resolve them? Thanks. riskin ========================== 263??????????? From ollie at sis.com.tw Wed Feb 12 21:17:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed Feb 12 21:17:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030213015858.5AC581BCB0@smtp.x263.net> References: <20030213015858.5AC581BCB0@smtp.x263.net> Message-ID: <1045103540.1292.2.camel@ollie> On Thu, 2003-02-13 at 09:53, riskin at 263.net wrote: > > Does your mainboad support APIC? > > I think that if The SMP kernel is ok,the mainboard must support APIC. > If the mainboad doesn't support APIC,maybe the kernel need support IRQ route table. > But the 2.2.x kernel doesn't support parsing the IRQ route table supplied by LinuxBIOS. > But the mainboad(sis630 chip set) used by me doesn't support it,according to ollie.( ollie at sis.com.tw) > > Is the sis630 chip set wired as following? > > > * INTA INTB INTC INTD > * ---------------------------- > * slot 1: dev=0x9 wiring: PIRQ_C PIRQ_D PIRQ_A PIRQ_B > * slot 2: dev=0xb wiring: PIRQ_B PIRQ_C PIRQ_D PIRQ_A > * slot 3: dev=0xd wiring: PIRQ_A PIRQ_B PIRQ_C PIRQ_D > The IRQ routing depends on the layout of the mainboard and has nothing to do with chipset (in general). You can not use the SiS 630 hack designed for winfast 6300 for your board. Ollie From riskin at 263.net Wed Feb 12 21:17:33 2003 From: riskin at 263.net (riskin at 263.net) Date: Wed Feb 12 21:17:33 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030213023428.E86791BCA1@smtp.x263.net> >I don't think the 2.2.x kernel can set up IRQs correctly. Can you try >2.4.x kernel first ? >ollie lho I have tried 2.4.17 kernel,solt1 and solt2 can work normally. Though solt3 can get IRQ,it can't work. Could you tell me how the mainboard(pcchips m758lmr+: sis630 chip set) IRQ lines is wired? Is the pcchips m758lmr+(sis630 chip set) wired as following? * INTA INTB INTC INTD * ---------------------------- * slot 1: dev=0x9 wiring: PIRQ_C PIRQ_D PIRQ_A PIRQ_B * slot 2: dev=0xb wiring: PIRQ_B PIRQ_C PIRQ_D PIRQ_A * slot 3: dev=0xd wiring: PIRQ_A PIRQ_B PIRQ_C PIRQ_D Thanks. riskin ========================== 263??????????? From ollie at sis.com.tw Wed Feb 12 21:21:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed Feb 12 21:21:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030213015858.5AC581BCB0@smtp.x263.net> References: <20030213015858.5AC581BCB0@smtp.x263.net> Message-ID: <1045103652.1291.5.camel@ollie> On Thu, 2003-02-13 at 09:53, riskin at 263.net wrote: > ----- Original Message ----- > From: "(Eric W. Biederman)" > To: "Ronald G. Minnich" > Cc: , > Sent: 2003-02-12 20:44:11 > Subject: Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard > > > >2.2 was o.k. with an SMP kernel, and an MP table in LinuxBIOS. The > >other cases it failed with. We were just happy when we could load 2.2 > >and we quickly switched to 2.3.x. The 2.4.x kernel code for assigning > >interrupts from irqs is not to bad, if you want to look at putting > >it into LinuxBIOS to support your 2.2.x kernel.... > > > >> We're going to have to get linuxbios to set this stuff up. > >> > >> I made a first stab but ran out of time, will have to try again > >> later. > > > >The interesting variant which is coming up is MSI. Interrupts > >over the pci bus, as specified in pci 2.3, pci-x 2.0 and pci-express. > > > >The interrupt story keeps getting more complicated, not less... > > > >Eric > > Does your mainboad support APIC? > > I think that if The SMP kernel is ok,the mainboard must support APIC. > If the mainboad doesn't support APIC,maybe the kernel need support IRQ route table. > But the 2.2.x kernel doesn't support parsing the IRQ route table supplied by LinuxBIOS. > But the mainboad(sis630 chip set) used by me doesn't support it,according to ollie.( ollie at sis.com.tw) > > Is the sis630 chip set wired as following? > > > * INTA INTB INTC INTD > * ---------------------------- > * slot 1: dev=0x9 wiring: PIRQ_C PIRQ_D PIRQ_A PIRQ_B > * slot 2: dev=0xb wiring: PIRQ_B PIRQ_C PIRQ_D PIRQ_A > * slot 3: dev=0xd wiring: PIRQ_A PIRQ_B PIRQ_C PIRQ_D > BTW, I don' think 2.2.x kernel has the code to program th IRQ router in the chipset neither. -- ollie lho From ollie at sis.com.tw Wed Feb 12 21:24:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed Feb 12 21:24:01 2003 Subject: ecs k7som + other supported chipsets In-Reply-To: <3E4AA759.5040507@manoweb.com> References: <3E4AA759.5040507@manoweb.com> Message-ID: <1045103995.1291.9.camel@ollie> On Thu, 2003-02-13 at 03:58, Alessio Sangalli wrote: > Is there any support for ecs k7som (sis 740) or other DDR athlon > motherboards? unfortunately pchips 810 has only 2 pci slots, and we need > three. I can easily find newer motherboards with DDR chipsets here, > that's why I ask about linuxbios support for those. > There is support for 735 with DDR. It should not take to much effort to port to 740. The only problem is that you have to sign NDA of some kind to get the register spec/bios programming guide from SiS. > What is the difference between t30d and 730s? are they both supported? > Do you mean 730d ?? I never heard of that. > The ideal solution would be a motherboard with integrated digital audio, > but I think only VIA chipsets offer this. How is the situation from this > point of view? > > What integrated digital audio ?? SiS 740 has AC97 controller similar to i810's. -- ollie lho From ollie at sis.com.tw Wed Feb 12 21:40:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed Feb 12 21:40:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030213023428.E86791BCA1@smtp.x263.net> References: <20030213023428.E86791BCA1@smtp.x263.net> Message-ID: <1045104890.1290.13.camel@ollie> On Thu, 2003-02-13 at 10:29, riskin at 263.net wrote: > >I don't think the 2.2.x kernel can set up IRQs correctly. Can you try > >2.4.x kernel first ? > >ollie lho > > I have tried 2.4.17 kernel,solt1 and solt2 can work normally. > Though solt3 can get IRQ,it can't work. > > Could you tell me how the mainboard(pcchips m758lmr+: sis630 chip set) IRQ lines is wired? > > Is the pcchips m758lmr+(sis630 chip set) wired as following? > > > * INTA INTB INTC INTD > * ---------------------------- > * slot 1: dev=0x9 wiring: PIRQ_C PIRQ_D PIRQ_A PIRQ_B > * slot 2: dev=0xb wiring: PIRQ_B PIRQ_C PIRQ_D PIRQ_A > * slot 3: dev=0xd wiring: PIRQ_A PIRQ_B PIRQ_C PIRQ_D > I don't know. You should ask pcchips. Only mainboard vendor knows how they layout their boards. -- ollie lho From steve at nexpath.com Wed Feb 12 22:59:01 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 12 22:59:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030213015858.5AC581BCB0@smtp.x263.net> Message-ID: > eth1: RTL8139 Interrupt line blocked, status 1. > > Could you give me some advice to resolve them? > > > riskin You can delete the route table stuff as it is not used in 2.2 and will work as per standard linuxbios (irq_tables.c) in 2.4. The forced routing was only necessary for the stpc which the Linux kernel does not support. As for INTA/B/C/D, this is strictly a motherboard wiring issue. Each PCI plug-in card connects to an interrupt line (if it uses one), these are called in the pci spec as PIRQA,B,C,D. The plug in card usually only uses one, typically. That line is wired from the slot on the motherboard to a corresponding INT line of the bridge (ie, the sis630), these are called INTA,B,C,D. For example, on the Sis630, INTA is pin K5, INTB is pin J5, etc. The wiring is cycled around on the motherboard and the slots to equalize the use of the interrupts. Which PIRQ the card hooks to depends on the card design. You need to program the sis630 to tell it which INTA,B,C,D should be hooked to which conventional interrupt line, irq 10,11, etc (this is calling routing). Further, you need to inform the Linux driver which irq to use as well. Reading the INTERRUPT_PIN PCI register (of the plug-in card) reports which PIRQ is being used by the card, if it is non-zero. You then program the INTERRUPT_LINE register (on the card), based on the motherboard wiring, and router programming, to indicate which IRQ this PIRQ ultimately leads to. It appears to me that the INTERRUPT_LINE register as programmed for 2.2 is simply informational to the Linux driver, and not actually used by the card. I may have that wrong, though, I am not an expert on PCI. But it does not seem to be used on 2.4 at all. I think the problem is you have programmed the RTL8139 PCI register, but you have not programmed the routing of PIRQ->interrupt in the bridge, and you really don't know the motherboard wiring. So the driver gets the IRQ, but it doesn't actually work (not routed). You are not sure whether it is INTA,B,C or D. You could figure this out by running 2.4 and getting the routing table, but you could also experiment and figure it out. Net cards are perfect for this experiment since they simply won't work without an IRQ but yet they don't seem to hang or crash Linux otherwise. The bridge can be programmed as detailed in the 2.4 kernel, in arch/i386/kernel/pci_irq.c, for the sis chip. The vendor id is 1039H and the device id is 0008H, known as the LPC Bridge portion of the sis630, and the registers are 0x41-44 corresponding to INTA-D. The 2.4 code relevant to the sis is pretty short, and is quoted below. I think the comment about values 1-4 is how the BIOS routing table is written, and has nothing to do with the sis bridge. /* * PIRQ routing for SiS 85C503 router used in several SiS chipsets * According to the SiS 5595 datasheet (preliminary V1.0, 12/24/1997) * the related registers work as follows: * * general: one byte per re-routable IRQ, * bit 7 IRQ mapping enabled (0) or disabled (1) * bits [6:4] reserved * bits [3:0] IRQ to map to * allowed: 3-7, 9-12, 14-15 * reserved: 0, 1, 2, 8, 13 * * individual registers in device config space: * * 0x41/0x42/0x43/0x44: PCI INT A/B/C/D - bits as in general case * * 0x61: IDEIRQ: bits as in general case - but: * bits [6:5] must be written 01 * bit 4 channel-select primary (0), secondary (1) * * 0x62: USBIRQ: bits as in general case - but: * bit 4 OHCI function disabled (0), enabled (1) * * 0x6a: ACPI/SCI IRQ - bits as in general case * * 0x7e: Data Acq. Module IRQ - bits as in general case * * Apparently there are systems implementing PCI routing table using both * link values 0x01-0x04 and 0x41-0x44 for PCI INTA..D, but register offsets * like 0x62 as link values for USBIRQ e.g. So there is no simple * "register = offset + pirq" relation. * Currently we support PCI INTA..D and USBIRQ and try our best to handle * both link mappings. * IDE/ACPI/DAQ mapping is currently unsupported (left untouched as set by BIOS). */ static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq, int irq) { u8 x; int reg = pirq; switch(pirq) { case 0x01: case 0x02: case 0x03: case 0x04: reg += 0x40; case 0x41: case 0x42: case 0x43: case 0x44: case 0x62: x = (irq&0x0f) ? (irq&0x0f) : 0x80; if (reg != 0x62) break; /* always mark OHCI enabled, as nothing else knows about this */ x |= 0x40; break; case 0x61: case 0x6a: case 0x7e: printk(KERN_INFO "advanced SiS pirq mapping not yet implemented\n"); return 0; default: printk(KERN_INFO "SiS router pirq escape (%d)\n", pirq); return 0; } pci_write_config_byte(router, reg, x); return 1; } Hope I got all this right, I am sure if I didn't someone will point it out. Basically, set INTA-D to irq11, program irq11 on the card, and it should work. Or, set A to 9, B to 10, etc., and then try setting the irqs on the card one at a time until it works. Do this on all slots and you can get the wiring. Very tedious, though. -Steve From ebiederman at lnxi.com Thu Feb 13 00:10:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 13 00:10:00 2003 Subject: Ram initialization and small c. Message-ID: Years ago when C was young and implementations were not readily available people compilers for subsets of C and called then small C compilers. Currently one of the greatest challenges in LinuxBIOS is to write ram initialization code. On x86 this is all done in 8 general purpose registers. And it takes about a 1000 lines of assembly per memory controller, to do a good job and handle all of the auto-configuration cases. Debugging the assembly is bad as frequently adding the debug code breaks the code we are trying to debug. Additionally there is no code reuse between the two binaries that make up LinuxBIOS as one is in C and the other in assembly. By this point I have enough practice I am good at writing the assembly code, that I think it hardly matters. But I have seen several proficient coders just grind to a halt when confronted with miles of assembly. So what I propose is to write a small C compiler for LinuxBIOS. Various reports from ages past put it at about a man-month of effort to get the first version going. And it may be better than that as there are a couple of places I can copy code from. tcc, lcc, gcc, and other small c projects. Up until this point all C compilers have had an assumption that you can have a stack. And most simple C compilers have kept none of the data structures needed to do inline and similar optimizations that are necessary when you don't have ram. So I think it is easiest to build up something very simple from scratch. That is the route I am going to try. No promises, but I should start a trial implementation soon. Ron. I am going to need to do a branch soon as I do the Hammer port and integrate a small C compiler. And I want to make some clean fixes and remove some of the backwards compatibility cruft, and the linuxbios 1.0 code base is an inappropriate place to target. It should be possible to roll in most of the improvements into the 1.0 codebase, but that will just increase the clutter of the codebase. Eric From lawrence at tyanchina.com Thu Feb 13 04:16:01 2003 From: lawrence at tyanchina.com (lawrence) Date: Thu Feb 13 04:16:01 2003 Subject: Bringing up eth0 failed Message-ID: <1045128902.8421.48.camel@dai.sh.corp.tyan.com> Hi, all: I have a problem about etho bringing up. The error output is following: Bringing up interface eth0: dhcpcd[440]: timed out waiting for a valid DHCP server response Determining IP information for eth0... failed. So I check the packets transmitted between DHCP server and client base on LinuxBIOS. I find the client can submit a request, but it can not receive the ACK from DHCP server, so it fail to determine its IP. The output differences between the normal BIOS and LinuxBIOS: normal BIOS: ENABLING IO-APIC IRQs Setting 8 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 8 ... ok. Setting 9 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 9 ... ok. Setting 10 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 10 ... ok. ..TIMER: vector=0x31 pin1=2 pin2=0 PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0 PCI->APIC IRQ transform: (B0,I29,P0) -> 16 PCI->APIC IRQ transform: (B0,I31,P0) -> 18 PCI->APIC IRQ transform: (B0,I31,P1) -> 17 PCI->APIC IRQ transform: (B4,I1,P0) -> 48 PCI->APIC IRQ transform: (B1,I1,P0) -> 17 PCI->APIC IRQ transform: (B1,I2,P0) -> 18 e100: eth0: Intel(R) PRO/100 S Server Adapter Mem:0xfe7fe000 IRQ:17 Speed:0 Mbps Dx:N/A Hardware receive checksums enabled Setting network parameters: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: [ OK ] LinuxBIOS: Setting 8 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 8 ... ok. Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge PCI->APIC IRQ transform: (B0,I29,P0) -> 16 PCI->APIC IRQ transform: (B0,I29,P1) -> 16 PCI->APIC IRQ transform: (B0,I29,P2) -> 16 PCI->APIC IRQ transform: (B0,I31,P0) -> 18 PCI->APIC IRQ transform: (B0,I31,P1) -> 17 PCI->APIC IRQ transform: (B4,I1,P0) -> 24 Bringing up loopback interface: [ OK ] Bringing up interface eth0: dhcpcd[440]: timed out waiting for a valid DHCP server response Determining IP information for eth0... failed. [FAILED] Does the problem come from mptable.c? How can I do next? Who can tell me? Thanks a lot! Best Regards, Lawrence From gnuorder at tampabay.rr.com Thu Feb 13 09:31:00 2003 From: gnuorder at tampabay.rr.com (GNUOrder) Date: Thu Feb 13 09:31:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: <200302131450.h1DEoGKm016292@ms-smtp-01.tampabay.rr.com> Would it be easier to design this into gcc as a separate architecture or would that be too unmanagable? It may or may not be of benefit to other embedded projects as well so there may be more help keeping it up to date if it was in the gcc tree. Then again, someone could modify it for their own needs and make it unusable for what it was intended. GO On Thursday 13 February 2003 00:29, Eric W. Biederman wrote: > Years ago when C was young and implementations were not readily > available people compilers for subsets of C and called then small C > compilers. > > Currently one of the greatest challenges in LinuxBIOS is to write > ram initialization code. On x86 this is all done in 8 general purpose > registers. And it takes about a 1000 lines of assembly per memory > controller, to do a good job and handle all of the auto-configuration > cases. Debugging the assembly is bad as frequently adding the debug > code breaks the code we are trying to debug. Additionally there is no > code reuse between the two binaries that make up LinuxBIOS as one is > in C and the other in assembly. > > By this point I have enough practice I am good at writing the assembly > code, that I think it hardly matters. But I have seen several > proficient coders just grind to a halt when confronted with miles of > assembly. > > So what I propose is to write a small C compiler for LinuxBIOS. > Various reports from ages past put it at about a man-month of effort > to get the first version going. And it may be better than that as > there are a couple of places I can copy code from. tcc, lcc, gcc, and > other small c projects. > > Up until this point all C compilers have had an assumption that you > can have a stack. And most simple C compilers have kept none of the > data structures needed to do inline and similar optimizations that > are necessary when you don't have ram. > > So I think it is easiest to build up something very simple from > scratch. That is the route I am going to try. No promises, but > I should start a trial implementation soon. > > Ron. I am going to need to do a branch soon as I do the Hammer > port and integrate a small C compiler. And I want to make some > clean fixes and remove some of the backwards compatibility cruft, and > the linuxbios 1.0 code base is an inappropriate place to target. > It should be possible to roll in most of the improvements into the 1.0 > codebase, but that will just increase the clutter of the codebase. > > Eric > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Thu Feb 13 09:37:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 13 09:37:01 2003 Subject: Ram initialization and small c. In-Reply-To: <200302131450.h1DEoGKm016292@ms-smtp-01.tampabay.rr.com> References: <200302131450.h1DEoGKm016292@ms-smtp-01.tampabay.rr.com> Message-ID: GNUOrder writes: > Would it be easier to design this into gcc as a separate architecture or > would that be too unmanagable? It may or may not be of benefit to other > embedded projects as well so there may be more help keeping it up to date if > it was in the gcc tree. Then again, someone could modify it for their own > needs and make it unusable for what it was intended. Beats me.. gcc is the one compiler of the free software compilers it might be possible to integrate with. I think it is a real pain to start with. If someone knows more about gcc feel free to go ahead and try. Mostly I am avoiding that route in the interests of simplicity and comprehensibility. Someone familiar with gcc might have a different take on the situation. As things get a little farther I hope to publish the subset of C I plan on using, which can aid other attempts. Eric From rminnich at lanl.gov Thu Feb 13 10:02:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 13 10:02:01 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030213023428.E86791BCA1@smtp.x263.net> Message-ID: On Thu, 13 Feb 2003 riskin at 263.net wrote: > I have tried 2.4.17 kernel,solt1 and solt2 can work normally. > Though solt3 can get IRQ,it can't work. did you get the right linuxbios? we had ANOTHER problem with these mainboards in that the three slot one could not run with the 2 slot linuxbios -- they rewired things. I don't use these chipsets right now so I am not much help, sorry. ron From rminnich at lanl.gov Thu Feb 13 10:11:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 13 10:11:01 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 12 Feb 2003, Eric W. Biederman wrote: > Ron. I am going to need to do a branch soon as I do the Hammer > port and integrate a small C compiler. And I want to make some > clean fixes and remove some of the backwards compatibility cruft, and > the linuxbios 1.0 code base is an inappropriate place to target. > It should be possible to roll in most of the improvements into the 1.0 > codebase, but that will just increase the clutter of the codebase. OK, but be aware that a person here is doing the PPC port, so we'll need to see how to keep him up-to-date with what you're doing. Although the PPC code is mostly C, since the cache-as-ram trick is actually well-supported and working on that architecture. We don't want to drop too many mainboards off the edge in the long term. A branch would be a good place to fix up support for multiple south and north bridges. ron From rminnich at lanl.gov Thu Feb 13 10:13:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 13 10:13:00 2003 Subject: Ram initialization and small c. In-Reply-To: <200302131450.h1DEoGKm016292@ms-smtp-01.tampabay.rr.com> Message-ID: On Thu, 13 Feb 2003, GNUOrder wrote: > Would it be easier to design this into gcc as a separate architecture or > would that be too unmanagable? It may or may not be of benefit to other > embedded projects as well so there may be more help keeping it up to date if > it was in the gcc tree. Then again, someone could modify it for their own > needs and make it unusable for what it was intended. and lest we forget, there are 8 32-bit scratchpad registers in most northbridges nowadays; it would be nice to use them. ron From aip at cwlinux.com Thu Feb 13 10:47:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Thu Feb 13 10:47:00 2003 Subject: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: ; from Ronald G. Minnich on Thu, Feb 13, 2003 at 08:21:19AM -0700 References: <20030213023428.E86791BCA1@smtp.x263.net> Message-ID: <20030214000615.A21381@mail.cwlinux.com> > did you get the right linuxbios? we had ANOTHER problem with these > mainboards in that the three slot one could not run with the 2 slot > linuxbios -- they rewired things. In order to get the third one working, you may need to turn off the on-board audio or modem so that you get an extra irq. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From ebiederman at lnxi.com Thu Feb 13 10:55:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 13 10:55:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 12 Feb 2003, Eric W. Biederman wrote: > > > Ron. I am going to need to do a branch soon as I do the Hammer > > port and integrate a small C compiler. And I want to make some > > clean fixes and remove some of the backwards compatibility cruft, and > > the linuxbios 1.0 code base is an inappropriate place to target. > > It should be possible to roll in most of the improvements into the 1.0 > > codebase, but that will just increase the clutter of the codebase. > > OK, but be aware that a person here is doing the PPC port, so we'll need > to see how to keep him up-to-date with what you're doing. I intend to be as public as I can about it, so the LinuxBIOS list should work. > Although the PPC code is mostly C, since the cache-as-ram trick is > actually well-supported and working on that architecture. Yes, which is one of the things that encouraged me to try it. > We don't want to drop too many mainboards off the edge in the long term. Agreed. But at the same time our code base is such that hardwaremain() is not as fixed as it should be. Which means that without great care things break. > > A branch would be a good place to fix up support for multiple south and > north bridges. I have to. Multiple identical northbridges, and southbridges will actually be quite common on the Hammer architecture. I actually have a fix present in the pci code to detect and handle these but I have not currently pushed the code. What I expect is that initially everything will work in the 1.0 codebase but only a subset will work with the 2.0 codebase. At the same time a goal of the 2.0 codebase is that the infrastructure should be clean enough that we don't have to keep continually modifying it and breaking things when more boards are brought online. Ron I don't know how to manage it but we need to setup a system where we have releases of the core codebase. And one of the tasks of doing a release need to be to review the changes that went in since the last release so we can avoid things like a broken intel_chip_post macro. Having code like that temporarily in CVS is fine. In the core that is a pain. The way I expect developers to work is that they start with a stable release of the core, do a port. And the occasionally update to a later core. And when the code is on an uptodate core submitting code back to the core LinuxBIOS tree. That roughly seems to fit how Tyson and other embedded guys work, and how I do ports I can support. The problem with submitting code back right now is that the CVS tree is a moving target. And I am very very cautious about importing it into my tree as it may break something, on a port I support. Eric From jerj at coplanar.net Thu Feb 13 13:15:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Thu Feb 13 13:15:01 2003 Subject: Q: MTD and NIC Roms... In-Reply-To: <3E4B37CD.8090507@pobox.com> References: <3E4B37CD.8090507@pobox.com> Message-ID: <1045161274.1295.103.camel@contact.skynet.coplanar.net> On Thu, 2003-02-13 at 01:14, Jeff Garzik wrote: > Eric W. Biederman wrote: > > Currently I have a patch to eepro100.c that adds an MTD map driver so > > the onboard rom can be written. Making code like etherboot easier to > > flash etc. > [...] > > I am currently looking for ideas on ways to cleanly get this code > > into the kernel, and I am looking for ideas. The map driver is > > > Well... this functionality has existed for a while, and it doesn't need > to be in the kernel :) > > Donald Becker's diag suite can do flashing. > ftp://www.scyld.com/pub/diag/ He provides means to program the flash > from userspace. I tried it on a tulip, and it caused a hard reset. PCI bus issues? Also, by making it a map driver, I can flash LinuxBIOS into EEPROM, disable write access to the EEPROM, and put the *DoC* in the NIC socket. Putting a public key in the EEPROM and making it RO makes the whole system secure. Or I could port DoC and jffs driver to userspace... Porting devbios to MTD will then give a large library of NOR flash, including quirks (like ATMEL has different versions, and none work if you just use the datasheet), and allow them to be used in arbitrary sockets. Also, say bye bye to the "pull out the eeprom and put in DoC quick so the electrons don't notice" trick. Just put the DoC into the NIC, boot up, flash, power down, swap to BIOS socket. Sorry LinuxBIOS guys, I guess you'll have to switch back to drinking coffee. > > And I think that's the best place for it. We _could_ bloat up the > kernel code by adding the ability flash -- but how many users is that > going to serve, that are not already served by existing programs? So, I > disagree with getting this stuff into the kernel at all. > > Jeff > > > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Jeremy Jackson From steve at nexpath.com Thu Feb 13 13:48:00 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Thu Feb 13 13:48:00 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: > GNUOrder writes: > > > Would it be easier to design this into gcc as a separate > > architecture or > > would that be too unmanagable? > Beats me.. gcc is the one compiler of the free software compilers it > might be possible to integrate with. I think it is a real pain to > start with. > Eric Will you be able to use the gnu pre-processor unchanged? or adapt it? The macro expansion seems pretty important. -Steve From rminnich at lanl.gov Thu Feb 13 14:50:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 13 14:50:01 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 13 Feb 2003, Eric W. Biederman wrote: > Agreed. But at the same time our code base is such that hardwaremain() > is not as fixed as it should be. Which means that without great care > things break. I'm assuming hardwaremain is dead, although I will be sorry to see our very first linuxbios message go in the ashbin of history. :-) > Ron I don't know how to manage it but we need to setup a system where > we have releases of the core codebase. And one of the tasks of > doing a release need to be to review the changes that went in since > the last release so we can avoid things like a broken intel_chip_post > macro. Having code like that temporarily in CVS is fine. In the core > that is a pain. absolutely. Here is where my experience falls short. Do you have (or does anyone have) experience with managing this sort of thing? I agree that the tree has been moving pretty quickly. I would request the committers to use the RFC process to this list before making far-reaching changes. Any change that involves .inc or .S files is far-reaching, no matter how small it looks. ron From rsmith at bitworks.com Thu Feb 13 15:05:01 2003 From: rsmith at bitworks.com (Richard Smith) Date: Thu Feb 13 15:05:01 2003 Subject: dump_spd_registers bug In-Reply-To: <3E4AD3F3.9050405@bitworks.com> References: <3E4AD3F3.9050405@bitworks.com> Message-ID: <3E4BFEE1.7030806@bitworks.com> dump_spd_registers seems to have a bug. After it calls smbus_read_byte it does a 'jz dump_spd_reg_next_dimm' Why? Is it looking to see if the loaded data byte is zero? if so then this dosen't work because the 'in' instruction from the read dosen't set the flags. And even if this did work zeros occur naturally in the spd datastream so skipping the dimm if you get a zero is bad. I've modified smbus_read_byte to set/clear the carry bit on failure/success and now dump_spd_registers checks that and that seems to work fine. Is this the right solution or am I still missing something? From ebiederman at lnxi.com Thu Feb 13 18:05:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 13 18:05:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 13 Feb 2003, Eric W. Biederman wrote: > > > Agreed. But at the same time our code base is such that hardwaremain() > > is not as fixed as it should be. Which means that without great care > > things break. > > I'm assuming hardwaremain is dead, although I will be sorry to see our > very first linuxbios message go in the ashbin of history. :-) Actually my intention is to simplify it and make it architectural neutral. The basic layout I am looking at, is to have some kind of list of hardware in the code. And then for each piece of hardware call an initialization function. This has the potential to replace a lot of code in the current hardwaremain.c Handling initialization order is an interesting problem I have not tackled yet. There is some prototyping of that in the p4dpr, build for this. I just have not taken advantage of it yet. > > Ron I don't know how to manage it but we need to setup a system where > > we have releases of the core codebase. And one of the tasks of > > doing a release need to be to review the changes that went in since > > the last release so we can avoid things like a broken intel_chip_post > > macro. Having code like that temporarily in CVS is fine. In the core > > that is a pain. > > absolutely. Here is where my experience falls short. Do you have (or does > anyone have) experience with managing this sort of thing? > > I agree that the tree has been moving pretty quickly. I would request the > committers to use the RFC process to this list before making far-reaching > changes. Any change that involves .inc or .S files is far-reaching, no > matter how small it looks. A little bit, and Ken Yap of etherboot does a good job, so it may be worth looking at what he is doing and emulate that to some extent. Basically one person is the release manager (usually the maintainer of the project). And that person makes the final decision when a release is ready. Bumps the version number, tags CVS and puts out a tarball with all of the code as of that release. One of the things I do with releases at Linux Networx, is I always make a diff against the last release. Review it. And make certain I know what all of the code in there is for. And I worry more about generic code that affects everyone. And less about what an happens on an individual board. And stable releases are different from development releases. For development releases a things breaking is expected. For stable releases the level of care and conservatism must go up. Which is while I figure it is time to start a development version of LinuxBIOS so I can twist turn and break things. The 1.0.x series can stay around supporting everything we do now. The 1.2.x or 2.0.x series will handle all new things. And if a motherboard has an active maintainer. The code can be moved to the new codebase. If not we can just drop that port from the latest version of the tree. But dropping ports and breaking ports by design should only happen on major versions of LinuxBIOS. And new major versions should come very seldom. As our abstraction layer gets better there are fewer and fewer reasons to break an existing port. But there are a lot of dead experimental features whose time has come to be dropped. Non ELF booting. northbridge_fixup, southbridge_fixup, etc calls in hardwaremain. Which are just not generic enough. Some of the old pci calls. The etherboot built into LinuxBIOS, etc. Every project is different and things work out differently. By dropping the code in a development release and still supporting it in the last stable release things should get a lot better. Eric From ebiederman at lnxi.com Thu Feb 13 18:14:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Thu Feb 13 18:14:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Steve M. Gehlbach" writes: > > GNUOrder writes: > > > > > Would it be easier to design this into gcc as a separate > > > architecture or > > > would that be too unmanagable? > > > Beats me.. gcc is the one compiler of the free software compilers it > > might be possible to integrate with. I think it is a real pain to > > start with. > > > Eric > > Will you be able to use the gnu pre-processor unchanged? or adapt it? The > macro expansion seems pretty important. It can used unchanged, though I don't know if that is a reason to use it. Having a C preprocessor is definitely a requirement of the LinuxBIOS small C. To have an idea how small a fairly complete C compiler can get, lookup tcc. It can very nearly compile the kernel and the source is only 200K or so. It currently does not optimize but... Eric From riskin at 263.net Thu Feb 13 20:42:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Thu Feb 13 20:42:00 2003 Subject: FW: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030214010518.DCF221BD46@smtp.x263.net> ----- Original Message ----- From: "Ronald G. Minnich" To: Cc: ,,, Sent: 2003-02-14 07:21:19 Subject: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard >did you get the right linuxbios? we had ANOTHER problem with these >mainboards in that the three slot one could not run with the 2 slot >linuxbios -- they rewired things. > >I don't use these chipsets right now so I am not much help, sorry. > >ron Could you tell me the difference between sis630 and sis630e chipset? ========================== 263??????????? From rminnich at lanl.gov Thu Feb 13 23:57:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 13 23:57:00 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 13 Feb 2003, Eric W. Biederman wrote: > The basic layout I am looking at, is to have some kind of list of hardware > in the code. And then for each piece of hardware call an initialization > function. This has the potential to replace a lot of code in the > current hardwaremain.c Handling initialization order is an > interesting problem I have not tackled yet. I think the superio stuff is one possible way. I've found that three passes covers the case for superio, and actually for southbridge. For the multiple northbridge case did you want to discover northbridges dynamically or continue to specify it in a config file. The _fixup stuff goes away with the three pass approach, I think. I'd like to hash this out a bit on the list the way I've hashed out other approaches in the past (config tool, new superio, etc.) to see if we can't scare up good ideas from other people. ron From ollie at sis.com.tw Fri Feb 14 01:29:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Fri Feb 14 01:29:00 2003 Subject: FW: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard In-Reply-To: <20030214010518.DCF221BD46@smtp.x263.net> References: <20030214010518.DCF221BD46@smtp.x263.net> Message-ID: <1045204676.1154.1.camel@ollie> On Fri, 2003-02-14 at 08:59, riskin at 263.net wrote: > ----- Original Message ----- > From: "Ronald G. Minnich" > To: > Cc: ,,, > Sent: 2003-02-14 07:21:19 > Subject: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard > > >did you get the right linuxbios? we had ANOTHER problem with these > >mainboards in that the three slot one could not run with the 2 slot > >linuxbios -- they rewired things. > > > >I don't use these chipsets right now so I am not much help, sorry. > > > >ron > > Could you tell me the difference between sis630 and sis630e chipset? > No difference in theory. I think the problem is that you have wrong IRQ table. Did you tried get_irqtable util ? -- ollie lho From aod at unisys.com.br Fri Feb 14 01:47:00 2003 From: aod at unisys.com.br (Andre Dias) Date: Fri Feb 14 01:47:00 2003 Subject: parallel port and joyport Message-ID: <4.3.0.20030214050424.00fed848@mail.unisys.com.br> I am having trouble trying to use the m810 parallel port and joyport with linuxbios. Perhaps the BIOS sets the port/irq etc. Has anyone gone over this problems? andre http://usuarios.uninet.com.br/~aod ---------------------------------------------- From ebiederman at lnxi.com Fri Feb 14 03:41:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 03:41:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 13 Feb 2003, Eric W. Biederman wrote: > > > The basic layout I am looking at, is to have some kind of list of hardware > > in the code. And then for each piece of hardware call an initialization > > function. This has the potential to replace a lot of code in the > > current hardwaremain.c Handling initialization order is an > > interesting problem I have not tackled yet. > > I think the superio stuff is one possible way. I've found that three > passes covers the case for superio, and actually for southbridge. > > For the multiple northbridge case did you want to discover northbridges > dynamically or continue to specify it in a config file. Auto discovery is necessary as everything may not be plugged in. But I suspect I will also want to specify information that is valid if the cpu/northbridge is plugged in. > The _fixup stuff goes away with the three pass approach, I think. I need to look closely at this issue. We have one huge hook before hardwaremain. Beyond that I suspect doing something as simple as going through the devices in a tree structured order would remove the need for multiple passes. > I'd like to hash this out a bit on the list the way I've hashed out other > approaches in the past (config tool, new superio, etc.) to see if we can't > scare up good ideas from other people. We are still on the list. And talking is good. But to a certain extent you don't see things until code is written and you try it. So we need a development branch to try these things out on. I don't promise we will get it perfect the first try. The goal is to get it close enough that we won't break ports by going the last few inches. Things like having no guaranteed order the code will be called independent of the device tree should help. By device tree I am thinking of the something roughly like pci device tree. How far devices are from the cpu. The goal is not perfection but a useful approximation of reality. Eric From ollie at sis.com.tw Fri Feb 14 04:27:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Fri Feb 14 04:27:00 2003 Subject: parallel port and joyport In-Reply-To: <4.3.0.20030214050424.00fed848@mail.unisys.com.br> References: <4.3.0.20030214050424.00fed848@mail.unisys.com.br> Message-ID: <1045215833.1256.1.camel@ollie> On Fri, 2003-02-14 at 16:05, Andre Dias wrote: > I am having trouble trying to use the m810 parallel port and joyport with > linuxbios. Perhaps the BIOS sets the port/irq etc. > > Has anyone gone over this problems? > andre Parallel port and game port are not inited in linuxbios. You have to program it by yourself. Try download datasheet of ITE 8705 first. -- ollie lho From ian.castle at coldcomfortfarm.net Fri Feb 14 06:04:01 2003 From: ian.castle at coldcomfortfarm.net (Ian Castle) Date: Fri Feb 14 06:04:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: <1045221803.1698.4.camel@kerberos> On Thu, 2003-02-13 at 05:29, Eric W. Biederman wrote: > > Years ago when C was young and implementations were not readily > available people compilers for subsets of C and called then small C > compilers. > Not sure if this is of any use/relevance, but mention of Small-C brought back some distant memories... On my bookshelf I have a copy of : The Small-C Handbook James E. Hendrix 1984 It has the source of the small-c compiler in it. It is targeted at the 8080 though. The source is only a thousand or so lines of C. Can't see any sign of a licence though.. Way back when I got it I had thought of porting it to the 68000.. but ending up using BCPL instead.... From rminnich at lanl.gov Fri Feb 14 09:50:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 14 09:50:01 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 14 Feb 2003, Eric W. Biederman wrote: > I need to look closely at this issue. We have one huge hook before > hardwaremain. Beyond that I suspect doing something as simple > as going through the devices in a tree structured order would > remove the need for multiple passes. I am not so sure. The Acer superio needed at least two passes, one before pci scan and one after, the reason being that certain resources were not visible on PCI unless and enable was set, then the device got scanned, then some post-scan fixup got done. ron From aip at cwlinux.com Fri Feb 14 10:58:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Fri Feb 14 10:58:01 2003 Subject: Ram initialization and small c. In-Reply-To: ; from Ronald G. Minnich on Fri, Feb 14, 2003 at 08:09:24AM -0700 References: Message-ID: <20030215001749.A4722@mail.cwlinux.com> > I am not so sure. The Acer superio needed at least two passes, one > before pci scan and one after, the reason being that certain resources > were not visible on PCI unless and enable was set, then the device got > scanned, then some post-scan fixup got done. Same as VIA for enabling ethernet and IDE's compatible mode. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From rminnich at lanl.gov Fri Feb 14 11:31:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 14 11:31:00 2003 Subject: development branch Message-ID: I think another goal is going to be setting up IRQs. ron From ebiederman at lnxi.com Fri Feb 14 13:55:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 13:55:00 2003 Subject: Ram initialization and small c. In-Reply-To: <1045221803.1698.4.camel@kerberos> References: <1045221803.1698.4.camel@kerberos> Message-ID: Ian Castle writes: > On Thu, 2003-02-13 at 05:29, Eric W. Biederman wrote: > > > > Years ago when C was young and implementations were not readily > > available people compilers for subsets of C and called then small C > > compilers. > > > > Not sure if this is of any use/relevance, but mention of Small-C brought > back some distant memories... On my bookshelf I have a copy of : > > The Small-C Handbook > James E. Hendrix > 1984 > > It has the source of the small-c compiler in it. It is targeted at the > 8080 though. The source is only a thousand or so lines of C. Can't see > any sign of a licence though.. I think I have seen it as shareware type license... With the small size you can see why I find it attractive to just write a compiler... Eric From ebiederman at lnxi.com Fri Feb 14 14:00:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 14:00:00 2003 Subject: Ram initialization and small c. In-Reply-To: <20030215001749.A4722@mail.cwlinux.com> References: <20030215001749.A4722@mail.cwlinux.com> Message-ID: Andrew Ip writes: > > I am not so sure. The Acer superio needed at least two passes, one > > before pci scan and one after, the reason being that certain resources > > were not visible on PCI unless and enable was set, then the device got > > scanned, then some post-scan fixup got done. > Same as VIA for enabling ethernet and IDE's compatible mode. For a number of these case forcing the device into the table of devices present can help a lot. Eric From rminnich at lanl.gov Fri Feb 14 14:03:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 14 14:03:01 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 14 Feb 2003, Eric W. Biederman wrote: > For a number of these case forcing the device into the table > of devices present can help a lot. yes but, there is a loop. = enable some piece of the device = scan pci = enable more bits of the device based on the pci scan I am pretty sure dependency trees don't cover that kind of cycle. ron From ebiederman at lnxi.com Fri Feb 14 14:08:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 14:08:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 14 Feb 2003, Eric W. Biederman wrote: > > > For a number of these case forcing the device into the table > > of devices present can help a lot. > > yes but, there is a loop. > > = enable some piece of the device > = scan pci > = enable more bits of the device based on the pci scan > > I am pretty sure dependency trees don't cover that kind of cycle. First what the code does right now is: Enable pci bus. scan pci bus. Enable pci buses found. scan pci buses found. etc. So in the worst case you should be able to lie and put in a pseudo device, or two that happen to be called at the proper times. Which I why I think I can get away with a single pass... Eric From rminnich at lanl.gov Fri Feb 14 16:29:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 14 16:29:01 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 14 Feb 2003, Eric W. Biederman wrote: > So in the worst case you should be able to lie and put > in a pseudo device, or two that happen to be called at the proper > times. pseudo-device per chip type? Or a generic pseudo-device? or ... ron From ebiederman at lnxi.com Fri Feb 14 16:52:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 16:52:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 14 Feb 2003, Eric W. Biederman wrote: > > > So in the worst case you should be able to lie and put > > in a pseudo device, or two that happen to be called at the proper > > times. > > pseudo-device per chip type? > > Or a generic pseudo-device? or ... > In most cases I think just putting it in the table of devices so we find the device even if the default pci_scan does not report it, should be enough. For the weird cases. I am content that I can put a dummy device at an appropriate place in the list of devices, and have it do something. That is not a case I plan on using. If we can get the abstraction so it actually models what is going on. We are in much better shape. And that is what I intend to concentrate on. So what I am looking at: The current pci bus scan starts with a root pci bus device. And then finds the devices on that bus, and the recursively scans the sub busses. And the following things are possible. We can have multiple top level devices. We can have force a device onto a given pci bus. I want to make this process device driven, and get the configuration to just decorate the device tree with information such as irq routing, and default device settings (like the baud rate). Irq routing currently does interesting things if you plug in a pci card with a bridge chip on it, I believe all of our current tables have the potential to hand out the wrong information as the bus numbers change. Eric From rminnich at lanl.gov Fri Feb 14 19:35:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 14 19:35:00 2003 Subject: Ram initialization and small c. In-Reply-To: Message-ID: On 14 Feb 2003, Eric W. Biederman wrote: > So what I am looking at: > > The current pci bus scan starts with a root pci bus device. > And then finds the devices on that bus, and the recursively scans > the sub busses. I'm still not getting it. For some chips, LinuxBIOS needs to call some chip-specific code for that device BEFORE the pci bus scan, or resource allocation gets done incorrectly. How can we structure the code so that the pre-pci init functions work in a reasonable way that most people can understand? The current superio stuff does this, and the information to drive it is contained in the superio file. If you have code that needs to be called before the PCI scan, you initalize the structure member to point to a function. Same for after PCI scan, same for right before hardwaremain() exits. You can look at the superio.c file for the given chip and see if this pre-pci-scan function exists and is called. I like the self-contained nature of the superio.c files (I grabbed all those ideas from Plan 9). Does this seem desirable to people? If so, can we expand it to the south and north bridges so as to replace the current ad-hoc mechanisms? If this mechanism is not desirable, how would it change? Would the .c files continue to be self-contained or would we start getting into more linker sets and other magic stuff (which, as you can tell, worries me as it does confuse people). I would appreciate some feedback from the other committers and developers. ron From ebiederman at lnxi.com Fri Feb 14 20:24:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 14 20:24:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 14 Feb 2003, Eric W. Biederman wrote: > > > So what I am looking at: > > > > The current pci bus scan starts with a root pci bus device. > > And then finds the devices on that bus, and the recursively scans > > the sub busses. > O.k. Getting into specifics: >From our pci.h, the current operations we have for a pci device. struct pci_dev_operations { void (*read_resources)(struct pci_dev *dev); void (*set_resources)(struct pci_dev *dev); void (*init)(struct pci_dev *dev); unsigned int (*scan_bus)(struct pci_dev *bus, unsigned int max); }; > I'm still not getting it. > > For some chips, LinuxBIOS needs to call some chip-specific code for that > device BEFORE the pci bus scan, or resource allocation gets done > incorrectly. How can we structure the code so that the pre-pci init > functions work in a reasonable way that most people can understand? The > current superio stuff does this, and the information to drive it is > contained in the superio file. If you have code that needs to be called > before the PCI scan, you initalize the structure member to point to a > function. Same for after PCI scan, same for right before hardwaremain() > exits. You can look at the superio.c file for the given chip and see if > this pre-pci-scan function exists and is called. O.k. The superio code I definitely figure is a step in that direction. This discussion must get into nitty gritty specifics if we are going to reach a consensus. What we currently do: pci_enumerate(); pci_configure(); pci_initialize(); In pci_enumerate(), If a device is in the hard coded list it is placed into the list of pci devices even if it does not exist. This allows invisible devices on the motherboard to be configured. In addition each device is assigned a set of operations. set_pci_ops does that work. set_pci_ops first looks through a table of device drivers and listed by vendor and device id to see if it can find a specific driver for that device. If a driver is found it uses those device methods. Otherwise depending if it is a bridge or a normal pci device a default set of methods is assigned. After pci_scan_bus finishes enumerating the devices on a bus. It looks at each child device to see if it has a scan_bus method. And if so it calls child->ops->scan_bus(). Which is usually just pci_scan_bus again. In pci_configure. The device tree is walked again. And for each device it's read_resources operation is called, to find the bar's on that device. read_resources allows for the presence of non standard bars. Each bar read_resources returns can either be a fixed resource, that must be catered to. Or a resource needing to be assigned a value. Then a second pass is made to the tree and set_resources is called on each device. For bridges, read_resources, and set_resources are recursive. In pci_initialize. The device tree is walked one last time, and this time the init() method of each device is called. > I like the self-contained nature of the superio.c files (I grabbed all > those ideas from Plan 9). Does this seem desirable to people? Yes. Self contained is good. The one part my newer pci code that is lacking that you did well on the superio code is a way to build the static device information. I suspect we want to allow a different structure for each different device, but basically I like the superio directive. > If so, can > we expand it to the south and north bridges so as to replace the current > ad-hoc mechanisms? Look at what I have done with pci. Essentially I have already done that. Everything but making the configuration manageable. > If this mechanism is not desirable, how would it change? Would the > .c files continue to be self-contained or would we start getting into more > linker sets and other magic stuff (which, as you can tell, worries me as > it does confuse people). The only magic thing that I might touch with a linker is building the table of devices. But that is to make things more self contained. > I would appreciate some feedback from the other committers and > developers. Agreed. Just Eric talking is imperfect. I just looked through the LinuxBIOS tree at every superio.c. And perhaps I missed something but I did not see a single superio file that used more than one of the three functions defined, and none of them used the pre pci function. So all of those I can straight forwardly transformed so their init or finishup method is converted into a pci init method and called from pci_initialize(). For the hypothetical case of needing a device that is called before the rest of the pci initialization, it can be forced into the device tree ahead of everything else. And it's scan_bus method can do what special magic is required. Similarly for the hypothetical case of needing a device that is called after everything else, a dummy device can be inserted way at the bottom and the end of the pci device tree, so that it's init method will be called last. So it is possible in a nasty way to cope with those hypothetical situations. Buying time for a clean fix to be put into the LinuxBIOS tree. If you have specific examples of things that need to be done I am quite willing to discuss them and how I would fit it into the new frame work. The code flow I am confident of. The mechanism to configure it that I do not currently have that problem solved. But I suspect we can use something like the current superio configuration to statically build parts of the device tree. Eric From zhushisongzhu at yahoo.com Sun Feb 16 08:09:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Sun Feb 16 08:09:01 2003 Subject: how to build linuxbios rom image(256k) Message-ID: <20030216132904.32643.qmail@web13201.mail.yahoo.com> how to build linuxbios rom images( for 256 flash ) which can boot linux from hda? I need the info about the tools we need and the steps we should follow. thanks zhu --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day -------------- next part -------------- An HTML attachment was scrubbed... URL: From riskin at 263.net Mon Feb 17 02:38:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Mon Feb 17 02:38:00 2003 Subject: FW: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard Message-ID: <20030217075719.935841BEDC@smtp.x263.net> >On Fri, 2003-02-14 at 08:59, riskin at 263.net wrote: >> ----- Original Message ----- >> From: "Ronald G. Minnich" >> To: >> Cc: ,,, >> Sent: 2003-02-14 07:21:19 >> Subject: Re:Re: Re:Re:Re:Re: rtl8139 NIC IRQ is 0 on m758lmr+ mainboard >> > >No difference in theory. I think the problem is that you have wrong IRQ >table. Did you tried get_irqtable util ? > > >-- >ollie lho Thanks, I have resolved these problems. riskin ========================== 263??????????? From zhushisongzhu at yahoo.com Mon Feb 17 05:59:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Mon Feb 17 05:59:01 2003 Subject: can pcm-5823 boot linux from doc directly Message-ID: <20030217111929.58769.qmail@web13206.mail.yahoo.com> linuxbios can support pcm-5823, but it needs etherboot. can pcm-5823 boot linux from doc embedded in the board directly? zhu --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day -------------- next part -------------- An HTML attachment was scrubbed... URL: From aip at cwlinux.com Mon Feb 17 06:22:00 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 17 06:22:00 2003 Subject: can pcm-5823 boot linux from doc directly In-Reply-To: <20030217111929.58769.qmail@web13206.mail.yahoo.com>; from zhu shi song on Mon, Feb 17, 2003 at 03:19:29AM -0800 References: <20030217111929.58769.qmail@web13206.mail.yahoo.com> Message-ID: <20030217194153.A8539@mail.cwlinux.com> Zhu, > linuxbios can support pcm-5823, but it needs etherboot. can pcm-5823 boot linux from doc embedded in the board directly? It should be possible. Can you see it from regular Linux? PCM-5823 with DOC? IIRC, most 5823 don't have DOC socket. In normal case, pcm-5823 boots from CF card pretty nicely. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From pyro at linuxlabs.com Mon Feb 17 15:04:00 2003 From: pyro at linuxlabs.com (steven james) Date: Mon Feb 17 15:04:00 2003 Subject: weighing in Message-ID: Greetings, Thinking about initialization where one device's init is required to make others show up: In the cases I have seen, any devices that require another device's setup, the new device either has a higher device or function number, or it is on a subordinate bus. The mose common case is the superIO devices which require both southbridge and PnP setup. Perhaps the best thing is a provision for a function call upon scanning a device. That function would init it far enough to reveal anything behind it and no further. It could then either scan any subordinate busses and dependant devices, or just return and let the scan that found it continue to higher dev/fn numbers. G'day, sjames -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From ebiederman at lnxi.com Mon Feb 17 15:18:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon Feb 17 15:18:00 2003 Subject: weighing in In-Reply-To: References: Message-ID: steven james writes: > Greetings, > > Thinking about initialization where one device's init is required to make > others show up: > > In the cases I have seen, any devices that require another device's setup, > the new device either has a higher device or function number, or it is on > a subordinate bus. The mose common case is the superIO devices which > require both southbridge and PnP setup. > > Perhaps the best thing is a provision for a function call upon scanning a > device. That function would init it far enough to reveal anything behind > it and no further. It could then either scan any subordinate busses and > dependant devices, or just return and let the scan that found it continue > to higher dev/fn numbers. So the scan_bus function in pch.h should work then, and it seems to be a reasonable match. Eric From rminnich at lanl.gov Mon Feb 17 22:32:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 17 22:32:00 2003 Subject: weighing in In-Reply-To: Message-ID: On Mon, 17 Feb 2003, steven james wrote: > In the cases I have seen, any devices that require another device's setup, > the new device either has a higher device or function number, or it is on > a subordinate bus. The mose common case is the superIO devices which > require both southbridge and PnP setup. > > Perhaps the best thing is a provision for a function call upon scanning a > device. That function would init it far enough to reveal anything behind > it and no further. It could then either scan any subordinate busses and > dependant devices, or just return and let the scan that found it continue > to higher dev/fn numbers. on some devices (e.g. the acer southbridge) I think it is too late by that point. ron From adam.r.hunt at gmx.net Tue Feb 18 02:58:01 2003 From: adam.r.hunt at gmx.net (adam.r.hunt at gmx.net) Date: Tue Feb 18 02:58:01 2003 Subject: Needed: Motherboard Recomendations Message-ID: <8153.1045556287@www53.gmx.net> I am looking for an integrated MicroATX (or FlexATX) Socket 478 motherboard. It needs to have onboard video, sound and LAN. I plan on puting a 2.0GHz Celeron on it. I want to experiment with lowering the core voltage to ~1.1V from 2.525V in order to lower the thermal output (there have been reports of this working). The goal is to build myself a fanless PC (still working on the power supply issues). There will be no hard drive just a decent sized RAM drive and NFS mounted partions. Thanks --adam -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage! From Nick.Pye at rexam.com Tue Feb 18 04:11:00 2003 From: Nick.Pye at rexam.com (Pye, Nick) Date: Tue Feb 18 04:11:00 2003 Subject: l440bx / piix4e motherboard Message-ID: Hi What utils are available to burn the image directly to a DoC via the BIOS socket on a 440BX/PIIX4E motherboard ? ____________________________________________ Nick Pye Global Project Team Rexam plc T +44 (0)7811 447 087 Nick.Pye at rexam.com ************************************************************************************************************ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please do not distribute, copy or use this communication or the information. Instead, if you have received this communication in error, please notify the sender immediately and then destroy any copies of it. Due to the nature of the Internet, the sender is unable to ensure the integrity of this message and does not accept any liability or responsibility for any errors or omissions (whether as the result of this message having been intercepted or otherwise) in the contents of this message. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of the company. ************************************************************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rexam_logo1.gif Type: image/gif Size: 861 bytes Desc: rexam_logo1.gif URL: From Nick.Pye at rexam.com Tue Feb 18 04:19:00 2003 From: Nick.Pye at rexam.com (Pye, Nick) Date: Tue Feb 18 04:19:00 2003 Subject: 440BX/PIIX4E motherboard Message-ID: Hi What utils are available to burn the image directly to a DoC via the BIOS socket on a 440BX/PIIX4E motherboard ? ____________________________________________ Nick Pye Global Project Team Rexam plcT +44 (0)7811 447 087 Nick.Pye at rexam.com ************************************************************************************************************ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please do not distribute, copy or use this communication or the information. Instead, if you have received this communication in error, please notify the sender immediately and then destroy any copies of it. Due to the nature of the Internet, the sender is unable to ensure the integrity of this message and does not accept any liability or responsibility for any errors or omissions (whether as the result of this message having been intercepted or otherwise) in the contents of this message. Any views expressed in this communication are those of the individual sender, except where the sender specifically states them to be the views of the company. ************************************************************************************************************ From pyro at linuxlabs.com Tue Feb 18 07:31:01 2003 From: pyro at linuxlabs.com (steven james) Date: Tue Feb 18 07:31:01 2003 Subject: weighing in In-Reply-To: Message-ID: Greetings, I just looked at that code. I see what you mean. A question there, we are still going to want early serial output. It's ugly, but could special cases like that go into preram init? That does look like a step back to what we have now, but it may be hard to help in corner cases, and would allow for a neat and clean init for most chipsets. The question is, it thats's done, would the exception become the rule? G'day, sjames On Mon, 17 Feb 2003, Ronald G. Minnich wrote: > On Mon, 17 Feb 2003, steven james wrote: > > > In the cases I have seen, any devices that require another device's setup, > > the new device either has a higher device or function number, or it is on > > a subordinate bus. The mose common case is the superIO devices which > > require both southbridge and PnP setup. > > > > > Perhaps the best thing is a provision for a function call upon scanning a > > device. That function would init it far enough to reveal anything behind > > it and no further. It could then either scan any subordinate busses and > > dependant devices, or just return and let the scan that found it continue > > to higher dev/fn numbers. > > on some devices (e.g. the acer southbridge) I think it is too late by that > point. > > 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 701 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 Feb 18 10:22:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 18 10:22:01 2003 Subject: weighing in In-Reply-To: Message-ID: On Tue, 18 Feb 2003, steven james wrote: > A question there, we are still going to want early serial output. It's > ugly, but could special cases like that go into preram init? That does > look like a step back to what we have now, but it may be hard to help in > corner cases, and would allow for a neat and clean init for most chipsets. yes, but I think the way we do it now is ok. You always need this strange early stuff to get going. ron From tmc at deficient.ca Tue Feb 18 17:07:01 2003 From: tmc at deficient.ca (Spencer Hildebrandt) Date: Tue Feb 18 17:07:01 2003 Subject: Transmeta boot Message-ID: Has anyone been able to get a TM5400 to boot under LinuxBIOS? Regards, Spencer From Ulrik.Forsgren at epl.ericsson.se Tue Feb 18 17:17:09 2003 From: Ulrik.Forsgren at epl.ericsson.se (Ulrik Forsgren (EAB)) Date: Tue Feb 18 17:17:09 2003 Subject: irq_table.c without a pirq table? Message-ID: <9505F6390AA7D311A2D500508B951BEF0D470B50@esealnt427> Hi! I'm am testing LinuxBIOS on a Pentium motherboard that doesn't have a pirq table in BIOS and I suppose that Linux requires a pirq table to be able route the irqs to the PCI boards. I have scanned the original BIOS without finding the PIRQ tag. How can I create an irq_table.c when I can't copy it from the original BIOS? PCIBIOS 2.1 calls? Rgds, UFo Ulrik Forsgren ulrik.forsgren at epl.ericsson.se From rminnich at lanl.gov Tue Feb 18 19:14:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 18 19:14:01 2003 Subject: irq_table.c without a pirq table? In-Reply-To: <9505F6390AA7D311A2D500508B951BEF0D470B50@esealnt427> Message-ID: can you tell us more? what name etc.? ron From spirit at reactor.ru Tue Feb 18 19:45:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Tue Feb 18 19:45:00 2003 Subject: via epia, pchips 787cl+ Message-ID: <167257821407.20030219040500@reactor.ru> Hello! The linuxbios status comments for via epia say "etherboot" only. Does that mean that epia won't be able to boot from a local ide hard drive? Are there any plans to implement the support for lilo/whatever booting from the hard drive on epia? Another question is about the pcchips 787cl+ 3.0 board. It's sis630e + it8705. I didn't find sis630e in the list of supported devices, but I found some discussion on how to enable or disable something on that chipset. That's confusing. Is sis630e supported, or is it not? With best regards, Alexander mailto:spirit at reactor.ru From ebiederman at lnxi.com Tue Feb 18 20:12:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 18 20:12:01 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <167257821407.20030219040500@reactor.ru> References: <167257821407.20030219040500@reactor.ru> Message-ID: Alexander Amelkin writes: > Hello! > > The linuxbios status comments for via epia say "etherboot" only. > Does that mean that epia won't be able to boot from a local ide hard > drive? Nope, etherboot supports booting from the local ide hard drive, at least as well as the native LinuxBIOS IDE code does. > Are there any plans to implement the support for > lilo/whatever booting from the hard drive on epia? Things are gradually improving. Those of us who think a development machines has a 1000 motherboards don't always see the point in booting off a local hard drive :) Eric From ebiederman at lnxi.com Tue Feb 18 20:31:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 18 20:31:01 2003 Subject: weighing in In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On Tue, 18 Feb 2003, steven james wrote: > > > A question there, we are still going to want early serial output. It's > > ugly, but could special cases like that go into preram init? That does > > look like a step back to what we have now, but it may be hard to help in > > corner cases, and would allow for a neat and clean init for most chipsets. > > yes, but I think the way we do it now is ok. You always need this strange > early stuff to get going. There are and always will be 2 specials cases. - Ram initialization - Console initialization. Both of those will always need to be handled early in strange special ways. The goal is to cleanup all of the rest of the code as much as possible. Especially at the point of making the code more reuseable. Right now I have a larger number of initialization functions being called from mainboard_fixup. Those are the real functions that need to be tackled. The superio model comes close to handling those cases cleanly. The big issue with superio code is that we use one structure for all possible static values, that is silly. Another issue is irq allocation. Currently if a card is plugged in with a pci bridge on it we have broken pirq, and mptables. So those tables need to be generated a little more dynamically then we do now. For each device if we have a linked list of structures listing configuration information, we should have a clean model. A linked list may be overkill but it allows fairly generic things like irq routing to be attached, which the device driver does not need to process. An alternative would be to have parallel trees of information. In addition as this settles out we want to export the entire device tree in the LinuxBIOS table so the OS can do something with it, if it feels like it. Eric From ebiederman at lnxi.com Tue Feb 18 20:38:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 18 20:38:01 2003 Subject: irq_table.c without a pirq table? In-Reply-To: <9505F6390AA7D311A2D500508B951BEF0D470B50@esealnt427> References: <9505F6390AA7D311A2D500508B951BEF0D470B50@esealnt427> Message-ID: "Ulrik Forsgren (EAB)" writes: > Hi! > > I'm am testing LinuxBIOS on a Pentium motherboard that doesn't have a pirq table > in BIOS and I suppose that Linux requires a pirq table to be able route the irqs > to the PCI boards. > > I have scanned the original BIOS without finding the PIRQ tag. > > How can I create an irq_table.c when I can't copy it from the original BIOS? > > PCIBIOS 2.1 calls? Or looking at the irqs assigned on the pci bus and at the irq router. Or looking at the MP table. Or looking through the information provided by ACPI. Eric From ebiederman at lnxi.com Tue Feb 18 20:44:05 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 18 20:44:05 2003 Subject: 440BX/PIIX4E motherboard In-Reply-To: References: Message-ID: "Pye, Nick" writes: > Hi What utils are available to burn the image directly to a DoC via the BIOS > socket on a 440BX/PIIX4E motherboard ? The mtd kernel drivers... Eric From rminnich at lanl.gov Tue Feb 18 20:51:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 18 20:51:01 2003 Subject: weighing in In-Reply-To: Message-ID: On 18 Feb 2003, Eric W. Biederman wrote: > Right now I have a larger number of initialization functions being > called from mainboard_fixup. Those are the real functions that need > to be tackled. The superio model comes close to handling those cases > cleanly. The big issue with superio code is that we use one structure > for all possible static values, that is silly. There are two static structures in there, and I think I know which one you mean, but want to clarify. This one, I assume, is OK struct superio_control { void (*pre_pci_init)(struct superio *s); void (*init)(struct superio *s); void (*finishup)(struct superio *s); unsigned int defaultport; /* the defaultport. Can be overridden * by commands in config */ // This is the print name for debugging char *name; }; Fairly generic and represents how to attack a superio. Universal to all superios. This one, I think is the mistake: struct superio { struct superio_control *super; // the ops for the device. unsigned int port; // if non-zero, overrides the default port // com ports. This is not done as an array (yet). // We think it's easier to set up from python if it is not an array. struct com_ports com1, com2, com3, com4; // DMA, if it exists. struct lpt_ports lpt1, lpt2; /* flags for each device type. Unsigned int. */ // low order bit ALWAYS means enable. Next bit means to enable // LPT is in transition, so we leave this here for the moment. // The winbond chips really stretched the way this works. // so many functions! unsigned int ide, floppy, lpt; unsigned int keyboard, cir, game; unsigned int gpio1, gpio2, gpio3; unsigned int acpi,hwmonitor; }; because all the superios are so different (I never realized how different!) this struct is a mess and we don't want to repeat this for the south and north bridge hardware. Make sense? ron From ebiederman at lnxi.com Tue Feb 18 21:03:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 18 21:03:00 2003 Subject: weighing in In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 18 Feb 2003, Eric W. Biederman wrote: > > > Right now I have a larger number of initialization functions being > > called from mainboard_fixup. Those are the real functions that need > > to be tackled. The superio model comes close to handling those cases > > cleanly. The big issue with superio code is that we use one structure > > for all possible static values, that is silly. > > There are two static structures in there, and I think I know which one you > mean, but want to clarify. > > This one, I assume, is OK > > struct superio_control { > void (*pre_pci_init)(struct superio *s); > void (*init)(struct superio *s); > void (*finishup)(struct superio *s); > unsigned int defaultport; /* the defaultport. Can be overridden > * by commands in config > */ > // This is the print name for debugging > char *name; > }; > > > Fairly generic and represents how to attack a superio. Universal to all > superios. Right. The one I have for pci is a little different but roughly equivalent. > This one, I think is the mistake: I would just call it in need of a better abstraction. Not a really a mistake. > struct superio { > struct superio_control *super; // the ops for the device. > unsigned int port; // if non-zero, overrides the default port > // com ports. This is not done as an array (yet). > // We think it's easier to set up from python if it is not an > array. > struct com_ports com1, com2, com3, com4; > // DMA, if it exists. > struct lpt_ports lpt1, lpt2; > /* flags for each device type. Unsigned int. */ > // low order bit ALWAYS means enable. Next bit means to enable > // LPT is in transition, so we leave this here for the moment. > // The winbond chips really stretched the way this works. > // so many functions! > unsigned int ide, floppy, lpt; > unsigned int keyboard, cir, game; > unsigned int gpio1, gpio2, gpio3; > unsigned int acpi,hwmonitor; > }; > > because all the superios are so different (I never realized how > different!) this struct is a mess and we don't want to repeat this for the > south and north bridge hardware. Correct. > Make sense? Yes. I am thinking of something like: struct setup_info { struct setup_info *next; int type; }; struct irq_routing { struct setup_info info; /* Flesh this out... */ }; struct static_resources { struct setup_info info; /* Flesh this out... */ }; struct old_superio { struct setup_info info; struct com_ports com1, com2, com3, com4; struct lpt_ports lpt1,lpt2; unsigned int ide, floppy, lpt; unsigned int keyboard, cir, game; unsigned int gpio1, gpio2, gpio3; unsigned int acpi,hwmonitor; /* Don't use this for real.. */ }; The important characteristics are: - Any developer can add new structure types and they can be motherboard or device specific - There is a way for generic code to access configuration settings information about a device. Eric From ollie at sis.com.tw Tue Feb 18 22:15:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Tue Feb 18 22:15:00 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <167257821407.20030219040500@reactor.ru> References: <167257821407.20030219040500@reactor.ru> Message-ID: <1045625547.1128.3.camel@ollie> On Wed, 2003-02-19 at 09:05, Alexander Amelkin wrote: > Hello! > > The linuxbios status comments for via epia say "etherboot" only. > Does that mean that epia won't be able to boot from a local ide hard > drive? Are there any plans to implement the support for > lilo/whatever booting from the hard drive on epia? > > Another question is about the pcchips 787cl+ 3.0 board. It's sis630e > + it8705. I didn't find sis630e in the list of supported devices, > but I found some discussion on how to enable or disable something on > that chipset. That's confusing. Is sis630e supported, or is it not? > SiS 630e is exactly the same as SiS 630 from SW point of view. -- ollie lho From Ulrik.Forsgren at epl.ericsson.se Wed Feb 19 07:33:00 2003 From: Ulrik.Forsgren at epl.ericsson.se (Ulrik Forsgren (EAB)) Date: Wed Feb 19 07:33:00 2003 Subject: irq_table.c without a pirq table? Message-ID: <9505F6390AA7D311A2D500508B951BEF0D470B54@esealnt427> Hi! Here is more information. Motherboard: Jetway 656HXA. Chipset: Intel 430HX, PIIX3 Superio: Winbond 83877f Original BIOS image: http://www.jetway.com.tw/evisn/download/bios/hxa/Hxa-b02.bin The motherboards was chosen because I needed something that I could experiment with and destory without loosing anything valuable. I have "successfully" booted a Linux kernel (mounted filesystem and running /bin/sh), but I ran into a similar problem as http://www.clustermatic.org/pipermail/linuxbios/2003-February/001904.html, I couldn't bring up the NIC. The reason was that the kernel couldn't assign an IRQ to it and I associate the problem with fact that I haven't implemented an irq table yet. So I started to search for one and getpir didn't result in a hit. Here I am search for all kind of information about PCI & interrupts and irq tables.... Best Regards, /UFo -----Original Message----- From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] Sent: den 19 februari 2003 02:54 To: Ulrik Forsgren (EAB) Cc: 'linuxbios at clustermatic.org' Subject: Re: irq_table.c without a pirq table? "Ulrik Forsgren (EAB)" writes: > Hi! > > I'm am testing LinuxBIOS on a Pentium motherboard that doesn't have a pirq table > in BIOS and I suppose that Linux requires a pirq table to be able route the irqs > to the PCI boards. > > I have scanned the original BIOS without finding the PIRQ tag. > > How can I create an irq_table.c when I can't copy it from the original BIOS? > > PCIBIOS 2.1 calls? Or looking at the irqs assigned on the pci bus and at the irq router. Or looking at the MP table. Or looking through the information provided by ACPI. Eric From zhushisongzhu at yahoo.com Wed Feb 19 08:20:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 19 08:20:00 2003 Subject: winbond 83977ef problem Message-ID: <20030219134028.8790.qmail@web13207.mail.yahoo.com> I'm using ec3 mainboard, it just like advantech pcm-5823, except ec3 use winbond 83977f as superio. the config file of the ec3 mainboard is as follows: # Copyright (c) 2002 Christer Weinigel # This is a config file for the evoc ec3 mainboard # The board is a National Semiconductor GX1 + CS5530 + winbond 83977f # design. It is a fairly complete PC with VGA, two serial port, one parallel port, two USB ports, a PS/2 Keyboard # connector (can also be used for a PS/2 Mouse using a splitter # cable), floppy, IDE and finally one ethernet port using a RTL8139C # ethernet chip. Other than that the board has a DiskOnChip socket # and a PC104 connector for expansion. arch i386 cpu p5 mainboardinit cpu/i386/entry16.inc mainboardinit cpu/i386/entry32.inc ldscript cpu/i386/entry16.lds ldscript cpu/i386/entry32.lds mainboardinit cpu/i386/reset16.inc ldscript cpu/i386/reset16.lds ######################################################################## option SERIAL_SUPERIO_BASEADDRESS=0x3f0 mainboardinit superio/winbond/w83977fa/setup_serial.inc mainboardinit pc80/serial.inc mainboardinit arch/i386/lib/console.inc ######################################################################## northbridge nsc/gx1 southbridge nsc/cs5530 nsuperio winbond/w83977ef keyboard=1 com1={1} com2={1} floppy=1 ######################################################################## # Lots of constans, you probably don't need to change anything here. "Config" 66 lines, 2139 characters # Lots of constans, you probably don't need to change anything here. # GX_BASE is the address of a configuration memory region for the GX1 # processor. You probably don't want to change this. option GX_BASE=0x40000000 ######################################################################## # Southbridge configuration # no need to assign INTA-D, since it is done by pirq table # option CS5530_INTA=9 # option CS5530_INTB=10 # option CS5530_INTC=11 # option CS5530_INTD=15 option CS5530_PRIMARY_IDE=1 option CS5530_SECONDARY_IDE=1 ######################################################################## option NO_KEYBOARD=1 option FINAL_MAINBOARD_FIXUP=1 object mainboard.o object irq_tables.o option ZKERNEL_START=0xfffc0000 option HAVE_PIRQ_TABLE=1 # Local variables: # compile-command: "make -C /export/bios/voyager2" # End: But when entering winbond configuration mode, ec3 halt. part of crt0.s as following: ........ movb $ 0x88 , %al ; outb %al, $0x80 /*work ok, can see it from pc diagnostic card*/ movb $0x87 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb /* halt*/ movb $ 0x89 , %al ; outb %al, $0x80 /*can't see it from pc dianostic card*/ movb $0x87 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $ 0x90 , %al ; outb %al, $0x80 movb $7 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $2 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $ 0x90 , %al ; outb %al, $0x80 movb $0x30 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $1 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x24 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0xa4 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x2b , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x1 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb what's the problem? zhu --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhushisongzhu at yahoo.com Wed Feb 19 08:27:12 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 19 08:27:12 2003 Subject: winbond 83977ef problem Message-ID: <20030219134041.25282.qmail@web13201.mail.yahoo.com> I'm using ec3 mainboard, it just like advantech pcm-5823, except ec3 use winbond 83977f as superio. the config file of the ec3 mainboard is as follows: # Copyright (c) 2002 Christer Weinigel # This is a config file for the evoc ec3 mainboard # The board is a National Semiconductor GX1 + CS5530 + winbond 83977f # design. It is a fairly complete PC with VGA, two serial port, one parallel port, two USB ports, a PS/2 Keyboard # connector (can also be used for a PS/2 Mouse using a splitter # cable), floppy, IDE and finally one ethernet port using a RTL8139C # ethernet chip. Other than that the board has a DiskOnChip socket # and a PC104 connector for expansion. arch i386 cpu p5 mainboardinit cpu/i386/entry16.inc mainboardinit cpu/i386/entry32.inc ldscript cpu/i386/entry16.lds ldscript cpu/i386/entry32.lds mainboardinit cpu/i386/reset16.inc ldscript cpu/i386/reset16.lds ######################################################################## option SERIAL_SUPERIO_BASEADDRESS=0x3f0 mainboardinit superio/winbond/w83977fa/setup_serial.inc mainboardinit pc80/serial.inc mainboardinit arch/i386/lib/console.inc ######################################################################## northbridge nsc/gx1 southbridge nsc/cs5530 nsuperio winbond/w83977ef keyboard=1 com1={1} com2={1} floppy=1 ######################################################################## # Lots of constans, you probably don't need to change anything here. "Config" 66 lines, 2139 characters # Lots of constans, you probably don't need to change anything here. # GX_BASE is the address of a configuration memory region for the GX1 # processor. You probably don't want to change this. option GX_BASE=0x40000000 ######################################################################## # Southbridge configuration # no need to assign INTA-D, since it is done by pirq table # option CS5530_INTA=9 # option CS5530_INTB=10 # option CS5530_INTC=11 # option CS5530_INTD=15 option CS5530_PRIMARY_IDE=1 option CS5530_SECONDARY_IDE=1 ######################################################################## option NO_KEYBOARD=1 option FINAL_MAINBOARD_FIXUP=1 object mainboard.o object irq_tables.o option ZKERNEL_START=0xfffc0000 option HAVE_PIRQ_TABLE=1 # Local variables: # compile-command: "make -C /export/bios/voyager2" # End: But when entering winbond configuration mode, ec3 halt. part of crt0.s as following: ........ movb $ 0x88 , %al ; outb %al, $0x80 /*work ok, can see it from pc diagnostic card*/ movb $0x87 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb /* halt*/ movb $ 0x89 , %al ; outb %al, $0x80 /*can't see it from pc dianostic card*/ movb $0x87 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $ 0x90 , %al ; outb %al, $0x80 movb $7 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $2 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $ 0x90 , %al ; outb %al, $0x80 movb $0x30 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $1 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x24 , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0xa4 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x2b , %al; movw 0x3f0 , %dx; outb %al, %dx ; outb %al,$0xeb movb $0x1 , %al; movw 0x3f0 +1 , %dx; outb %al, %dx ; outb %al,$0xeb what's the problem? zhu --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerj at coplanar.net Wed Feb 19 09:33:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Wed Feb 19 09:33:00 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? Message-ID: <1045666425.3456.3.camel@contact.skynet.coplanar.net> I'm looking at bits and pieces of a TI/Acer Extensa 455T laptop, and I would like to try LinuxBIOS for it if I can get the datasheet. I wrote ALI, but I'm not getting my hopes up. -- Jeremy Jackson From jerj at coplanar.net Wed Feb 19 09:51:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Wed Feb 19 09:51:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: <1045667536.3456.5.camel@contact.skynet.coplanar.net> On Thu, 2003-02-13 at 14:11, Steve M. Gehlbach wrote: > Will you be able to use the gnu pre-processor unchanged? or adapt it? The > macro expansion seems pretty important. FYI, I was reading about newer GCC (3.2?) that have merged the preprocessor into the main parser. -- Jeremy Jackson From rminnich at lanl.gov Wed Feb 19 10:05:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 10:05:00 2003 Subject: irq_table.c without a pirq table? In-Reply-To: <9505F6390AA7D311A2D500508B951BEF0D470B54@esealnt427> Message-ID: On Wed, 19 Feb 2003, Ulrik Forsgren (EAB) wrote: > Hi! > > Here is more information. > > Motherboard: Jetway 656HXA. > Chipset: Intel 430HX, PIIX3 ^^^^^ unsupported chipset. Were you going to do your own? ron From rminnich at lanl.gov Wed Feb 19 10:22:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 10:22:00 2003 Subject: Ram initialization and small c. In-Reply-To: <1045667536.3456.5.camel@contact.skynet.coplanar.net> Message-ID: On 19 Feb 2003, Jeremy Jackson wrote: > On Thu, 2003-02-13 at 14:11, Steve M. Gehlbach wrote: > > > Will you be able to use the gnu pre-processor unchanged? or adapt it? The > > macro expansion seems pretty important. > > FYI, I was reading about newer GCC (3.2?) that have merged the > preprocessor into the main parser. I have been on the hunt for small c-like compilers. I have yet to find one that runs in the registers only, i.e. has an addressable memory of 16 words. My concern about a full-blown c compiler is this: we are going to move from debugging 1000 or so lines of assembly to debugging the compiler, and shipping a full compiler with linuxbios, just to eliminate this 1000 or so lines of assembly. It seems hard to justify. Since we will be the probable only users of this compiler the support burden will fall on us. There are not that many people out there needing a compiler that does this "your memory is only your register set" capability. Is there another way? Could we, for example, build a tool that would take a description of the actions for turning on memory and generate the code? This would be a specialized "little language". I'm looking for those too -- sort of a "meta assembler". I once wrote an OS using a set of "algol-like" assembler macros. It wasn't perfect but the job of writing the OS was considerably reduced. Should we do this? I think we would all like something better than assembly for the hard memory turn-on step, I am just not sure it is a C compiler. thanks ron From rminnich at lanl.gov Wed Feb 19 10:31:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 10:31:00 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? In-Reply-To: <1045666425.3456.3.camel@contact.skynet.coplanar.net> Message-ID: On 19 Feb 2003, Jeremy Jackson wrote: > I'm looking at bits and pieces of a TI/Acer Extensa 455T laptop, and I > would like to try LinuxBIOS for it if I can get the datasheet. I wrote > ALI, but I'm not getting my hopes up. Is this a new or old laptop? ron From ebiederman at lnxi.com Wed Feb 19 11:26:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 19 11:26:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 19 Feb 2003, Jeremy Jackson wrote: > > > On Thu, 2003-02-13 at 14:11, Steve M. Gehlbach wrote: > > > > > Will you be able to use the gnu pre-processor unchanged? or adapt it? The > > > macro expansion seems pretty important. > > > > FYI, I was reading about newer GCC (3.2?) that have merged the > > preprocessor into the main parser. > > I have been on the hunt for small c-like compilers. I have yet to find one > that runs in the registers only, i.e. has an addressable memory of 16 > words. > > My concern about a full-blown c compiler is this: we are going to move > from debugging 1000 or so lines of assembly to debugging the compiler, and > shipping a full compiler with linuxbios, just to eliminate this 1000 or so > lines of assembly. To shipping a 1000 or so lines of C. And it is not a full compiler for all of C just an appropriate subset. And the output will be assembler. > It seems hard to justify. Since we will be the probable > only users of this compiler the support burden will fall on us. There are > not that many people out there needing a compiler that does this "your > memory is only your register set" capability. Nope. > Is there another way? Could we, for example, build a tool that would take > a description of the actions for turning on memory and generate the code? > This would be a specialized "little language". I'm looking for those too > -- sort of a "meta assembler". Personally I think it is harder to write a compiler for a declarative language instead of an imperative language like C. > I once wrote an OS using a set of "algol-like" assembler macros. It wasn't > perfect but the job of writing the OS was considerably reduced. Should we > do this? That is essentially what I am suggesting. > I think we would all like something better than assembly for the hard > memory turn-on step, I am just not sure it is a C compiler. Personally I don't think it will be that bad. Non optimizing compilers are straight forward and pretty easy to get right. The basic trick is not to let the task be overwhelming. The largest benefit comes from supporting a subset of C, as that allows code sharing. I currently have a month in my schedule to investigate that. If it looks to hard I will back off but I intend to give it a good effort. To my mind this problem is a lot like supporting printf. A full printf is scary and huge. And small subset of printf like we have now is not to bad and can easily maintained. And it can be easily extended to add missing printf features if needed. In school I majored in languages and I wrote a C interpreter in a semester, and if I had another week or two it would have been a compiler as well. The nastiest most distracting part of a compiler is the parser, and that we can borrow from elsewhere. My intention is to use a recursive descent parser, so the compiler can be easily tweaked. And I guess I do not see the maintenance being a major issue. Small simple focus programs that don't handle the general case tend to be easier to write, and maintain. Eric From spirit at reactor.ru Wed Feb 19 11:35:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Wed Feb 19 11:35:00 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <1045625547.1128.3.camel@ollie> References: <167257821407.20030219040500@reactor.ru> <1045625547.1128.3.camel@ollie> Message-ID: <53314450055.20030219194849@reactor.ru> Hello ollie, Wednesday, February 19, 2003, 6:32:27 AM, you wrote: >> Another question is about the pcchips 787cl+ 3.0 board. It's sis630e >> + it8705. I didn't find sis630e in the list of supported devices, >> but I found some discussion on how to enable or disable something on >> that chipset. That's confusing. Is sis630e supported, or is it not? >> ol> SiS 630e is exactly the same as SiS 630 from SW point of view. Cool, but SiS630 is not on the list. There is SiS635 and pcchips m758lmr+, both without any status report. I assume that pcchips m758lmr+ is somehow similar to the pcchips m758LT v7.0, which is listed on the pcchips site, but anyway the status for m758lmr+ is empty. :( Does that mean that there is no SiS630 version of the linuxbios? With best regards, Alexander mailto:spirit at reactor.ru From bari at onelabs.com Wed Feb 19 11:43:00 2003 From: bari at onelabs.com (Bari Ari) Date: Wed Feb 19 11:43:00 2003 Subject: Blurring The Line Between BIOS And OS Message-ID: <3E53B79D.6000305@onelabs.com> Anyone else see this yesterday? The Register http://www.theregister.co.uk/content/3/29374.html and Slashdot had an article http://slashdot.org/article.pl?sid=03/02/18/2228255 about "software (that resides within the system firmware and a protected area of the hard drive) that allows users on anything from servers to embedded systems to run diagnostics, browse the web and other things without having to boot into a full fledged OS." Hey let's fix broken BIOS and hardware bugs with some broken bloatware. --Bari From ebiederman at lnxi.com Wed Feb 19 11:51:02 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 19 11:51:02 2003 Subject: Ram initialization and small c. In-Reply-To: <1045667536.3456.5.camel@contact.skynet.coplanar.net> References: <1045667536.3456.5.camel@contact.skynet.coplanar.net> Message-ID: Jeremy Jackson writes: > On Thu, 2003-02-13 at 14:11, Steve M. Gehlbach wrote: > > > Will you be able to use the gnu pre-processor unchanged? or adapt it? The > > macro expansion seems pretty important. > > FYI, I was reading about newer GCC (3.2?) that have merged the > preprocessor into the main parser. It doesn't much matter as the preprocessor is not that complicated. Eric From whm_buaa at sina.com Wed Feb 19 12:07:00 2003 From: whm_buaa at sina.com (=?GB2312?Q?=CD=F5=BA=A3=C3=F7?=) Date: Wed Feb 19 12:07:00 2003 Subject: help!!!who can explain the interface between linuxbios and linux. Message-ID: <200302191706.h1JH6eG06375@nwn.definitive.org> dear all: I have developed a linuxbios debug system succefully.I introduced gdb stub into my system. In my system ,developers can debug linuxbios at source code level. I setup the stub at the beginning of the begin of the function of hardwaremain, the first c function.Now the system can excute the function of "step",'step into" "step out" ,"breakpoint"and so on. but the system has not been tested fully. I wonder if my design is usefull to others. by the way, I have several question.I will appreciate anyone's any idea! my question are as follows: 1. As we know, traditonal BIOS not only do some initialization work, but also put some data about the hardware in somewhere.BIOS even offer some routine such as intx( I know that In linux souce file "setup.s",int10, int13and int15 are used),but linuxbios doesn't offer. my question is: what is the mininal need of linux kernel's starting? what data does It need in detail? where does the data need to be placed in detail? what routine does linux kernel need for it's starting ? how does linuxbios offer these data and routines? 2. the second question is about PCI. I found that in linuxbios, some PCI initialization work is done.as we know ,in linux kernel, the same work was be done.Some linuxbios PCI initialization code is even the same with linux kernel. my question is: if the initialization in linuxbios is necessary? 3. my third question is about etherboot. I get a ide-patch of etherboot, and I succefully boot my system via IDE .I have read the code for a long time,but still have no idea about it. I found it seems does not do the same as setup.s,the kernel loader of traditional linux.who can explain it to me? I know there are some clever and experienced man in this site.I am very interested in this topic and admire all the man with good skills.I am looking forward to some help. best regards! yours HaimingWang -------------- next part -------------- An HTML attachment was scrubbed... URL: From spirit at reactor.ru Wed Feb 19 12:33:01 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Wed Feb 19 12:33:01 2003 Subject: via epia, pchips 787cl+ In-Reply-To: References: <167257821407.20030219040500@reactor.ru> Message-ID: <23318273623.20030219205232@reactor.ru> Hello Eric, Wednesday, February 19, 2003, 4:32:39 AM, you wrote: EWB> Alexander Amelkin writes: >> Hello! >> >> The linuxbios status comments for via epia say "etherboot" only. >> Does that mean that epia won't be able to boot from a local ide hard >> drive? EWB> Nope, etherboot supports booting from the local ide hard drive, EWB> at least as well as the native LinuxBIOS IDE code does. Cool! Can you tell me how critical that "problem with irq routing table" is on VIA EPIA? >> Are there any plans to implement the support for >> lilo/whatever booting from the hard drive on epia? EWB> Things are gradually improving. Those of us who think a development EWB> machines has a 1000 motherboards don't always see the point in booting EWB> off a local hard drive :) I didn't understand what you meant, but the fact that etherboot supports booting from a local hard disk is very good. With best regards, Alexander mailto:spirit at reactor.ru Reactor Critical - 3D Hardware reviews http://www.reactor.ru - in Russian http://www.reactorcritical.com - in English --8<--just-a-cookie---------------------------------------------- Solving the problem takes three times less time than discussing all pros and cons of the solution. --8<------------------------------------------------------------- From pyro at linuxlabs.com Wed Feb 19 12:42:01 2003 From: pyro at linuxlabs.com (steven james) Date: Wed Feb 19 12:42:01 2003 Subject: weighing in In-Reply-To: Message-ID: Greetings, Given the many permutations of com lpt, and other devices from (possibly multiple) superios, I wonder if a linked list of single device structs might not be a better abstraction. I've certainly seen enough cases where various chips provide the same class of device, such as e750[01] where ICH3 provides IDE and Intel puts a Promise IDE-RAID (really just IDE with soft raid in firmware) on the board. Then there's the SiS630 boards that have an rtl8139 and a disconnected SiS900 ethernet on board. G'day, sjames On 18 Feb 2003, Eric W. Biederman wrote: > "Ronald G. Minnich" writes: > > > On 18 Feb 2003, Eric W. Biederman wrote: > > > > > Right now I have a larger number of initialization functions being > > > called from mainboard_fixup. Those are the real functions that need > > > to be tackled. The superio model comes close to handling those cases > > > cleanly. The big issue with superio code is that we use one structure > > > for all possible static values, that is silly. > > > > There are two static structures in there, and I think I know which one you > > mean, but want to clarify. > > > > This one, I assume, is OK > > > > struct superio_control { > > void (*pre_pci_init)(struct superio *s); > > void (*init)(struct superio *s); > > void (*finishup)(struct superio *s); > > unsigned int defaultport; /* the defaultport. Can be overridden > > * by commands in config > > */ > > // This is the print name for debugging > > char *name; > > }; > > > > > > Fairly generic and represents how to attack a superio. Universal to all > > superios. > > Right. The one I have for pci is a little different but roughly equivalent. > > > This one, I think is the mistake: > > I would just call it in need of a better abstraction. Not > a really a mistake. > > > struct superio { > > struct superio_control *super; // the ops for the device. > > unsigned int port; // if non-zero, overrides the default port > > // com ports. This is not done as an array (yet). > > // We think it's easier to set up from python if it is not an > > array. > > struct com_ports com1, com2, com3, com4; > > // DMA, if it exists. > > struct lpt_ports lpt1, lpt2; > > /* flags for each device type. Unsigned int. */ > > // low order bit ALWAYS means enable. Next bit means to enable > > // LPT is in transition, so we leave this here for the moment. > > // The winbond chips really stretched the way this works. > > // so many functions! > > unsigned int ide, floppy, lpt; > > unsigned int keyboard, cir, game; > > unsigned int gpio1, gpio2, gpio3; > > unsigned int acpi,hwmonitor; > > }; > > > > because all the superios are so different (I never realized how > > different!) this struct is a mess and we don't want to repeat this for the > > south and north bridge hardware. > > Correct. > > > Make sense? > > Yes. > > I am thinking of something like: > > struct setup_info { > struct setup_info *next; > int type; > }; > > struct irq_routing { > struct setup_info info; > /* Flesh this out... */ > }; > > struct static_resources { > struct setup_info info; > /* Flesh this out... */ > }; > > struct old_superio { > struct setup_info info; > struct com_ports com1, com2, com3, com4; > struct lpt_ports lpt1,lpt2; > unsigned int ide, floppy, lpt; > unsigned int keyboard, cir, game; > unsigned int gpio1, gpio2, gpio3; > unsigned int acpi,hwmonitor; > /* Don't use this for real.. */ > }; > > The important characteristics are: > > - Any developer can add new structure types and they can be > motherboard or device specific > > - There is a way for generic code to access configuration settings > information about a device. > > Eric > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From rminnich at lanl.gov Wed Feb 19 12:50:21 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 12:50:21 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <53314450055.20030219194849@reactor.ru> Message-ID: On Wed, 19 Feb 2003, Alexander Amelkin wrote: > Cool, but SiS630 is not on the list. There is SiS635 and pcchips > m758lmr+, both without any status report. I assume that pcchips m758lmr+ > is somehow similar to the pcchips m758LT v7.0, which is listed on the > pcchips site, but anyway the status for m758lmr+ is empty. :( > > Does that mean that there is no SiS630 version of the linuxbios? there was, but I have had no confirmed "good builds" lately. ron From rminnich at lanl.gov Wed Feb 19 12:59:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 12:59:01 2003 Subject: Blurring The Line Between BIOS And OS In-Reply-To: <3E53B79D.6000305@onelabs.com> Message-ID: On Wed, 19 Feb 2003, Bari Ari wrote: > Hey let's fix broken BIOS and hardware bugs with some broken bloatware. > I found the whole thing pretty amusing. ron From steve at nexpath.com Wed Feb 19 13:07:04 2003 From: steve at nexpath.com (Steve M. Gehlbach) Date: Wed Feb 19 13:07:04 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <53314450055.20030219194849@reactor.ru> Message-ID: > Cool, but SiS630 is not on the list. There is SiS635 and pcchips > m758lmr+, both without any status report. I assume that pcchips m758lmr+ > is somehow similar to the pcchips m758LT v7.0, which is listed on the > pcchips site, but anyway the status for m758lmr+ is empty. :( > > Does that mean that there is no SiS630 version of the linuxbios? > > With best regards, > Alexander mailto:spirit at reactor.ru mainboard/pcchips/m787cl+ The 787cl+ uses the sis630 and status is stable. The config (util/config/pcchips787.config) is setup to boot from IDE using linuxbios ide routines. -Steve From ebiederman at lnxi.com Wed Feb 19 14:40:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 19 14:40:01 2003 Subject: via epia, pchips 787cl+ In-Reply-To: <23318273623.20030219205232@reactor.ru> References: <167257821407.20030219040500@reactor.ru> <23318273623.20030219205232@reactor.ru> Message-ID: Alexander Amelkin writes: > Hello Eric, > > Wednesday, February 19, 2003, 4:32:39 AM, you wrote: > > EWB> Alexander Amelkin writes: > > >> Hello! > >> > >> The linuxbios status comments for via epia say "etherboot" only. > >> Does that mean that epia won't be able to boot from a local ide hard > >> drive? > > EWB> Nope, etherboot supports booting from the local ide hard drive, > EWB> at least as well as the native LinuxBIOS IDE code does. > > Cool! Can you tell me how critical that "problem with irq routing > table" is on VIA EPIA? I wouldn't know. > > >> Are there any plans to implement the support for > >> lilo/whatever booting from the hard drive on epia? > > EWB> Things are gradually improving. Those of us who think a development > EWB> machines has a 1000 motherboards don't always see the point in booting > EWB> off a local hard drive :) > > I didn't understand what you meant That last couple of machines I played with LinuxBIOS on were: MCR A cluster with roughly 1200 nodes. Pink (for Ron Minnich) with roughly a 1000 nodes. > but the fact that etherboot > supports booting from a local hard disk is very good. While there is support for booting off of the hard drive we don't have all of the usability issues ironed out yet. In particular you can boot one thing off of the hard drive and lilo/whatever don't work yet. Eric From ebiederman at lnxi.com Wed Feb 19 14:50:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 19 14:50:01 2003 Subject: weighing in In-Reply-To: References: Message-ID: steven james writes: > Greetings, > > Given the many permutations of com lpt, and other devices from (possibly > multiple) superios, I wonder if a linked list of single device structs > might not be a better abstraction. I agree. The more I look at the more I like the linked list idea. Being able to have structures for the common things like ide/serial/parallel ports sounds very good. > I've certainly seen enough cases where various chips provide the same > class of device, such as e750[01] where ICH3 provides IDE and Intel puts a > Promise IDE-RAID (really just IDE with soft raid in firmware) on the > board. > > Then there's the SiS630 boards that have an rtl8139 and a disconnected > SiS900 ethernet on board. Yep. We have to know which chips are on the board and which ones to enable. Eric From ollie at sis.com.tw Wed Feb 19 19:46:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Wed Feb 19 19:46:01 2003 Subject: via epia, pchips 787cl+ In-Reply-To: References: Message-ID: <1045703040.1129.6.camel@ollie> On Thu, 2003-02-20 at 01:56, Ronald G. Minnich wrote: > On Wed, 19 Feb 2003, Alexander Amelkin wrote: > > > Cool, but SiS630 is not on the list. There is SiS635 and pcchips > > m758lmr+, both without any status report. I assume that pcchips m758lmr+ > > is somehow similar to the pcchips m758LT v7.0, which is listed on the > > pcchips site, but anyway the status for m758lmr+ is empty. :( > > > > Does that mean that there is no SiS630 version of the linuxbios? > > there was, but I have had no confirmed "good builds" lately. > I am sorry for that. We don't have any 730 or 730 boards around so I can not do regression test on that. -- ollie lho From terryc at tyanchina.com Wed Feb 19 20:18:01 2003 From: terryc at tyanchina.com (Terry B. Chen) Date: Wed Feb 19 20:18:01 2003 Subject: question about option parameter Message-ID: <441383BA85E81D48964152E537886C9D28B0F4@mail.sh.corp.tyan.com> Hi all: Because the payload for normal image is too big, so I have to make one 1MB Linuxbios rom. Then I change the option ROM_SIZE=1048576 but I get a rom of 1,343,488. someone can help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerj at coplanar.net Wed Feb 19 21:48:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Wed Feb 19 21:48:01 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? In-Reply-To: References: Message-ID: <1045710545.3902.0.camel@contact.skynet.coplanar.net> On Wed, 2003-02-19 at 10:51, Ronald G. Minnich wrote: > On 19 Feb 2003, Jeremy Jackson wrote: > > > I'm looking at bits and pieces of a TI/Acer Extensa 455T laptop, and I > > would like to try LinuxBIOS for it if I can get the datasheet. I wrote > > ALI, but I'm not getting my hopes up. > > > Is this a new or old laptop? Very old. > > ron -- Jeremy Jackson From whm_buaa at sina.com Wed Feb 19 21:55:01 2003 From: whm_buaa at sina.com (=?us-ascii?Q?=CD=F5=BA=A3=C3=F7?=) Date: Wed Feb 19 21:55:01 2003 Subject: help!!!who can explain the interface between linuxbios and linux. Message-ID: <200302200249.h1K2nhG08442@nwn.definitive.org> dear all: I have developed a linuxbios debug system succefully.I introduced gdb stub into my system. In my system ,developers can debug linuxbios at source code level. I setup the stub at the beginning of the begin of the function of hardwaremain, the first c function.Now the system can excute the function of "step",'step into" "step out" ,"breakpoint"and so on. but the system has not been tested fully. I wonder if my design is usefull to others. by the way, I have several question.I will appreciate anyone's any idea! my question are as follows: 1. As we know, traditonal BIOS not only do some initialization work, but also put some data about the hardware in somewhere.BIOS even offer some routine such as intx( I know that In linux souce file "setup.s",int10, int13and int15 are used),but linuxbios doesn't offer. my question is: what is the mininal need of linux kernel's starting? what data does It need in detail? where does the data need to be placed in detail? what routine does linux kernel need for it's starting ? how does linuxbios offer these data and routines? 2. the second question is about PCI. I found that in linuxbios, some PCI initialization work is done.as we know ,in linux kernel, the same work was be done.Some linuxbios PCI initialization code is even the same with linux kernel. my question is: if the initialization in linuxbios is necessary? 3. my third question is about etherboot. I get a ide-patch of etherboot, and I succefully boot my system via IDE .I have read the code for a long time,but still have no idea about it. I found it seems does not do the same as setup.s,the kernel loader of traditional linux.who can explain it to me? I know there are some clever and experienced man in this site.I am very interested in this topic and admire all the man with good skills.I am looking forward to some help. best regards! yours HaimingWang -------------- next part -------------- An HTML attachment was scrubbed... URL: From whm_buaa at sina.com Wed Feb 19 22:02:00 2003 From: whm_buaa at sina.com (=?GB2312?Q?=CD=F5=BA=A3=C3=F7?=) Date: Wed Feb 19 22:02:00 2003 Subject: help!!!who can explain the interface between linuxbios and linux. Message-ID: <200302200255.h1K2tJG08482@nwn.definitive.org> dear all: I have developed a linuxbios debug system succefully.I introduced gdb stub into my system. In my system ,developers can debug linuxbios at source code level. I setup the stub at the beginning of the begin of the function of hardwaremain, the first c function.Now the system can excute the function of "step",'step into" "step out" ,"breakpoint"and so on. but the system has not been tested fully. I wonder if my design is usefull to others. by the way, I have several question.I will appreciate anyone's any idea! my question are as follows: 1. As we know, traditonal BIOS not only do some initialization work, but also put some data about the hardware in somewhere.BIOS even offer some routine such as intx( I know that In linux souce file "setup.s",int10, int13and int15 are used),but linuxbios doesn't offer. my question is: what is the mininal need of linux kernel's starting? what data does It need in detail? where does the data need to be placed in detail? what routine does linux kernel need for it's starting ? how does linuxbios offer these data and routines? 2. the second question is about PCI. I found that in linuxbios, some PCI initialization work is done.as we know ,in linux kernel, the same work was be done.Some linuxbios PCI initialization code is even the same with linux kernel. my question is: if the initialization in linuxbios is necessary? 3. my third question is about etherboot. I get a ide-patch of etherboot, and I succefully boot my system via IDE .I have read the code for a long time,but still have no idea about it. I found it seems does not do the same as setup.s,the kernel loader of traditional linux.who can explain it to me? I know there are some clever and experienced man in this site.I am very interested in this topic and admire all the man with good skills.I am looking forward to some help. best regards! yours HaimingWang -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Wed Feb 19 22:38:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 19 22:38:01 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? In-Reply-To: <1045710545.3902.0.camel@contact.skynet.coplanar.net> Message-ID: On 19 Feb 2003, Jeremy Jackson wrote: > On Wed, 2003-02-19 at 10:51, Ronald G. Minnich wrote: > > On 19 Feb 2003, Jeremy Jackson wrote: > > > > > I'm looking at bits and pieces of a TI/Acer Extensa 455T laptop, and I > > > would like to try LinuxBIOS for it if I can get the datasheet. I wrote > > > ALI, but I'm not getting my hopes up. > > > > > > Is this a new or old laptop? > > Very old. > > If it doesn't have SDRAM, but only has DRAM, there is a good chance that DRAM will Just Work, simplifying linuxbios. I sure wish you would buy a new sis 630-based laptop and make it work! ron From rminnich at lanl.gov Thu Feb 20 00:02:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 20 00:02:01 2003 Subject: help!!!who can explain the interface between linuxbios and linux. In-Reply-To: <200302200255.h1K2tJG08482@nwn.definitive.org> Message-ID: On Tue, 20 Feb 2001, [GB2312] ?????? wrote: > dear all: > I have developed a linuxbios debug system succefully.I introduced gdb > stub into my system. In my system ,developers can debug linuxbios at > source code level. I setup the stub at the beginning of the begin of the > function of hardwaremain, the first c function.Now the system can excute > the function of "step",'step into" "step out" ,"breakpoint"and so on. > but the system has not been tested fully. > I wonder if my design is usefull to others. This is truly wonderful, and we need to get it into the tree, I can try to work with you on that. > 2. the second question is about PCI. I found that in linuxbios, some PCI > initialization work is done.as we know ,in linux kernel, the same work > was be done.Some linuxbios PCI initialization code is even the same with > linux kernel. my question is: > if the initialization in linuxbios is necessary? yes, it is, Linux has shown that it must have some PCI initialization done. Thanks, and if you don't get other answers for the other questions I will try to answer those too. ron From nick-linuxbios at bostonimportcenter.com Thu Feb 20 01:50:01 2003 From: nick-linuxbios at bostonimportcenter.com (Nicholas Mistry) Date: Thu Feb 20 01:50:01 2003 Subject: 2 questions.. 1. laptops and linuxbios, 2. bios-savior for laptops? Message-ID: <1233.64.216.21.158.1045725026.squirrel@www.mistry.com> ok, sorry for the dual post, but they are somewhat related. 1. I havent really put much thought to using linuxbios on a laptop, but a recent post has planted a bug in my brain to try and get it to work on some of the older laptops i have laying around. How many people have tried to get linux bios on their laptops, and how well does it work. this issue now prompts this quesion: 2. What type of "bios savior" options are there for laptops? or is that just a pipe dream at this point? -N From terryc at tyanchina.com Thu Feb 20 03:21:01 2003 From: terryc at tyanchina.com (Terry B. Chen) Date: Thu Feb 20 03:21:01 2003 Subject: option_table ? Message-ID: <441383BA85E81D48964152E537886C9D28B172@mail.sh.corp.tyan.com> Hi all, I have a question about option table; the utility "build_opt_tbl.c" will give us an option_table.c automatically, but where is the option_table [ ] used? How to control my Linuxbios go to fallback or normal image? We always run in fallback image. Can someone give me some suggestions? The code is in file reset_test.inc and cmos_failover.inc. The code total is " #define MCH_DRC 0x7C #define DRC_IC (1 << 29) /* If I have already booted once skip a bunch of initialization */ /* To see if I have already booted I check to see if memory * has been enabled. */ movl $MCH_DRC, %eax PCI_READ_CONFIG_DWORD testl $DRC_IC, %eax setnz %al testb %al, %al jz __failover_boot __failover_reset: movb $RTC_BOOT_BYTE, %al outb %al, $0x70 inb $0x71, %al testb $(1<<1), %al jnz __normal_image jmp __cpu_reset __failover_boot: /* See if the cmos clear jumper has been set */ movl $((RTC_DEVFN << 8) | GEN_PMCON_3), %eax PCI_READ_CONFIG_DWORD testl $RTC_FAILED, %eax jz __cs_test /* There are no impossible values, no checksums * so just trust whatever value we have in the * cmos. */ __rtc_failed: movb $RTC_BOOT_BYTE, %al outb %al, $0x70 inb $0x71, %al andb $0xfc, %al outb %al, $0x71 jmp __cs_test /* test the checksum */ __cs_test: movl $77,%ecx xor %ebx,%ebx movl $RTC_BOOT_BYTE, %edx 1: addl $1, %edx movl %edx, %eax outb %al, $0x70 inb $0x71, %al addl %eax,%ebx subl $1,%ecx jnz 1b not %ebx addl $1, %edx movl %edx, %eax outb %al, $0x70 inb $0x71, %al movb %al,%ch addl $1, %edx movl %edx, %eax outb %al, $0x70 inb $0x71, %al movb %ch,%ah cmpw %ax,%bx jz __rtc_ok /* Set to fall back mode */ movb $RTC_BOOT_BYTE, %al outb %al, $0x70 inb $0x71, %al andb $0xfc, %al outb %al, $0x71 /* The byte is o.k. see where to go */ __rtc_ok: movb $RTC_BOOT_BYTE, %al outb %al, $0x70 inb $0x71, %al /* Transfer the boot bit from bit 0 to bit 1. * And clear bit 0 so that unless we say it works we * fallback to the other bios image immediately. */ movb %al, %bl andb $0xfc, %al andb $1, %bl shlb %bl orb %bl, %al outb %al, $0x71 testb $(1<<1), %al jnz __normal_image -------------- next part -------------- An HTML attachment was scrubbed... URL: From terryc at tyanchina.com Thu Feb 20 05:59:01 2003 From: terryc at tyanchina.com (Terry B. Chen) Date: Thu Feb 20 05:59:01 2003 Subject: how to choice fallback or normal image? Message-ID: <441383BA85E81D48964152E537886C9D28B188@mail.sh.corp.tyan.com> Dear all: I was puzzled by the fallback and normal image in s2722 (e7500), I am sorry to ask so simple question. When shall we use the fallback image and when shall we use the normal image? How you control which to run? The register DRC (7c) bit 29(Init complete) seem not to be set after memory initialization complete. am I right? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerj at coplanar.net Thu Feb 20 08:48:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Thu Feb 20 08:48:01 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? In-Reply-To: References: Message-ID: <1045750175.4674.9.camel@contact.skynet.coplanar.net> On Wed, 2003-02-19 at 22:58, Ronald G. Minnich wrote: > > If it doesn't have SDRAM, but only has DRAM, there is a good chance that > DRAM will Just Work, simplifying linuxbios. How is that? It is FP-DRAM, do some of those controllers do the autosizing in hardware? It has 2 SODIMMs. I seem to remember now that 72pin SIMMs had size jumpers. > > I sure wish you would buy a new sis 630-based laptop and make it work! I'd love to. It may not be in my budget right now. BUT, who makes them? I will look around at stores; I'd prefer to have one apart first, but I might settle for and lspci on one in a store. LinuxBIOS support is one criterion, ATI or other open-source DRI supported 3d graphics is another. -- Jeremy Jackson From rminnich at lanl.gov Thu Feb 20 09:54:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 20 09:54:00 2003 Subject: 2 questions.. 1. laptops and linuxbios, 2. bios-savior for laptops? In-Reply-To: <1233.64.216.21.158.1045725026.squirrel@www.mistry.com> Message-ID: On Thu, 20 Feb 2003, Nicholas Mistry wrote: > 1. I havent really put much thought to using linuxbios on a laptop, but a > recent post has planted a bug in my brain to try and get it to work on > some of the older laptops i have laying around. How many people have > tried to get linux bios on their laptops, and how well does it work. we tried with IBM but IBM wouldn't let IBM put linuxbios on an IBM laptop. Yes, this is all true. > 2. What type of "bios savior" options are there for laptops? or is that > just a pipe dream at this point? linuxbios fallback would work fine as a bios savior. Plus, many laptops have on options if you fry the flash. ron From rminnich at lanl.gov Thu Feb 20 09:58:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 20 09:58:01 2003 Subject: ALI M1429L 386/486 mem ctlr datasheet - anyone have it? In-Reply-To: <1045750175.4674.9.camel@contact.skynet.coplanar.net> Message-ID: On 20 Feb 2003, Jeremy Jackson wrote: > How is that? It is FP-DRAM, do some of those controllers do the > autosizing in hardware? It has 2 SODIMMs. I seem to remember now that > 72pin SIMMs had size jumpers. no, the old DRAM is simple. You just start accessing it. To see how much there is, you start reading/writing until you get errors. It was really easy. ron From pyro at linuxlabs.com Thu Feb 20 10:06:01 2003 From: pyro at linuxlabs.com (steven james) Date: Thu Feb 20 10:06:01 2003 Subject: how to choice fallback or normal image? In-Reply-To: <441383BA85E81D48964152E537886C9D28B188@mail.sh.corp.tyan.com> Message-ID: Greetings, Several conditions need to exist for the primary image to be used. The code looks at the RTC register to check for indication of power failure (either battery dead, or clear CMOS jumper set), then the CMOS checksum is checked. If both tests show that CMOS is valid, then check the RTC_BOOT_BYTE. First, bit 0 is moved to bit 1 and bit 0 is cleared. Then, if bit 1 is set, call the primary (normal image), That is done so that if the boot fails for some reason, it will choose the fallback image next time. It is also possible to cause a fallback boot by setting the clear CMOS jumper. The RTC_BOOT_BYTE is not included in the checksum since it will be changed wi8th every boot. Note that on some boards, the CMOS checksum is skipped. G'day, sjames The RTC_BOOT_BYTE On Thu, 20 Feb 2003, Terry B. Chen wrote: > Dear all: > I was puzzled by the fallback and normal image in s2722 > (e7500), I am sorry to ask so simple question. When shall we use the > fallback image and when shall we use the normal image? How you control > which to run? > The register DRC (7c) bit 29(Init complete) seem not to be set > after memory initialization complete. am I right? > Thank you! > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bari at onelabs.com Thu Feb 20 11:48:01 2003 From: bari at onelabs.com (Bari Ari) Date: Thu Feb 20 11:48:01 2003 Subject: 2 questions.. 1. laptops and linuxbios, 2. bios-savior for laptops? References: <1233.64.216.21.158.1045725026.squirrel@www.mistry.com> Message-ID: <3E550C2B.90409@onelabs.com> Nicholas Mistry wrote: >ok, sorry for the dual post, but they are somewhat related. > >1. I havent really put much thought to using linuxbios on a laptop, but a >recent post has planted a bug in my brain to try and get it to work on >some of the older laptops i have laying around. How many people have >tried to get linux bios on their laptops, and how well does it work. > > The trick with laptops is getting LinuxBIOS to work along with the system/power management controller. I'd suggest working with the SiS based laptops or the new Intel Centrino http://developer.intel.com/design/chipsets/mobile/index.htm?iid=devnav_btn1+hw_chip_mobile͔GM laptops and tablets that are now or very soon to pop up everywhere. Several vendors are using the Hitachi H8s http://www.hitachisemiconductor.com/sic/jsp/japan/eng/products/mpumcu/816bit/h8s/index.html for a system/power management controller. Which has a rich development environment http://www.hitachisemiconductor.com/sic/jsp/japan/eng/products/mpumcu/tool/download/crosstool/h8/h8v5003.html unfortunately only for windowz and Solaris. Depending on the vendor the security feature may not be enabled on the H8s F-ZTAT (flash) so firmware may be modified, otherwise you'll have to get LinuxBIOS to work around it. Another issue is that video BIOS is combined with the system BIOS since many laptops use chipsets with integrated graphics. Getting your hands on the video BIOS binary may be a problem. Don't even ask for video BIOS source since the binary is typically released along with a modification tool that does not require the BIOS source for modification. Most 830 based designs also use the H8s but will probably soon disappear from store shelves. Bari From bari at onelabs.com Thu Feb 20 16:36:00 2003 From: bari at onelabs.com (Bari Ari) Date: Thu Feb 20 16:36:00 2003 Subject: 2 questions.. 1. laptops and linuxbios, 2. bios-savior for laptops? References: Message-ID: <3E554FA2.7090308@onelabs.com> >On Thu, 20 Feb 2003, Nicholas Mistry wrote: > > > >>1. I havent really put much thought to using linuxbios on a laptop, but a >>recent post has planted a bug in my brain to try and get it to work on >>some of the older laptops i have laying around. How many people have >>tried to get linux bios on their laptops, and how well does it work. >> Just came across this today: Lindows Notebook http://info.lindows.com/mobilepc/mobilepc.htm This may be a good candidate as well. Bari From riskin at 263.net Thu Feb 20 21:12:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Thu Feb 20 21:12:00 2003 Subject: How to initialize USB controller in LinuxBios? Message-ID: <20030221023143.214BA1BD5A@smtp.x263.net> Hi,ollie, My kernel is "2.2.14",so I need to initialize USB controller in LinuxBios. But,I don't know how to correctly initialize USB controller in LinuxBios on the sis630e chipset. I have checked the USB pci config space on the sis630e chipset, so I assigned "I/0" addresses "0xd001<<12" and "0xd8001<<12". And,the function number of the tow USB controller is 2 and 3. So,I modified LinuxBios like following: void pci_usb_enable(unsigned bus, unsigned slot, unsigned int irq) { unsigned functNum; struct pci_dev *pdev; unsigned char line; unsigned char readback; u32 io[2]={0xd001<<12,0xd801<<12}; for (functNum = 2; functNum < 4; functNum++) { pdev = pci_find_slot(bus, (slot << 3) + functNum); if (pdev) { pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &line); printk_debug("USB PIN: %d\n",line); pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, \ io[functNum-2]); pci_write_config_byte(pdev, PCI_COMMAND, \ PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); if ((line >= 1) && (line <= 4)) { printk_debug("Assigning usb IRQ %d to %d:%x.%d\n", \ irq, bus, slot, functNum); pci_write_config_byte(pdev, PCI_INTERRUPT_LINE,\ irq); pci_read_config_byte(pdev, PCI_INTERRUPT_LINE, \ &readback); printk_debug(" Readback = %d\n", readback); } } } } ... pci_usb_enable(0,1,0xa); ... After done this,I looked up /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: Silicon Integrated Systems Unknown device (rev 33). Vendor id=1039. Device id=630. Medium devsel. Master Capable. Latency=64. Non-prefetchable 32 bit memory at 0xf8000000 [0xf8000000]. Bus 0, device 0, function 1: IDE interface: Silicon Integrated Systems 85C5513 (rev 208). Fast devsel. IRQ 14. Master Capable. Latency=16. I/O at 0x2c00 [0x2c01]. Bus 0, device 1, function 0: ISA bridge: Silicon Integrated Systems 85C503 (rev 0). Medium devsel. Master Capable. No bursts. Bus 0, device 1, function 1: Ethernet controller: Silicon Integrated Systems Unknown device (rev 131). Vendor id=1039. Device id=900. Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64. Min Gnt=52.Max Lat=11. I/O at 0xb000 [0xb001]. Non-prefetchable 32 bit memory at 0xfc108000 [0xfc108000]. Bus 0, device 1, function 2: USB Controller: Silicon Integrated Systems 7001 USB (rev 7). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xd001000 [0xd001000]. Bus 0, device 1, function 3: USB Controller: Silicon Integrated Systems 7001 USB (rev 7). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xd801000 [0xd801000]. Bus 0, device 2, function 0: PCI bridge: Silicon Integrated Systems 5591/5592 AGP (rev 0). Fast devsel. Master Capable. No bursts. Min Gnt=8. Bus 0, device 9, function 0: Bridge: Texas Instruments Unknown device (rev 0). Vendor id=104c. Device id=ac60. Medium devsel. IRQ 5. Non-prefetchable 32 bit memory at 0xfc10b000 [0xfc10b000]. Non-prefetchable 32 bit memory at 0xfc100000 [0xfc100000]. Non-prefetchable 32 bit memory at 0xfc10c000 [0xfc10c000]. Bus 0, device 11, function 0: Ethernet controller: Realtek 8139 (rev 16). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0x2400 [0x2401]. Non-prefetchable 32 bit memory at 0xfc10d000 [0xfc10d000]. Bus 0, device 13, function 0: Ethernet controller: Realtek 8139 (rev 16). Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable. Latency=64. Min Gnt=32.Max Lat=64. I/O at 0x2800 [0x2801]. Non-prefetchable 32 bit memory at 0xfc10e000 [0xfc10e000]. Bus 1, device 0, function 0: VGA compatible controller: Silicon Integrated Systems Unknown device (rev 33). Vendor id=1039. Device id=6300. Medium devsel. Fast back-to-back capable. BIST capable. Prefetchable 32 bit memory at 0xf0000000 [0xf0000008]. Non-prefetchable 32 bit memory at 0xfc000000 [0xfc000000]. I/O at 0x1000 [0x1001]. I didn't find The "I/O" addresses of USB controller. So,is there other things need to be done to initialize USB controller correctly? Could you help me? Thanks, riskin ========================== 263??????????? From terryc at tyanchina.com Thu Feb 20 21:16:01 2003 From: terryc at tyanchina.com (Terry B. Chen) Date: Thu Feb 20 21:16:01 2003 Subject: how to choice fallback or normal image? Message-ID: <441383BA85E81D48964152E537886C9D28B1E0@mail.sh.corp.tyan.com> I read the code in cmos_failover.inc But I don?t understand that RTC_BOOT_BYTE bit 1 gets the value from bit 0, the program clear bit 0 every time. But When to set the bit0 to 1, it will make the code jump to normal image next time? I search 0x70(cmos index) in all but I cant find when set bit 0 to 1? -----Original Message----- From: steven james [mailto:pyro at linuxlabs.com] Sent: 2003?2?20? 23:27 To: Terry B. Chen Cc: linuxbios at clustermatic.org Subject: Re: how to choice fallback or normal image? Greetings, Several conditions need to exist for the primary image to be used. The code looks at the RTC register to check for indication of power failure (either battery dead, or clear CMOS jumper set), then the CMOS checksum is checked. If both tests show that CMOS is valid, then check the RTC_BOOT_BYTE. First, bit 0 is moved to bit 1 and bit 0 is cleared. Then, if bit 1 is set, call the primary (normal image), That is done so that if the boot fails for some reason, it will choose the fallback image next time. It is also possible to cause a fallback boot by setting the clear CMOS jumper. The RTC_BOOT_BYTE is not included in the checksum since it will be changed wi8th every boot. Note that on some boards, the CMOS checksum is skipped. G'day, sjames The RTC_BOOT_BYTE On Thu, 20 Feb 2003, Terry B. Chen wrote: > Dear all: > I was puzzled by the fallback and normal image in s2722 > (e7500), I am sorry to ask so simple question. When shall we use the > fallback image and when shall we use the normal image? How you control > which to run? > The register DRC (7c) bit 29(Init complete) seem not to be set > after memory initialization complete. am I right? > Thank you! > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From ollie at sis.com.tw Thu Feb 20 23:13:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Thu Feb 20 23:13:01 2003 Subject: How to initialize USB controller in LinuxBios? In-Reply-To: <20030221023143.214BA1BD5A@smtp.x263.net> References: <20030221023143.214BA1BD5A@smtp.x263.net> Message-ID: <1045801785.1265.3.camel@ollie> On Fri, 2003-02-21 at 10:26, riskin at 263.net wrote: > Hi,ollie, > > My kernel is "2.2.14",so I need to initialize USB controller in LinuxBios. > > But,I don't know how to correctly initialize USB controller in LinuxBios > on the sis630e chipset. > > I have checked the USB pci config space on the sis630e chipset, > so I assigned "I/0" addresses "0xd001<<12" and "0xd8001<<12". > And,the function number of the tow USB controller is 2 and 3. > Do you really have any idea about USB controller ?? USB controller does not require IP address space, it uses MMIO address space which is called non-prefetchable memory in PCI spec. The controller does not need any special init stuff. I don't think USB is supported by 2.2.x kernel neither. Why do you insist using 2.2.x kernel ? -- ollie lho From riskin at 263.net Thu Feb 20 23:48:00 2003 From: riskin at 263.net (riskin at 263.net) Date: Thu Feb 20 23:48:00 2003 Subject: How to initialize USB controller in LinuxBios? Message-ID: <20030221050705.F23731BED8@smtp.x263.net> ----- Original Message ----- From: "ollie lho" To: Cc: ,,"LinuxBIOS Mailing List" ,"Ronald G Minnich" Sent: 2003-02-21 20:29:46 Subject: Re: How to initialize USB controller in LinuxBios? >On Fri, 2003-02-21 at 10:26, riskin at 263.net wrote: >Do you really have any idea about USB controller ?? USB controller >does not require IP address space, it uses MMIO address space which >is called non-prefetchable memory in PCI spec. The controller does >not need any special init stuff. I don't think USB is supported by >2.2.x kernel neither. Why do you insist using 2.2.x kernel ? > >-- >ollie lho I don't want to use 2.2.x kernel,but for some reasons, I must use the version. I don't know about USB controller indeed. But why do I see "I/O" addresses in standard bios environment on other boxes(not sis630e chipset),instead of non-prefetchable memory? In addition,there are patches supporting USB in 2.2.x kernel.I have successfully tried it on standard bios environment with 2.2.x kernel. Thanks, riskin ========================== 263??????????? From bari at onelabs.com Fri Feb 21 01:10:01 2003 From: bari at onelabs.com (Bari Ari) Date: Fri Feb 21 01:10:01 2003 Subject: Intel IDF - EFI to replace BIOS Message-ID: <3E55C82E.7040702@onelabs.com> Looks like Intel is predicting EFI to replace BIOS soon from the presentation at the IDF this week. http://news.zdnet.co.uk/story/0,,t269-s2130826,00.html http://slashdot.org/article.pl?sid=03/02/20/189208 http://www.anandtech.com/showdoc.html?i=1791&p=2 http://www.intel.com/technology/efi/index.htm Bari From ollie at sis.com.tw Fri Feb 21 01:24:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Fri Feb 21 01:24:01 2003 Subject: How to initialize USB controller in LinuxBios? In-Reply-To: <20030221050705.F23731BED8@smtp.x263.net> References: <20030221050705.F23731BED8@smtp.x263.net> Message-ID: <1045809590.1263.9.camel@ollie> On Fri, 2003-02-21 at 13:01, riskin at 263.net wrote: > > I don't want to use 2.2.x kernel,but for some reasons, > I must use the version. > > I don't know about USB controller indeed. > But why do I see "I/O" addresses in standard bios environment > on other boxes(not sis630e chipset),instead of non-prefetchable memory? > Either the BIOS or the HW is buggy. -- ollie lho From ebiederman at lnxi.com Fri Feb 21 02:15:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Fri Feb 21 02:15:01 2003 Subject: Intel IDF - EFI to replace BIOS In-Reply-To: <3E55C82E.7040702@onelabs.com> References: <3E55C82E.7040702@onelabs.com> Message-ID: Bari Ari writes: > Looks like Intel is predicting EFI to replace BIOS soon from the > presentation at the IDF this week. Ah, the dreamers. I have not seen anything redeemable about EFI yet. And you can't boot anything old with it. Of a long list of things EFI gets wrong, probably the most telling is even Intel cannot write a correct driver. Much to much of EFI comes out of the backwards compatibility is bad mentality of IA64. Replacing that something that works with else I expect to be a hard sell. Eric From xuning1979 at hotmail.com Fri Feb 21 03:37:01 2003 From: xuning1979 at hotmail.com (xu xuning) Date: Fri Feb 21 03:37:01 2003 Subject: help Message-ID: Hello everyone: I have used Kernel-2.4.19_CWLINUX_4 from http://www.cwlinux.com/downloads/linuxbios-sdk/kernel/2.4.19/ but failed! my machine is winfast6300 MA Pro (doc md2800-d08 on i686), and through the console ( i use hypertrm.exe from windows on another machine),the information is following: ###################################################### LinuxBIOS-1.0.0 Mon Jan 20 15:34:48 EST 2003 starting... Copying LinuxBIOS to ram. LinuxBIOS-1.0.0 Mon Jan 20 15:34:48 EST 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 handle_superio start, s 0000ce80 nsuperio 1 s->super 0000e1f8 handle_superio Pass 0, check #0, s 0000ce80 s->super 0000e1f8 handle_superio: Pass 0, Superio SiS 950 handle_superio port 0x0, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 0, done #0 handle_superio done Scanning PCI bus...PCI: PCI: 00:00.0 [1039/0630] PCI: 00:00.1 [1039/5513] PCI: 00:01.0 [1039/0008] PCI: 00:01.1 [1039/0900] PCI: 00:01.2 [1039/7001] PCI: 00:01.3 [1039/7001] PCI: 00:01.4 [1039/7018] PCI: 00:01.6 [1039/7013] PCI: 00:02.0 [1039/0001] PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [1039/6300] PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done totalram:56M Initializing CPU #0 Updating microcode microcode_info: sig = 0x00000683 pf=0x00000010 rev = 0x00000000 Enabling cache... Setting fixed MTRRs(0-88 Setting fixed MTRRs(0-16) type:HB DONE fixed MTRRs Setting variable MTRR 0 , base: 0MB,range: 32MB,type HB Setting variable MTRR 1 , base: 32MB,range: 16MB, type HB Setting variable MTRR 2, base: 48MB, range: 8MB, type HB DONE variable MTRRs Clear out the extra MTRR's call intel_enable_fixed_mtrr() call intel_enable_var_mtrr() Leave setup_mtrrs done. Max cpuid index :2 Vendor ID :GenuineIntel Processor Type :0x00 Processor Family :0x06 Processor Model :0x08 Processor Mask Processor Stepping:0x03 Feature flags :0x0383fbff Cache/TLB descriptor values: 1 reads required Desc 0x01 : Instr TLB:4KB pages, 4-way set assoc,32 entries Desc 0x02 : Instr TLB:4MB pages,fully assoc,2 entries Desc 0x03 : Data TLB: 4KB pages,4-way set assoc, 64 entries Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x00 : null Desc 0x41 : L2 Unified cache: 128K bytes, 4-way set assoc, 32 byte line size Desc 0x08 : Inst cache: 16K bytes,4-way set assoc,32 byte line size Desc 0x04 : Data TLB:4MB pages,4-way set assoc,8 entries Desc 0x0c : Data cache:16K bytes,2-way or 4-way or 4-way set assoc,32 byte line size MTRR check Fixed MTRRs: Enabled Variable MTRRs: Enabled Configuring L2 cache...CPU signature of 680 so no L2 cache configuration Enable Cache done. Disabling local apic...done CPU #0 Initialized Allocating PCI resources... ASSIGN RESOURCES, bus 0 PCI: 00:00.0 10 <- [0x8000000 - 0xfbffffff] mem PCI: 00:00.1 10 <- [0x00002c90 - 0x00002c93] io PCI: 00:00.1 14 <- [0x00002ca0 - 0x00002ca3] io PCI: 00:00.1 18 <- [0x00002cb0 - 0x00002cb3] io PCI: 00:00.1 1c <- [0x00002cc0 - 0x00002cc3] io PCI: 00:00.1 20 <- [0x00002c80 - 0x00002c83] io PCI: 00:00.1 10 <- [0x00002000 - 0x000020ff] io PCI: 00:01.1 14 <- [0xfc100000 - 0xfc100fff] mem PCI: 00:01.2 10 <- [0xfc101000 - 0xfc101fff] mem PCI: 00:01.3 10 <- [0xfc102000 - 0xfc102fff] mem PCI: 00:01.4 10 <- [0x00002400 - 0x000024ff] io PCI: 00:01.4 14 <- [0xfc103000 - 0 PCI: 00:01.6 10 <- [0x00002800 - 0x000028ff] io PCI: 00:01.6 14 <- [0x00002c00 - 0x00002c7f] io PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io PCI: 00:02.0 24 <- [0xf0000000 - 0xf7ffffff] bus 1 prefmem PCI: 00:02.0 20 <- [0xfc000000 - 0xfc0fffff] bus 1 mem ASSIGN RESOURCES, bus 1 PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] prefmem PCI: 01:00.0 14 <- [0xfc000000 - 0xfc01ffff] mem PCI: 01:00.0 18 <- [0x00001000 - 0x0000107f] io Allocating VGA resource done. Enabling PCI resourcess...PCI: 00:00.0 cmd <- 0 PCI: 00:00.1 cmd <- 01 PCI: 00:01.0 cmd <- 0c PCI: 00:01.1 cmd <- 03 PCI: 00:01.2 cmd <- 02 PCI: 00:01.3 cmd <- 02 PCI: 00:01.4 cmd <- 03 PCI: 00:01.6 cmd <- 01 PCI: 00:02.0 cmd <- 27 PCI: 01:00.0 cmd <- 03 done. Initializing PCI devices... PCI devices initialized Enabled in SIS 503 regs 0x40 and 0x45 Now try to turn off shadow device for SiS 630 is 0x127ec Shadow memory disabled in SiS 630 handle_superio start, s 0000ce80 nsuperio 1 s->super 0000e1f8 handle_superio Pass 1, check #0, s 0000ce80 s->super 0000e1f8 handle_superio: Pass 1, Superio SiS 950 handle_superio port 0x2e, defaultport 0x2e handle_superio Using port 0x2e handle_superio Pass 1, done #0 handle_superio done Winfast 6300 (and similar)...Entering the initregs process Southbridge fixup done for SIS 503 handle_superio start, s 0000ce80 nsuperio 1 s->super 0000e1f8 handle_superio Pass 2, check #0, s 0000ce80 s->super 0000e1f8 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 Checking IRQ routing tables.../opt/cwlinux/freebios/src/arch/i386/lib/pirq_routing.c: 23: check_pirq_routiing_table() - irq_routing_table located at : 0x0000a94 done. Copying IRQ routing tables to 0xf0000...done. Wrote linuxbios table at : 00000500 - 0000067c checksum 7c69 Jumping to linuxbiosmain()... Welcome to start32, the open sourced starter. This space will eventually hold more diagnostic information. Jamuary 2000 , James Hendricks, Dale Webster,and Ron Version 0.1 init_bytes Gunzip setup gunzip_setup output data is 0x00100000 Gunzipping boot code 42:fill_inbuf() - ram buffer:-0x0001afe4 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00010000 block_count:0 inbuf[0] is 0x1f flush 0x00100000 count 0x00008000 flush 0x00108000 count 0x00008000 flush 0x00110000 count 0x00008000 flush 0x00118000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00020000 block_count:1 inbuf[0] is 0x3b flush 0x00120000 count 0x00008000 flush 0x00128000 co flush 0x00130000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00030000 block_count:2 inbuf[0] is 0xf1 flush 0x00138000 count 0x00008000 flush 0x00140000 count 0x00008000 flush 0x00148000 count 0x00008000 flush 0x00150000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00040000 block_count:3 inbuf[0] is 0xe2 flush 0x00158000 count 0x00008000 flush 0x00160000 count 0x00008000 flush 0x00168000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x0 inbuf[0] is 0x4d flush 0x00170000 count 0x00008000 flush 0x00178000 count 0x00008000 flush 0x00180000 count 0x00008000 flush 0x00188000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00060000 block_count:5 inbuf[0] is 0x7e flush 0x00190000 count 0x00008000 flush 0x00198000 count 0x00008000 flush 0x001a0000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00070000 block_count:6 inbuf[0] is 0x5d flush 0x001a8000 count 0x00008000 flush 0x001b0000 count 0x00008000 flush 0x001b8000 count 0x00008000 flush 0x001c0000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00080000 block_count:7 inbuf[0] is 0x2d flush 0x001c8000 count 0x00008000 flush 0x001d0000 count 0x00008000 flush 0x001d8000 count 0x00008000 flush 0x001e0000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x00090000 block_count:8 inbuf[0] is 0x6b flush 0x001e8000 count 0x00008000 flush 0x001f0000 count 0x00008000 flush 0x001f8000 count 0x00008000 flush 0x00200000 count 0x00008000 flush 0x00208000 count 0x00008000 flush 0x00210000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x000a0000 block_count:9 inbuf[0] is 0x6e flush 0x00218000 count 0x00008000 flush 0x00220000 count 0x00008000 flush 0x00228000 count 0x00008000 flush 0x00230000 count 0x00008000 done memcpy_from_doc_mil 52:fill_inbuf() - nvram:0x000b0000 block_count:10 inbuf[0] is 0x32 flush 0x00238000 count 0x00008000 flush 0x00240000 count 0x00008000 flush 0x00248000 count 0x00008000 flush 0x00250000 count 0x00003de0 <1001> fini_bytes command line - [root=/dev/nftla console=ttyS0,115200 console=/dev/tty5 CONSOLE=/ dev/tty5 video=sisfb:640x480-8 at 60,font:VGA8x16] Jumping to boot code ################################################################## On my LinuxBIOS machine ,cann't get into the system and only a picture ! So can you tell me what's wrong with me and how to do next? thanks a lot! _________________________________________________________________ ???? MSN Explorer: http://explorer.msn.com/lccn/ From spirit at reactor.ru Fri Feb 21 06:29:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Fri Feb 21 06:29:00 2003 Subject: Is the project actually dead or what? In-Reply-To: References: Message-ID: <126469221825.20030221144821@reactor.ru> Hello! I decided to finally download the code for LinuxBIOS and all that I could find was a year 2001 dated snapshot and a year 2000 dated "release". Is the project dead or what? What are we discussing here then? Why the link at http://www.linuxbios.org/developer/download/index.html leads to a CVS tree of the freeBIOS project, which has nothing on its pages said about the www.LinuxBIOS.org ? Things seem so mysterious... Can anybody clarify them to me? With best regards, Alexander Reactor Critical - 3D Hardware reviews --8<--just-a-cookie---------------------------------------------- Real programmers don't read manuals. Reliance on a reference is a hallmark of the novice and the coward. --8<------------------------------------------------------------- From xpegenaute at telepolis.es Fri Feb 21 07:58:00 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Fri Feb 21 07:58:00 2003 Subject: Information Message-ID: <3E5641FF.3000101@telepolis.es> Hi, i'm new in the list and i'd like know more things about put Kernel Linux in flashrom. 1) i'd like know a right map of a flashrom.At the moment i know that Bios code start at 0xf000h in 16 bits mode, in 0xc000h, there is VGA bios. 2) i want test your work with simulator like bochs, is there some document to try it ..? Yes, i well-read the information in your web. And all aditional docs will be a good thing. Thanks. Xavi. From pyro at linuxlabs.com Fri Feb 21 08:13:00 2003 From: pyro at linuxlabs.com (steven james) Date: Fri Feb 21 08:13:00 2003 Subject: how to choice fallback or normal image? In-Reply-To: <441383BA85E81D48964152E537886C9D28B1E0@mail.sh.corp.tyan.com> Message-ID: Greetings, That is best done in Linux when it is truly known that the LinuxBIOS boot image was entirely successful (or at least successful enough that you could flash a new image if necessary). G'day, sjames On Fri, 21 Feb 2003, Terry B. Chen wrote: > I read the code in cmos_failover.inc > But I don??t understand that RTC_BOOT_BYTE bit 1 gets the value from bit 0, the program clear bit 0 every time. But When to set the bit0 to 1, it will make the code jump to normal image next time? > I search 0x70(cmos index) in all but I cant find when set bit 0 to 1? > > -----Original Message----- > From: steven james [mailto:pyro at linuxlabs.com] > Sent: 2003??2??20?? 23:27 > To: Terry B. Chen > Cc: linuxbios at clustermatic.org > Subject: Re: how to choice fallback or normal image? > > Greetings, > > > Several conditions need to exist for the primary image to be used. The > code looks at the RTC register to check for indication of power failure > (either battery dead, or clear CMOS jumper set), then the CMOS checksum is > checked. If both tests show that CMOS is valid, then check the > RTC_BOOT_BYTE. First, bit 0 is moved to bit 1 and bit 0 is cleared. Then, > if bit 1 is set, call the primary (normal image), That is done so that if > the boot fails for some reason, it will choose the fallback image next > time. It is also possible to cause a fallback boot by setting the clear > CMOS jumper. > > The RTC_BOOT_BYTE is not included in the checksum since it will be changed > wi8th every boot. > > Note that on some boards, the CMOS checksum is skipped. > > G'day, > sjames > > > The RTC_BOOT_BYTE > > > On Thu, 20 Feb 2003, Terry B. Chen wrote: > > > Dear all: > > I was puzzled by the fallback and normal image in s2722 > > (e7500), I am sorry to ask so simple question. When shall we use the > > fallback image and when shall we use the normal image? How you control > > which to run? > > The register DRC (7c) bit 29(Init complete) seem not to be set > > after memory initialization complete. am I right? > > Thank you! > > > > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From pyro at linuxlabs.com Fri Feb 21 08:24:00 2003 From: pyro at linuxlabs.com (steven james) Date: Fri Feb 21 08:24:00 2003 Subject: Is the project actually dead or what? In-Reply-To: <126469221825.20030221144821@reactor.ru> Message-ID: Greetings, Currently, for all practical purposes, freebios is LinuxBIOS. The project is actually quite active. The snapshots are way out of date. The best thing is to check out the freebios CVS tree for current images. Snapshots are reletive in any case as each mainboard in the tree is more or less it's own sub-project that happens to share a good bit of stable code in the tree with other boards. Each mainboard directory has a STATUS file indicating (hopefully) the date of the last known good build so if all else fails, a CVS checkout of that date should build and run correctly. G'day, sjames On Fri, 21 Feb 2003, Alexander Amelkin wrote: > Hello! > > I decided to finally download the code for LinuxBIOS and all that I > could find was a year 2001 dated snapshot and a year 2000 dated > "release". Is the project dead or what? What are we discussing here > then? Why the link at > http://www.linuxbios.org/developer/download/index.html leads to a > CVS tree of the freeBIOS project, which has nothing on its pages said > about the www.LinuxBIOS.org ? Things seem so mysterious... Can > anybody clarify them to me? > > With best regards, > Alexander > Reactor Critical - 3D Hardware reviews > > --8<--just-a-cookie---------------------------------------------- > Real programmers don't read manuals. Reliance on a reference is a > hallmark of the novice and the coward. > --8<------------------------------------------------------------- > > _______________________________________________ > 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 701 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 Fri Feb 21 08:57:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 21 08:57:01 2003 Subject: Intel IDF - EFI to replace BIOS In-Reply-To: <3E55C82E.7040702@onelabs.com> Message-ID: EFI sucks so bad, too. We need to get linuxbios more widely used or we'll be stuck with that EFI ugliness. ron From rminnich at lanl.gov Fri Feb 21 09:01:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 21 09:01:00 2003 Subject: help In-Reply-To: Message-ID: > command line - [root=/dev/nftla console=ttyS0,115200 console=/dev/tty5 > CONSOLE=/ > dev/tty5 video=sisfb:640x480-8 at 60,font:VGA8x16] > Jumping to boot code > > ################################################################## > > On my LinuxBIOS machine ,cann't get into the system and only a > picture ! So can you tell me what's wrong with me and how to do next? I think the picture means that sisfb is up and working. Have you tried hookiing up serial? why is your concols /dev/tty5? ron From rminnich at lanl.gov Fri Feb 21 09:03:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 21 09:03:01 2003 Subject: [9fans] Off the shelves plan9-compatible desktop (fwd) Message-ID: could this be the long-awaited linuxbios laptop? I think most of those chips work ... ron ---------- Forwarded message ---------- Date: Fri, 21 Feb 2003 11:12:55 +0000 From: Derek Fawcus Reply-To: 9fans at cse.psu.edu To: 9fans at cse.psu.edu Subject: Re: [9fans] Off the shelves plan9-compatible desktop On Fri, Feb 21, 2003 at 04:18:51PM +0900, okamoto at granite.cias.osakafu-u.ac.jp wrote: > As I got tired of debugging, I travelled into internet, and found > Lindows Mobile PC, which may be nice also to Plan 9. > However, I cann't figure it out whether it has 3 button mouse pad. > It looks like so... > 12.1" 1024x768 TFT > VIA C3 933 MHz Processor, <--- what's that? An x86 compatible processor made by VIA. It has poor FPU performance but reasonable integer performance. It's basically an i686 but with a semi implemented CMOV instruction. > VIA VT8606(Twister-T) + VT82C686B chipset, > Savage 4 AGP (which Russ's favurite chip?), > Realtek 10/100 LAN chip, > 20GB ATA HDD > Lindows3.0 OS <---- what's it? A Linux derived OS > 10.43x8.66x0.91" AND 2.9lbs (1.6kg)! > > any opinion? well if I was in the market for a laptop, I might well buy one... however, what I'd really like is a light enougth pad computer - all that I've seen so far are too heavy. DF From rminnich at lanl.gov Fri Feb 21 09:05:02 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri Feb 21 09:05:02 2003 Subject: Information In-Reply-To: <3E5641FF.3000101@telepolis.es> Message-ID: On Fri, 21 Feb 2003, Xavier Pegenaute wrote: > 1) i'd like know a right map of a flashrom.At the moment i know that > Bios code start at 0xf000h in 16 bits mode, in 0xc000h, there is VGA bios. 0xf0000 > 2) i want test your work with simulator like bochs, is there some > document to try it ..? I don't think so, but it would be very useful. ron From hansolofalcon at worldnet.att.net Fri Feb 21 10:10:01 2003 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Fri Feb 21 10:10:01 2003 Subject: Is the project actually dead or what? In-Reply-To: <126469221825.20030221144821@reactor.ru> Message-ID: <000901c2d9be$516ce5a0$7fb1580c@who5> Hello from Gregg C Levine Yes, the project, is alive and kicking. Currently all of the code, is indeed sitting on the CVS servers, at the project address given on the project pages a Source Forge. The ones you were looking at, and indeed the ones that I first grabbed, were the snapshots that were made up, simply for the ease of some of us, who don't have that feature access. All you need to do is follow the instructions given to retrieve the code from CVS, via the instructions on the webpage. ------------------- 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: Friday, February 21, 2003 6:48 AM > To: linuxbios at clustermatic.org > Subject: Is the project actually dead or what? > > Hello! > > I decided to finally download the code for LinuxBIOS and all that I > could find was a year 2001 dated snapshot and a year 2000 dated > "release". Is the project dead or what? What are we discussing here > then? Why the link at > http://www.linuxbios.org/developer/download/index.html leads to a > CVS tree of the freeBIOS project, which has nothing on its pages said > about the www.LinuxBIOS.org ? Things seem so mysterious... Can > anybody clarify them to me? > > With best regards, > Alexander > Reactor Critical - 3D Hardware reviews > > --8<--just-a-cookie---------------------------------------------- > Real programmers don't read manuals. Reliance on a reference is a > hallmark of the novice and the coward. > --8<------------------------------------------------------------- > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios From spirit at reactor.ru Fri Feb 21 15:25:00 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Fri Feb 21 15:25:00 2003 Subject: DoC or regular Flash? In-Reply-To: <000901c2d9be$516ce5a0$7fb1580c@who5> References: <000901c2d9be$516ce5a0$7fb1580c@who5> Message-ID: <154501413494.20030221234452@reactor.ru> Hello! I'm trying to figure out how to build and install the linuxbios on my pc787cl+ motherboard. I read the SIS630 HOWTO and now I have a strong feeling like I need to buy a DiskOnChip and that linuxbios can't be put into a regular flash chip (where the regular bios is contained). Am I right? How big the linuxbios is then if it can't fit into a 2Mbit flash where a usual BIOS fits with all its bells and whistles? Or am I wrong? Then how do I flash the linuxbios into the regular flash chip on a SiS630 mainboard? Is the procedure the same as for DoC? With best regards, Alexander mailto:spirit at reactor.ru From jerj at coplanar.net Fri Feb 21 20:17:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Fri Feb 21 20:17:00 2003 Subject: 2 questions.. 1. laptops and linuxbios, 2. bios-savior for laptops? In-Reply-To: <1233.64.216.21.158.1045725026.squirrel@www.mistry.com> References: <1233.64.216.21.158.1045725026.squirrel@www.mistry.com> Message-ID: <1045877929.10170.0.camel@contact.skynet.coplanar.net> On Thu, 2003-02-20 at 02:10, Nicholas Mistry wrote: > 2. What type of "bios savior" options are there for laptops? or is that > just a pipe dream at this point? I plan to use a PLCC extractor on mine. Not an option for everyone though. -- Jeremy Jackson From zhushisongzhu at yahoo.com Sat Feb 22 05:16:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Sat Feb 22 05:16:01 2003 Subject: gx1 ram size error Message-ID: <20030222103653.40446.qmail@web13201.mail.yahoo.com> now i can boot my ec3 mainboard, but linuxbios can only find 32M ram, but I have 256M RAM. do you meet such problem? ec3 mainboard specification: processor: on-board NS GX1 233MHZ(fanless) chipset: NS CS5530A System Memory: one SDRAM DIMM BIOS: 2Mbit Flash BIOS solid state disk: support diskonchip 2000 --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From aip at cwlinux.com Sun Feb 23 05:16:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Sun Feb 23 05:16:01 2003 Subject: gx1 ram size error In-Reply-To: <20030222103653.40446.qmail@web13201.mail.yahoo.com>; from zhu shi song on Sat, Feb 22, 2003 at 02:36:53AM -0800 References: <20030222103653.40446.qmail@web13201.mail.yahoo.com> Message-ID: <20030223183707.B30277@mail.cwlinux.com> Zhu, > now i can boot my ec3 mainboard, but linuxbios can only find 32M ram, but I have 256M RAM. do you meet such problem? > ec3 mainboard specification: > processor: on-board NS GX1 233MHZ(fanless) > chipset: NS CS5530A > System Memory: one SDRAM DIMM > BIOS: 2Mbit Flash BIOS > solid state disk: support diskonchip 2000 I haven't seen this problem on 5823. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: From christer at weinigel.se Sun Feb 23 10:24:00 2003 From: christer at weinigel.se (Christer Weinigel) Date: Sun Feb 23 10:24:00 2003 Subject: gx1 ram size error In-Reply-To: <20030222103653.40446.qmail@web13201.mail.yahoo.com> References: <20030222103653.40446.qmail@web13201.mail.yahoo.com> Message-ID: zhu shi song writes: > now i can boot my ec3 mainboard, but linuxbios can only find 32M ram, but I have 256M RAM. do you meet such problem? > > ec3 mainboard specification: > > processor: on-board NS GX1 233MHZ(fanless) > > chipset: NS CS5530A > > System Memory: one SDRAM DIMM > > BIOS: 2Mbit Flash BIOS > > solid state disk: support diskonchip 2000 What does it say during boot? The RAM sizing code will print a few debug messages during boot. /Christer -- "Just how much can I get away with and still go to heaven?" Freelance consultant specializing in device driver programming for Linux Christer Weinigel http://www.weinigel.se From spirit at reactor.ru Sun Feb 23 16:47:01 2003 From: spirit at reactor.ru (Alexander Amelkin) Date: Sun Feb 23 16:47:01 2003 Subject: SiS630 flash_rom & various flash parts In-Reply-To: <1045809590.1263.9.camel@ollie> References: <20030221050705.F23731BED8@smtp.x263.net> <1045809590.1263.9.camel@ollie> Message-ID: <128679154993.20030224010714@reactor.ru> Hello ollie! As far as I understand, it's you, Ollie, who wrote that flash_rom program? My SiS630e board (pcchips m787cl+) has an EON EN29F002NT flash part on it and I also have a spare old 1Mbit SST29EE010 part. I saw the program supports SST29EE020... I thought (just an assumption) that SST29EE010 may be similar to SST29EE020 in all but the size, so I patched your program a little (added a record to the flashchips array and also added some #define's to flash.h) so it agreed to flash my spare chip. Unfortunately it didn't work. The flash_rom pretends to work, but quits after "Verifying 0x00000001". The board doesn't boot and when I place the EON part back in place, the board's CMOS turns out to be ruined. Can you imlement a correct support for SST29EE010 please? It has a sufficient size to put a linuxbios in there, so I'd like to use that part if possible. I hope it is electrically compatible with the SST29EE020 and EON EN29F002NT? I tried to find any of the parts you supports in local stores, but didn't find anything from that list that would suit my motherboard (I need a DIP32 chip). :( With best regards, Alexander mailto:spirit at reactor.ru From ollie at sis.com.tw Sun Feb 23 22:06:01 2003 From: ollie at sis.com.tw (ollie lho) Date: Sun Feb 23 22:06:01 2003 Subject: SiS630 flash_rom & various flash parts In-Reply-To: <128679154993.20030224010714@reactor.ru> References: <20030221050705.F23731BED8@smtp.x263.net> <1045809590.1263.9.camel@ollie> <128679154993.20030224010714@reactor.ru> Message-ID: <1046057133.1265.16.camel@ollie> On Mon, 2003-02-24 at 06:07, Alexander Amelkin wrote: > Hello ollie! > > As far as I understand, it's you, Ollie, who wrote that flash_rom > program? My SiS630e board (pcchips m787cl+) has an EON EN29F002NT > flash part on it and I also have a spare old 1Mbit SST29EE010 part. > I saw the program supports SST29EE020... I thought (just an > assumption) that SST29EE010 may be similar to SST29EE020 in all but > the size, so I patched your program a little (added a record to the > flashchips array and also added some #define's to flash.h) so it > agreed to flash my spare chip. Unfortunately it didn't work. The > flash_rom pretends to work, but quits after "Verifying 0x00000001". > The board doesn't boot and when I place the EON part back in place, > the board's CMOS turns out to be ruined. > I doubt it will work. Every EEPROM parts have slightly different command set/cycle for programming. You can not just change the ID and expect it to work. > Can you imlement a correct support for SST29EE010 please? It has a > sufficient size to put a linuxbios in there, so I'd like to use that > part if possible. I hope it is electrically compatible with the > SST29EE020 and EON EN29F002NT? > I am sorry that I can't do it for the moment. Programming EEPROM needs a little bit of trial and error. You can try download the datasheet from SST and modify the 29EE020 code. -- ollie lho From aip at cwlinux.com Mon Feb 24 07:45:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 24 07:45:01 2003 Subject: Status page Message-ID: <20030224210638.A13265@mail.cwlinux.com> Looks like status page is not being updated, eg 787 is not in the list. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From chromi at chromatix.demon.co.uk Mon Feb 24 07:48:01 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Mon Feb 24 07:48:01 2003 Subject: Getting a small cluster running - PC-Chips 810 Message-ID: Background: I want to get the most CPU power out of a limited budget, for use with a research project involving signal processing. So far, apart from buying a refurbished Mac, the best solution seems to be building an OpenMOSIX cluster using Athlon-XPs. I plan to use a "master" computer with a slightly faster CPU than the slaves, and fitted with a full-function m/board and peripherals. The master does not need to run LinuxBIOS, but it's existence means it should be easy to build kernel variants to test, without risking loss of machine functionality. To keep the cost of each slave as low as possible, I want to eliminate all storage hardware from them, including floppy drive. This means booting Linux over NFS, and/or installing part of it in the BIOS chip. Hence my interest in LinuxBIOS. If I will need significant extra hardware to reliably install LinuxBIOS, I might just as well boot from floppy. So far, I've identified a PC-Chips 810 board from one of my suppliers: http://www.aria.co.uk/ProductInfoComm.asp?ID=2050 which will be fitted with an Athlon-XP 2000+, some RAM, a case, a PSU, and nothing else whatsoever. Total slave cost in this configuration is under ?160 including VAT. Because this will be used in an academic Engineering department, there will probably be a Flash and/or EEPROM programmer lying around somewhere, that I can use rather than swapping BIOS chips. Can anyone provide guidance on my chances of success, and how easy this is likely to be? -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From aip at cwlinux.com Mon Feb 24 08:08:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 24 08:08:01 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: ; from Jonathan Morton on Mon, Feb 24, 2003 at 01:06:50PM +0100 References: Message-ID: <20030224212915.A13373@mail.cwlinux.com> Jonathan, > Background: I want to get the most CPU power out of a limited budget, > for use with a research project involving signal processing. So far, > apart from buying a refurbished Mac, the best solution seems to be > building an OpenMOSIX cluster using Athlon-XPs. > I plan to use a "master" computer with a slightly faster CPU than the > slaves, and fitted with a full-function m/board and peripherals. The > master does not need to run LinuxBIOS, but it's existence means it > should be easy to build kernel variants to test, without risking loss > of machine functionality. > To keep the cost of each slave as low as possible, I want to > eliminate all storage hardware from them, including floppy drive. > This means booting Linux over NFS, and/or installing part of it in > the BIOS chip. Hence my interest in LinuxBIOS. If I will need > significant extra hardware to reliably install LinuxBIOS, I might > just as well boot from floppy. > So far, I've identified a PC-Chips 810 board from one of my suppliers: > http://www.aria.co.uk/ProductInfoComm.asp?ID=2050 > which will be fitted with an Athlon-XP 2000+, some RAM, a case, a > PSU, and nothing else whatsoever. Total slave cost in this > configuration is under ?160 including VAT. > Because this will be used in an academic Engineering department, > there will probably be a Flash and/or EEPROM programmer lying around > somewhere, that I can use rather than swapping BIOS chips. > Can anyone provide guidance on my chances of success, and how easy > this is likely to be? You can try our romimage for PC-Chips 810 + etherboot, then setup a dhcp server and proper elf kernel image. It should be enough to get you started. FYI, PCCHIPS also has a newer 810 http://www.pcchips.com.tw/product/M810DLUv52c.html which has ddr, but I don't think it is supported at the moment. Ollie, do you have any info about this board which is using 730D chipset. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From chromi at chromatix.demon.co.uk Mon Feb 24 09:48:01 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Mon Feb 24 09:48:01 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: <20030224220654.A13957@mail.cwlinux.com> References: <20030224212915.A13373@mail.cwlinux.com> <20030224220654.A13957@mail.cwlinux.com> Message-ID: > > This seems to imply I don't need a Disk-on-Chip unit, separate Flash >> chip, or Flash programmer (unless I goof up, in which case the Flash >> programmer can be used to restore the original BIOS). Is this >> correct? > >That's right. DOC is not necessary, but would be a nice option to have. >DOC not only reduces traffic, but also allows some fancy features, eg kexec. I don't expect traffic or features to be a problem, as with OpenMOSIX the slave would be running almost nothing autonomously. > > FWIW, I'm planning to use Gentoo Linux, which should say something >> about my proficiency level. IOW, I'm not averse to compiling things >> and generally fiddling around, but the existence of a nearly >> plug-and-play solution is encouraging (and likely to satisfy my >> supervisor more easily). > >For fb support, you need sisfb_lite patch. If you don't need fb, stock >kernel might work. I probably don't need video at all, except to make sure the box boots properly. Even for that, I could probably get away with serial console, as I think the master will have two spare serial ports. :o) I'll try your stock image first as a proof of concept, then build an OpenMOSIX kernel and image using the least number of patches necessary. Gentoo include an OpenMOSIX-patched kernel source tree, which is nice of them, so I only need to worry about the LinuxBIOS patches and hackery. I'm guessing that if I use the vendor-supplied BIOS flash utility, I don't need to muck around with MTD drivers, right? Looking at the HOWTOs, that method seems to be extremely icky at the moment, requiring kernel source edits. I don't mind getting a single floppy drive, and moving it between slaves for this step. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From chromi at chromatix.demon.co.uk Mon Feb 24 16:01:01 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Mon Feb 24 16:01:01 2003 Subject: Low cost cluster In-Reply-To: <1046113590.25088.6.camel@harwood.home> References: <1046113590.25088.6.camel@harwood.home> Message-ID: >I agree with your reasoning - cheap motherboards are readily available. > >For use at home, however, I looked at the mini-ITX motherboards. >Less CPU performance of course, but low power and low cost. I don't think there'll be power problems with such a small number (initially just 2) of slaves, really. I'm constrained by a fairly tight capital budget, designed to make 1 good PC, and I found I could turn it into one respectable PC plus two cheap slaves. If I really wanted to push the CPU-power envelope, I'd get a refurbished PowerMac. I still might. The cluster would give me an aggregate 2500 MFLOPS, while a previous-model Mac would give me 3500 for about the same price (both figures being what the compiler alone can do). The only thing holding me back from that, is the possibility of needing to run high-end physical-simulation software that is probably only available for Windows. (Yes, I know about PC emulation software, but it takes a large performance hit.) BTW, this setup is officially to allow me to move my personal machines off the desk and back home! They're currently an Athlon 1.2GHz and a Duron 800, plus a Pentium-MMX and a 486 that are used as servers. >I also have a PC-chips 810MLR, which we used for Linuxbios work last >summer. I do hate to say it, but Linuxbios does work, but PCChips >have a rather bad reputation. Given the price, this isn't *so* surprising, but given the price it's also easy to "forgive and replace". Because they are slaves, it's easy to take one offline if it goes bad, and take time over getting it replaced (probably under warranty). I hope LinuxBIOS is more flexible than the rather anaemic status page suggests. >If someone else is paying, from a grant, then think about getting a >cluster with better hardware, say using Tyan or Supermicro motherboards. I will have to see if any are available at a comparable price. I do know that finding a case big enough to fit a Tiger into, while still keeping the price down, could be a real pain. But then, SMP boards tend not to be designed to be cheap. :) That is a good point though - I should look at putting a pair of SMP machines together, and see how the price compares. However, I think the single SMP I priced was scraping the budget already - Athlon-MPs are priced noticeably higher than their single equivalents, which definitely hurts when compared to clusters of single-CPU slaves. >A little more capital cost will result in much less grief later. >And also think about the cases - do you have room for a pile of big >ATX cases? Let me see, right now the desk has one full-tower and one midi-tower ATX, one AT, and one low-profile desktop, plus two monitors, at least three keyboards, plus a laptop, all piled on and around it. I'm planning to replace all that with one large medium-tower and two midi ATXs, plus one monitor and one keyboard. I don't think space is a problem. :-) >Where is your department? Lancaster, UK. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From rminnich at lanl.gov Mon Feb 24 17:20:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon Feb 24 17:20:00 2003 Subject: Low cost cluster In-Reply-To: Message-ID: On Mon, 24 Feb 2003, Jonathan Morton wrote: > refurbished PowerMac. I still might. The cluster would give me an > aggregate 2500 MFLOPS, while a previous-model Mac would give me 3500 how did you get to that #? just wondering. If you're counting on Altivec that's a mistake. ron From aip at cwlinux.com Mon Feb 24 20:22:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Mon Feb 24 20:22:01 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: ; from Jonathan Morton on Mon, Feb 24, 2003 at 02:59:14PM +0100 References: <20030224212915.A13373@mail.cwlinux.com> <20030224220654.A13957@mail.cwlinux.com> Message-ID: <20030225094407.A21772@mail.cwlinux.com> > I'm guessing that if I use the vendor-supplied BIOS flash utility, I > don't need to muck around with MTD drivers, right? Looking at the > HOWTOs, that method seems to be extremely icky at the moment, > requiring kernel source edits. I don't mind getting a single floppy > drive, and moving it between slaves for this step. One of the advantages of LinuxBIOS is you can flash rom in Linux using flash_on and flash_rom which comes with LinuxBIOS. With these utils, you don't need mtd. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From ollie at sis.com.tw Mon Feb 24 21:28:00 2003 From: ollie at sis.com.tw (ollie lho) Date: Mon Feb 24 21:28:00 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: <20030224212915.A13373@mail.cwlinux.com> References: <20030224212915.A13373@mail.cwlinux.com> Message-ID: <1046141285.1931.1.camel@ollie> On Mon, 2003-02-24 at 21:29, Andrew Ip wrote: > You can try our romimage for PC-Chips 810 + etherboot, then setup a dhcp > server and proper elf kernel image. It should be enough to get you started. > FYI, PCCHIPS also has a newer 810 > http://www.pcchips.com.tw/product/M810DLUv52c.html which has ddr, but I > don't think it is supported at the moment. Ollie, do you have any info about > this board which is using 730D chipset. > I don't think there is officially a thing called 730D. Judge for the web page, I guess it is a 'remarked', 'cost down' version of SiS 740. -- ollie lho From alesan at manoweb.com Tue Feb 25 01:30:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Tue Feb 25 01:30:01 2003 Subject: Low cost cluster In-Reply-To: <1046113590.25088.6.camel@harwood.home> References: <1046113590.25088.6.camel@harwood.home> Message-ID: <3E5B126C.7090103@manoweb.com> Jonathan Morton wrote: > If I really wanted to push the CPU-power envelope, I'd get a refurbished > PowerMac. I still might. The cluster would give me an aggregate 2500 > MFLOPS, while a previous-model Mac would give me 3500 for about the is this supposed to be funny or do you really believe S. Job's jokes? ;) bye!!! ciao as -- How to build a lirc receiver http://www.manoweb.com/alesan/lirc From alesan at manoweb.com Tue Feb 25 01:33:01 2003 From: alesan at manoweb.com (Alessio Sangalli) Date: Tue Feb 25 01:33:01 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: References: <20030224212915.A13373@mail.cwlinux.com> <1046141285.1931.1.camel@ollie> Message-ID: <3E5B12F7.1010508@manoweb.com> ollie lho wrote: > I don't think there is officially a thing called 730D. Judge for the web > page, I guess it is a 'remarked', 'cost down' version of SiS 740. As I asked you few days ago... is there around somebody willing to add support for sis740? I think my company would be interested and pay for it ;) bye as -- How to build a lirc receiver http://www.manoweb.com/alesan/lirc From chromi at chromatix.demon.co.uk Tue Feb 25 02:51:00 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Tue Feb 25 02:51:00 2003 Subject: Low cost cluster In-Reply-To: References: Message-ID: > > refurbished PowerMac. I still might. The cluster would give me an >> aggregate 2500 MFLOPS, while a previous-model Mac would give me 3500 > >how did you get to that #? just wondering. If you're counting on Altivec >that's a mistake. I count Altivec because I'm confident the Apple-modified compiler is capable of producing code for my present algorithm. Even if it can't, I can write it in fairly easily - I'm no stranger to PPC code. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From chromi at chromatix.demon.co.uk Tue Feb 25 03:11:01 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Tue Feb 25 03:11:01 2003 Subject: Low cost cluster In-Reply-To: <3E5B126C.7090103@manoweb.com> References: <1046113590.25088.6.camel@harwood.home> <3E5B126C.7090103@manoweb.com> Message-ID: >>If I really wanted to push the CPU-power envelope, I'd get a refurbished >>PowerMac. I still might. The cluster would give me an aggregate 2500 >>MFLOPS, while a previous-model Mac would give me 3500 for about the > >is this supposed to be funny or do you really believe S. Job's jokes? I currently have a G3, which I benchmarked the main component of my current algorithm on, obtaining 0.5 MFLOPS/MHz. I then disassembled the code and noted that FP load, multiply-add, and store instructions could be replaced by their Altivec equivalents, which operate on four times the number of operands and are equally fast. I even checked the dispatcher rules to make sure that would not be a bottleneck - the G4+ is able to dispatch a vector multiply-add and a vector load/store, plus an integer operation (say, pointer arithmetic) and a branch if required, all in the same clock cycle. Thus I obtained an effective performance figure of 2.0 MFLOPS/MHz, versus Athlon-XP figure of 0.5 (for both x87 and SSE) and Pentium-4 figure of 0.4 (for SSE). This is not hype - this is me reading the documentation and doing the maths. Note that all figures assume the working set fits in cache. I believe I can ensure this, and it's also considerably easier to achieve with a Mac's 1MB L3. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From chromi at chromatix.demon.co.uk Tue Feb 25 05:31:01 2003 From: chromi at chromatix.demon.co.uk (Jonathan Morton) Date: Tue Feb 25 05:31:01 2003 Subject: Low cost cluster In-Reply-To: References: Message-ID: > > Thus I obtained an effective performance figure of 2.0 MFLOPS/MHz, >> versus Athlon-XP figure of 0.5 (for both x87 and SSE) and Pentium-4 >> figure of 0.4 (for SSE). This is not hype - this is me reading the >> documentation and doing the maths. > >This is an estimate, not a benchmark. It would be interesting what the >Apple C compiler would make from your code. Your code seems to map to >AltiVec very well, this is pretty rare. My algorithm is made up of standard matrix operations, such as multiplies and inversions. By transposing one of the matrices beforehand, the individual operations are mostly sequential in terms of memory access and uniform in terms of operation, which means it does map very well to vector code. It would probably also benefit from 3DNOW on the Athlon, but I understand x86 assembly code is a lot hairier, and certainly my compiler is unable to generate 3DNOW code by itself. As a result, I've been unable to determine how much benefit I might see. >Have G4 with equivalent MHz rating of Athlons been sold lately? It seems >Athlons are clocked at twice the speed of G4s. >What is the cost of a refurbished G4 system vs. a bunch of recent Athlons? >I think the MFlops/$ benchmark is more interesting. For comparable prices, I can get an 867MHz dual G4, or three single Athlon-XPs at 1666MHz. Given that I can get four times the performance per clock per CPU with the G4, it's a net win - as I posted earlier, 3500 against 2500 MFLOPS. I'm still concerned about the potential of having to use Windows software though, and that's likely to sway the final decision. Another worthwhile comparison might be in terms of MFLOPS per watt, and that would be particularly relevant to larger clusters, where power consumption and heat become significant environmental factors. I understand a 1GHz G4+ is at around 15-20W maximum, which I'd assume is while running Altivec code (and would go down with the vector units not in use). By comparison, Athlons seem to average around 50W, depending on the particular core type and clock speed, and are unable to shut down functional units that are not in use. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: chromi at chromatix.demon.co.uk website: http://www.chromatix.uklinux.net/ tagline: The key to knowledge is not to rely on people to teach you it. From zhushisongzhu at yahoo.com Tue Feb 25 06:07:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Tue Feb 25 06:07:01 2003 Subject: (no subject) Message-ID: <20030225112848.70521.qmail@web13206.mail.yahoo.com> can you copy irq_tables to 0xf0000 on your mainboard? thanks --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Tue Feb 25 09:22:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 09:22:00 2003 Subject: Low cost cluster In-Reply-To: Message-ID: On Tue, 25 Feb 2003, Jonathan Morton wrote: > >how did you get to that #? just wondering. If you're counting on Altivec > >that's a mistake. > > I count Altivec because I'm confident the Apple-modified compiler is > capable of producing code for my present algorithm. Even if it > can't, I can write it in fairly easily - I'm no stranger to PPC code. our experience has been 'don't believe it till you try it', but maybe it will work for you. ron From rminnich at lanl.gov Tue Feb 25 09:27:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 09:27:00 2003 Subject: (no subject) In-Reply-To: <20030225112848.70521.qmail@web13206.mail.yahoo.com> Message-ID: On Tue, 25 Feb 2003, zhu shi song wrote: > can you copy irq_tables to 0xf0000 on your mainboard? > It depends on the chipset on the mainboard and also if the code for that chipset sets up 0xf0000 as 'shadow memory'. For most platforms, the answer is still 'no'. But for most platforms, I think the answer could be 'yes' ron From freedman at physics.cornell.edu Tue Feb 25 09:28:34 2003 From: freedman at physics.cornell.edu (Daniel Freedman) Date: Tue Feb 25 09:28:34 2003 Subject: Low cost cluster In-Reply-To: References: Message-ID: <20030225144737.GT14025@physics.cornell.edu> On Tue, Feb 25, 2003, Jonathan Morton wrote: > > > Thus I obtained an effective performance figure of 2.0 MFLOPS/MHz, > >> versus Athlon-XP figure of 0.5 (for both x87 and SSE) and Pentium-4 > >> figure of 0.4 (for SSE). This is not hype - this is me reading the > >> documentation and doing the maths. > > > >This is an estimate, not a benchmark. It would be interesting what the > >Apple C compiler would make from your code. Your code seems to map to > >AltiVec very well, this is pretty rare. > > My algorithm is made up of standard matrix operations, such as > multiplies and inversions. By transposing one of the matrices > beforehand, the individual operations are mostly sequential in terms > of memory access and uniform in terms of operation, which means it > does map very well to vector code. Hi, Have you looked into atlas for matrix operations? It gets a very high percentage of peak performance on the ia32 class (as well as on other architectures), and may very well change the assumptions you are making. We use it extensively on our 50 node (100 AthlonMP 2000, 100Gb RAM) cluster to do Density Functional Theory. Just FYI, FFTW (Fastest Fourier Transforms in the West) is also a self-optimizing codebase that gives very good performance. Both are easily found via google. HTH, Daniel -- Daniel A. Freedman , Graduate Fellow Electronic Structure Calculations, LASSP, Cornell University Free University Project: http://www.freeuniversityproject.org Help build an accredited open-admission, free-tuition online university! From jerj at coplanar.net Tue Feb 25 10:54:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue Feb 25 10:54:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: <1046189782.1278.6.camel@contact.skynet.coplanar.net> Below is a trivial C program with a function call and a few loops. When compiled with gcc using the stated flags, it does not use any stack. The assembler output is below. /* sample program demonstrating trivial C program */ /* that doesn't use stack when compiled with gcc */ /* compile with gcc -O -fverbose-asm -fomit-frame-pointer -S -Winline */ /* -O optimization is required to honour inline keyword */ /* __attribute__((always_inline)); could be used if opt is bad */ /* -fverbose-asm helps when choosing compiler options */ /* -fomit-frame-pointer eliminates function prologue */ /* -S generates assembly, .c file becomes .s so you can inspect */ /* -Winline explains why if something can't be inlined */ extern volatile int r; /* example MMIO register, could be an io insn also */ static inline int afunc(const int x) { register int y; for (y=0; y I have been on the hunt for small c-like compilers. I have yet to find one > that runs in the registers only, i.e. has an addressable memory of 16 > words. > > My concern about a full-blown c compiler is this: we are going to move > from debugging 1000 or so lines of assembly to debugging the compiler, and > shipping a full compiler with linuxbios, just to eliminate this 1000 or so > lines of assembly. It seems hard to justify. Since we will be the probable > only users of this compiler the support burden will fall on us. There are > not that many people out there needing a compiler that does this "your > memory is only your register set" capability. > -- Jeremy Jackson From rminnich at lanl.gov Tue Feb 25 11:08:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 11:08:01 2003 Subject: Ram initialization and small c. In-Reply-To: <1046189782.1278.6.camel@contact.skynet.coplanar.net> Message-ID: On 25 Feb 2003, Jeremy Jackson wrote: > Below is a trivial C program with a function call and a few loops. When > compiled with gcc using the stated flags, it does not use any stack. > The assembler output is below. neat! I wonder if we'll be able to work with the gcc community somehow to get what Eric needs with a standard gcc. ron From ebiederman at lnxi.com Tue Feb 25 11:32:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 25 11:32:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > On 25 Feb 2003, Jeremy Jackson wrote: > > > Below is a trivial C program with a function call and a few loops. When > > compiled with gcc using the stated flags, it does not use any stack. > > The assembler output is below. > > neat! > > I wonder if we'll be able to work with the gcc community somehow to get > what Eric needs with a standard gcc. I suspect a careful gcc port of gcc to x86-noram can handle it, and long term that is probably where the effort needs to go. Short term I suspect there would be a lot of distraction with just the mechanics of gcc. If someone knows gcc better than me feel free. For the first proof of concept pass I am going to tackle something simple and stand alone. When that works we will have something to use for the short term, and something we can point at and say hey it works. What will it take to get gcc to do something similar. One of the very nice things about C is that practically every optimization can be done by hand. So a C compiler really only needs to do register allocation, instruction selection, and instruction scheduling. Which means you really don't need a compiler that is especially smart. Anyway we will see in a little bit what makes the most sense. Eric From ebiederman at lnxi.com Tue Feb 25 11:43:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 25 11:43:00 2003 Subject: help!!!who can explain the interface between linuxbios and linux. In-Reply-To: <200302200255.h1K2tJG08482@nwn.definitive.org> References: <200302200255.h1K2tJG08482@nwn.definitive.org> Message-ID: ??? writes: > dear all: > I have developed a linuxbios debug system succefully.I introduced gdb stub into > my system. In my system ,developers can debug linuxbios at source code level. I > setup the stub at the beginning of the begin of the function of hardwaremain, > the first c function.Now the system can > > excute the function of "step",'step into" "step out" ,"breakpoint"and so on. but > the system has not been tested fully. > > I wonder if my design is usefull to others. > by the way, I have several question.I will appreciate anyone's any idea! > my question are as follows: To some extent. Being able to dump the contents of data structures is generally more useful than the ability to single step. The code that needs the most debugging on a routine basis is the ram initialization and your debugger does not work that early. > 1. As we know, traditonal BIOS not only do some initialization work, but also > put some data about the hardware in somewhere.BIOS even offer some routine such > as intx( I know that In linux souce file "setup.s",int10, int13and int15 are > used),but linuxbios doesn't offer. > > my question is: what is the mininal need of linux kernel's starting? A table of the data usually collected by setup.S. Basically just the memory size. > what data does It need in detail? where does the data need to be placed in > detail? > > what routine does linux kernel need for it's starting ? > how does linuxbios offer these data and routines? see mkelfImage. For the most part we skip arch/i386/boot/setup.S in the kernel and jump right to arch/i386/kernel/head.S > 2. the second question is about PCI. I found that in linuxbios, some PCI > initialization work is done.as we know ,in linux kernel, the same work was be > done.Some linuxbios PCI initialization code is even the same with linux > kernel. my question is: > > if the initialization in linuxbios is necessary? Yes. The targets in Linux and LinuxBIOS with respect to pci initialization are totally different. The Linux code when in doubt assumes the BIOS set it up properly, it is good enough to handle random hot-plug devices, and it has to cope with the fact that we are using some hardware while the pci bus is being setup. LinuxBIOS on the other hand know it must setup all of the pci devices, and it does not need to cope devices that are already in use. > 3. my third question is about etherboot. > I get a ide-patch of etherboot, and I succefully boot my system via IDE .I > have read the code for a long time,but still have no idea about it. I found it > seems does not do the same as setup.s,the kernel loader of traditional linux.who > can explain it to me? Roughly the boot process under LinuxBIOS or etherboot is simple. There is a file (preferably an ELF executable). That file specifies where chunks of it should be loaded into memory, and those chunks are copied where they belong. In addition an entry point is specified and after the loading is complete that entry point is jumped to. The major difference is that everything happens in flat 32bit mode. That is x86 protected mode with paging disabled. Which is the simplest processor mode to run in. > I know there are some clever and experienced man in this site.I am very > interested in this topic and admire all the man with good skills.I am looking > forward to some help. I hope this helps. Eric From ebiederman at lnxi.com Tue Feb 25 11:50:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 25 11:50:00 2003 Subject: Getting a small cluster running - PC-Chips 810 In-Reply-To: <20030225094407.A21772@mail.cwlinux.com> References: <20030224212915.A13373@mail.cwlinux.com> <20030224220654.A13957@mail.cwlinux.com> <20030225094407.A21772@mail.cwlinux.com> Message-ID: Andrew Ip writes: > > I'm guessing that if I use the vendor-supplied BIOS flash utility, I > > don't need to muck around with MTD drivers, right? Looking at the > > HOWTOs, that method seems to be extremely icky at the moment, > > requiring kernel source edits. I don't mind getting a single floppy > > drive, and moving it between slaves for this step. > One of the advantages of LinuxBIOS is you can flash rom in Linux using > flash_on and flash_rom which comes with LinuxBIOS. With these utils, you > don't need mtd. It depends. At least long term I really suspect the mtd stuff is going to be more maintainable. Mostly it is a matter of volume of use, and the ease of adding new flash parts. That and accessing some of that hardware from user space makes me nervous. The long term nice thing about the mtd layer is longer term you can actually put a filesystem on your rom chip. We are a long ways off from that yet but still. Eric From rminnich at lanl.gov Tue Feb 25 12:45:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 12:45:01 2003 Subject: Ram initialization and small c. In-Reply-To: <3E5BB166.3070807@kesa.com> Message-ID: I would like to see that code, thanks ron From steve at nexpath.com Tue Feb 25 12:56:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Feb 25 12:56:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: Message-ID: <3E5BB4E9.6030803@nexpath.com> Ronald G. Minnich wrote: > I would like to see that code, thanks > > ron > The original message is below since I think it did not post to the list due to my return email address (fixed that I think). The code is attached (6 files). ------ I think you have to cramp your C coding style anyway, to stay within registers. The extra scratch area does not help much, with chips such as the SiS630, only has three gp regs, little help. You can't go around declaring variables willy nilly, you run out of space (registers) no matter what compiler. I also have been experimenting with inline gcc, and I think it works pretty well and once you get the hang of it, and it _is_ easier than assy. I have re-coded the console routines, and ram setup, and spd timing setup on the sis630 for C. It is still a wip but I have tested the spd setup by wrapping a real main on a live machine. So far it is about 400 lines of C, should I attach it? It compiles without using the stack (except for a %ebp push/pop which can be deleted). I can't see how a special compiler gets you enough more than gcc to be worth the downside of effort and debugging. Scratch regs vary from chip to chip, and use 1.5 regs to access (pci). You could use the %ebp and %esp which is a gain of two (and maybe %es %fs etc), but I think using gcc will get us there anyway. Just another opinion to put in the hat. -Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chipinit.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: common.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: console.h URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: raminit.c Type: image/x-xbitmap Size: 802 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setup.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 630_regs.h URL: From justin at street-vision.com Tue Feb 25 13:36:01 2003 From: justin at street-vision.com (Justin Cormack) Date: Tue Feb 25 13:36:01 2003 Subject: [commit] Support for Intel se7501cw2 In-Reply-To: References: Message-ID: <1046199479.1547.2.camel@lotte> On Fri, 2003-02-07 at 00:30, steven james wrote: > Greetings, > > I've just committed support for the 533MHz FSB version of Intel > Clearwater and the E7501 northbridge. > > It's not well tested yet, but it does etherboot the kernel. > How similar is E7505? Does anyone have the docs? There are now much cheaper, actual ATX form factor E7505 eg http://www.supermicro.com/PRODUCT/MotherBoards/E7505/X5DAL-G.htm These are GBP 299, with only 1 fewer AGP socket, built in e1000. Justin From rminnich at lanl.gov Tue Feb 25 14:03:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 14:03:01 2003 Subject: [commit] Support for Intel se7501cw2 In-Reply-To: <1046199479.1547.2.camel@lotte> Message-ID: I'm trying out a 7501 now, and then 7505 ron From pyro at linuxlabs.com Tue Feb 25 14:07:00 2003 From: pyro at linuxlabs.com (steven james) Date: Tue Feb 25 14:07:00 2003 Subject: [commit] Support for Intel se7501cw2 In-Reply-To: <1046199479.1547.2.camel@lotte> Message-ID: Greetings, It looks pretty similar (there are a few additional documented settings). There are likely a few undocumented regs in the 0x80-0x8f range that will have to be hacked on. The docs are on Intel's website. (select products, server/workstation chipsets, follow the links. Datasheet links to the right of the page). G'day, sjames On 25 Feb 2003, Justin Cormack wrote: > On Fri, 2003-02-07 at 00:30, steven james wrote: > > Greetings, > > > > I've just committed support for the 533MHz FSB version of Intel > > Clearwater and the E7501 northbridge. > > > > It's not well tested yet, but it does etherboot the kernel. > > > > How similar is E7505? Does anyone have the docs? There are now much > cheaper, actual ATX form factor E7505 eg > > http://www.supermicro.com/PRODUCT/MotherBoards/E7505/X5DAL-G.htm > > These are GBP 299, with only 1 fewer AGP socket, built in e1000. > > Justin > > > _______________________________________________ > 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 701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bari at onelabs.com Tue Feb 25 14:32:01 2003 From: bari at onelabs.com (Bari Ari) Date: Tue Feb 25 14:32:01 2003 Subject: [commit] Support for Intel se7501cw2 References: <1046199479.1547.2.camel@lotte> Message-ID: <3E5BCA3E.4090301@onelabs.com> Justin Cormack wrote: >On Fri, 2003-02-07 at 00:30, steven james wrote: > > >>Greetings, >> >>I've just committed support for the 533MHz FSB version of Intel >>Clearwater and the E7501 northbridge. >> >>It's not well tested yet, but it does etherboot the kernel. >> >> >> > >How similar is E7505? Does anyone have the docs? There are now much >cheaper, actual ATX form factor E7505 eg > > > The 7505 is very similar to the 7501 with 533 MHz system bus and also features 8x AGP.... a missing feature from recent Xeon chipsets. And according to the Digitimes http://www.digitimes.com/NewsShow/Article.asp?datePublish=2003/02/20&pages=PR&seq=206 the 800MHz system bus with DDR400 chips (i865, i875) are due out next quarter. We should work on having LinuxBIOS ready and publicly posted for chipsets the moment they are released. This would be a nice step towards having LinuxBIOS ready months before release as legacy BIOS vendors have always done. Bari From jerj at coplanar.net Tue Feb 25 18:35:00 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Tue Feb 25 18:35:00 2003 Subject: Ram initialization and small c. In-Reply-To: <3E5BB166.3070807@kesa.com> References: <3E5BB166.3070807@kesa.com> Message-ID: <1046217433.1662.79.camel@contact.skynet.coplanar.net> On Tue, 2003-02-25 at 13:09, Steve Gehlbach wrote: > I think you have to cramp your C coding style anyway, to stay within > registers. The extra scratch area does not help much, with chips such A compiler *made* to compile this way could help a great deal by scheduling instructions like an RPN calculator though, so *you* don't have to write in spaghetti code. BUT, would C's block-scope local variables allow registers to be re-used by different local variables, so instead of void func (void) { register int eax; /* use i for one purpose */ /* use same i for something else */ } you could do void func (void) { { register int ramsize; /* use ramsize */ } { register int cpuid; /* use cpuid */ } } and have both end up using the same register, kind of like a union, but still looking more like C than assembler. > as the SiS630, only has three gp regs, little help. You can't go around > declaring variables willy nilly, you run out of space (registers) no > matter what compiler. But for the cases where (in the chipset or whereever) there are scratch registers, global extern static variables that are fixed when linking, (or define them in an assembler stub with .org or such) would allow them to be used easily from C. > > I also have been experimenting with inline gcc, and I think it works > pretty well and once you get the hang of it, and it _is_ easier than > assy. I have re-coded the console routines, and ram setup, and spd > timing setup on the sis630 for C. It is still a wip but I have tested > the spd setup by wrapping a real main on a live machine. > > So far it is about 400 lines of C, should I attach it? It compiles > without using the stack (except for a %ebp push/pop which can be deleted). Please do. It would be a good example of how complex the code can be with the register/inline constraints. As for the frame pointer (you mean at the start of the first function), take a look at my sample, have you tried -fomit-frame-pointer? > > I can't see how a special compiler gets you enough more than gcc to be > worth the downside of effort and debugging. Scratch regs vary from chip > to chip, and use 1.5 regs to access (pci). You could use the %ebp and > %esp which is a gain of two (and maybe %es %fs etc), but I think using > gcc will get us there anyway. Looking at -fcall-saved-REG it seems that %esp and %ebp may be off limits for gcc, but the info docs are a little vague, perhaps it must be tried to be proven one way or the other. Inline assemply may allow them to be used, but that would almost be back where we started. -- Jeremy Jackson From rminnich at lanl.gov Tue Feb 25 18:46:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 18:46:00 2003 Subject: Ram initialization and small c. In-Reply-To: <1046217433.1662.79.camel@contact.skynet.coplanar.net> Message-ID: On 25 Feb 2003, Jeremy Jackson wrote: > BUT, would C's block-scope local variables allow registers to be re-used > by different local variables, so instead of > void func (void) { > { > register int ramsize; > /* use ramsize */ > } > { > register int cpuid; > /* use cpuid */ > } > } that should work very well. ron From steve at nexpath.com Tue Feb 25 19:14:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Feb 25 19:14:01 2003 Subject: Ram initialization and small c. In-Reply-To: <1046217433.1662.79.camel@contact.skynet.coplanar.net> References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> Message-ID: <3E5C0DA4.3080400@nexpath.com> Jeremy Jackson wrote: >>So far it is about 400 lines of C, should I attach it? It compiles >>without using the stack (except for a %ebp push/pop which can be deleted). > > > Please do. It would be a good example of how complex the code can be > with the register/inline constraints. I thought I did attach it. Did the list delete the attachments? -Steve From ebiederman at lnxi.com Tue Feb 25 20:03:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue Feb 25 20:03:01 2003 Subject: Ram initialization and small c. In-Reply-To: <1046217433.1662.79.camel@contact.skynet.coplanar.net> References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> Message-ID: Jeremy Jackson writes: > On Tue, 2003-02-25 at 13:09, Steve Gehlbach wrote: > > > I think you have to cramp your C coding style anyway, to stay within > > registers. The extra scratch area does not help much, with chips such > > A compiler *made* to compile this way could help a great deal by > scheduling instructions like an RPN calculator though, so *you* don't > have to write in spaghetti code. So far I like the extern inline aspect in that it makes a good proof of concept that this code can be written in C, and that it is not so outrageous to expect a compiler to do it. Steve for a feel of my worries try compiling that code with gcc-3.3. If what I saw earlier today is right it won't work because someone has decided that aggressive inlining is bad thing... > > BUT, would C's block-scope local variables allow registers to be re-used > by different local variables, so instead of > > void func (void) { > register int eax; > > /* use i for one purpose */ > > /* use same i for something else */ > } > > you could do > > void func (void) { > { > register int ramsize; > /* use ramsize */ > } > { > register int cpuid; > /* use cpuid */ > } > } > > and have both end up using the same register, kind of like a union, > but still looking more like C than assembler. Yes. That is basic live variable analysis. In general a value not a variable gets assigned to a register. The rule is that if a variable is assigned a new value before the old value is used again. The variable can be dropped in the intervening space, and afterwards a new register can be assigned. It can go as far as a new register assignment every time you change the value of a variable. > > as the SiS630, only has three gp regs, little help. You can't go around > > declaring variables willy nilly, you run out of space (registers) no > > matter what compiler. > > But for the cases where (in the chipset or whereever) there are scratch > registers, global extern static variables that are fixed when linking, > (or define them in an assembler stub with .org or such) would allow them > to be used easily from C. That definitely requires some thinking. When it requires extra registers to spill a register it can be hard for a compiler. I am going to start with the spill free case... > > So far it is about 400 lines of C, should I attach it? It compiles > > without using the stack (except for a %ebp push/pop which can be deleted). > > Please do. It would be a good example of how complex the code can be > with the register/inline constraints. It has already shown up on the list but watch out for the inline part that says it is a pixmap when it should be text plain. Eric From yapeehuey at hotmail.com Tue Feb 25 20:13:00 2003 From: yapeehuey at hotmail.com (Yap Ee Huey) Date: Tue Feb 25 20:13:00 2003 Subject: tusl2-c motherboard Message-ID: Hi all, My name is eehuey, I was unable to use your help page cgi to send my mainboard info , so I use email, hope you don't mind. Mainboard : ASUS TUSL2-C (Socket 370, Intel 815EP Flash Device : SST 49LF002A Output from lspci -- 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 04) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 05) 00:1f.0 ISA bridge: Intel Corp. 82801BA ISA Bridge (LPC) (rev 05) 00:1f.1 IDE interface: Intel Corp. 82801BA IDE U100 (rev 05) 00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 05) 00:1f.3 SMBus: Intel Corp. 82801BA/BAM SMBus (rev 05) 00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 05) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon QD 02:07.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) regards, eehuey _________________________________________________________________ Download the latest MSN Messenger http://messenger.msn.com.my From steve at nexpath.com Tue Feb 25 22:30:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Feb 25 22:30:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> Message-ID: <3E5C3D91.3080601@nexpath.com> Eric W. Biederman wrote: > > Steve for a feel of my worries try compiling that code with gcc-3.3. If > what I saw earlier today is right it won't work because someone has decided > that aggressive inlining is bad thing... > Hmm... I assume you mean gcc-3.2.2 unless you have a pre-release. I have gcc3.2 on a RH machine, it seems to work on my code, although I had to delete a couple of asm's and fiddle with raminit.c: went back to "register int i asm ("ecx");". Otherwise gcc3.2 was more efficient (-181 lines), and it uses the %ebp differently. As a result, checking for "push" or "esp" is not effective to determine spill cases, you have to look for %ebp which it does tmp storage with mov's. Interesting that gcc3.2 seems to ignore the -fomit-frame-pointer since there is a "leave" at the end. Not sure why. Note the reason for the push of the %ebp in gcc2.95 is that 2.95 uses it for temp storage (hadn't noticed this before) if you set -fomit-frame-pointer, and so it push/pops it on entry and leaving. -Steve From zhushisongzhu at yahoo.com Tue Feb 25 22:40:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Tue Feb 25 22:40:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: Message-ID: <20030226035437.38829.qmail@web13206.mail.yahoo.com> for mainboards that can't copy irq_routing_table to 0xf0000, what should we do to let linux setup irq of pci device correctly? "Ronald G. Minnich" wrote:On Tue, 25 Feb 2003, zhu shi song wrote: > can you copy irq_tables to 0xf0000 on your mainboard? > It depends on the chipset on the mainboard and also if the code for that chipset sets up 0xf0000 as 'shadow memory'. For most platforms, the answer is still 'no'. But for most platforms, I think the answer could be 'yes' ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Tue Feb 25 22:43:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue Feb 25 22:43:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226035437.38829.qmail@web13206.mail.yahoo.com> Message-ID: On Tue, 25 Feb 2003, zhu shi song wrote: > > for mainboards that can't copy irq_routing_table to 0xf0000, what should > we do to let linux setup irq of pci device correctly? make sure that CONFIG_COMPRESS=0 ron From aip at cwlinux.com Tue Feb 25 22:50:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Tue Feb 25 22:50:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226035437.38829.qmail@web13206.mail.yahoo.com>; from zhu shi song on Tue, Feb 25, 2003 at 07:54:37PM -0800 References: <20030226035437.38829.qmail@web13206.mail.yahoo.com> Message-ID: <20030226121140.A8412@mail.cwlinux.com> Zhu, > for mainboards that can't copy irq_routing_table to 0xf0000, what should we do to let linux setup irq of pci device correctly? Have you checked if CONFIG_COMPRESS is set 0? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From steve at nexpath.com Tue Feb 25 23:36:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Tue Feb 25 23:36:00 2003 Subject: Ram initialization and small c. In-Reply-To: References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> Message-ID: <3E5C4D03.9060401@nexpath.com> Eric W. Biederman wrote: > Steve for a feel of my worries try compiling that code with gcc-3.3. If > what I saw earlier today is right it won't work because someone has decided > that aggressive inlining is bad thing... > I did discover (by accident) that gcc3.2 gets more aggressive in inlining if you call the top routine "main" instead of some other function name. gcc2.95 doesn't have this behavior. -Steve From zhushisongzhu at yahoo.com Wed Feb 26 00:30:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 26 00:30:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: Message-ID: <20030226055140.10225.qmail@web13205.mail.yahoo.com> yes , CONFIG_COMPRESS=0 but it seems there is no effect, should i set kernel pci access mode to any or direct? "Ronald G. Minnich" wrote:On Tue, 25 Feb 2003, zhu shi song wrote: > > for mainboards that can't copy irq_routing_table to 0xf0000, what should > we do to let linux setup irq of pci device correctly? make sure that CONFIG_COMPRESS=0 ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From aip at cwlinux.com Wed Feb 26 00:47:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Feb 26 00:47:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226055140.10225.qmail@web13205.mail.yahoo.com>; from zhu shi song on Tue, Feb 25, 2003 at 09:51:40PM -0800 References: <20030226055140.10225.qmail@web13205.mail.yahoo.com> Message-ID: <20030226140857.A9944@mail.cwlinux.com> > yes , CONFIG_COMPRESS=0 > but it seems there is no effect, should i set kernel pci access mode to any or direct? PCI access mode has to be direct. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From zhushisongzhu at yahoo.com Wed Feb 26 01:54:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 26 01:54:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226140857.A9944@mail.cwlinux.com> Message-ID: <20030226071559.41130.qmail@web13203.mail.yahoo.com> no any progress. linux can't assign pci irq. what's wrong? Andrew Ip wrote: > yes , CONFIG_COMPRESS=0 > but it seems there is no effect, should i set kernel pci access mode to any or direct? PCI access mode has to be direct. -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From aip at cwlinux.com Wed Feb 26 02:21:01 2003 From: aip at cwlinux.com (Andrew Ip) Date: Wed Feb 26 02:21:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226071559.41130.qmail@web13203.mail.yahoo.com>; from zhu shi song on Tue, Feb 25, 2003 at 11:15:59PM -0800 References: <20030226140857.A9944@mail.cwlinux.com> <20030226071559.41130.qmail@web13203.mail.yahoo.com> Message-ID: <20030226154313.A11344@mail.cwlinux.com> > no any progress. linux can't assign pci irq. what's wrong? Have you run getpir to get the correct pirq table? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. From zhushisongzhu at yahoo.com Wed Feb 26 02:54:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 26 02:54:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226154313.A11344@mail.cwlinux.com> Message-ID: <20030226081601.50005.qmail@web13203.mail.yahoo.com> yes, irq_tables.c is: /* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*4, /* there can be total 4 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0x90, /* Where the interrupt router lies (dev) */ 0x8c00, /* IRQs devoted exclusively to PCI usage */ 0x1078, /* Vendor */ 0x2, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0x4d, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { {0,0x78, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}}, 0x2, 0}, {0,0x88, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0}, {0,0x98, {{0x1, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}}, 0, 0}, {0x40,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0}, } }; Andrew Ip wrote:> no any progress. linux can't assign pci irq. what's wrong? Have you run getpir to get the correct pirq table? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhushisongzhu at yahoo.com Wed Feb 26 03:27:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 26 03:27:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226081601.50005.qmail@web13203.mail.yahoo.com> Message-ID: <20030226084833.44780.qmail@web13205.mail.yahoo.com> sorry, check sum should be 0xf0. NIC is ok. but usb's irq is not correct. zhu shi song wrote: yes, irq_tables.c is: /* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*4, /* there can be total 4 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0x90, /* Where the interrupt router lies (dev) */ 0x8c00, /* IRQs devoted exclusively to PCI usage */ 0x1078, /* Vendor */ &nb! sp; 0x2, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0xf0, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { {0,0x78, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}}, 0x2, 0}, {0,0x88, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0}, &n! bsp; {0,0x98, {{0x1, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}}, 0, 0}, {0x40,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0}, } }; Andrew Ip wrote: > no any progress. linux can't assign pci irq. what's wrong? Have you run getpir to get the correct pirq table? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhushisongzhu at yahoo.com Wed Feb 26 07:29:00 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Wed Feb 26 07:29:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226084833.44780.qmail@web13205.mail.yahoo.com> Message-ID: <20030226125120.16210.qmail@web13201.mail.yahoo.com> usb's irq is still incorrect. under normal linux, usb's irq is 15, but under linuxbios the irq is 10. so usb can't work correctly. what's the correct step to run getpir? what's the rule for linux kernel to assign pci irq according to irq routing table? thanks zhu shi song wrote: sorry, check sum should be 0xf0. NIC is ok. but usb's irq is not correct. zhu shi song wrote: yes, irq_tables.c is: /* This file was generated by getpir.c, do not modify! (but if you do, please run checkpir on it to verify) Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*4, /* there can be total 4 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0x90, /* Where the interrupt router lies (dev) */ 0x8c00, /* IRQs devoted exclusively to PCI usage */ 0x1078, /* Vendor */ &am! p;nb! sp; 0x2, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0xf0, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { {0,0x78, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}}, 0x2, 0}, {0,0x88, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0}, &n! bsp;&n! bsp; {0,0x98, {{0x1, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}, {0, 0xdeb8}}, 0, 0}, {0x40,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0}, } }; Andrew Ip wrote: > no any progress. linux can't assign pci irq. what's wrong? Have you run getpir to get the correct pirq table? -Andrew -- Andrew Ip Email: aip at cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Wed Feb 26 09:55:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 26 09:55:00 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226055140.10225.qmail@web13205.mail.yahoo.com> Message-ID: On Tue, 25 Feb 2003, zhu shi song wrote: > but it seems there is no effect, should i set kernel pci access mode to > any or direct? should not matter for IRQ, but try direct anyway. ron From rminnich at lanl.gov Wed Feb 26 09:59:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 26 09:59:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226071559.41130.qmail@web13203.mail.yahoo.com> Message-ID: send the output of your serial port one more time, sorry, I"ve lost context. ron From rminnich at lanl.gov Wed Feb 26 10:00:31 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 26 10:00:31 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226084833.44780.qmail@web13205.mail.yahoo.com> Message-ID: On Wed, 26 Feb 2003, zhu shi song wrote: > > sorry, check sum should be 0xf0. NIC is ok. but usb's irq is not correct. Is this, by any chance, the error in which the USB hardware is not being enabled? ron From rminnich at lanl.gov Wed Feb 26 10:03:01 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 26 10:03:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: <20030226125120.16210.qmail@web13201.mail.yahoo.com> Message-ID: On Wed, 26 Feb 2003, zhu shi song wrote: > > usb's irq is still incorrect. under normal linux, usb's irq is 15, but > under linuxbios the irq is 10. so usb can't work correctly. what's the > correct step to run getpir? what's the rule for linux kernel to assign > pci irq according to irq routing table? thanks There is a chance that the PIR on the standard BIOS is wrong! This happens. We've seen cases where the BIOS settings do not agree with the PIR settings, and the BIOS is just setting in the correct interrupt. What board is this again (Sorry I forgot) ron From ebiederman at lnxi.com Wed Feb 26 19:31:01 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 26 19:31:01 2003 Subject: Ram initialization and small c. In-Reply-To: <3E5C3D91.3080601@nexpath.com> References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> <3E5C3D91.3080601@nexpath.com> Message-ID: Steve Gehlbach writes: > Eric W. Biederman wrote: > > > Steve for a feel of my worries try compiling that code with gcc-3.3. If > > what I saw earlier today is right it won't work because someone has decided > > that aggressive inlining is bad thing... > > > > Hmm... I assume you mean gcc-3.2.2 unless you have a pre-release. I don't currently have a pre release but that is what I was thinking about. But 3.3 is scheduled to release in the next couple of weeks. And one of the issues that was being vigorously discussed on the gcc list was how to handle the fact that 3.3 does not inline nearly as much as 3.2 and there was not currently a way to get it to inline more than it thought was reasonable. was > on a RH machine, it seems to work on my code, although I had to delete a couple > of asm's and fiddle with raminit.c: went back to "register int i asm ("ecx");". > Otherwise gcc3.2 was more efficient (-181 lines), and it uses the %ebp > differently. As a result, checking for "push" or "esp" is not effective to > determine spill cases, you have to look for %ebp which it does tmp storage with > mov's. The requirements of these small tweaks when building are why I am convinced that in the long run we need actual compiler support. Either in gcc or in one we write ourselves. For now we have an easier way to generate the assembly code. > Interesting that gcc3.2 seems to ignore the -fomit-frame-pointer since there is > a "leave" at the end. Not sure why. > > Note the reason for the push of the %ebp in gcc2.95 is that 2.95 uses it for > temp storage (hadn't noticed this before) if you set -fomit-frame-pointer, and > so it push/pops it on entry and leaving. That makes sense. Eric From steve at nexpath.com Wed Feb 26 20:41:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Feb 26 20:41:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> <3E5C3D91.3080601@nexpath.com> Message-ID: <3E5D739A.4070106@nexpath.com> Eric W. Biederman wrote: > The requirements of these small tweaks when building are why I am convinced > that in the long run we need actual compiler support. Either in gcc or > in one we write ourselves. For now we have an easier way to generate the > assembly code. > Actually I don't mind the inline tweaking approach and I think it is easier to write and debug than assy, but others will disagree. My concern is that a register-only compiler may be an intractable problem, and any way you go at it (custom or .md file for gcc) you will have to tweak and craft the C code just as much. If in fact this is true, then the benefit over inlining gcc seems minimal. Wish there were a way to answer this question before you invest a month of time. -Steve From ziegast at vix.com Wed Feb 26 21:00:01 2003 From: ziegast at vix.com (Eric Ziegast) Date: Wed Feb 26 21:00:01 2003 Subject: Amptron 3787CLM - will donate hardware for support Message-ID: <20030227022206.60B614C951@rous.redbarn.org> Note: I'd normally use the linuxbios.org web page submission form, but the form is not working, and there is no contact info that looked readily available. The list isn't a bad place to find people willing to work on new hardware, so here goes... I found some cheap motherboards from Amptron that make an ideal terminal server or low-power workstation. It's the PIII-3787CLM+. You might recognize the motherboard if you bought one of those $199 Fry's/Walmart PCs recently. The motherboard + 733MHz Via C3 costs about $70 retail. It comes with just about everything you need for a desktop: AGP Video, AC97 sound, 10/100 Ethernet, and USB. All I need to do is add a floppy drive, some RAM, and then boot. Motherboard specs: http://www.amptron.com/html/MotherboardP3_M787CL+_frame.html I plan to use the motherboard on desktops (LTSP and/or diskless NFS-based RedHat 8.0) and some servers (add more RAM and maybe a a uDMA drive or two). I'd really like to just boot Linux off the BIOS to make boot times faster and have one less moving part to fail. If the BIOS supported USB boot drives, I'd just get a keychain drive and be done. The built-in Ethernet doesn't PXEboot, so LinuxBIOS looks like the only way to get rid of the floppy. I'd be glad to donate a montherboard ($70 retail value each) to anyone who can get one of them to boot to become either a LTSP client or a diskless Linux workstation (initrd root + NFS /usr) without the use of a floppy disk. I'll throw in a $20 256MB DIMM for fun. The label on the BIOS chip reads: "686 AMIBIOS (C)1999 BS46". The Amptron web page states it's 2MB "Flash". I don't know how this compares to DiskOnChip, but it's my preference not to have to buy/install DOC if I can avoid it. Reading the Sis630 LinuxBIOS HOWTO, I don't feel confident in my ability to get it to work on new unsupported hardware. If you think you can get it to work, drop me a line. If you can make a public HOWTO document for me and others to install LinuxBIOS on the board (without buying DiskOnChip), you can keep your parts. If it's not possible, let me know. I really like the hardware becasue it's an excellent, low-power (25W), cheap desktop platform. It could also be a part of dense low-bandwidth low-power server clusters. Eric Ziegast San Diego, CA ziegast at vix.com 619-994-UNIX (cell) Some info off a system on which I installed RedHat 8.0... # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 21) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 83) 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07) 00:01.3 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 21) # dmesg Linux version 2.4.18-14 (bhcompile at stripples.devel.redhat.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Sep 4 11:57:57 EDT 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000fdf0000 (usable) BIOS-e820: 000000000fdf0000 - 000000000fdf8000 (ACPI data) BIOS-e820: 000000000fdf8000 - 000000000fe00000 (ACPI NVS) BIOS-e820: 00000000ffef0000 - 00000000fff00000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 253MB LOWMEM available. On node 0 totalpages: 65008 zone(0): 4096 pages. zone(1): 60912 pages. zone(2): 0 pages. Kernel command line: ro root=LABEL=/ Initializing CPU#0 Detected 735.006 MHz processor. Speakup v-1.00 CVS: Tue Jun 11 14:22:53 EDT 2002 : initialized Console: colour VGA+ 80x25 Calibrating delay loop... 1468.00 BogoMIPS Memory: 251216k/260032k available (1193k kernel code, 6400k reserved, 984k data, 200k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 4096 (order: 3, 32768 bytes) ramfs: mounted with options: ramfs: max_pages=31655 max_file_pages=0 max_inodes=0 max_dentries=31655 Buffer cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 00803035 80803035 00000000, vendor = 5 CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After vendor init, caps: 00803135 80803035 00000000 00000000 CPU: After generic, caps: 00803135 80803035 00000000 00000000 CPU: Common caps: 00803135 80803035 00000000 00000000 CPU: Centaur VIA Samuel 2 stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch at atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfd9f8, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router SIS [1039/0008] at 00:01.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found speakup: initialized device: /dev/synth, node (MAJOR 10, MINOR 25) Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) Starting kswapd VFS: Diskquotas version dquot_6.5.0 initialized pty: 512 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS0 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10e block: 480 slots per queue, batch=120 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 01 PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try using pci=biosirq. SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS630 ATA 66 controller ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA hda: WDC WD200BB-60DGA0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=2434/255/63, UDMA(66) ide-floppy driver 0.99.newide Partition check: hda: hda1 hda2 hda3 floppy0: no floppy controllers found NET4: Frame Diverter 0.46 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize ide-floppy driver 0.99.newide md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 127k freed VFS: Mounted root (ext2 filesystem). Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Freeing unused kernel memory: 200k freed usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Found IRQ 10 for device 00:01.3 PCI: Sharing IRQ 10 with 00:01.2 usb-ohci.c: USB OHCI at membase 0xd0844000, IRQ 10 usb-ohci.c: usb-00:01.3, Silicon Integrated Systems [SiS] 7001 (#2) usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 10 for device 00:01.2 PCI: Sharing IRQ 10 with 00:01.3 usb-ohci.c: USB OHCI at membase 0xd0846000, IRQ 10 usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 3 ports detected usb.c: registered new driver hiddev usb.c: registered new driver hid hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,2), internal journal Adding Swap: 522104k swap-space (priority -1) kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.18, 14 May 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. ohci1394: pci_module_init failed ip_tables: (C) 2000-2002 Netfilter core team sis900.c: v1.08.04 4/25/2002 PCI: Found IRQ 11 for device 00:01.1 divert: allocating divert_blk for eth0 eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using transceiver found at address 1 as default eth0: SiS 900 PCI Fast Ethernet at 0xde00, IRQ 11, 00:07:95:35:88:b1. eth0: Media Link On 100mbps half-duplex From ebiederman at lnxi.com Wed Feb 26 21:18:00 2003 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed Feb 26 21:18:00 2003 Subject: Ram initialization and small c. In-Reply-To: <3E5D739A.4070106@nexpath.com> References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> <3E5C3D91.3080601@nexpath.com> <3E5D739A.4070106@nexpath.com> Message-ID: Steve Gehlbach writes: > Eric W. Biederman wrote: > > > The requirements of these small tweaks when building are why I am convinced > > that in the long run we need actual compiler support. Either in gcc or > > in one we write ourselves. For now we have an easier way to generate the > > assembly code. > > > > Actually I don't mind the inline tweaking approach and I think it is > easier to write and debug than assy, but others will disagree. The only part I don't like is that you have to keep the .S files around... > My concern is that a register-only compiler may be an intractable > problem, and any way you go at it (custom or .md file for gcc) you > will have to tweak and craft the C code just as much. It should have problems only when you run out of registers, which I think is a rather different problem. > If in fact this > is true, then the benefit over inlining gcc seems minimal. Wish there > were a way to answer this question before you invest a month of time. Oh. I think I can have some answers in less than a month. That is just what I have allocated for investigation. But it will take a week or so to get something working well enough to compare with the inline tweaking approach. Plus write now I am enjoying the change of pace. Eric From rminnich at lanl.gov Wed Feb 26 22:43:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed Feb 26 22:43:00 2003 Subject: Amptron 3787CLM - will donate hardware for support In-Reply-To: <20030227022206.60B614C951@rous.redbarn.org> Message-ID: On Wed, 26 Feb 2003, Eric Ziegast wrote: > Note: I'd normally use the linuxbios.org web page submission form, but > the form is not working, and there is no contact info that > looked readily available. The list isn't a bad place to find > people willing to work on new hardware, so here goes... sorry about the form, we're in transition and that thing never got used by anybody so we took it off. > The label on the BIOS chip reads: "686 AMIBIOS (C)1999 BS46". > The Amptron web page states it's 2MB "Flash". I don't know how probably 2 Mbit, not 2 Mbyte. Is it a 32-pin DIP or a little square thing? can you peel the label off and see what the part # is? Would you consider IDE-flash? pretty cheap and works now. We have 1152 of them working fine here at LANL. ron From steve at nexpath.com Wed Feb 26 22:46:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Feb 26 22:46:01 2003 Subject: Ram initialization and small c. In-Reply-To: References: <3E5BB166.3070807@kesa.com> <1046217433.1662.79.camel@contact.skynet.coplanar.net> <3E5C3D91.3080601@nexpath.com> <3E5D739A.4070106@nexpath.com> Message-ID: <3E5D928C.7020000@nexpath.com> Eric W. Biederman wrote: > Oh. I think I can have some answers in less than a month. That is > just what I have allocated for investigation. But it will take a week > or so to get something working well enough to compare with the inline > tweaking approach. > > Plus write now I am enjoying the change of pace. Cool, let's see how it goes. Feed it the decode routine from nrv2b.c and see how it likes that. gcc is a long ways from doing this in registers without a major re-write, which is probably about as much work as your implementation in assy. Very clever assy code, BTW. Also I think the .S files don't have to be kept if we use a trivial post processing program like below. -Steve #!/usr/bin/perl # # program to process a .s file generated by gcc # to eliminate gcc gingerbread so the file # can be used for linuxbios. # Also check for register spillage and use of the # stack since this code is intended to run without # ram. # # GPL for the linuxbios project # # by. Steve M. Gehlbach (steve @ kesa . com) # $ret = 0; while () { # # save everything and go over it # once to check for errors # $line = $_; # get everthing up to comment # we don't want to bail out on items # in comments. $_ = (split(/\#/))[0]; next unless ($_); # # now check for things that indicate that # the stack is being used, which means that gcc # failed to fully inline code # with no stack pushes &Abort if /\(\%esp\)/; if (/\(\%ebp\)/) { &Abort unless /\%esp/; } &Abort if /\scall\s/; &Abort if /\.Lfe2\:/; /pushl/ && ($line = '#'.$line); /pop/ && ($line = '#'.$line); /leave/ && ($line = '#'.$line); /\%esp/ && ($line = '#'.$line); /ret/ && do { # only one return should be there &Abort if ($ret); # convert the last return to a jump in case # ret is in middle of code; rel jump okay? $line =~ s/ret/jmp \.Lfe1/; $ret++; }; # save the processed line push @lines,$line; } # # okay so print it out # while ($_ = shift @lines) { print $_; } exit (0); # # error print it with gas pseudo-ops # and bail # sub Abort { chomp $line; print ".print \"$line <<< ERROR*** gcc uses stack or failed to inline code!\"\n"; print ".err\n"; exit (1); } From steve at nexpath.com Wed Feb 26 22:55:00 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Wed Feb 26 22:55:00 2003 Subject: Amptron 3787CLM - will donate hardware for support In-Reply-To: <20030227022206.60B614C951@rous.redbarn.org> References: <20030227022206.60B614C951@rous.redbarn.org> Message-ID: <3E5D9500.6080501@nexpath.com> Eric Ziegast wrote: > I found some cheap motherboards from Amptron that make an ideal > terminal server or low-power workstation. It's the PIII-3787CLM+. > You might recognize the motherboard if you bought one of those > $199 Fry's/Walmart PCs recently. The motherboard + 733MHz Via C3 > costs about $70 retail. It comes with just about everything you > need for a desktop: AGP Video, AC97 sound, 10/100 Ethernet, and > USB. All I need to do is add a floppy drive, some RAM, and then boot. > > Motherboard specs: > http://www.amptron.com/html/MotherboardP3_M787CL+_frame.html Try http://www.knowledgemicro.com/detail.php?name=MB-M787CL%2B at $52.27. Says its 1GHZ but otherwise the same. This boots under linuxbios with vga and local disk but I have not done it for etherboot. Should be only an hour or so of work, though. -Steve From zhushisongzhu at yahoo.com Thu Feb 27 02:05:01 2003 From: zhushisongzhu at yahoo.com (zhu shi song) Date: Thu Feb 27 02:05:01 2003 Subject: irq_routing_table can't be copied to 0xf0000 In-Reply-To: Message-ID: <20030227072610.16687.qmail@web13206.mail.yahoo.com> evoc mainboard specififaction: on-board NS GX1 233Mhz(fanless) NS CS5530A winbond83977f realtek rtl8139C attached file is linux kern boot mesgs. "Ronald G. Minnich" wrote: On Wed, 26 Feb 2003, zhu shi song wrote: > > usb's irq is still incorrect. under normal linux, usb's irq is 15, but > under linuxbios the irq is 10. so usb can't work correctly. what's the > correct step to run getpir? what's the rule for linux kernel to assign > pci irq according to irq routing table? thanks There is a chance that the PIR on the standard BIOS is wrong! This happens. We've seen cases where the BIOS settings do not agree with the PIR settings, and the BIOS is just setting in the correct interrupt. What board is this again (Sorry I forgot) ron _______________________________________________ Linuxbios mailing list Linuxbios at clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 123.txt URL: From nathanael at gnat.ca Thu Feb 27 08:58:00 2003 From: nathanael at gnat.ca (Nathanael Noblet) Date: Thu Feb 27 08:58:00 2003 Subject: Suggestions Message-ID: <991AC4AC-4A5E-11D7-A97D-0003931B4D6A@gnat.ca> Hello, I'm wondering if anyone has any suggestion of any boards that are supported by linuxbios and have AGP graphics, audio and possibly onboard network (though eventually I'd like to add wireless networking instead). In a small form factor, like a SBC type setup. If you do that would be great. -- 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 Thu Feb 27 11:16:01 2003 From: steve at nexpath.com (Steve Gehlbach) Date: Thu Feb 27 11:16:01 2003 Subject: Suggestions In-Reply-To: <991AC4AC-4A5E-11D7-A97D-0003931B4D6A@gnat.ca> References: <991AC4AC-4A5E-11D7-A97D-0003931B4D6A@gnat.ca> Message-ID: <3E5E4081.8090608@nexpath.com> Nathanael Noblet wrote: > Hello, > I'm wondering if anyone has any suggestion of any boards that are > supported by linuxbios and have AGP graphics, audio and possibly onboard > network (though eventually I'd like to add wireless networking instead). > In a small form factor, like a SBC type setup. If you do that would be > great. > Depends on what you mean by "small", but the Via EPIA might work, mini ITX format. It's a little bleeding edge at the moment but some folks do have it working I think. I also think there is an epiafb, but not sure if it uses AGP. Linuxbios support of vga on boot is not there yet, work ongoing. But Andrew Ip would have more information. -Steve From xpegenaute at telepolis.es Thu Feb 27 11:23:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Thu Feb 27 11:23:01 2003 Subject: flashrom Message-ID: <3E5E5B75.7040306@telepolis.es> Hi, normally when a mainboard's specification say that has 2Mb of Flash ROM, are 2Mbits or Mbytes ..? Regards. Xavi. From rminnich at lanl.gov Thu Feb 27 11:38:00 2003 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu Feb 27 11:38:00 2003 Subject: flashrom In-Reply-To: <3E5E5B75.7040306@telepolis.es> Message-ID: On Thu, 27 Feb 2003, Xavier Pegenaute wrote: > normally when a mainboard's specification say that has 2Mb of Flash ROM, > are 2Mbits or Mbytes ..? always mbits, since that makes it seem larger, and the marketing guys are in charge. ron From jerj at coplanar.net Thu Feb 27 11:40:01 2003 From: jerj at coplanar.net (Jeremy Jackson) Date: Thu Feb 27 11:40:01 2003 Subject: flashrom In-Reply-To: <3E5E5B75.7040306@telepolis.es> References: <3E5E5B75.7040306@telepolis.es> Message-ID: <1046365299.3683.1.camel@contact.skynet.coplanar.net> On Thu, 2003-02-27 at 13:39, Xavier Pegenaute wrote: > Hi, > > normally when a mainboard's specification say that has 2Mb of Flash ROM, > are 2Mbits or Mbytes ..? It's 2Mi bits, Mi = 1024 * 1024. /8 = 256 Ki bytes. Ki= 1024 -- Jeremy Jackson From bari at onelabs.com Thu Feb 27 11:43:01 2003 From: bari at onelabs.com (Bari Ari) Date: Thu Feb 27 11:43:01 2003 Subject: flashrom References: <3E5E5B75.7040306@telepolis.es> Message-ID: <3E5E45BD.1080304@onelabs.com> Xavier Pegenaute wrote: > Hi, > > normally when a mainboard's specification say that has 2Mb of Flash > ROM, are 2Mbits or Mbytes ..? Mb = megabit MB = megabyte Most motherboards have 2 megabits (2Mb) of Flash ROM. Lots of motherboard specifications are poorly written and edited with MB used for Mb. When in doubt, check the part number on the surface of the Flash device. Bari From xpegenaute at telepolis.es Fri Feb 28 05:04:01 2003 From: xpegenaute at telepolis.es (Xavier Pegenaute) Date: Fri Feb 28 05:04:01 2003 Subject: About ADLO Message-ID: <3E5F5438.7040604@telepolis.es> Hi again, i'm not sure of how ADLO work ..., to work with ADLO, i need a Matsonic motherboard with a LinuxBios installed, once time i have this, i make the new elf file with a bios of Bochs and a Video Bios, and after i put these files overwriting the LinuxBios ..? or Adding these files to rom bios ?, if i add i'll have two bios code runing (first of the LinuxBios, and after of Bochs) is not there problems with it ?. Really is possible make work the Bochs Bios like a normal Bios ..?, they have code that only work with Bochs, like an outport to INFO_PORT ... Regards. Xavi. From mwilkinson at ndirect.co.uk Fri Feb 28 16:12:00 2003 From: mwilkinson at ndirect.co.uk (Mark Wilkinson) Date: Fri Feb 28 16:12:00 2003 Subject: flash_rom.c Message-ID: <200302282125.50005.mwilkinson@ndirect.co.uk> Hello I'm not sure who this should be addressed to, so appologies to the rest of the list. Briefly, I'm interested in running linuxBios on a via epia board, so I've gotten hold of a bios saviour ready to see how far I can get. After compiling up a rom image, and scanning the archives for how to burn the flash from linux, I compiled up the flash_rom program from the util directory. When running it with no image name (just so I could identify the flash chip of the bios saviour) I was greeted with a segmentation fault. To cut the story short, it seems that after scanning the pci bus in enable_flash_write() and not finding any of the devices in the enables (enable still set to 0) it still tries to call the 'doit' routine. I've included a patch that corrects the problem. Hope it's of use to someone. The second question I have (I think this is for Ron or Eric) is about the Config file under src/arch/i386/lib. I've notice that it has two copies of the 'object c_start.S' line. Is there a reason for this ? I've noticed that the NLBConfig.py script generates warnings about re-defining the object. Regards Mark Wilkinson --- orig/util/flash_and_burn/flash_rom.c Fri Feb 28 17:21:37 2003 +++ freebios/util/flash_rom.c Fri Feb 28 20:56:55 2003 @@ -291,7 +291,8 @@ } /* now do the deed. */ - enable->doit(dev, enable->name); + if ( enable ) + enable->doit(dev, enable->name); return 0; } From bari at onelabs.com Fri Feb 28 18:42:00 2003 From: bari at onelabs.com (Bari Ari) Date: Fri Feb 28 18:42:00 2003 Subject: LinuxBIOS Laptop Message-ID: <3E5FF995.6020606@onelabs.com> Here's a nice candidate to build a LinuxBIOS laptop. http://www.xbitlabs.com/news/story.html?id=1046444411 The site is currently /.ed but the specs are: ECS announced recently its DeskNote i-Buddie A980 mobile desktop PC, the first ever mobile barebone computer. It features no display, no CPU, no RAM and no HDD, but only the case with keyboard and touchpad. The indisputable trump of the novelty is that you are free to install the most high-end and cutting-edge hardware, or you may buy not really expensive components that are enough for your needs. Here is the list of i-Buddie A980 technical peculiarities: * Supports Socket 478 Pentium 4 / Celeron processors with 400/533MHz FSB with 3.06GHz clock-speed and above; * SiS650 chipset with SiS962 I/O controller; * 1 DIMM slot for up to 1GB of PC2100 or PC2700 DDR SDRAM memory. * Integrated graphics core, ability to install NVIDIA GeForce4 Go420 mobile graphics card. * 2-channel ATA-100/66/33 integrated controller; * Includes an 8x DVD-ROM drive; * Free bay for 2.5 HDD; * 4 USB 2.0 ports; * FireWire (IEEE1394) port ; * IR port with transfer rate up to 115.2Kbit/s; * 10/100Mbit/s Ethernet adapter and connector; * Integrated 56K modem; * 6-channel audio solution and built-in speakers; * Size: 342mm (W) x 300mm (D) x 34mm(min)/50.5mm(max); * Weight: 1.8Kg. End-users have a lot of opportunities to expand and configure such computers, they even now can choose between 14 and 15 TFT panel, what should allow ECS customers to get the most cost-effective solutions possible. According to this French web-site, such barebones will be priced at $300. Not expensive, I believe, but remember that you will need to get a display, a microprocessor, a memory module and a hard disk drive to make it functional. Bari