From smithbone at gmail.com Wed Feb 1 14:16:35 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 1 Feb 2006 07:16:35 -0600 Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver for Geode GX In-Reply-To: <1138744295.6032.9.camel@logarithm.lanl.gov> References: <43DF9C09.30806@arcom.com> <8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com> <1138734537.6032.1.camel@logarithm.lanl.gov> <8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com> <1138740595.6032.4.camel@logarithm.lanl.gov> <8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com> <1138744295.6032.9.camel@logarithm.lanl.gov> Message-ID: <8a0c36780602010516m28e7fd5fr6ef6a9bebb36ed50@mail.gmail.com> > The driver says portions were _derrived_ from the 2.4 driver. Its not > a straight port. > > I've asked the author to comment on what the differences are. Here's his response: === > Aside from being more recient whats the difference between your driver > and the 2.6.11 driver patch from AMD? There's only a driver for the Geode LX (or more correctly, our AMD FAE couldn't point me to a driver for the Geode GX). AMD's drivers tend to use their OS independant HAL (c.f. cimarron for the Geode LX driver and their use of the Durango API in their old 2.4 drivers for the Geode GX). As such, they're not suitable for inclusion into the kernel anyway. David Vrabel === -- Richard A. Smith From rminnich at lanl.gov Wed Feb 1 15:17:38 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 01 Feb 2006 07:17:38 -0700 Subject: [LinuxBIOS] Issue with VIA Epia MII In-Reply-To: <43E0AC0B.1010500@famille-simonnet.net> References: <43E0AC0B.1010500@famille-simonnet.net> Message-ID: <43E0C302.5000307@lanl.gov> I don'thave an MII. Comments anyone? Jean-Noel Simonnet wrote: > Ronald, > > I am having difficulties with the VIA Epia M 6000 and LinuxBIOS snapshot > 2158 dated 9 January 2006. > The board has just one IDE disk attached. > > Here are the POST codes I observe : > ... A few codes going fast > FE, stays here for 4 seconds while IDE disk is being spinned > 97 > 80 > 88 > FF > 00 Hangs here. At this point, the RUN LED of the POST card keeps > blinking very fast. > > NB : Board runs fine with the original BIOSes, as well as the ones I > downloaded from VIA Web site. > > Screen remains black, inactive all the time. > > I have followed the instructions in the EPIA-M HOWTO, in particular > capturing the ACPI dsdt and generating the file dsdt.c. > You will find below a copy of the dsdt -tc step which generated errors > and warnings. > dsdt was captured on original BIOS version 1.35 from VIA (Phoenix BIOS). > > I have also captured the video BIOS and added as indicated in the > documentation (video.rom.bin first). I am attaching my Config.lb and > Makefile > > Can you let me know if there is anything I can do to fix the issue ? > > Thanks for your help and best regards > > Jean-Noel Simonnet > > Flashing BIOS > -------------- > Did it with the Willem programmer, in fresh new chips, so that I could > safely play with LinuxBIOS > > Generating dsdt.c : > ----------------- > ns2:~/LinuxBIOS# iasl -d dsdt > > Intel ACPI Component Architecture > AML Disassembler version 20051216 [Jan 14 2006] > Copyright (C) 2000 - 2005 Intel Corporation > Supports ACPI Specification Revision 3.0 > > Loading Acpi table from file dsdt > Acpi table [DSDT] successfully installed and loaded > Pass 1 parse of [DSDT] > Pass 2 parse of [DSDT] > Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) > .................................................................................................................................................................................................................. > > Parsing completed > Disassembly completed, written to "dsdt.dsl" > ns2:~/LinuxBIOS# iasl -tc dsdt.dsl > > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20051216 [Jan 14 2006] > Copyright (C) 2000 - 2005 Intel Corporation > Supports ACPI Specification Revision 3.0 > > dsdt.dsl 359: Method (\_WAK, 1, NotSerialized) > Warning 2078 - ^ Reserved method must return a value > (_WAK) > > dsdt.dsl 403: Store (Local0, Local0) > Error 1048 - ^ Method local variable is not > initialized (Local0) > > dsdt.dsl 411: Store (Local0, Local0) > Error 1048 - ^ Method local variable is not > initialized (Local0) > > dsdt.dsl 1433: Method (STM, 0, Serialized) > Warning 2085 - ^ Not all control paths return > a value (STM_) > > dsdt.dsl 3102: Method (_STA, 0, NotSerialized) > Warning 2085 - ^ Not all control paths > return a value (_STA) > > dsdt.dsl 3102: Method (_STA, 0, NotSerialized) > Warning 2078 - ^ Reserved method must return > a value (_STA) > > ASL Input: dsdt.dsl - 3590 lines, 118620 bytes, 1427 keywords > Compilation complete. 2 Errors, 4 Warnings, 0 Remarks, 364 Optimizations > ns2:~/LinuxBIOS# > > > ------------------------------------------------------------------------ > > # Sample config file for EPIA-M > # This will make a target directory of ./epia-m > > target epia-m > > mainboard via/epia-m > > option MAXIMUM_CONSOLE_LOGLEVEL=8 > option DEFAULT_CONSOLE_LOGLEVEL=8 > option CONFIG_CONSOLE_SERIAL8250=1 > > option ROM_SIZE=256*1024 > option HAVE_OPTION_TABLE=1 > option CONFIG_ROM_STREAM=1 > option HAVE_FALLBACK_BOOT=1 > > ### > ### Compute the location and size of where this firmware image > ### (linuxBIOS plus bootloader) will live in the boot rom chip. > ### > option FALLBACK_SIZE=0x30000 > > ## LinuxBIOS C code runs at this location in RAM > option _RAMBASE=0x00004000 > > # > ### > ### Compute the start location and size size of > ### The linuxBIOS bootloader. > ### > > # > # EPIA-M > # > #romimage "normal" > # option USE_FALLBACK_IMAGE=0 > # option ROM_IMAGE_SIZE=0xc000 > # option ROM_SECTION_OFFSET=0x10000 > # option ROM_SECTION_SIZE=0x18000 > # option XIP_ROM_BASE=0xfffd0000 > # option LINUXBIOS_EXTRA_VERSION=".0Normal" > # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf > # payload ../../../../tg3--ide_disk.zelf > # payload ../../../../../lnxieepro100.ebi > # payload /filo.elf > #end > > romimage "fallback" > option USE_FALLBACK_IMAGE=1 > option ROM_IMAGE_SIZE=0x10000 > option ROM_SECTION_OFFSET=0x10000 > option ROM_SECTION_SIZE=0x30000 > # option XIP_ROM_BASE=0xfffe0000 > option LINUXBIOS_EXTRA_VERSION=".0Fallback" > # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf > # payload ../../../../tg3--ide_disk.zelf > # payload ../../../../../lnxieepro100.ebi > # payload ../../../../../filo.elf > payload /root/LinuxBIOS/filo.elf > end > > buildrom ./linuxbios.rom ROM_SIZE "fallback" > > > ------------------------------------------------------------------------ > > # File: via/epia-m/epia-m/Makefile is autogenerated > > all: ./linuxbios.rom > > include Makefile.settings > > fallback/linuxbios.rom: > if (cd fallback; \ > make linuxbios.rom)\ > then true; else exit 1; fi; > > clean: fallback-clean > > fallback-clean: > (cd fallback; make clean) > > ./linuxbios.rom: fallback/linuxbios.rom > cat /root/LinuxBIOS/video.bios.bin fallback/linuxbios.rom > ./linuxbios.rom > > .PHONY: all clean fallback-clean fallback/linuxbios.rom > > > > Makefile: /root/LinuxBIOS/LinuxBIOSv2/targets/via/epia-m/epia-m/config.py /root/LinuxBIOS/LinuxBIOSv2/targets/via/epia-m/Config.lb > (cd /root/LinuxBIOS/LinuxBIOSv2/targets ; via/epia-m/epia-m/config.py via/epia-m/Config.lb /root/LinuxBIOS/LinuxBIOSv2) > From Jeff.Young at gd-ais.com Wed Feb 1 16:10:46 2006 From: Jeff.Young at gd-ais.com (Young, Jeff S.) Date: Wed, 1 Feb 2006 09:10:46 -0600 Subject: [LinuxBIOS] emulator and S2895 board Message-ID: <0CA0904277689E458CC4130BDDFDF26706EA1D@MNBM01-MAIL01.ad.gd-ais.com> Howdy folks, I have gotten past my previous roadblocks and now the BIOS goes into The emulator and hangs. Can I bypass this somehow? Also, where are the patches for the 2.6 kernel so that I can get up into Kernel mode? Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Wed Feb 1 17:19:12 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 01 Feb 2006 09:19:12 -0700 Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver for Geode GX In-Reply-To: <8a0c36780602010516m28e7fd5fr6ef6a9bebb36ed50@mail.gmail.com> References: <43DF9C09.30806@arcom.com> <8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com> <1138734537.6032.1.camel@logarithm.lanl.gov> <8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com> <1138740595.6032.4.camel@logarithm.lanl.gov> <8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com> <1138744295.6032.9.camel@logarithm.lanl.gov> <8a0c36780602010516m28e7fd5fr6ef6a9bebb36ed50@mail.gmail.com> Message-ID: <1138810752.6032.29.camel@logarithm.lanl.gov> On Wed, 2006-02-01 at 07:16 -0600, Richard Smith wrote: > > The driver says portions were _derrived_ from the 2.4 driver. Its not > > a straight port. > > > > I've asked the author to comment on what the differences are. > > Here's his response: > > === > > Aside from being more recient whats the difference between your driver > > and the 2.6.11 driver patch from AMD? > > There's only a driver for the Geode LX (or more correctly, our AMD FAE > couldn't point me to a driver for the Geode GX). > We know that FAEs don't know much about linux ;-) From the README This product adds support for the AMD Geode(TM) GX processor and the AMD Geode(TM) CS5535 companion device to the Linux 2.6.11 kernel tree. > AMD's drivers tend to use their OS independant HAL (c.f. cimarron for > the Geode LX driver and their use of the Durango API in their old 2.4 > drivers for the Geode GX). As such, they're not suitable for inclusion > into the kernel anyway. > >From what I found in the patch. +#ifdef MODULE +MODULE_AUTHOR("AMD"); +MODULE_DESCRIPTION("Geode GX3 Cimarron graphics engine abstraction layer"); +MODULE_LICENSE("GPL"); +#endif Why can't i be include in the kernel? > David Vrabel > === > > -- > Richard A. Smith -- Li-Ta Lo Los Alamos National Lab From smithbone at gmail.com Wed Feb 1 18:15:25 2006 From: smithbone at gmail.com (Richard Smith) Date: Wed, 1 Feb 2006 12:15:25 -0500 Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver for Geode GX In-Reply-To: <1138810752.6032.29.camel@logarithm.lanl.gov> References: <43DF9C09.30806@arcom.com> <8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com> <1138734537.6032.1.camel@logarithm.lanl.gov> <8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com> <1138740595.6032.4.camel@logarithm.lanl.gov> <8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com> <1138744295.6032.9.camel@logarithm.lanl.gov> <8a0c36780602010516m28e7fd5fr6ef6a9bebb36ed50@mail.gmail.com> <1138810752.6032.29.camel@logarithm.lanl.gov> Message-ID: <8a0c36780602010915i585f5768rc8d08ba4e1cc99ce@mail.gmail.com> On 2/1/06, Li-Ta Lo wrote: > > AMD's drivers tend to use their OS independant HAL (c.f. cimarron for > > the Geode LX driver and their use of the Durango API in their old 2.4 > > drivers for the Geode GX). As such, they're not suitable for inclusion > > into the kernel anyway. > > > > >From what I found in the patch. > > +#ifdef MODULE > +MODULE_AUTHOR("AMD"); > +MODULE_DESCRIPTION("Geode GX3 Cimarron graphics engine abstraction > layer"); > +MODULE_LICENSE("GPL"); > +#endif > > Why can't i be include in the kernel? The module is only an abstraction layer. I suspect that the actual Cimarron engine may not be GPL. Even if it is I'm pretty sure there is no way the maintainers would add an additional HAL layer to the framebuffer code that is only for 1 device type. For mainline inclusion it needs to use the existing framework. You will have to contact the author for more details. -- Richard A. Smith From rminnich at lanl.gov Wed Feb 1 21:13:32 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 01 Feb 2006 13:13:32 -0700 Subject: [LinuxBIOS] [Fwd: Re: Issue with VIA Epia MII] Message-ID: <43E1166C.5050706@lanl.gov> epia M -------------- next part -------------- An embedded message was scrubbed... From: Jean-Noel Simonnet Subject: Re: Issue with VIA Epia MII Date: Wed, 01 Feb 2006 17:28:26 +0000 Size: 8520 URL: From talbotx at comcast.net Wed Feb 1 23:37:45 2006 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 01 Feb 2006 14:37:45 -0800 Subject: [LinuxBIOS] What geode board? Message-ID: <43E13839.2080404@comcast.net> What geode board are you working with? The GX2 board? Price? -Adam Talbot From rminnich at lanl.gov Wed Feb 1 23:37:45 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 01 Feb 2006 15:37:45 -0700 Subject: [LinuxBIOS] What geode board? In-Reply-To: <43E13839.2080404@comcast.net> References: <43E13839.2080404@comcast.net> Message-ID: <43E13839.4030807@lanl.gov> Adam Talbot wrote: > What geode board are you working with? The GX2 board? Price? we're working with the lippert fastrunner here. The GX2 is not without problems. They really rely heavily on SMI mode. I don't much like this. For example, Ollie just told me that PCI config accesses (cf8/cfc) are trapped into SMI mode and emulated. ron From talbotx at comcast.net Thu Feb 2 04:57:38 2006 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 01 Feb 2006 19:57:38 -0800 Subject: [LinuxBIOS] What geode board? In-Reply-To: <43E13839.4030807@lanl.gov> References: <43E13839.2080404@comcast.net> <43E13839.4030807@lanl.gov> Message-ID: <43E18332.5030306@comcast.net> How is it on boot time? How long does linuxbios take before it gets to the payload? -Adam Ronald G Minnich wrote: > Adam Talbot wrote: > >> What geode board are you working with? The GX2 board? Price? > > > we're working with the lippert fastrunner here. > > The GX2 is not without problems. They really rely heavily on SMI mode. > I don't much like this. For example, Ollie just told me that PCI > config accesses (cf8/cfc) are trapped into SMI mode and emulated. > > ron > > From ollie at lanl.gov Thu Feb 2 07:20:30 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 01 Feb 2006 23:20:30 -0700 Subject: [LinuxBIOS] What geode board? In-Reply-To: <43E18332.5030306@comcast.net> References: <43E13839.2080404@comcast.net> <43E13839.4030807@lanl.gov> <43E18332.5030306@comcast.net> Message-ID: <1138861232.5151.5.camel@logarithm.lanl.gov> On Wed, 2006-02-01 at 19:57 -0800, Adam Talbot wrote: > How is it on boot time? How long does linuxbios take before it gets to > the payload? > -Adam > Nobody has a working LinuxBIOS for GX2 yet. > Ronald G Minnich wrote: > > > Adam Talbot wrote: > > > >> What geode board are you working with? The GX2 board? Price? > > > > > > we're working with the lippert fastrunner here. > > > > The GX2 is not without problems. They really rely heavily on SMI mode. > > I don't much like this. For example, Ollie just told me that PCI > > config accesses (cf8/cfc) are trapped into SMI mode and emulated. > > > > ron > > > > > > -- Li-Ta Lo Los Alamos National Lab From talbotx at comcast.net Thu Feb 2 18:14:53 2006 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 02 Feb 2006 09:14:53 -0800 Subject: [LinuxBIOS] Good board for linux bios Message-ID: <43E23E0D.402@comcast.net> -Linuxbios In my normal hunting of e-bay I found a nice embedded board for a good price, I just bought one :-) I do not think Linuxbios will be hard to port on to this board. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=6845741668 -Adam From pada at chemonline.de Thu Feb 2 19:02:09 2006 From: pada at chemonline.de (Daniel Parthey) Date: Thu, 2 Feb 2006 19:02:09 +0100 Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic In-Reply-To: <20060130133200.GA11842@daniel.localdomain> References: <20060130133200.GA11842@daniel.localdomain> Message-ID: <20060202180209.GA8946@daniel.localdomain> Hello, Daniel Parthey wrote: > I tried to get LinuxBIOS Rev 2163 running on an VIA EPIA-ML6000EA Board > using the EPIA-M target. The kernel is on /dev/hda1 of an IDE harddisk. Note that I'm using an EPIA ML, not an M board. > it boots, network is working, but vga output fails Maybe the EPIA-M HOWTO should tell that one needs to extract the VGA BIOS from EPIA-M Bios Version 1.13 if one wants to use graphics on EPIA-ML. > DO THE VGA BIOS > found VGA: vid=1106, did=3122 > rom base, size: fffc0000 > write_protect_vgabios > bus/devfn = 0x100 > biosint: # 0x6, eax 0x5f53 ebx 0x101 ecx 0x19f88 edx 0xe093 > biosint: ebp 0x19090 esp 0x39d8 edi 0xfa90 esi 0x1a539 > biosint: ip 0xc763 cs 0xf000 flags 0x202 > biosint: Oops, exception 6 > biosint: Bailing out > biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0 > biosint: ebp 0x19fa8 esp 0xffa edi 0x0 esi 0xffff725e > biosint: ip 0x8f7e cs 0x0 flags 0x46 > BIOSINT: Unsupport int #0x10 > Devices initialized Christian S?hs told on the list, that one needs an older vga bios for that. First I will try to extract VGA Bios from BIOS 1.02 and 1.01 for the EPIA-ML. Then I will try the BIOS 1.16 for the EPIA-M. Unfortunately, VIA has taken all other versions off the web :( Can I boot the EPIA-M Bios on the EPIA-ML board, or does it fail? > ACPI: bus type pci registered > [...] > <0>Kernel panic - not syncing: Attempted to kill init! Disabling ACPI and AGPGART in the kernel fixed the problem, so this was certainly an ACPI issue. Thanks to Anton Borisov. Boot speeds is also an issue here, it looks like we need a separate target/mainboard for the EPIA-ML in order to speed up the boot process for EPIA-ML. It also boots very slowly here, I will try Christian S?hs' changes discussed on this list in December 2005 and disable some features (like smbus?) in the EPIA-ML boot process. Obviously, EPIA-M and EPIA-ML have different features, compare them: http://www.via.com.tw/en/products/mainboards/mini_itx/epia_m/index.jsp#spec http://www.via.com.tw/en/products/mainboards/mini_itx/epia_ml/index.jsp#spec Regards, Daniel. -- Chemnitzer LinuxTage 4. und 5. Maerz 2006 | Mobil D2 : +49-173-1701879 http://chemnitzer.linux-tage.de/ | Jabber : pada at jabber.ccc.de From gjohnson at lanl.gov Thu Feb 2 19:08:17 2006 From: gjohnson at lanl.gov (Greg Johnson) Date: Thu, 2 Feb 2006 11:08:17 -0700 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS Message-ID: <20060202180817.GX1534@durango.c3.lanl.gov> We have noticed some performance issues with the nvidia sata controller under LinuxBIOS. With FB it is faster. Using "hdparm -Tt /dev/sda" we measure 30 MB/s with LB and 45 MB/s with FB on a particular node. lspci reports 0000:01:08.0 IDE interface: nVidia Corporation: Unknown device 0055 (rev a3) (prog-if 85 [Master SecO PriO]) with LB and 0000:00:08.0 IDE interface: nVidia Corporation: Unknown device 0055 (rev f3) (prog-if 85 [Master SecO PriO]) with FB. Also "hdparm -I /dev/sda" reports R/W multiple sector transfer: Max = 16 Current = 16 with FB and R/W multiple sector transfer: Max = 16 Current = 0 with LB. Any ideas about how to improve the SATA performance under LB? Thanks, Greg From ward at gnu.org Thu Feb 2 19:25:48 2006 From: ward at gnu.org (Ward Vandewege) Date: Thu, 2 Feb 2006 13:25:48 -0500 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS In-Reply-To: <20060202180817.GX1534@durango.c3.lanl.gov> References: <20060202180817.GX1534@durango.c3.lanl.gov> Message-ID: <20060202182548.GA10305@io.pong.be> On Thu, Feb 02, 2006 at 11:08:17AM -0700, Greg Johnson wrote: > with LB. Any ideas about how to improve the SATA performance under LB? I'm afraid I don't have answers for you, but I do have a couple of questions :) Do you boot off SATA? If so, I assume you use Etherboot? Which version? Which version of LB are you running? I've yet to get LB stable on our Tyan s2891, running with the latest versions of LB/Etherboot... Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From chris at suehsi.de Thu Feb 2 19:59:55 2006 From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=) Date: Thu, 02 Feb 2006 19:59:55 +0100 Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic In-Reply-To: <20060202180209.GA8946@daniel.localdomain> References: <20060130133200.GA11842@daniel.localdomain> <20060202180209.GA8946@daniel.localdomain> Message-ID: <43E256AB.1000000@suehsi.de> Daniel Parthey schrieb: > Hello, > > Daniel Parthey wrote: > >>I tried to get LinuxBIOS Rev 2163 running on an VIA EPIA-ML6000EA Board >>using the EPIA-M target. The kernel is on /dev/hda1 of an IDE harddisk. > > Note that I'm using an EPIA ML, not an M board. > > >>it boots, network is working, but vga output fails > > Maybe the EPIA-M HOWTO should tell that one needs to extract the VGA BIOS > from EPIA-M Bios Version 1.13 if one wants to use graphics on EPIA-ML. Thats right, an extracted vga.rom from this version works for the ML, too. > > >>DO THE VGA BIOS >>found VGA: vid=1106, did=3122 if you later want to use the X via driver modul, you should remember on 3122 this is the ID Number you need to change in the vgabioa.c if I remember right. >>rom base, size: fffc0000 >>write_protect_vgabios >>bus/devfn = 0x100 >>biosint: # 0x6, eax 0x5f53 ebx 0x101 ecx 0x19f88 edx 0xe093 >>biosint: ebp 0x19090 esp 0x39d8 edi 0xfa90 esi 0x1a539 >>biosint: ip 0xc763 cs 0xf000 flags 0x202 >>biosint: Oops, exception 6 >>biosint: Bailing out >>biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0 >>biosint: ebp 0x19fa8 esp 0xffa edi 0x0 esi 0xffff725e >>biosint: ip 0x8f7e cs 0x0 flags 0x46 >>BIOSINT: Unsupport int #0x10 >>Devices initialized > I get a equal output, if I use the orginal vga.rom from factory bios version 1.16 for Epia-M > > Christian S?hs told on the list, that one needs an older vga bios for that. > First I will try to extract VGA Bios from BIOS 1.02 and 1.01 for the EPIA-ML. I,m not sure, but I think they won't work. Have a look at the bios code with cbrom or any tool you want. and compare the vga rom names. If I remember right there is only one version, which works with LB and that is the vga.rom at orginal bios from epia-M Version 1.13 for the Epia-ML. > Then I will try the BIOS 1.16 for the EPIA-M. That won't work, too. > Unfortunately, VIA has taken all other versions off the web :( > Thats right, somewhere in the List is a link to the 1.13 version. > Can I boot the EPIA-M Bios on the EPIA-ML board, or does it fail? > It fails. > >>ACPI: bus type pci registered >>[...] >> <0>Kernel panic - not syncing: Attempted to kill init! > > Disabling ACPI and AGPGART in the kernel fixed the problem, > so this was certainly an ACPI issue. Thanks to Anton Borisov. > > Boot speeds is also an issue here, it looks like we need a separate > target/mainboard for the EPIA-ML in order to speed up the boot > process for EPIA-ML. It also boots very slowly here, I will try > Christian S?hs' changes discussed on this list in December 2005 > and disable some features (like smbus?) in the EPIA-ML boot process. > > Obviously, EPIA-M and EPIA-ML have different features, compare them: > http://www.via.com.tw/en/products/mainboards/mini_itx/epia_m/index.jsp#spec You should disable the search for the firewire stuff, somewhere under the northbridge directory for epia-ml. If this is not disabled it tooks about 10 seconds before linuxbios boot. > http://www.via.com.tw/en/products/mainboards/mini_itx/epia_ml/index.jsp#spec > > Regards, > Daniel. From chris at suehsi.de Thu Feb 2 20:18:37 2006 From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=) Date: Thu, 02 Feb 2006 20:18:37 +0100 Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic In-Reply-To: <43E256AB.1000000@suehsi.de> References: <20060130133200.GA11842@daniel.localdomain> <20060202180209.GA8946@daniel.localdomain> <43E256AB.1000000@suehsi.de> Message-ID: <43E25B0D.5080001@suehsi.de> >> >>>DO THE VGA BIOS >>>found VGA: vid=1106, did=3122 > > > if you later want to use the X via driver modul, you should remember on > 3122 > this is the ID Number you need to change in the vgabioa.c if I remember > right. > > Sorry, it seems it is in mainboard.c in the write_protect_vgabios function. chris From gjohnson at lanl.gov Thu Feb 2 23:46:18 2006 From: gjohnson at lanl.gov (Greg Johnson) Date: Thu, 2 Feb 2006 15:46:18 -0700 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS Message-ID: <20060202224618.GZ1534@durango.c3.lanl.gov> > I'm afraid I don't have answers for you, but I do have a couple of > questions :) Do you boot off SATA? If so, I assume you use Etherboot? > Which version? Which version of LB are you running? Ward, I am booting with Etherboot v5.4.1. LinuxBIOS is from November sometime. I think this version is from Yh Lu. He helped with getting it to work. I just tried to build it from the current (r2169) svn, and it doesn't boot: LinuxBIOS-1.1.8_s2891_Normal Thu Feb 2 22:15:06 UTC 2006 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. core0: --- { APICID = 12 NODEID = 01 COREID = 00} --- SBLink=00 NC node|link=00 NC node|link=02 busn=40 ht reset - Greg From rminnich at lanl.gov Fri Feb 3 04:33:14 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Thu, 02 Feb 2006 20:33:14 -0700 Subject: [LinuxBIOS] What geode board? In-Reply-To: <43E18332.5030306@comcast.net> References: <43E13839.2080404@comcast.net> <43E13839.4030807@lanl.gov> <43E18332.5030306@comcast.net> Message-ID: <43E2CEFA.60000@lanl.gov> Adam Talbot wrote: > How is it on boot time? How long does linuxbios take before it gets to > the payload? we're not there yet. ron From ward at gnu.org Fri Feb 3 04:45:58 2006 From: ward at gnu.org (Ward Vandewege) Date: Thu, 2 Feb 2006 22:45:58 -0500 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS In-Reply-To: <20060202224618.GZ1534@durango.c3.lanl.gov> References: <20060202224618.GZ1534@durango.c3.lanl.gov> Message-ID: <20060203034558.GA11887@io.pong.be> Hi Greg, On Thu, Feb 02, 2006 at 03:46:18PM -0700, Greg Johnson wrote: > I am booting with Etherboot v5.4.1. OK, same here. > LinuxBIOS is from November > sometime. I think this version is from Yh Lu. He helped with getting > it to work. I just tried to build it from the current (r2169) svn, and > it doesn't boot: > > > LinuxBIOS-1.1.8_s2891_Normal Thu Feb 2 22:15:06 UTC 2006 starting... > (0,1) link=01 > (1,0) link=00 > 02 nodes initialized. > core0: --- { APICID = 12 NODEID = 01 COREID = 00} --- > SBLink=00 > NC node|link=00 > NC node|link=02 > busn=40 > ht reset - Yeah, that's what I'm seeing too - 10 to 30 seconds into the boot process. So I guess I'm not alone then. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From Jeff.Young at gd-ais.com Fri Feb 3 16:42:21 2006 From: Jeff.Young at gd-ais.com (Young, Jeff S.) Date: Fri, 3 Feb 2006 09:42:21 -0600 Subject: [LinuxBIOS] Linux Kernel Patches Message-ID: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> Howdy folks, I have gotten Linuxbios to run on my tyan s2895 board to the point that I am Reading the kernel image off of the hard drive. At this point, I crash. I would like to Know where are the Linux Kernel patches to apply to make this work correctly. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Fri Feb 3 16:52:04 2006 From: smithbone at gmail.com (Richard Smith) Date: Fri, 3 Feb 2006 10:52:04 -0500 Subject: [LinuxBIOS] Linux Kernel Patches In-Reply-To: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> References: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> Message-ID: <8a0c36780602030752n34d87a6dk807c635f085b147e@mail.gmail.com> > Howdy folks, > > I have gotten Linuxbios to run on my tyan s2895 board to the > point that I am > > Reading the kernel image off of the hard drive. At this point, I crash. I > would like to > > Know where are the Linux Kernel patches to apply to make this work > correctly. > Well it would help to know what kernel you are trying to load. *grin* What devices you have enabled. Perhaps the serial log of the boot, etc... There are not any "official" kernel patches as it all depends on what hardware you have and what you are trying to do. I don't use that hardware but in 99% of the cases the kernel crash is due to linuxbios not setting something up like the factory bios does. First you need to load a memtest payload and verify your RAM is working 100%. -- Richard A. Smith From stepan at openbios.org Fri Feb 3 16:59:42 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 3 Feb 2006 16:59:42 +0100 Subject: [LinuxBIOS] Linux Kernel Patches In-Reply-To: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> References: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> Message-ID: <20060203155942.GA21461@openbios.org> * Young, Jeff S. [060203 16:42]: > Howdy folks, > > I have gotten Linuxbios to run on my tyan s2895 board to the point > that I am > > Reading the kernel image off of the hard drive. At this point, I crash. I > would like to > > Know where are the Linux Kernel patches to apply to make this work correctly. There are no patched needed for LinuxBIOSv2. Where exactly does it crash? While reading the Linux kernel off the hard drive? Do you get a crash, or is there just no output from the kernel? Are you sure you enabled serial console in your kernel parameters and while compiling the kernel? Stefan From bios at matter.net Sat Feb 4 00:59:10 2006 From: bios at matter.net (Larry Matter) Date: Fri, 3 Feb 2006 15:59:10 -0800 (PST) Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic In-Reply-To: <43E256AB.1000000@suehsi.de> References: <20060130133200.GA11842@daniel.localdomain> <20060202180209.GA8946@daniel.localdomain> <43E256AB.1000000@suehsi.de> Message-ID: <20626.148.87.1.172.1139011150.squirrel@mail.matter.net> > Daniel Parthey schrieb: >> Hello, >> >> Daniel Parthey wrote: >> >>>I tried to get LinuxBIOS Rev 2163 running on an VIA EPIA-ML6000EA Board >>>using the EPIA-M target. The kernel is on /dev/hda1 of an IDE harddisk. >> >> Note that I'm using an EPIA ML, not an M board. >> >> >>>it boots, network is working, but vga output fails >> >> Maybe the EPIA-M HOWTO should tell that one needs to extract the VGA >> BIOS >> from EPIA-M Bios Version 1.13 if one wants to use graphics on EPIA-ML. > > Thats right, an extracted vga.rom from this version works for the ML, too. >> >> >>>DO THE VGA BIOS >>>found VGA: vid=1106, did=3122 > > if you later want to use the X via driver modul, you should remember on > 3122 > this is the ID Number you need to change in the vgabioa.c if I remember > right. > >>>rom base, size: fffc0000 >>>write_protect_vgabios >>>bus/devfn = 0x100 >>>biosint: # 0x6, eax 0x5f53 ebx 0x101 ecx 0x19f88 edx 0xe093 >>>biosint: ebp 0x19090 esp 0x39d8 edi 0xfa90 esi 0x1a539 >>>biosint: ip 0xc763 cs 0xf000 flags 0x202 >>>biosint: Oops, exception 6 >>>biosint: Bailing out >>>biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0 >>>biosint: ebp 0x19fa8 esp 0xffa edi 0x0 esi 0xffff725e >>>biosint: ip 0x8f7e cs 0x0 flags 0x46 >>>BIOSINT: Unsupport int #0x10 >>>Devices initialized >> > > I get a equal output, if I use the orginal vga.rom from factory bios > version 1.16 for Epia-M > >> >> Christian S?hs told on the list, that one needs an older vga bios for >> that. >> First I will try to extract VGA Bios from BIOS 1.02 and 1.01 for the >> EPIA-ML. > > I,m not sure, but I think they won't work. > Have a look at the bios code with cbrom or any tool you want. > and compare the vga rom names. If I remember right there is only one > version, which works with LB and that is the vga.rom at orginal bios > from epia-M Version 1.13 for the Epia-ML. > >> Then I will try the BIOS 1.16 for the EPIA-M. > > That won't work, too. > >> Unfortunately, VIA has taken all other versions off the web :( >> > Thats right, somewhere in the List is a link to the 1.13 version. > >> Can I boot the EPIA-M Bios on the EPIA-ML board, or does it fail? >> > It fails. > >> >>>ACPI: bus type pci registered >>>[...] >>> <0>Kernel panic - not syncing: Attempted to kill init! >> >> Disabling ACPI and AGPGART in the kernel fixed the problem, >> so this was certainly an ACPI issue. Thanks to Anton Borisov. >> >> Boot speeds is also an issue here, it looks like we need a separate >> target/mainboard for the EPIA-ML in order to speed up the boot >> process for EPIA-ML. It also boots very slowly here, I will try >> Christian S?hs' changes discussed on this list in December 2005 >> and disable some features (like smbus?) in the EPIA-ML boot process. >> >> Obviously, EPIA-M and EPIA-ML have different features, compare them: >> http://www.via.com.tw/en/products/mainboards/mini_itx/epia_m/index.jsp#spec > > You should disable the search for the firewire stuff, somewhere under > the northbridge directory for epia-ml. If this is not disabled it tooks > about 10 seconds before linuxbios boot. > >> http://www.via.com.tw/en/products/mainboards/mini_itx/epia_ml/index.jsp#spec >> >> Regards, >> Daniel. > > > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From bios at matter.net Sat Feb 4 01:02:11 2006 From: bios at matter.net (Larry Matter) Date: Fri, 3 Feb 2006 16:02:11 -0800 (PST) Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic In-Reply-To: <43E256AB.1000000@suehsi.de> References: <20060130133200.GA11842@daniel.localdomain> <20060202180209.GA8946@daniel.localdomain> <43E256AB.1000000@suehsi.de> Message-ID: <52539.148.87.1.172.1139011331.squirrel@mail.matter.net> >> Unfortunately, VIA has taken all other versions off the web :( >> > Thats right, somewhere in the List is a link to the 1.13 version. I couldn't find a posting with that information, but I did find this link on opendrivers.com (supposedly EPIA M Bios 1.13): http://download.opendrivers.com/drv/bios-and-system-update/via/i0100113.bin Hopefully it is what you need. Larry From yinghailu at gmail.com Sat Feb 4 03:04:08 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Feb 2006 10:04:08 +0800 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS In-Reply-To: <20060203034558.GA11887@io.pong.be> References: <20060202224618.GZ1534@durango.c3.lanl.gov> <20060203034558.GA11887@io.pong.be> Message-ID: <2ea3fae10602031804w75fd0a6cw5e60ca28d1fb1601@mail.gmail.com> I will revisit the s2891 support next week. Thanks Yinghai Lu On 2/3/06, Ward Vandewege wrote: > Hi Greg, > > On Thu, Feb 02, 2006 at 03:46:18PM -0700, Greg Johnson wrote: > > I am booting with Etherboot v5.4.1. > > OK, same here. > > > LinuxBIOS is from November > > sometime. I think this version is from Yh Lu. He helped with getting > > it to work. I just tried to build it from the current (r2169) svn, and > > it doesn't boot: > > > > > > LinuxBIOS-1.1.8_s2891_Normal Thu Feb 2 22:15:06 UTC 2006 starting... > > (0,1) link=01 > > (1,0) link=00 > > 02 nodes initialized. > > core0: --- { APICID = 12 NODEID = 01 COREID = 00} --- > > SBLink=00 > > NC node|link=00 > > NC node|link=02 > > busn=40 > > ht reset - > > Yeah, that's what I'm seeing too - 10 to 30 seconds into the boot process. So > I guess I'm not alone then. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From yinghailu at gmail.com Sat Feb 4 03:05:41 2006 From: yinghailu at gmail.com (yhlu) Date: Sat, 4 Feb 2006 10:05:41 +0800 Subject: [LinuxBIOS] Linux Kernel Patches In-Reply-To: <20060203155942.GA21461@openbios.org> References: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> <20060203155942.GA21461@openbios.org> Message-ID: <2ea3fae10602031805o4443051dl55f614d50086dcd4@mail.gmail.com> Jeff, After I get back, I will check that for you. You may use latest kernel.... YH From rminnich at lanl.gov Sat Feb 4 03:18:20 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Fri, 03 Feb 2006 19:18:20 -0700 Subject: [LinuxBIOS] Linux Kernel Patches In-Reply-To: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> References: <0CA0904277689E458CC4130BDDFDF26706EA21@MNBM01-MAIL01.ad.gd-ais.com> Message-ID: <43E40EEC.4020501@lanl.gov> Young, Jeff S. wrote: > > > Howdy folks, > > I have gotten Linuxbios to run on my tyan s2895 board to the > point that I am > > Reading the kernel image off of the hard drive. At this point, I > crash. I would like to > > Know where are the Linux Kernel patches to apply to make this work > correctly. > > > > Thanks, > > Jeff > > > There should not be any. Please send me serial console output if you can. thanks and sorry. ron From kfuchs at winternet.com Sat Feb 4 04:17:58 2006 From: kfuchs at winternet.com (Ken Fuchs) Date: Fri, 3 Feb 2006 21:17:58 -0600 (CST) Subject: [LinuxBIOS] Flash Programmer recommendation [Was: IWILL DK8-HTX] Message-ID: <200602040317.k143HwJm027617@tundra.winternet.com> phil wrote: > What hardware flash programmer would you suggest to get started? Enhanced Willem Universal Programmer There are several different versions. The most recent one was on eBay for as little as $40 or get it here: http://www.mcumall.com/comersus/store/comersus_dynamicindex.asp It's also mentioned several times in the LinuxBIOS Wiki FAQ. It supports a large number of chips, each chip type requires a different DIP switch setting (see blue device in picture of above URI). Sincerely, Ken Fuchs From rminnich at lanl.gov Sun Feb 5 06:50:07 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sat, 04 Feb 2006 22:50:07 -0700 Subject: [LinuxBIOS] issue tracker and doxygen working again Message-ID: <43E5920F.3090400@lanl.gov> ok, first, I took all the virus-laden isue tracker crap that the bad guys put in and resolved it as follows: resolved: people who do this type of thing are worthless pudknockers. I will try to start closing out issues again. Second, make documentation works again. This is pretty nice, you get web pages, a latex document, and man pages. Missing is the pass over all the include files, I'll try to wrap that up too. Note that for a given target, doxygen ONLY is run on the source files for that target. So the html, latex, and man pages are in a sense custome for that target. You can also browse the source, structs, etc.; this may help with comprehension (I sure hope so!) To test this, on, e.g. via/epia ./buildtarget via/epia cd via/epia/epia/fallback make documentation firefox html/index.html thanks ron From stuge-linuxbios at cdy.org Sun Feb 5 08:16:58 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 5 Feb 2006 08:16:58 +0100 Subject: [LinuxBIOS] issue tracker and doxygen working again In-Reply-To: <43E5920F.3090400@lanl.gov> References: <43E5920F.3090400@lanl.gov> Message-ID: <20060205071658.11927.qmail@cdy.org> On Sat, Feb 04, 2006 at 10:50:07PM -0700, Ronald G Minnich wrote: > Second, > make documentation > works again. This is pretty nice, you get web pages, Perhaps the autobuilder that tries to build all mainboards could build also all HTML docs and publish them somewhere? I think that would be a great resource. //Peter From rminnich at gmail.com Mon Feb 6 02:03:09 2006 From: rminnich at gmail.com (ron minnich) Date: Sun, 5 Feb 2006 17:03:09 -0800 Subject: [LinuxBIOS] issue tracker and doxygen working again In-Reply-To: <20060205071658.11927.qmail@cdy.org> References: <43E5920F.3090400@lanl.gov> <20060205071658.11927.qmail@cdy.org> Message-ID: <13426df10602051703u72dc3d80h1f30fcb83b4ce6e5@mail.gmail.com> > Perhaps the autobuilder that tries to build all mainboards could > build also all HTML docs and publish them somewhere? I think that > would be a great resource. > > > //Peter It would be very interesting to have, at linuxbios.org, the html trees for documentation of all mainboards. neat idea, what do you think stepan? ron From stepan at openbios.org Mon Feb 6 09:39:42 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Mon, 6 Feb 2006 09:39:42 +0100 Subject: [LinuxBIOS] issue tracker and doxygen working again In-Reply-To: <13426df10602051703u72dc3d80h1f30fcb83b4ce6e5@mail.gmail.com> References: <43E5920F.3090400@lanl.gov> <20060205071658.11927.qmail@cdy.org> <13426df10602051703u72dc3d80h1f30fcb83b4ce6e5@mail.gmail.com> Message-ID: <20060206083942.GA27214@openbios.org> * ron minnich [060206 02:03]: > > Perhaps the autobuilder that tries to build all mainboards could > > build also all HTML docs and publish them somewhere? I think that > > would be a great resource. > > > > > > //Peter > > It would be very interesting to have, at linuxbios.org, the html trees > for documentation of all mainboards. neat idea, what do you think > stepan? Definitely. I'll look at it. Stefan From talbotx at comcast.net Tue Feb 7 07:41:02 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 06 Feb 2006 22:41:02 -0800 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb Message-ID: <43E840FE.4050703@comcast.net> Fun easy question. Messing about with my new board, and have an easy question. So I have both the SST 39SF020 and the 39SF040 flash chip. My payload is just filo; so I can fit Linuxbios on the 256Kb or the 512Kb flash chip. Is there any reason to use the 512Kb? Faster, slower, any thing else like that? -Adam From stuge-linuxbios at cdy.org Tue Feb 7 08:26:04 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Tue, 7 Feb 2006 08:26:04 +0100 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E840FE.4050703@comcast.net> References: <43E840FE.4050703@comcast.net> Message-ID: <20060207072604.28682.qmail@cdy.org> On Mon, Feb 06, 2006 at 10:41:02PM -0800, Adam Talbot wrote: > Fun easy question. > Messing about with my new board, and have an easy question. So I have > both the SST 39SF020 and the 39SF040 flash chip. My payload is just > filo; so I can fit Linuxbios on the 256Kb or the 512Kb flash chip. Is > there any reason to use the 512Kb? > Faster, slower, any thing else like that? It depends on the second line of numbers on the package. SST 39SF0x0(A) is on the first line 45-4C-NH(E) or something similar is on the second line 45/70 is read access speed in ns 4 is minimum life in write cycles C is temperature range (Commercial 0c->70c or Industrial -40c->85c) N is PLCC H is 32 leads E is lead-free Page 20 of http://www.sst.com/downloads/datasheet/S71147.pdf But, I doubt you would even be able to measure difference in speed between 45 and 70 ns versions. :) //Peter From talbotx at comcast.net Tue Feb 7 08:51:31 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 06 Feb 2006 23:51:31 -0800 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <20060207072604.28682.qmail@cdy.org> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> Message-ID: <43E85183.2060300@comcast.net> -Peter Stuge Cool, that is great info to know. Both of my chips are 45-4C-NH. 45 Msec 4=10,000 write cycles (doc, thank you for the link) PLCC, 32 Is there any thing from the Linuxbios side of the world, besides the size config? Does Linuxbios load the whole chip into ram(so 256k or 512k), or just it's self on startup? Speed in ns: What controls that? Can I set/change the access speed to my "bios chip"? I have a few boards that had Eon chips(120ns), I have replaced them with SST's(45ns), they work fine. Are they running faster? On this current project all I care about is boot time and ever 0.10 seconds I can save, counts. -Adam Peter Stuge wrote: >On Mon, Feb 06, 2006 at 10:41:02PM -0800, Adam Talbot wrote: > > >>Fun easy question. >>Messing about with my new board, and have an easy question. So I have >>both the SST 39SF020 and the 39SF040 flash chip. My payload is just >>filo; so I can fit Linuxbios on the 256Kb or the 512Kb flash chip. Is >>there any reason to use the 512Kb? >>Faster, slower, any thing else like that? >> >> > >It depends on the second line of numbers on the package. > >SST 39SF0x0(A) is on the first line >45-4C-NH(E) or something similar is on the second line > >45/70 is read access speed in ns >4 is minimum life in write cycles >C is temperature range (Commercial 0c->70c or Industrial -40c->85c) >N is PLCC >H is 32 leads >E is lead-free > >Page 20 of http://www.sst.com/downloads/datasheet/S71147.pdf > > >But, I doubt you would even be able to measure difference in speed >between 45 and 70 ns versions. :) > > >//Peter > > > From smithbone at gmail.com Tue Feb 7 15:11:44 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 7 Feb 2006 08:11:44 -0600 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E85183.2060300@comcast.net> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> Message-ID: <8a0c36780602070611l123a6e85wd177a00f9681f0a8@mail.gmail.com> > Is there any thing from the Linuxbios side of the world, besides the > size config? Are you sure that your board has >=A18 routed to the chip for >=512k? If not then those address lines might be no connects and they will float. Meaning that they can change on a whim. If A18 changes you will switch from 0-256k area to the 256k-512k and unless you have duplicated the code into the area of the part things will go south. > Does Linuxbios load the whole chip into ram(so 256k or 512k), or just > it's self on startup? It only copies what it thinks it needs. > What controls that? Can I set/change the access speed to my "bios chip"? Maybe. > I have a few boards that had Eon chips(120ns), I have replaced them with > SST's(45ns), they work fine. Are they running faster? No. This completely depends on the chipset and where your part is located. If you part is fetched via ISA cycles then there's not a lot you can do. Some chipsets will let you vary some ISA settings and perhaps the number of wait states in the ISA cycle but normally that just lets you slow down and not go faster. If you can change the ISA clock then it _will_ go faster. The ISA clock probably comes from a source thats not variable or it may affect other things in the system. You will have to look at the chipset docs. I remember back in the good old AT "turbo" days that in turbo mode the ISA clock was sometimes increased. The coming of the vesa local bus and then the PCI bus took care of that though. If you bios is on the LPC bus then there might be some more flexability. I've not used the LPC bus much so I can't comment. The same rules will mostly apply. There will be a clock that drives the bus. Increase the clock you increase the bus speed. If there is a wait state > 0 setting it to 0 should increase the speed as well. Expect to hang your system a lot while playing with this. > On this current project all I care about is boot time and ever 0.10 > seconds I can save, counts. I suspect that you have more success on speedups by tweaking the linuxbios/linux kernel startup code than by trying to play with the bios access times. Sending a byte out the serial port at 115200 is approx 80 times slower than a ISA bios fetch. So you will have the most dramatic speed up by nuking anything that writes to the serial port. -- Richard A. Smith From smithbone at gmail.com Tue Feb 7 15:19:28 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 7 Feb 2006 08:19:28 -0600 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <8a0c36780602070611l123a6e85wd177a00f9681f0a8@mail.gmail.com> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> <8a0c36780602070611l123a6e85wd177a00f9681f0a8@mail.gmail.com> Message-ID: <8a0c36780602070619h35e190a4jc353271799693f5a@mail.gmail.com> > > If you can change the ISA clock then it _will_ go faster. The ISA > clock probably comes from a source thats not variable or it may affect > other things in the system. You will have to look at the chipset > docs. I remember back in the good old AT "turbo" days that in turbo > mode the ISA clock was sometimes increased. The coming of the vesa > local bus and then the PCI bus took care of that though. I should probally note that some of these settings will probably be set with pin "strappings" (stuff that is clocked into the chip when reset goes from active to inactive) Meaning that you have to change hardware to set them. In some cases you can play with the settings after-the-fact but your changes may be ignored. -- Richard A. Smith From bari at onelabs.com Tue Feb 7 15:35:26 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 07 Feb 2006 08:35:26 -0600 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E85183.2060300@comcast.net> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> Message-ID: <43E8B02E.5020606@onelabs.com> Adam Talbot wrote: > Speed in ns: > What controls that? Can I set/change the access speed to my "bios chip"? The timing of the Flash BIOS read and write cycles are hardwired into the chipset and clock synthesizer. At most there is a pinstrap (Pinstrap = A signal line on a chipset that is read only after RESET that is used to configure the chipset. The line is either tied to a High or Low via a resistor.) to chose the type of firmware interface, x8, x16, LPC or FWH. For an example, see page #3 of this schematic: http://www.amd.com/epd/desiging/evalboards/8.am186ccev/22002_1/22002_1.pdf > I have a few boards that had Eon chips(120ns), I have replaced them with > SST's(45ns), they work fine. Are they running faster? No. The chipset spec may just require a flash device of 120ns or less. Dropping in a faster flash device doesn't change the read access speed, since the speed is driven by the chipset. -Bari From talbotx at comcast.net Tue Feb 7 18:18:41 2006 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 07 Feb 2006 09:18:41 -0800 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E8B02E.5020606@onelabs.com> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> <43E8B02E.5020606@onelabs.com> Message-ID: <43E8D671.70701@comcast.net> Wow, that is allot of really good info. Thank you Ron, Peter and Bari. This all just sounds like over clocking the bios :-) So let me take the path of messing with Linuxbios code instead of messing with hardware access times that may or may not effect my system and will be almost impossible to tell. Ron stated: "Sending a byte out the serial port at 115200 is approx 80 times slower than a ISA bios fetch. So you will have the most dramatic speed up by nuking anything that writes to the serial port" So if I turn off any serial console, that is fixed? Does VGA bios have the same problem? -Aadm > Adam Talbot wrote: > >> Speed in ns: >> What controls that? Can I set/change the access speed to my "bios chip"? > > > The timing of the Flash BIOS read and write cycles are hardwired into > the chipset and clock synthesizer. At most there is a pinstrap > (Pinstrap = A signal line on a chipset that is read only after RESET > that is used to configure the chipset. The line is either tied to a > High or Low via a resistor.) to chose the type of firmware interface, > x8, x16, LPC or FWH. > > For an example, see page #3 of this schematic: > http://www.amd.com/epd/desiging/evalboards/8.am186ccev/22002_1/22002_1.pdf > > > >> I have a few boards that had Eon chips(120ns), I have replaced them >> with SST's(45ns), they work fine. Are they running faster? > > > No. The chipset spec may just require a flash device of 120ns or less. > Dropping in a faster flash device doesn't change the read access > speed, since the speed is driven by the chipset. > > -Bari > From rminnich at lanl.gov Tue Feb 7 18:18:16 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 07 Feb 2006 10:18:16 -0700 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E8D671.70701@comcast.net> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> <43E8B02E.5020606@onelabs.com> <43E8D671.70701@comcast.net> Message-ID: <43E8D658.20708@lanl.gov> Adam Talbot wrote: > "Sending a byte out the serial port at 115200 is approx 80 times slower > than a ISA bios fetch. So you will have the most dramatic speed up by > nuking anything that writes to the serial port" > > So if I turn off any serial console, that is fixed? Does VGA bios have > the same problem? vga bios is plenty fast. ron From smithbone at gmail.com Tue Feb 7 18:46:38 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 7 Feb 2006 11:46:38 -0600 Subject: [LinuxBIOS] Fun easy question. 512Kb or 256Kb In-Reply-To: <43E8D671.70701@comcast.net> References: <43E840FE.4050703@comcast.net> <20060207072604.28682.qmail@cdy.org> <43E85183.2060300@comcast.net> <43E8B02E.5020606@onelabs.com> <43E8D671.70701@comcast.net> Message-ID: <8a0c36780602070946r22bde320l4ee23ea52557f3b0@mail.gmail.com> On 2/7/06, Adam Talbot wrote: > So let me take the path of messing with Linuxbios code instead of > messing with hardware access times that may or may not effect my system > and will be almost impossible to tell. Good choice. *grin* > > Ron stated: Richard actually. But Ron has lots of good things to say as well. > "Sending a byte out the serial port at 115200 is approx 80 times slower > than a ISA bios fetch. So you will have the most dramatic speed up by > nuking anything that writes to the serial port" > > So if I turn off any serial console, that is fixed? Do you mean serial console in Linux kernel or the Linuxbios serial diagnostic output? Linuxbios serial output dosen't do much (if any) buffering so its at the bottom. Set you log level to 0 and you will go the fastest. Linux kernel serial console does slow down the kernel boot but since it does some buffering its not quite as slow. To a point. Once you fill up the console buffer it will block until room is ready as well. Just like linuxbios. > Does VGA bios have > the same problem? No the VGA device lives on the PCI (or AGP) bus so the IO is done at PCI speed which is very fast. Video writes in general are some what slow. So the less you do the faster you will go. -- Richard A. Smith From ward at gnu.org Tue Feb 7 21:47:56 2006 From: ward at gnu.org (Ward Vandewege) Date: Tue, 7 Feb 2006 15:47:56 -0500 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS In-Reply-To: <2ea3fae10602031804w75fd0a6cw5e60ca28d1fb1601@mail.gmail.com> References: <20060202224618.GZ1534@durango.c3.lanl.gov> <20060203034558.GA11887@io.pong.be> <2ea3fae10602031804w75fd0a6cw5e60ca28d1fb1601@mail.gmail.com> Message-ID: <20060207204756.GA21082@io.pong.be> Hi Yinghai, On Sat, Feb 04, 2006 at 10:04:08AM +0800, yhlu wrote: > I will revisit the s2891 support next week. Any progress yet? Thanks, Ward. > On 2/3/06, Ward Vandewege wrote: > > Hi Greg, > > > > On Thu, Feb 02, 2006 at 03:46:18PM -0700, Greg Johnson wrote: > > > I am booting with Etherboot v5.4.1. > > > > OK, same here. > > > > > LinuxBIOS is from November > > > sometime. I think this version is from Yh Lu. He helped with getting > > > it to work. I just tried to build it from the current (r2169) svn, and > > > it doesn't boot: > > > > > > > > > LinuxBIOS-1.1.8_s2891_Normal Thu Feb 2 22:15:06 UTC 2006 starting... > > > (0,1) link=01 > > > (1,0) link=00 > > > 02 nodes initialized. > > > core0: --- { APICID = 12 NODEID = 01 COREID = 00} --- > > > SBLink=00 > > > NC node|link=00 > > > NC node|link=02 > > > busn=40 > > > ht reset - > > > > Yeah, that's what I'm seeing too - 10 to 30 seconds into the boot process. So > > I guess I'm not alone then. -- Ward Vandewege Free Software Foundation - Senior System Administrator From yinghai.lu at amd.com Tue Feb 7 22:48:42 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 7 Feb 2006 13:48:42 -0800 Subject: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A08@ssvlexmb2.amd.com> Just got back. YH -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ward Vandewege Sent: Tuesday, February 07, 2006 12:48 PM To: yhlu Cc: Greg Johnson; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] Slow SATA on Tyan s2891 with LinuxBIOS Hi Yinghai, On Sat, Feb 04, 2006 at 10:04:08AM +0800, yhlu wrote: > I will revisit the s2891 support next week. Any progress yet? Thanks, Ward. > On 2/3/06, Ward Vandewege wrote: > > Hi Greg, > > > > On Thu, Feb 02, 2006 at 03:46:18PM -0700, Greg Johnson wrote: > > > I am booting with Etherboot v5.4.1. > > > > OK, same here. > > > > > LinuxBIOS is from November > > > sometime. I think this version is from Yh Lu. He helped with getting > > > it to work. I just tried to build it from the current (r2169) svn, and > > > it doesn't boot: > > > > > > > > > LinuxBIOS-1.1.8_s2891_Normal Thu Feb 2 22:15:06 UTC 2006 starting... > > > (0,1) link=01 > > > (1,0) link=00 > > > 02 nodes initialized. > > > core0: --- { APICID = 12 NODEID = 01 COREID = 00} --- > > > SBLink=00 > > > NC node|link=00 > > > NC node|link=02 > > > busn=40 > > > ht reset - > > > > Yeah, that's what I'm seeing too - 10 to 30 seconds into the boot process. So > > I guess I'm not alone then. -- Ward Vandewege Free Software Foundation - Senior System Administrator -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From miernik at ffii.org Tue Feb 7 23:39:23 2006 From: miernik at ffii.org (Miernik) Date: Tue, 7 Feb 2006 22:39:23 +0000 (UTC) Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? Message-ID: What is the transfer rate and latency of the interface between the CPU and the BIOS socket in motherboards like Via Epia or Tyan Opteron boards? What I am thinking to do is to put very fast SRAM there (it should work, shouldn't it?), battery backed up of course, and run the LinuxBIOS and kernel XiP eXecute in Place (without copying to RAM). Would that work? Imagine I could put 8 MB of fast SRAM there. Now, would that make sense, is the interface as fast as the FSB if I have a 200 MHz FSB for example? If I put some SRAM with random access time below 5 ns in there would it communicate with the CPU faster than DRAM in hte DIMM sockets is? Or at least as fast? With the intention of running it XiP. -- From rminnich at lanl.gov Tue Feb 7 23:42:21 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 07 Feb 2006 15:42:21 -0700 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: References: Message-ID: <43E9224D.4030606@lanl.gov> Miernik wrote: > What is the transfer rate and latency of the interface between the CPU > and the BIOS socket in motherboards like Via Epia or Tyan Opteron > boards? > > What I am thinking to do is to put very fast SRAM there (it should work, > shouldn't it?), battery backed up of course, and run the LinuxBIOS and > kernel XiP eXecute in Place (without copying to RAM). Would that work? > Imagine I could put 8 MB of fast SRAM there. won't help. The timing is set by chipset. faster part won't run faster. I wish it would. ron From miernik at ffii.org Wed Feb 8 00:39:46 2006 From: miernik at ffii.org (Miernik) Date: Wed, 8 Feb 2006 00:39:46 +0100 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: <43E9224D.4030606@lanl.gov> References: <43E9224D.4030606@lanl.gov> Message-ID: <20060207233945.GE16534@ffii.org> On Tue, Feb 07, 2006 at 03:42:21PM -0700, Ronald G Minnich wrote: > won't help. The timing is set by chipset. faster part won't run faster. And what is the timing for example chipsets? For VT8601, VT8623 for example? How much slower it is from the timing of RAM? Do some chipsets have it higher then others or is there some kind of common speed which everyone uses? Can't the chipset be "tweaked" to overclock that bus? -- From rminnich at lanl.gov Wed Feb 8 00:46:09 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 07 Feb 2006 16:46:09 -0700 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: <20060207233945.GE16534@ffii.org> References: <43E9224D.4030606@lanl.gov> <20060207233945.GE16534@ffii.org> Message-ID: <43E93141.4010606@lanl.gov> Miernik wrote: > And what is the timing for example chipsets? It really varies. There is no one constant. > For VT8601, VT8623 for example? These are north, flash is on south, so they are not the issue. Do some chipsets have it higher then others or is there some kind > of common speed which everyone uses? There is no common speed. If you have a slow socket, using a faster part won't hurt -- it just runs slow. ron From miernik at ffii.org Wed Feb 8 01:13:03 2006 From: miernik at ffii.org (Miernik) Date: Wed, 8 Feb 2006 00:13:03 +0000 (UTC) Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? References: <43E9224D.4030606@lanl.gov> <20060207233945.GE16534@ffii.org> <43E93141.4010606@lanl.gov> Message-ID: Ronald G Minnich wrote: > It really varies. There is no one constant. >> For VT8601, VT8623 for example? > These are north, flash is on south, so they are not the issue. The link between North and South, for example the Ultra V-Link in CN400 is 1066 MB/s anyway, so that's the higher limit. DDR400 runs 3200 MB/s so it'll be 3 times slower anyway, no matter what the Southbridge does, if the Northbridge is CN400. So for example what it is on VT8237 (the speed of connection to flash chip), does anyone have the datasheet? How is this parameter commonly called in datasheets, so I can google for it? What are the known southbridges with highest speed? -- From bari at onelabs.com Wed Feb 8 01:31:49 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 07 Feb 2006 18:31:49 -0600 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: References: <43E9224D.4030606@lanl.gov> <20060207233945.GE16534@ffii.org> <43E93141.4010606@lanl.gov> Message-ID: <43E93BF5.1080904@onelabs.com> Miernik wrote: > > So for example what it is on VT8237 (the speed of connection to flash > chip), does anyone have the datasheet? > > How is this parameter commonly called in datasheets, so I can google for > it? What are the known southbridges with highest speed? > The VT8237 supports LPC flash. The LPC clock is the same speed as the PCI clock, 33MHz. For more info take a look at the LPC spec: http://www.intel.com/design/chipsets/industry/lpc.htm -Bari From bari at onelabs.com Wed Feb 8 01:58:53 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 07 Feb 2006 18:58:53 -0600 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: References: Message-ID: <43E9424D.60406@onelabs.com> Miernik wrote: > What I am thinking to do is to put very fast SRAM there (it should work, > shouldn't it?), No, it won't work. SRAM and DRAM operate very differently and have entirely different interfaces. PC chipset memory controllers do not support SRAM. battery backed up of course, and run the LinuxBIOS and > kernel XiP eXecute in Place (without copying to RAM). Would that work? No. See answer above. > Imagine I could put 8 MB of fast SRAM there. > > Now, would that make sense, is the interface as fast as the FSB if I > have a 200 MHz FSB for example? > > If I put some SRAM with random access time below 5 ns in there would it > communicate with the CPU faster than DRAM in hte DIMM sockets is? Or at > least as fast? With the intention of running it XiP. The memory controllers drive the speed of the memory bus cycles. Maybe the confusion here is due to an assumption that all memory controllers and memory devices use SPD (or speed detection algorithims) to detect the memory device speeds. SPD is only used with memory modules, not with Flash or SRAM. Memory devices have timing specifications that guarantee that the memory device will have stable valid data ready to be read from it or that the memory device can write data sent to it AFTER a certain period has elapsed, after the access cycle has been initiated by the memory controller. -Bari From miernik at ffii.org Wed Feb 8 02:04:01 2006 From: miernik at ffii.org (Miernik) Date: Wed, 8 Feb 2006 01:04:01 +0000 (UTC) Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? References: <43E9224D.4030606@lanl.gov> <20060207233945.GE16534@ffii.org> <43E93141.4010606@lanl.gov> <43E93BF5.1080904@onelabs.com> Message-ID: Bari Ari wrote: > The VT8237 supports LPC flash. The LPC clock is the same speed as the > PCI clock, 33MHz. > > For more info take a look at the LPC spec: > http://www.intel.com/design/chipsets/industry/lpc.htm 33 MHz, 4 bit wide, that gives 16 MB/s theoretical maximum. Not really impressive compared to 1066 MB/s N-S link. 64 times slower. And 192 times slower than DDR400 RAM. Am I right? XiP would be terribly slow :( -- From miernik at ffii.org Wed Feb 8 02:11:41 2006 From: miernik at ffii.org (Miernik) Date: Wed, 8 Feb 2006 01:11:41 +0000 (UTC) Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? References: <43E9424D.60406@onelabs.com> Message-ID: Bari Ari wrote: > >> What I am thinking to do is to put very fast SRAM there (it should work, >> shouldn't it?), > > No, it won't work. SRAM and DRAM operate very differently and have > entirely different interfaces. PC chipset memory controllers do not > support SRAM. I think you misunderstood me. I didn't intend to put SRAM in the DRAM sockets, but in the BIOS chip NOR flash socket. Isn't NOR flash read the same way as SRAM (write is different of course, but I don't care about writes here)? Would that work? -- From bari at onelabs.com Wed Feb 8 04:21:13 2006 From: bari at onelabs.com (Bari Ari) Date: Tue, 07 Feb 2006 21:21:13 -0600 Subject: [LinuxBIOS] what is the fastest speed of BIOS socket? In-Reply-To: References: <43E9224D.4030606@lanl.gov> <20060207233945.GE16534@ffii.org> <43E93141.4010606@lanl.gov> <43E93BF5.1080904@onelabs.com> Message-ID: <43E963A9.9090106@onelabs.com> Miernik wrote: > Bari Ari wrote: > >>The VT8237 supports LPC flash. The LPC clock is the same speed as the >>PCI clock, 33MHz. >> >>For more info take a look at the LPC spec: >>http://www.intel.com/design/chipsets/industry/lpc.htm > > > 33 MHz, 4 bit wide, that gives 16 MB/s theoretical maximum. Not really > impressive compared to 1066 MB/s N-S link. 64 times slower. And 192 > times slower than DDR400 RAM. Am I right? XiP would be terribly slow :( > Yes, slow. > I think you misunderstood me. I didn't intend to put SRAM in the DRAM > sockets, but in the BIOS chip NOR flash socket. Isn't NOR flash read the > same way as SRAM (write is different of course, but I don't care about > writes here)? > > Would that work? Even if you had SRAM with matching packages and pinouts to replace the Flash, the read access times would be the same. The chipset sets the speed of LPC, ISA or FWH interface. -Bari From aissaoui_hacen at yahoo.fr Sat Feb 11 11:32:20 2006 From: aissaoui_hacen at yahoo.fr (Hacen Aissaoui) Date: Sat, 11 Feb 2006 11:32:20 +0100 Subject: [LinuxBIOS] I'm back In-Reply-To: <43CD196A.8030108@lanl.gov> References: <43CD196A.8030108@lanl.gov> Message-ID: <43EDBD34.4090103@yahoo.fr> Hello Ron, Sorry to disturb but could you explain where we stand now concerning the VIA EPIA 800 ? I saw a lot of expert discussions about VIA EPIA but I must admit I could not understand what it was about. Is there any blocking issue at the moment ? How could anyone help ? Thanks for all your work ! Hacen Ronald G Minnich wrote: > I am going to start trying to catch up our svn info. > > Will those of you have a mobo working, please send me: > the mobo name > the xvn revision > > so I can fill out the table. > > ron > > ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger. Appelez le monde entier ? partir de 0,012 ?/minute ! T?l?chargez sur http://fr.messenger.yahoo.com From rminnich at lanl.gov Sat Feb 11 16:54:27 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sat, 11 Feb 2006 08:54:27 -0700 Subject: [LinuxBIOS] I'm back In-Reply-To: <43EDBD34.4090103@yahoo.fr> References: <43CD196A.8030108@lanl.gov> <43EDBD34.4090103@yahoo.fr> Message-ID: <43EE08B3.9020600@lanl.gov> Hacen Aissaoui wrote: > Hello Ron, > > Sorry to disturb but could you explain where we stand now concerning the > VIA EPIA 800 ? it does not work at present, AFAIK. comes all the way up, but ethernet will not work. It can't receive packets. They seem to be getting corrupted. ron From zoxed_c at arcor.de Sat Feb 11 17:54:32 2006 From: zoxed_c at arcor.de (Simon Kellett) Date: Sat, 11 Feb 2006 17:54:32 +0100 Subject: [LinuxBIOS] Gigabyte GA-8I848P-G support ? Message-ID: Hi, I am interested in this project as a home user who does leave his computer running, and would like a fast startup time !! (And a nicer splash then the BIOS screen would be nice to !!). From talbotx at comcast.net Sun Feb 12 23:42:50 2006 From: talbotx at comcast.net (Adam Talbot) Date: Sun, 12 Feb 2006 14:42:50 -0800 Subject: [LinuxBIOS] resizing a stock bios Message-ID: <43EFB9EA.40209@comcast.net> How do I resize a stock bios? The current rom is 512kb and so is the flash chip. I have a smaller flash chip that I would like to use to free up the big chip. This means i need to make a 512kb rom file fit on a 256kb rom :-). Is this even possible? -Adam From aissaoui_hacen at yahoo.fr Mon Feb 13 14:31:06 2006 From: aissaoui_hacen at yahoo.fr (Hacen Aissaoui) Date: Mon, 13 Feb 2006 14:31:06 +0100 Subject: [LinuxBIOS] resizing a stock bios In-Reply-To: <43EFB9EA.40209@comcast.net> References: <43EFB9EA.40209@comcast.net> Message-ID: <43F08A1A.6070605@yahoo.fr> Have you tried the classical CBROM tool ? Here is a link to small tutorial about it : http://www.blackfiveservices.co.uk/awbmtools.shtml Hacen Adam Talbot wrote: > How do I resize a stock bios? > The current rom is 512kb and so is the flash chip. I have a smaller > flash chip that I would like to use to free up the big chip. This means > i need to make a 512kb rom file fit on a 256kb rom :-). Is this even > possible? > -Adam > > ___________________________________________________________________________ Nouveau : t?l?phonez moins cher avec Yahoo! Messenger. Appelez le monde entier ? partir de 0,012 ?/minute ! T?l?chargez sur http://fr.messenger.yahoo.com From bari at onelabs.com Mon Feb 13 18:19:52 2006 From: bari at onelabs.com (Bari Ari) Date: Mon, 13 Feb 2006 11:19:52 -0600 Subject: [LinuxBIOS] resizing a stock bios In-Reply-To: <43EFB9EA.40209@comcast.net> References: <43EFB9EA.40209@comcast.net> Message-ID: <43F0BFB8.2030601@onelabs.com> Adam Talbot wrote: > How do I resize a stock bios? > The current rom is 512kb and so is the flash chip. I have a smaller > flash chip that I would like to use to free up the big chip. This means > i need to make a 512kb rom file fit on a 256kb rom :-). Is this even > possible? I highly doubt you'll be able to cut it down to half its size. Take a look at this pdf, Award BIOS Code Injection: http://www.codebreakers-journal.com/index.php/CodeBreakersMagazine/article/view/2/2 It has a pretty good breakdown of a popular stock BIOS and the tools to modify it without going the NDA route. Goggle for info on Cbrom and AwardMod. Also look at AWBM2TIFF and TIFF2AWBM to convert the BIOS splash images. -Bari From gjohnson at lanl.gov Mon Feb 13 19:32:45 2006 From: gjohnson at lanl.gov (Greg Johnson) Date: Mon, 13 Feb 2006 11:32:45 -0700 Subject: [LinuxBIOS] LinuxBIOS on Tyan s2891? Message-ID: <20060213183245.GA19253@durango.c3.lanl.gov> YH, Any news? Thanks, Greg From bari at onelabs.com Mon Feb 13 22:09:05 2006 From: bari at onelabs.com (Bari Ari) Date: Mon, 13 Feb 2006 15:09:05 -0600 Subject: [LinuxBIOS] Tutorial about Bios In-Reply-To: <003a01c630cc$8bc7da30$0b00a8c0@iris> References: <43EFB9EA.40209@comcast.net> <43F0BFB8.2030601@onelabs.com> <003a01c630cc$8bc7da30$0b00a8c0@iris> Message-ID: <43F0F571.5060106@onelabs.com> Paulo da Silva wrote: > Hi guys, > > I joined to this forum to learn about bios. > > I have a project with cpu x86 compatible, and the development kit I have > use redboot to start linux, and I want to put a bios,so I want > documentation about bios to understand how it works. > > Links to docs will be welcome. > > thanks in advance. > > Paulo Ask LinuxBIOS questions here: linuxbios at openbios.org LinuxBIOS doc's are found at: http://www.linuxbios.org/index.php/Documentation As far as documentation for a standard BIOS, try Google for sites like http://www.wimsbios.com/ -Bari From psilva at opensoftware-br.com Mon Feb 13 23:25:17 2006 From: psilva at opensoftware-br.com (Paulo da Silva) Date: Mon, 13 Feb 2006 19:25:17 -0300 Subject: [LinuxBIOS] Tutorial about Bios Message-ID: <008f01c630ec$5e870580$0b00a8c0@iris> Thank you for your answer Bari, and sorry me about my email to your pvt email, I did a mistake. /PSilva -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogelio.serrano at gmail.com Tue Feb 14 02:18:27 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Tue, 14 Feb 2006 09:18:27 +0800 Subject: [LinuxBIOS] linuxbios ecs kt600 Message-ID: I wonder if linuxbios can be made to work on my motherboard. Even without the datasheet. lspci -vvv: 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge (rev 80) Subsystem: Elitegroup Computer Systems Unknown device 1884 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0a.0 SCSI storage controller: Adaptec AIC-7861 (rev 03) Subsystem: Adaptec AHA-2940AU Single Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- From rogelio.serrano at gmail.com Tue Feb 14 02:58:41 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Tue, 14 Feb 2006 09:58:41 +0800 Subject: [LinuxBIOS] linuxbios ecs kt600 In-Reply-To: References: Message-ID: On 2/14/06, Rogelio Serrano wrote: > > I wonder if linuxbios can be made to work on my motherboard. Even without > the datasheet. > > Maybe i should get an intel board instead. -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From talbotx at comcast.net Tue Feb 14 05:57:48 2006 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 13 Feb 2006 20:57:48 -0800 Subject: [LinuxBIOS] where to go to buy new bios chips Message-ID: <43F1634C.1010104@comcast.net> Where would i go to by new bios chips? like: SST39SF040, SST39SF020? -Adam From rminnich at lanl.gov Tue Feb 14 06:10:20 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Mon, 13 Feb 2006 22:10:20 -0700 Subject: [LinuxBIOS] where to go to buy new bios chips In-Reply-To: <43F1634C.1010104@comcast.net> References: <43F1634C.1010104@comcast.net> Message-ID: <43F1663C.2010007@lanl.gov> Adam Talbot wrote: > Where would i go to by new bios chips? > like: > SST39SF040, SST39SF020? > -Adam > For small parts count and non-corporate buys, maybe digikey? For quantity buys, in the past, we have used avnet. ron From bari at onelabs.com Tue Feb 14 06:38:58 2006 From: bari at onelabs.com (Bari Ari) Date: Mon, 13 Feb 2006 23:38:58 -0600 Subject: [LinuxBIOS] where to go to buy new bios chips In-Reply-To: <43F1634C.1010104@comcast.net> References: <43F1634C.1010104@comcast.net> Message-ID: <43F16CF2.1020503@onelabs.com> Adam Talbot wrote: > Where would i go to by new bios chips? > like: > SST39SF040, SST39SF020? Look here: http://www.sst.com/sales/distributors.xhtml -Bari From BJ.Kowalski at gd-ais.com Wed Feb 15 19:22:59 2006 From: BJ.Kowalski at gd-ais.com (Kowalski, Bobby Jim) Date: Wed, 15 Feb 2006 12:22:59 -0600 Subject: [LinuxBIOS] Tyan S2895 and nVidia GeForce 6200 Message-ID: I have a Tyan S2895 motherboard with an nVidia GeForce 6200 TurboCache addon card (nVidia NX6200TC-TD64EB). I seem to be having problems that appear, at this point, to be related to the executing the Option ROM code using the X86 emulator code. When LinuxBIOS (v2-2174) executes it detects the addon card and reports it as PCI device 03:00.0 (last PCI device in system - motherboard slot 1 PCI-E x16). This card has an Expansion ROM (a.k.a. Option ROM) and it is detected by LinuxBIOS. I have verified that the function pci_rom_load() correctly copies the image from the ROM to memory at 0xc0000 (copies 0xf600 bytes). I have also verified that 0xc0000 is empty (contains all 0x00) prior to the copy occuring. After the Expansion ROM is loaded into RAM the function run_bios() is called. In that function there is a printk_debug("entering emulator") just before the call to X86EMU_exec(). I have noticed that the first "e" of the message appears on the screen and is followed by the remainder of the message, character at a time, after much delay (seconds) between characters. Once the call to X86EMU_exec() is made the system never completes the boot process as I do not see any of the messages such as: Devices initialized Writing IRQ routing tables .... Wrote the mp table ... Moving GDT to 0x500 ..... I also do not see the POST code of 0x89 (out of hardwaremain() after dev_initialize() completes. I would be interested in hearing if anyone has successsfully used this card on a Tyan S2895 with LinuxBIOS or on any other motherboard with LinuxBIOS. Booting the standard Tyan BIOS (PhoenixBIOS 1.01.2895) and running SuSE 10.0 it works fine. I would also be interested in hearing which addon VGA cards have been used successfully (lately) on the S2895 as the S2895 does not have a VGA capability on the motherboard. Thanks BJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Thu Feb 16 18:27:19 2006 From: yinghailu at gmail.com (yhlu) Date: Thu, 16 Feb 2006 09:27:19 -0800 Subject: [LinuxBIOS] serverworks HT1000/HT2000 (bcm5785/5780) support Message-ID: <2ea3fae10602160927j56401444q3405fe0b9a9c1c1@mail.gmail.com> Please check the r2176 for chipset support and ref board (BLAST) support from serverworks (broadcom) YH From rogelio.serrano at gmail.com Fri Feb 17 15:18:50 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Fri, 17 Feb 2006 22:18:50 +0800 Subject: [LinuxBIOS] using bigger bios chip Message-ID: is it possible to just replace my bios chip with a bigger one? -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Fri Feb 17 16:47:28 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 17 Feb 2006 16:47:28 +0100 Subject: [LinuxBIOS] using bigger bios chip In-Reply-To: References: Message-ID: <20060217154728.GA12726@openbios.org> * Rogelio Serrano [060217 15:18]: > > is it possible to just replace my bios chip with a bigger one? possibly. This depends on the motherboard and flashchip you are using. Most likely, yes. But it has to be a compatible one. Stefan From rogelio.serrano at gmail.com Tue Feb 21 18:02:02 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Wed, 22 Feb 2006 01:02:02 +0800 Subject: [LinuxBIOS] disassembly of bios code Message-ID: Im trying to make linuxbios work on a kt600 mb by trying to understand how the bios initializes the board during bootup. Any tips? -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Tue Feb 21 18:12:43 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Tue, 21 Feb 2006 18:12:43 +0100 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: Message-ID: <20060221171243.GA23326@openbios.org> * Rogelio Serrano [060221 18:02]: > Im trying to make linuxbios work on a kt600 mb by trying to understand how the > bios initializes the board during bootup. Any tips? Go to http://www.via.com.tw/en/support/datasheets/ and tell them you need the KT600 datasheets. Stefan From jardel at lesc.ufc.br Tue Feb 21 18:19:55 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Tue, 21 Feb 2006 14:19:55 -0300 Subject: [LinuxBIOS] RES: disassembly of bios code In-Reply-To: Message-ID: Dear Mr. Serrano, I suggest you the articles by Darmawan Mappatutu. http://www.geocities.com/mamanzip/ Thanks. Jardel. Development Engineer. Federal University of Ceara - LESC ________________________________________ De: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] Em nome de Rogelio Serrano Enviada em: ter?a-feira, 21 de fevereiro de 2006 14:02 Para: linuxbios at linuxbios.org Assunto: [LinuxBIOS] disassembly of bios code Im trying to make linuxbios work on a kt600 mb by trying to understand how the bios initializes the board during bootup. Any tips? -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers From rogelio.serrano at gmail.com Tue Feb 21 18:32:00 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Wed, 22 Feb 2006 01:32:00 +0800 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <20060221171243.GA23326@openbios.org> References: <20060221171243.GA23326@openbios.org> Message-ID: On 2/22/06, Stefan Reinauer wrote: > > * Rogelio Serrano [060221 18:02]: > > Im trying to make linuxbios work on a kt600 mb by trying to understand > how the > > bios initializes the board during bootup. Any tips? > > Go to http://www.via.com.tw/en/support/datasheets/ and tell them you > need the KT600 datasheets. > > Stefan > > I just filed a request. -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Tue Feb 21 19:01:17 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 21 Feb 2006 11:01:17 -0700 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: Message-ID: <43FB556D.3000801@lanl.gov> Rogelio Serrano wrote: > Im trying to make linuxbios work on a kt600 mb by trying to understand > how the bios initializes the board during bootup. Any tips? > one tip: I don't want any code that you can't document back to the chipset documents you have. In particular, I don't want anything that comes from disassembled bios code. We're worked very hard, and succeeded, at keeping the linuxbios code base clean; I want to keep it that way. ron From immani at gmail.com Tue Feb 21 19:32:19 2006 From: immani at gmail.com (Ven Immani) Date: Tue, 21 Feb 2006 10:32:19 -0800 Subject: [LinuxBIOS] Linux BIOS with Mellanox InfiniBand Message-ID: <43FB5CB3.5020106@gmail.com> Hi Has anyone been successful getting Mellanox InfiniBand adapter to work with Linux BIOS ? If yes, can you please share the motherboard type and any IB related specifics .. If no, is there anyone working on this .. what are the challenges currently involved .. Thanks in Advance, - Ven Immani From yinghai.lu at amd.com Tue Feb 21 19:40:58 2006 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 21 Feb 2006 10:40:58 -0800 Subject: [LinuxBIOS] Linux BIOS with Mellanox InfiniBand Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094A4A@ssvlexmb2.amd.com> Pci-e work with Tyan s2891, s2895 + LinuxBIOS. Pci-x would be more. From Tyan s2880... YH From petekarl at student.chalmers.se Tue Feb 21 19:47:02 2006 From: petekarl at student.chalmers.se (Peter Karlsson) Date: Tue, 21 Feb 2006 19:47:02 +0100 (CET) Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <43FB556D.3000801@lanl.gov> References: <43FB556D.3000801@lanl.gov> Message-ID: On Tue, 21 Feb 2006, Ronald G Minnich wrote: > one tip: I don't want any code that you can't document back to the > chipset documents you have. In particular, I don't want anything that > comes from disassembled bios code. We're worked very hard, and > succeeded, at keeping the linuxbios code base clean; I want to keep it > that way. But what about reverse-engineering the chips (in whatever way) and documenting it, and then contributing this documentation instead of code (a.k.a. clean-room engineering)? Best regards Peter K From talbotx at comcast.net Tue Feb 21 20:26:43 2006 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 21 Feb 2006 11:26:43 -0800 Subject: [LinuxBIOS] This should be an easy error... Message-ID: <43FB6973.30008@comcast.net> I am really stuck on this one. "XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE" Working on the epia-m with linuxbios rev 2100. I have set XIP_ROM_SIZE=0x20000 in my config.ld and keep getting that error. So I change the size and get a not divisible by 2 error. With out the option I get the same error... Any ideas? -Adam "XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE" make[1]: *** [auto.inc] Error 1 make[1]: Leaving directory `/root/LinuxBIOSv2-2100/targets/via/epia-m/epia-m/normal' make: *** [normal/linuxbios.rom] Error 1 From rminnich at lanl.gov Tue Feb 21 20:33:10 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 21 Feb 2006 12:33:10 -0700 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: <43FB556D.3000801@lanl.gov> Message-ID: <43FB6AF6.6030209@lanl.gov> Peter Karlsson wrote: > But what about reverse-engineering the chips (in whatever way) and > documenting it, and then contributing this documentation instead of code > (a.k.a. clean-room engineering)? > I'll let someone else handle that question. I only can say that I much prefer to work with companies that wish to help with linuxbios (such as AMD). If you have the possibility of collaboration with a company, that is preferable to having to reverse engineer. thanks ron From talbotx at comcast.net Tue Feb 21 23:13:44 2006 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 21 Feb 2006 14:13:44 -0800 Subject: [LinuxBIOS] Status of the epia-m Message-ID: <43FB9098.8040406@comcast.net> Is the current epia-m code running? -Adam From rogelio.serrano at gmail.com Wed Feb 22 02:30:51 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Wed, 22 Feb 2006 09:30:51 +0800 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <43FB556D.3000801@lanl.gov> References: <43FB556D.3000801@lanl.gov> Message-ID: On 2/22/06, Ronald G Minnich wrote: > > Rogelio Serrano wrote: > > Im trying to make linuxbios work on a kt600 mb by trying to understand > > how the bios initializes the board during bootup. Any tips? > > > > > one tip: I don't want any code that you can't document back to the > chipset documents you have. In particular, I don't want anything that > comes from disassembled bios code. We're worked very hard, and > succeeded, at keeping the linuxbios code base clean; I want to keep it > that way. > > ron > I understand. I will most likely get an intel board instead. -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogelio.serrano at gmail.com Wed Feb 22 04:48:59 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Wed, 22 Feb 2006 11:48:59 +0800 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <43FB6AF6.6030209@lanl.gov> References: <43FB556D.3000801@lanl.gov> <43FB6AF6.6030209@lanl.gov> Message-ID: On 2/22/06, Ronald G Minnich wrote: > > Peter Karlsson wrote: > > > But what about reverse-engineering the chips (in whatever way) and > > documenting it, and then contributing this documentation instead of code > > (a.k.a. clean-room engineering)? > > > > > I'll let someone else handle that question. I only can say that I much > prefer to work with companies that wish to help with linuxbios (such as > AMD). If you have the possibility of collaboration with a company, that > is preferable to having to reverse engineer. > > thanks > > ron > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > who alse has an NDA with via? Is it possible for individual nda holders to collaborate? Maybe with enough ports to via chipsets we can convince them to use it? -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Wed Feb 22 04:51:56 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 21 Feb 2006 20:51:56 -0700 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: <43FB556D.3000801@lanl.gov> Message-ID: <43FBDFDC.4030602@lanl.gov> Rogelio Serrano wrote: > I understand. I will most likely get an intel board instead. > > I would not recommend Intel either. They are not supportive of LinuxBIOS; quite the contrary. thanks ron From rminnich at lanl.gov Wed Feb 22 04:52:37 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 21 Feb 2006 20:52:37 -0700 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: <43FB556D.3000801@lanl.gov> <43FB6AF6.6030209@lanl.gov> Message-ID: <43FBE005.7030805@lanl.gov> Rogelio Serrano wrote: > who alse has an NDA with via? Is it possible for individual nda holders > to collaborate? Maybe with enough ports to via chipsets we can convince > them to use it? VIA has, in the past, been very helpful, on some chipsets. I would not rule out VIA being helpful again. Did you contact them? thanks ron From rogelio.serrano at gmail.com Wed Feb 22 05:28:49 2006 From: rogelio.serrano at gmail.com (Rogelio Serrano) Date: Wed, 22 Feb 2006 12:28:49 +0800 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <43FBDFDC.4030602@lanl.gov> References: <43FB556D.3000801@lanl.gov> <43FBDFDC.4030602@lanl.gov> Message-ID: On 2/22/06, Ronald G Minnich wrote: > > Rogelio Serrano wrote: > > > I understand. I will most likely get an intel board instead. > > > > > > > I would not recommend Intel either. They are not supportive of > LinuxBIOS; quite the contrary. > > thanks > > ron > I see. Its very expensive here in Manila too. Maybe an nforce4 board is better? Krgds, Roger OT: I wonder if there is an architecture out there with a "standardised" dram setup. Is there a pc architecture out there that does not require a bios? -- www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Wed Feb 22 05:54:55 2006 From: smithbone at gmail.com (Richard Smith) Date: Tue, 21 Feb 2006 22:54:55 -0600 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: <43FB556D.3000801@lanl.gov> <43FBDFDC.4030602@lanl.gov> Message-ID: <8a0c36780602212054w224d1e46n383b7d2e5e727bab@mail.gmail.com> > > OT: I wonder if there is an architecture out there with a "standardised" > dram setup. Is there a pc architecture out there that does not require a > bios? Get something ARM based. We (Bitworks) are likeing the offerings from sharp. Most don' t have a floating point unit though so if you are doing a lot of hard core math it might not hold up. -- Richard A. Smith From stepan at openbios.org Wed Feb 22 10:24:41 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Wed, 22 Feb 2006 10:24:41 +0100 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: References: <43FB556D.3000801@lanl.gov> <43FBDFDC.4030602@lanl.gov> Message-ID: <20060222092441.GA26760@openbios.org> * Rogelio Serrano [060222 05:28]: > I see. Its very expensive here in Manila too. Maybe an nforce4 board > is better? I think nforce4 is supported. Isn't that ck084? Stefan From rminnich at lanl.gov Wed Feb 22 16:40:22 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 22 Feb 2006 08:40:22 -0700 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <20060222092441.GA26760@openbios.org> References: <43FB556D.3000801@lanl.gov> <43FBDFDC.4030602@lanl.gov> <20060222092441.GA26760@openbios.org> Message-ID: <43FC85E6.10109@lanl.gov> Stefan Reinauer wrote: > * Rogelio Serrano [060222 05:28]: > >>I see. Its very expensive here in Manila too. Maybe an nforce4 board >>is better? > > > I think nforce4 is supported. Isn't that ck084? yes. Iwill, tyan, and others have very nice ck804 boards, and they are supported in linuxbios. ron From ragnar at hansarinne.fi Wed Feb 22 17:15:30 2006 From: ragnar at hansarinne.fi (Ragnar) Date: Wed, 22 Feb 2006 18:15:30 +0200 Subject: [LinuxBIOS] EPIA M COM2 problem + possible solution? Message-ID: <43FC8E22.5050304@hansarinne.fi> Hi I just started to play with linuxbios and a EPIA-M 6000, and everything worked fine first trial, except for the COM2 port. The COM2 was recognised by the kernel but it was not responding to changes on the input pins. After finding the vt1211 datasheet with google, I notice that there is a register in the vt1211 that controls UART2 pin selection. Reading this register after booting with linuxbios, I got 0xff. So according to the datasheet COM2 pins are not used by the UART2 but by somthing else. So by changing this register to 0x00, and COM2 works fine. But according to the datasheet the default value for this register is 0x00 which I interpret as reset value? So can there be some code somewhere that set this register to 0xff, for some other board using the vt1211 that have these pins connected to something else than COM2? Five of these pins can be used for monitoring an intel P6, and two can be used as SMBus but I guess the SMBus is controlled by the southbridge, and the last one is Infrared Tranciever Module on/off control. So my best guess is that for the EPIA M board, this pin select register should set to 0x00, but since I'm a beginner and don't have the bigger picture, this is just a guess. But it works fine for me. I have been using version 2100, but the vt1211 code doesn't seems to have changed since then. Here is a patch of this trivial change to v1211.c, probably not so good, but it works for me on the EPIA M 6000. 67a68,69 > pnp_write_config(dev, index + 0, (iobase >> 2) & 0xff); > break; 68a71 > pnp_write_config(dev, 0x27, 0x00); /* Set pin selection to serial port */ Ragnar. From jardel at lesc.ufc.br Wed Feb 22 17:41:26 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Wed, 22 Feb 2006 13:41:26 -0300 Subject: [LinuxBIOS] Rumba target and AMD RDK THINCLIENT In-Reply-To: <43FC8E22.5050304@hansarinne.fi> Message-ID: Dear, I have an geode gx2 amd rdk thinclient (GEODE GX + CS5535). Is it possible run rumba target in this system ? I?ve maked rumba target and tested it, but CRT didn?t work. Thanks for yours help. Jardel. Development Engineer Federal University of Ceara - LESC From rminnich at lanl.gov Wed Feb 22 18:20:33 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 22 Feb 2006 10:20:33 -0700 Subject: [LinuxBIOS] Rumba target and AMD RDK THINCLIENT In-Reply-To: <200602221644.k1MGiQZH014495@proofpoint2.lanl.gov> References: <200602221644.k1MGiQZH014495@proofpoint2.lanl.gov> Message-ID: <43FC9D61.1090506@lanl.gov> Jardel Silveira wrote: > Dear, > > > > I have an geode gx2 amd rdk thinclient (GEODE GX + CS5535). Is it > possible run rumba target in this system ? > I?ve maked rumba target and tested it, but CRT didn?t work. > > > Thanks for yours help. amazing. Did you get any serial output or anything? This target is very new, Ollie Lo has been working like crazy to get it going just this week. let me know how far it got ... thanks ron From yinghailu at gmail.com Wed Feb 22 18:41:19 2006 From: yinghailu at gmail.com (yhlu) Date: Wed, 22 Feb 2006 09:41:19 -0800 Subject: [LinuxBIOS] disassembly of bios code In-Reply-To: <20060222092441.GA26760@openbios.org> References: <43FB556D.3000801@lanl.gov> <43FBDFDC.4030602@lanl.gov> <20060222092441.GA26760@openbios.org> Message-ID: <2ea3fae10602220941g1f54fa48s9aa068ee752abf70@mail.gmail.com> Yes. On 2/22/06, Stefan Reinauer wrote: > * Rogelio Serrano [060222 05:28]: > > I see. Its very expensive here in Manila too. Maybe an nforce4 board > > is better? > > I think nforce4 is supported. Isn't that ck084? > > Stefan > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ollie at lanl.gov Wed Feb 22 19:06:54 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Feb 2006 11:06:54 -0700 Subject: [LinuxBIOS] Rumba target and AMD RDK THINCLIENT In-Reply-To: <43FC9D61.1090506@lanl.gov> References: <200602221644.k1MGiQZH014495@proofpoint2.lanl.gov> <43FC9D61.1090506@lanl.gov> Message-ID: <1140631615.18667.0.camel@logarithm.lanl.gov> On Wed, 2006-02-22 at 10:20 -0700, Ronald G Minnich wrote: > Jardel Silveira wrote: > > Dear, > > > > > > > > I have an geode gx2 amd rdk thinclient (GEODE GX + CS5535). Is it > > possible run rumba target in this system ? > > I?ve maked rumba target and tested it, but CRT didn?t work. > > > > > > Thanks for yours help. > > > amazing. Did you get any serial output or anything? This target is very > new, Ollie Lo has been working like crazy to get it going just this week. > I don't think there is anything in the CVS yet. I haven't commit anything. > let me know how far it got ... > > thanks > > ron > -- Li-Ta Lo Los Alamos National Lab From jardel at lesc.ufc.br Wed Feb 22 19:12:13 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Wed, 22 Feb 2006 15:12:13 -0300 Subject: [LinuxBIOS] RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <43FC9D61.1090506@lanl.gov> Message-ID: Dear, As a matter of fact, this target doesn?t seem to turn on my board. The power led is off. I?ve an FS2 JTAG interface and may be I can do some necessary tests. Thanks. Jardel. Development Engineer. Federal University of Ceara. -----Mensagem original----- De: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] Em nome de Ronald G Minnich Enviada em: quarta-feira, 22 de fevereiro de 2006 14:21 Para: Jardel Silveira Cc: linuxbios at linuxbios.org Assunto: Re: [LinuxBIOS] Rumba target and AMD RDK THINCLIENT Jardel Silveira wrote: > Dear, > > > > I have an geode gx2 amd rdk thinclient (GEODE GX + CS5535). Is it > possible run rumba target in this system ? > I?ve maked rumba target and tested it, but CRT didn?t work. > > > Thanks for yours help. amazing. Did you get any serial output or anything? This target is very new, Ollie Lo has been working like crazy to get it going just this week. let me know how far it got ... thanks ron -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From jardel at lesc.ufc.br Wed Feb 22 19:13:35 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Wed, 22 Feb 2006 15:13:35 -0300 Subject: [LinuxBIOS] RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <1140631615.18667.0.camel@logarithm.lanl.gov> Message-ID: Dear, I?ve maked the rumbo target available today four hours ago. If you would like, I can do some tests. Thanks. Jardel. -----Mensagem original----- De: Li-Ta Lo [mailto:ollie at lanl.gov] Enviada em: quarta-feira, 22 de fevereiro de 2006 15:07 Para: Ronald G Minnich Cc: Jardel Silveira; linuxbios at linuxbios.org Assunto: Re: [LinuxBIOS] Rumba target and AMD RDK THINCLIENT On Wed, 2006-02-22 at 10:20 -0700, Ronald G Minnich wrote: > Jardel Silveira wrote: > > Dear, > > > > > > > > I have an geode gx2 amd rdk thinclient (GEODE GX + CS5535). Is it > > possible run rumba target in this system ? > > I?ve maked rumba target and tested it, but CRT didn?t work. > > > > > > Thanks for yours help. > > > amazing. Did you get any serial output or anything? This target is very > new, Ollie Lo has been working like crazy to get it going just this week. > I don't think there is anything in the CVS yet. I haven't commit anything. > let me know how far it got ... > > thanks > > ron > -- Li-Ta Lo Los Alamos National Lab From mike at theptrgroup.com Wed Feb 22 22:42:09 2006 From: mike at theptrgroup.com (Mike Anderson) Date: Wed, 22 Feb 2006 16:42:09 -0500 Subject: [LinuxBIOS] Intel 845GV Support? Message-ID: <43FCDAB1.7050904@theptrgroup.com> Greetings! Has anyone had any luck with LinuxBios on the i845GV chipset? I found a few references here and there on the mailing list archive, but nothing definitive. TIA, Mike -- --------------------------------------------------------------- Mike Anderson 703.585.9384 CTO/Chief Scientist mike at ThePTRGroup.com www.ThePTRGroup.com Embedded, Real-Time Solutions --------------------------------------------------------------- "Software development is like making a baby. You can't make a baby in one month by impregnating nine women. Some things just take time." From talbotx at comcast.net Thu Feb 23 22:06:30 2006 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 23 Feb 2006 13:06:30 -0800 Subject: [LinuxBIOS] EPIA-M LinuxBIOS worked for my EPIA-M 10000 In-Reply-To: <43FD0CC7.7050300@mailcan.com> References: <43FD0CC7.7050300@mailcan.com> Message-ID: <43FE23D6.3040201@comcast.net> -Leon My board is close to the MII, but not exact. I have a different south bridge. http://www.bcmcom.com/bcm_product_ebc3266.htm So thinking that I can get the north bridge up, I am hoping that I can get my board to at least give me something out of the console, from there I can start debugging. I dont think the dd if=/dev/mem.... to grab the video bios will work for me, different address range's. Currently I have linuxbios 2177, same as you, but I dont have a computable flash chip (SST39SF040) currently not supported, so I am using an external burner. The biggest bug I am currently stuck on is the linuxbios.rom keeps coming out at 192k and not 256k... No clue what I have wrong. If i can get 256k then just `cat linuxbios.rom >> linuxbios.rom.512` do that twice and I should have a 512 rom. Can I snag a copy of your Config.lb? My current payload is /etc/hosts, I will switch to filo when I can get console running. For now I would just like to see ANY signs of life out of the console. Console is tested and fully running, I currently dont even use a screen, just serial console. -Adam Leon Woestenberg wrote: > Hello Adam, > > found your question on the LinuxBIOS list (see below). > > I just retried the EPIA-M LinuxBIOS code again and it worked for my > EPIA-M 10000 board. Actually, this is the first time I got it working. > SVN HEAD tree (rev 2177) with filo 4.2.0 with Linux 2.6.11 (or so). > > Note that I did *not* get VGA to work under the early LinuxBIOS boot > and FILO boot, it came up when Linux booted. I controlled FILO through > a null-modem serial connection. > > I have attached my notes below. > > Please if you proceed with your EPIA board, keep me in the loop with > your experiences. It's hard to find experiences from stuff that worked. > > note: Seaching for the VGA issue, it seems I should take the VGA BIOS > from some specific version of VIA's BIOS... > > Regards, > > Leon Woestenberg. > > > > [LinuxBIOS] Status of the epia-m > > *Adam Talbot* talbotx at comcast.net > > /Tue Feb 21 23:13:44 CET 2006/ > > * Previous message: [LinuxBIOS] This should be an easy error... > > * Next message: [LinuxBIOS] EPIA M COM2 problem + possible > solution? > > * *Messages sorted by:* [ date ] > > [ thread ] > > [ subject ] > > [ author ] > > > > ------------------------------------------------------------------------ > >Is the current epia-m code running? >-Adam > > > > > >------------------------------------------------------------------------ > >http://www.viaarena.com/default.aspx?PageID=22&DSCat=155&DCatType=3 > >i010t117.bin > >rev 2177 of linuxbiosv2 > >Debugging output from the EPIA: > >115200,8n1,first serial port > >Extract VGA BIOS: > >dd if=/dev/mem of=/video.bios.bin \ >bs=1 count=65536 skip=790528 > >Linux sits on: > >/dev/hdc2 on / type ext3 (rw,errors=remount-ro) > >In the 'util/flash_and_burn' directory is the source for the 'flash_rom' > utility, which is great for re-programming the flash chips on the > EPIA-M / MII. > >Correction: should be in 'util/flashrom' directory since 2101 or so. > >apt-get install pciutils >apt-get install pciutils-dev > >leon at nehemiah:~/sandbox/linuxbios/util/flashrom$ sudo -s >root at nehemiah:~/sandbox/linuxbios/util/flashrom# ./flashrom >Calibrating delay loop... ok >No LinuxBIOS table found. >Enabling flash write on VT8235...tried to set 0x45 to 0x55 on VT8235 failed (WARNING ONLY) >SST39SF020A found at physical address: 0xfffc0000 >Flash part is SST39SF020A >OK, only ENABLING flash write, but NOT FLASHING. > >SST39SF020A is a 256k words of 8 bit = 2 Mbit > >ST29SF040A is a 512k words of 8 bit = 4 Mbit > >Note that the EPIA will address the second half of the 4 Mbit Flash! To be sure, copy the bin to >both halves of the flash. > >wget http://felixx.tsn.or.jp/~ts1/filo/filo-0.4.2.tar.bz2 > >[...] > > The main configuration file for the epia-m is in > 'targets/via/epia-m/Config.lb' > > If you need to make any changes to the configuration, for example you wish to > locate filo.elf in a place other than '/filo.elf', or during the more advanced > steps of this HOWTO, then these changes are made to this file. > > You need to re-run the './buildtarget via/epia-m' after any such change. > > Change the configuration file to match the full path of the filo.elf file. > > payload /home/leon/sandbox/linuxbios/filo.elf > > Regenerate the build: > > ./buildtarget via/epia-m > >cd targets/via/epia-m/epia-m > >make > > > >cd filo >edit Config >make > >cp filo.elf ../linuxbios >cd ../linuxbios/targets >./buildtarget via/epia-m >cd via/epia-m/epia-m >edit Makefile > > >serial.c:54.34: serial.c:66.29: console.c:6.21: console.c:16.26: console.c:51.36: console.c:72.71: bist.h:11.34: auto.c:133.28: 0x81a44e0 noop Internal compiler warning: awakening noop? > > > > > > From ollie at lanl.gov Thu Feb 23 22:44:25 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 23 Feb 2006 14:44:25 -0700 Subject: [LinuxBIOS] RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <200602221815.k1MIF22Q032754@proofpoint2.lanl.gov> References: <200602221815.k1MIF22Q032754@proofpoint2.lanl.gov> Message-ID: <1140731066.19385.11.camel@logarithm.lanl.gov> On Wed, 2006-02-22 at 15:12 -0300, Jardel Silveira wrote: > Dear, > > > As a matter of fact, this target doesn?t seem to turn on my board. > The power led is off. > I?ve an FS2 JTAG interface and may be I can do some necessary tests. > I just committed the raminit.c for GX2. Please take a look at it. I presume you have access to the developer web site and docs there? I think I have implemented the DRAM init sequence in their GeodeROM Porting Guide and LX/GX processor data book correctly. But I may be wrong. I also thing probably I have to implement the PLL reset in order for DRAM to work. BTW, hook a serial console. I think the power led is controlled by software. It is off all the way in LinuxBIOS (yes, there is something on the serial console.) -- Li-Ta Lo Los Alamos National Lab From jardel at lesc.ufc.br Thu Feb 23 22:54:22 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Thu, 23 Feb 2006 18:54:22 -0300 Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <1140731066.19385.11.camel@logarithm.lanl.gov> Message-ID: Dear Mr. Li-Ta Lo, I?ve access only to the svn respository. I think don?t have access to the developer web site and docs there. I have both boards based on GX and LX processors. I will do the tests. Thanks for the attention. Jardel. -----Mensagem original----- De: Li-Ta Lo [mailto:ollie at lanl.gov] Enviada em: quinta-feira, 23 de fevereiro de 2006 18:44 Para: Jardel Silveira Cc: 'Ronald G Minnich'; linuxbios at linuxbios.org Assunto: Re: [LinuxBIOS] RES: Rumba target and AMD RDK THINCLIENT On Wed, 2006-02-22 at 15:12 -0300, Jardel Silveira wrote: > Dear, > > > As a matter of fact, this target doesn?t seem to turn on my board. > The power led is off. > I?ve an FS2 JTAG interface and may be I can do some necessary tests. > I just committed the raminit.c for GX2. Please take a look at it. I presume you have access to the developer web site and docs there? I think I have implemented the DRAM init sequence in their GeodeROM Porting Guide and LX/GX processor data book correctly. But I may be wrong. I also thing probably I have to implement the PLL reset in order for DRAM to work. BTW, hook a serial console. I think the power led is controlled by software. It is off all the way in LinuxBIOS (yes, there is something on the serial console.) -- Li-Ta Lo Los Alamos National Lab From stepan at coresystems.de Fri Feb 24 02:38:03 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 24 Feb 2006 02:38:03 +0100 Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT Message-ID: <20060224013803.GA14681@openbios.org> * Jardel Silveira [060223 22:54]: > > Dear Mr. Li-Ta Lo, > > > > I?ve access only to the svn respository. I think don?t have access to the > developer web site and docs there. Clarification: All information is freely available at www.linuxbios.org. There is no such thing as a developer web site. You only need to log in to the website to actually _change_ the content. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From leonw at mailcan.com Thu Feb 23 17:26:00 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Thu, 23 Feb 2006 17:26:00 +0100 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 Message-ID: <43FDE218.9080100@mailcan.com> Hello LinuxBIOS developers, I had to patch flashrom to work with my FlashROM as per the supplied patch. How exactly do I find out what probe/write/verify function triplet is needed. I copied from the AMD part, as to my knowledge the devices are fully compatible. Tested to work on EPIA-M; write/verify and boot LinuxBIOS. Regards, Leon. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: st_m29f040b.patch URL: From leonw at mailcan.com Thu Feb 23 17:45:44 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Thu, 23 Feb 2006 17:45:44 +0100 Subject: [LinuxBIOS] EPIA-M VGA BIOS - X gives VIA(0): Bad V-BIOS checksum Message-ID: <43FDE6B8.5060009@mailcan.com> Hello all, my target: VIA EPIA-M 10000 Latest linuxbios (rev 2177) I extracted the VIA VGA BIOS from the EPIA running official BIOS rev. 1.13. However, my X server reports: VIA(0): Bad V-BIOS checksum. Everything before that looks good. Upon boot, I *do* get VGA output of FILO. Would could be the cause? See below for details on what I did. Regards, Leon. ------ As a sidenote, I think the HOWTO/EPIA-M is wrong about how to extract: WRONG: dd if=/dev/mem of=/video.bios.bin \ WRONG: bs=1 count=65536 skip=790528 Note that 790528=0xC1000 and 65536=0x10000 /dev/mem must be read from 0xC000-0xD000 (VGA BIOS), whereas /proc/kcore must be read from 0xC1000-0xD1000 because kcore is an ELF 'view' to the memory, with a 0x1000 ELF header at 0xC000. What I did is extract from 0xC000-0xD000 as follows: dd if=/dev/mem of=/113mem.bin skip=1536 count=128 (bs=512 by default) ------ leon at nehemiah:/$ ls -ald /113mem.bin -rw-r--r-- 1 root root 65536 2006-02-23 03:57 /113mem.bin leon at nehemiah:/$ hexdump -C /113mem.bin | head -n 10 00000000 55 aa 7d e9 26 7f 5e 1b fa f9 f4 82 00 00 00 00 |U.}.&.^.........| 00000010 00 00 00 00 00 00 00 00 44 00 d4 b0 c6 00 49 42 |........D.....IB| 00000020 4d 20 43 4f 4d 50 41 54 49 42 4c 45 42 43 50 4f |M COMPATIBLEBCPO| 00000030 53 54 00 00 18 00 30 34 2f 31 38 2f 30 33 01 15 |ST....04/18/03..| 00000040 00 c0 c6 00 50 43 49 52 06 11 22 31 00 00 18 00 |....PCIR.."1....| 00000050 00 00 00 03 40 00 51 01 00 80 00 00 00 01 20 20 |.... at .Q....... | 00000060 20 56 49 41 20 54 65 63 2e 49 6e 63 2e 20 20 20 | VIA Tec.Inc. | 00000070 20 20 20 20 20 20 20 20 20 56 45 52 2e 56 54 33 | VER.VT3| 00000080 31 32 33 20 20 20 20 01 15 01 12 56 49 41 20 20 |123 ....VIA | 00000090 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 | ....| leon at nehemiah:/$ md5sum /113mem.bin 87017abc14c53e51a269fe59b5ba1508 /113mem.bin From lukesky740 at aol.com Sat Feb 18 22:45:19 2006 From: lukesky740 at aol.com (lukesky740 at aol.com) Date: Sat, 18 Feb 2006 16:45:19 -0500 Subject: [LinuxBIOS] supported in v1, not in v2? Message-ID: <8C802EBBF19B650-12D4-252FA@FWM-D18.sysops.aol.com> I noticed in the v1 tree that you support the LEX cv860a motherboard, yet there have been no updates to that tree in a long time (2 years?). I was dissapointed to see that it has not beed added to the v2 tree. Does this mean that there are no plans to include it? As I am new to this, I am uncertain of the ramifications in version difference from v1 to v2. Any insight would be greatly appreciated. Nathan Dragun From stepan at coresystems.de Fri Feb 24 03:02:43 2006 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 24 Feb 2006 03:02:43 +0100 Subject: [LinuxBIOS] supported in v1, not in v2? In-Reply-To: <8C802EBBF19B650-12D4-252FA@FWM-D18.sysops.aol.com> References: <8C802EBBF19B650-12D4-252FA@FWM-D18.sysops.aol.com> Message-ID: <20060224020243.GB16287@openbios.org> * lukesky740 at aol.com [060218 22:45]: > I noticed in the v1 tree that you support the LEX cv860a motherboard, > yet there have been no updates to that tree in a long time (2 years?). > I was dissapointed to see that it has not beed added to the v2 tree. > Does this mean that there are no plans to include it? Probably not, though anyone is welcome to help porting those motherboards to v2. v2 has some design advantages over v1 that make writing new ports somewhat easier. On the other hand - if a board is supported by v1, just use that one. The reason that code has not been touched in a very long time is that those boards do work pretty well and there's no need to change the code. > As I am new to this, I am uncertain of the ramifications in version > difference from v1 to v2. Any insight would be greatly appreciated. Basically in v1 all ram initialization code was written in assembly, while in v2 it is written in C. There's also only one device tree instead of a static and a dynamic device tree. Plus, there's ACPI support (because there are machines out there that can't be booted without ACPI anymore) Feel free to try v1, and if you find problems, report them here. We'll try to help as good as we can. Stefan -- coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. Tel.: +49 761 7668825 ? Fax: +49 761 7664613 Email: info at coresystems.de ? http://www.coresystems.de/ From smithbone at gmail.com Fri Feb 24 03:29:36 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 23 Feb 2006 20:29:36 -0600 Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <20060224013803.GA14681@openbios.org> References: <20060224013803.GA14681@openbios.org> Message-ID: <8a0c36780602231829r5398231ew777c5ad782b8091a@mail.gmail.com> > > Clarification: > All information is freely available at www.linuxbios.org. There is no > such thing as a developer web site. You only need to log in to the > website to actually _change_ the content. > I think he may be refering to the developer's web site for the Geode stuff. You have to register and have your access approved to gain access to the docs. Although I've also managed to get there via some google links. But the site may have just nibbled on the leftover cookies from previous logins. -- Richard A. Smith From smithbone at gmail.com Fri Feb 24 03:34:06 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 23 Feb 2006 20:34:06 -0600 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 In-Reply-To: <43FDE218.9080100@mailcan.com> References: <43FDE218.9080100@mailcan.com> Message-ID: <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> > How exactly do I find out what probe/write/verify function triplet is > needed. I copied from the AMD part, as to my knowledge the devices are > fully compatible. The data sheet. I suspect that the device is compatible. Especially if its billed as a direct cross. Do you have the datasheet? -- Richard A. Smith From smithbone at gmail.com Fri Feb 24 03:37:02 2006 From: smithbone at gmail.com (Richard Smith) Date: Thu, 23 Feb 2006 20:37:02 -0600 Subject: [LinuxBIOS] supported in v1, not in v2? In-Reply-To: <20060224020243.GB16287@openbios.org> References: <8C802EBBF19B650-12D4-252FA@FWM-D18.sysops.aol.com> <20060224020243.GB16287@openbios.org> Message-ID: <8a0c36780602231837w5dbae6c6ofd491ce7a3c85df5@mail.gmail.com> > Basically in v1 all ram initialization code was written in assembly, > while in v2 it is written in C. There's also only one device tree > instead of a static and a dynamic device tree. Plus, there's ACPI > support (because there are machines out there that can't be booted > without ACPI anymore) Video is in there as well. Getting video to work in V1 is quite a bit tricker than in V2. If you are wanting video then porting to V2 is probally a good idea. -- Richard A. Smith From leonw at mailcan.com Fri Feb 24 13:25:43 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Fri, 24 Feb 2006 13:25:43 +0100 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 In-Reply-To: <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> References: <43FDE218.9080100@mailcan.com> <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> Message-ID: <43FEFB47.8010203@mailcan.com> Hello Richard et al, Richard Smith wrote: >> How exactly do I find out what probe/write/verify function triplet is >> needed. I copied from the AMD part, as to my knowledge the devices are >> fully compatible. >> > > The data sheet. > > I suspect that the device is compatible. Especially if its billed as > a direct cross. Do you have the datasheet? > Sure, I do, for both the AMD and ST part. But I do not have the time to fully cross-reference it against all timing specs though. Regards, Leon. From stepan at openbios.org Fri Feb 24 13:47:23 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 24 Feb 2006 13:47:23 +0100 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 In-Reply-To: <43FEFB47.8010203@mailcan.com> References: <43FDE218.9080100@mailcan.com> <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> <43FEFB47.8010203@mailcan.com> Message-ID: <20060224124723.GA21052@openbios.org> * Leon Woestenberg [060224 13:25]: > Sure, I do, for both the AMD and ST part. > > But I do not have the time to fully cross-reference it against all > timing specs though. That part is uncritical. Make sure the block layout is the same. There are different parts that have a "boot block" in the top (T) or bottom (b) of the address range. When you test flashing on your system and it works, everything except the block sizes will be ok. Stefan From leonw at mailcan.com Fri Feb 24 14:26:38 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Fri, 24 Feb 2006 14:26:38 +0100 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 In-Reply-To: <20060224124723.GA21052@openbios.org> References: <43FDE218.9080100@mailcan.com> <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> <43FEFB47.8010203@mailcan.com> <20060224124723.GA21052@openbios.org> Message-ID: <43FF098E.3010507@mailcan.com> Hello all, Stefan Reinauer wrote: > * Leon Woestenberg [060224 13:25]: > >> Sure, I do, for both the AMD and ST part. >> >> But I do not have the time to fully cross-reference it against all >> timing specs though. >> > > That part is uncritical. Make sure the block layout is the same. There > are different parts that have a "boot block" in the top (T) or bottom > (b) of the address range. > > When you test flashing on your system and it works, everything except > the block sizes will be ok. > > I checked and can confirm that both parts use eight uniform erase blocks of 64kByte each, from the datasheets. These parts have no boot blocks BTW. With this, I think my patch is OK for inclusion. Regards, Leon. From stepan at openbios.org Fri Feb 24 15:06:37 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 24 Feb 2006 15:06:37 +0100 Subject: [LinuxBIOS] [RFC] [PATCH] ST M29F040 In-Reply-To: <43FF098E.3010507@mailcan.com> References: <43FDE218.9080100@mailcan.com> <8a0c36780602231834r3dd88e4ckebf096374c5f60b3@mail.gmail.com> <43FEFB47.8010203@mailcan.com> <20060224124723.GA21052@openbios.org> <43FF098E.3010507@mailcan.com> Message-ID: <20060224140637.GA6101@openbios.org> * Leon Woestenberg [060224 14:26]: > I checked and can confirm that both parts use eight uniform erase blocks > of 64kByte each, from the datasheets. > These parts have no boot blocks BTW. > > With this, I think my patch is OK for inclusion. commited. Stefan From leonw at mailcan.com Fri Feb 24 16:53:29 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Fri, 24 Feb 2006 16:53:29 +0100 Subject: [LinuxBIOS] VGA BIOS dissect.sh Message-ID: <43FF2BF9.2030200@mailcan.com> Hello, I found this script to be helpful to me in getting a VGA BIOS binary for my EPIA. --- leon at nehemiah:/tmp$ cat dissect.sh #!/bin/bash for OFFSET in 76607 107793 112921 113603 123297 136064 148043 186053; do dd if=i0100113.bin of=/tmp/rest.lha bs=1 skip=$OFFSET lha tv rest.lha done rm rest.lha --- Also, to get a rough first idea of the offsets: --- leon at nehemiah:/tmp$ grep -b -a -o lh5 i0100113.bin 0:lh5 76354:lh5 107256:lh5 112805:lh5 113207:lh5 122904:lh5 135994:lh5 148041:lh5 185911:lh5 --- Regards, Leon. From rminnich at lanl.gov Fri Feb 24 17:44:03 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Fri, 24 Feb 2006 09:44:03 -0700 Subject: [LinuxBIOS] VGA BIOS dissect.sh In-Reply-To: <43FF2BF9.2030200@mailcan.com> References: <43FF2BF9.2030200@mailcan.com> Message-ID: <43FF37D3.5090004@lanl.gov> Leon Woestenberg wrote: > Hello, > > I found this script to be helpful to me in getting a VGA BIOS binary for > my EPIA. hi leon, you have a working via with linuxbios, vga, etc? Have you made ANY local mods to the source tree? can you do this: tell me svn version # cat /proc/cpuinfo uname -a and send it to me? thanks ron From leonw at mailcan.com Fri Feb 24 18:35:41 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Fri, 24 Feb 2006 18:35:41 +0100 Subject: [LinuxBIOS] VGA BIOS dissect.sh In-Reply-To: <43FF37D3.5090004@lanl.gov> References: <43FF2BF9.2030200@mailcan.com> <43FF37D3.5090004@lanl.gov> Message-ID: <43FF43ED.3070204@mailcan.com> Hello Ronald, Ronald G Minnich wrote: > Leon Woestenberg wrote: >> I found this script to be helpful to me in getting a VGA BIOS binary >> for my EPIA. > > hi leon, you have a working via with linuxbios, vga, etc? Have you > made ANY local mods to the source tree? > Yes, working as in: I have a working LinuxBIOS and I see VGA output of FILO, can type and modify the FILO boot line if I wish to , and I can boot Linux properly. (Some stuff I have not yet working are: a LinuxBIOS logo (??) and X. Supposedly X should work again when I modify the ID in the mainboard code.) No, I have *not* touched *anything* in linuxbios/src. (I just verified this by svn diff to be sure) > can you do this: > > tell me svn version # 2177 > cat /proc/cpuinfo > uname -a leon at nehemiah:/tmp$ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 1 cpu MHz : 666.740 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge cmov mmx fxsr sse fxsr_opt bogomips : 1319.57 leon at nehemiah:/tmp$ uname -a Linux nehemiah 2.6.12-10-386 #1 Mon Feb 13 12:13:15 UTC 2006 i686 GNU/Linux Best regards, Leon. From jardel at lesc.ufc.br Fri Feb 24 20:28:16 2006 From: jardel at lesc.ufc.br (Jardel Silveira) Date: Fri, 24 Feb 2006 16:28:16 -0300 Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <1140731066.19385.11.camel@logarithm.lanl.gov> Message-ID: Dear Li-Ta Lo, I?ve just tried to compile rumba now and i?ve got this ouput? N_OFFSET='0x0' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xfffd0000' -DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0' -DCONFIG_UDELAY_IO='0' /home/jardel/projetos/LinuxBIOSv2/src/mainboard/amd/rumba/auto.c -o auto.inc raminit.c:3.61: struct mem_controller undeclared make[1]: ** [auto.inc] Erro 1 make[1]: Leaving directory `/home/jardel/projetos/LinuxBIOSv2/targets/amd/rumba/rumba/normal' make: ** [normal/linuxbios.rom] Erro 1 jardel at jardel:~/projetos/LinuxBIOSv2/targets/amd/rumba/rumba$ ls Thanks. Jardel. -----Mensagem original----- De: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] Em nome de Li-Ta Lo Enviada em: quinta-feira, 23 de fevereiro de 2006 18:44 Para: Jardel Silveira Cc: linuxbios at linuxbios.org Assunto: Re: [LinuxBIOS] RES: Rumba target and AMD RDK THINCLIENT On Wed, 2006-02-22 at 15:12 -0300, Jardel Silveira wrote: > Dear, > > > As a matter of fact, this target doesn?t seem to turn on my board. > The power led is off. > I?ve an FS2 JTAG interface and may be I can do some necessary tests. > I just committed the raminit.c for GX2. Please take a look at it. I presume you have access to the developer web site and docs there? I think I have implemented the DRAM init sequence in their GeodeROM Porting Guide and LX/GX processor data book correctly. But I may be wrong. I also thing probably I have to implement the PLL reset in order for DRAM to work. BTW, hook a serial console. I think the power led is controlled by software. It is off all the way in LinuxBIOS (yes, there is something on the serial console.) -- Li-Ta Lo Los Alamos National Lab -- linuxbios mailing list linuxbios at linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios From leonw at mailcan.com Fri Feb 24 23:16:10 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Fri, 24 Feb 2006 23:16:10 +0100 Subject: [LinuxBIOS] VGA BIOS dissect.sh In-Reply-To: <43FF37D3.5090004@lanl.gov> References: <43FF2BF9.2030200@mailcan.com> <43FF37D3.5090004@lanl.gov> Message-ID: <43FF85AA.8070502@mailcan.com> Hello again Ronald, Ronald G Minnich wrote: > Leon Woestenberg wrote: >> Hello, >> >> I found this script to be helpful to me in getting a VGA BIOS binary >> for my EPIA. > > > hi leon, you have a working via with linuxbios, vga, etc? Have you > made ANY local mods to the source tree? Concerning VGA BIOS, did you note my sidenote in my earlier mail (copied below again)? Dumbly following the HOWTO (which has a subtle bug) is not adviced: --- As a sidenote, I think the HOWTO/EPIA-M is wrong about how to extract: WRONG: dd if=/dev/mem of=/video.bios.bin \ WRONG: bs=1 count=65536 skip=790528 Note that 790528=0xC1000 and 65536=0x10000 /dev/mem must be read from 0xC000-0xD000 (VGA BIOS), whereas /proc/kcore must be read from 0xC1000-0xD1000 because kcore is an ELF 'view' to the memory, with a 0x1000 ELF header at 0xC000. What I did is extract from 0xC000-0xD000 as follows: dd if=/dev/mem of=/113mem.bin skip=1536 count=128 (bs=512 by default) ------ leon at nehemiah :/$ ls -ald /113mem.bin -rw-r--r-- 1 root root 65536 2006-02-23 03:57 /113mem.bin leon at nehemiah :/$ hexdump -C /113mem.bin | head -n 10 00000000 55 aa 7d e9 26 7f 5e 1b fa f9 f4 82 00 00 00 00 |/U.}.&.^.........| /00000010 00 00 00 00 00 00 00 00 44 00 d4 b0 c6 00 49 42 |/........D.....IB| /00000020 4d 20 43 4f 4d 50 41 54 49 42 4c 45 42 43 50 4f |M COMPATIBLEBCPO| 00000030 53 54 00 00 18 00 30 34 2f 31 38 2f 30 33 01 15 |/ST....04/18/03..| /00000040 00 c0 c6 00 50 43 49 52 06 11 22 31 00 00 18 00 |/....PCIR.."1....| /00000050 00 00 00 03 40 00 51 01 00 80 00 00 00 01 20 20 |/.... at .Q....... | /00000060 20 56 49 41 20 54 65 63 2e 49 6e 63 2e 20 20 20 | VIA Tec.Inc. | 00000070 20 20 20 20 20 20 20 20 20 56 45 52 2e 56 54 33 | VER.VT3| 00000080 31 32 33 20 20 20 20 01 15 01 12 56 49 41 20 20 |123 ....VIA | 00000090 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 | ....| leon at nehemiah :/$ md5sum /113mem.bin 87017abc14c53e51a269fe59b5ba1508 /113mem.bin --- Regards, Leon. From leonw at mailcan.com Sat Feb 25 02:41:40 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sat, 25 Feb 2006 02:41:40 +0100 Subject: [LinuxBIOS] Success report on VIA EPIA-M10000 Message-ID: <43FFB5D4.8020006@mailcan.com> Hello all, just wanted to report that I have gotten my EPIA-M10000 to boot LinuxBIOS 2184, then FILO 0.4.2, then Ubuntu with kernel 2.6.12 into X without problems. This time round (for learning purposes) I extracted the VGA BIOS from the BIOS upgrade file, and not from a running EPIA. (Still note that there is an error in the EPIA HOWTO about how to extract the VGA BIOS from memory. -- See my messages of the past few days for context.) For completeness, here is a small diff, plus an adapted Makefile that made this work. Thanks for all the work you guys have put into it. Next up is inclusion of the ACPI table. Regards, Leon. --- Index: src/mainboard/via/epia-m/mainboard.c =================================================================== --- src/mainboard/via/epia-m/mainboard.c (revision 2184) +++ src/mainboard/via/epia-m/mainboard.c (working copy) @@ -30,7 +30,7 @@ device_t dev; printk_info("write_protect_vgabios\n"); - dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0); + dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); if(dev) pci_write_config8(dev, 0x61, 0xaa); } Index: targets/via/epia-m/Config.lb =================================================================== --- targets/via/epia-m/Config.lb (revision 2184) +++ targets/via/epia-m/Config.lb (working copy) @@ -55,7 +55,7 @@ # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf # payload ../../../../../lnxieepro100.ebi - payload /filo.elf + payload /home/leon/sandbox/linuxbios-2184/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "fallback" Index: targets/via/epia-m/Config.vga.filo =================================================================== --- targets/via/epia-m/Config.vga.filo (revision 2184) +++ targets/via/epia-m/Config.vga.filo (working copy) @@ -38,20 +38,14 @@ option ROM_SECTION_OFFSET=0x10000 option ROM_SECTION_SIZE=0x18000 option LINUXBIOS_EXTRA_VERSION=".0Normal" -# payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf -# payload ../../../../tg3--ide_disk.zelf -# payload ../../../../../lnxieepro100.ebi - payload /filo.elf + payload /home/leon/sandbox/linuxbios-2184/filo.elf end romimage "fallback" option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0xc000 option LINUXBIOS_EXTRA_VERSION=".0Fallback" -# payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf -# payload ../../../../tg3--ide_disk.zelf -# payload ../../../../../lnxieepro100.ebi - payload /filo.elf + payload /home/leon/sandbox/linuxbios-2184/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" --- --- # File: via/epia-m/epia-m/Makefile is autogenerated all: ./linuxbios.rom include Makefile.settings fallback/linuxbios.rom: if (cd fallback; \ make linuxbios.rom)\ then true; else exit 1; fi; clean: fallback-clean fallback-clean: (cd fallback; make clean) ./linuxbios.rom: fallback/linuxbios.rom cat /home/leon/sandbox/linuxbios-2184/vgabios.bin fallback/linuxbios.rom > ./linuxbios.rom .PHONY: all clean fallback-clean fallback/linuxbios.rom Makefile: /home/leon/sandbox/linuxbios-2184/targets/via/epia-m/epia-m/config.py /home/leon/sandbox/linuxbios-2184/targets/via/epia-m/Config.lb (cd /home/leon/sandbox/linuxbios-2184/targets ; via/epia-m/epia-m/config.py via/epia-m/Config.lb /home/leon/sandbox/linuxbios-2184) --- From rminnich at gmail.com Sat Feb 25 06:44:09 2006 From: rminnich at gmail.com (ron minnich) Date: Fri, 24 Feb 2006 22:44:09 -0700 Subject: [LinuxBIOS] Success report on VIA EPIA-M10000 In-Reply-To: <43FFB5D4.8020006@mailcan.com> References: <43FFB5D4.8020006@mailcan.com> Message-ID: <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> This is intriguing. - dev = dev_find_device(PCI_VENDOR_ID _VIA, 0x3123, 0); + dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); I think what this means is that we need a new mainboard directory. can you give me more info about the exact mainboard. Another option, is to do something like tihs: dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0); if (! dev) dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); or some such. But if you could tell us the exact vendor etc. that would be good to know. thanks ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Sat Feb 25 11:50:34 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sat, 25 Feb 2006 11:50:34 +0100 Subject: [LinuxBIOS] Success report on VIA EPIA-M10000 In-Reply-To: <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> References: <43FFB5D4.8020006@mailcan.com> <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> Message-ID: <20060225105034.GA16213@openbios.org> * ron minnich [060225 06:44]: > This is intriguing. > > - dev = dev_find_device(PCI_VENDOR_ID > _VIA, 0x3123, 0); > + dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); > > I think what this means is that we need a new mainboard directory. can you give > me more info about the exact mainboard. > > Another option, is to do something like tihs: > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0); > if (! dev) > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); > > or some such. But if you could tell us the exact vendor etc. that would be good > to know. Or, to look for a VGA class device from VIA. Stefan From leonw at mailcan.com Sat Feb 25 14:30:17 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sat, 25 Feb 2006 14:30:17 +0100 Subject: [LinuxBIOS] Success report on VIA EPIA-M10000 In-Reply-To: <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> References: <43FFB5D4.8020006@mailcan.com> <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> Message-ID: <44005BE9.7000408@mailcan.com> Hello Ron, first my *unchanged* 2177 already worked in the console, but did make it into X; it reported: VIA(0): Bad V-BIOS checksum. Chris Suehs then responded to me off-list (Thanks Chris!): --- I have had the same problem for the via X driver. There is a failure in the LinuxBios Code for newer Epia M The vga bios section is not write protected, because the protection failt for a false Device ID You should try to change the code to the right ID in mainboard.c for the Epia to 3122 in the write_protect_vgabios function regards chris --- So I tried again with 2184 and this single change and it worked; I get into my X server without a hiss now. ron minnich wrote: > This is intriguing. > > > - dev = dev_find_device(PCI_VENDOR_ID > _VIA, 0x3123, 0); > + dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); > > I think what this means is that we need a new mainboard directory. can > you give me more info about the exact mainboard. > > Another option, is to do something like tihs: > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0); > if (! dev) > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); > > or some such. But if you could tell us the exact vendor etc. that > would be good to know. Ron, what exactly do you want to know further than this? VIA EPIA-M10000, PCB revision.B I could output lspci -vv or so if that helps? Regards, Leon Woestenberg. From leonw at mailcan.com Sat Feb 25 14:51:54 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sat, 25 Feb 2006 14:51:54 +0100 Subject: [LinuxBIOS] Success report on VIA EPIA-M10000 In-Reply-To: <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> References: <43FFB5D4.8020006@mailcan.com> <13426df10602242144w3fc4be13mf4854c3add24fa06@mail.gmail.com> Message-ID: <440060FA.1080702@mailcan.com> Ron, > > Another option, is to do something like tihs: > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3123, 0); > if (! dev) > dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0); > > or some such. But if you could tell us the exact vendor etc. that > would be good to know. FYI: leon at nehemiah:~$ sudo lspci -v -s 01:00.0 0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at d8000000 (32-bit, prefetchable) [size=64M] Memory at dc000000 (32-bit, non-prefetchable) [size=16M] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 2.0 leon at nehemiah:~$ lspci -n -s 01:00.0 0000:01:00.0 0300: 1106:3122 (rev 03) From leonw at mailcan.com Sat Feb 25 22:30:34 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sat, 25 Feb 2006 22:30:34 +0100 Subject: [LinuxBIOS] Checking if FlashROM pin A18 is connected? Message-ID: <4400CC7A.6090100@mailcan.com> Hello, I have a 512 kByte FlashROM but use 256 kByte images so far. I concatenate two of them, so even if address pin A18 is dangling, the CPU reads the image correctly. Now, if I understand correctly, the util/flashrom utility writes (-w) using the Flash programming algorithms, which do not touch A18. And if I understand correctly, it used mmap() to verify the image, which should use A18. Am I correct that by following this procedure, I can find out whether A18 is connected on my motherboard to the FlashROM socket? : dd if=/dev/random of=/tmp/random.bin bs=1024 count=512 flashrom -w /tmp/random.bin flashrom -v tmp/random.bin VERIFIED => A18 is connected Regards, Leon. *do not do this at home, it destroys your BIOS* From stepan at openbios.org Sat Feb 25 22:40:29 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sat, 25 Feb 2006 22:40:29 +0100 Subject: [LinuxBIOS] Checking if FlashROM pin A18 is connected? In-Reply-To: <4400CC7A.6090100@mailcan.com> References: <4400CC7A.6090100@mailcan.com> Message-ID: <20060225214028.GA20596@openbios.org> * Leon Woestenberg [060225 22:30]: > Am I correct that by following this procedure, I can find out whether > A18 is connected on my motherboard to the FlashROM socket? : > > dd if=/dev/random of=/tmp/random.bin bs=1024 count=512 > > flashrom -w /tmp/random.bin > flashrom -v tmp/random.bin > > VERIFIED => A18 is connected Yes. If the top half and the bottom half are different and both can be read, the pin for the highest bit is connected correctly. Stefan From rminnich at lanl.gov Sat Feb 25 22:35:42 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sat, 25 Feb 2006 14:35:42 -0700 Subject: [LinuxBIOS] Checking if FlashROM pin A18 is connected? In-Reply-To: <4400CC7A.6090100@mailcan.com> References: <4400CC7A.6090100@mailcan.com> Message-ID: <4400CDAE.60708@lanl.gov> Leon Woestenberg wrote: > Hello, > > I have a 512 kByte FlashROM but use 256 kByte images so far. I > concatenate two of them, so even if address pin A18 is dangling, the CPU > reads the image correctly. > > Now, if I understand correctly, the util/flashrom utility writes (-w) > using the Flash programming algorithms, which do not touch A18. And if I > understand correctly, it used > mmap() to verify the image, which should use A18. > > Am I correct that by following this procedure, I can find out whether > A18 is connected on my motherboard to the FlashROM socket? : > > dd if=/dev/random of=/tmp/random.bin bs=1024 count=512 > > flashrom -w /tmp/random.bin > flashrom -v tmp/random.bin > > VERIFIED => A18 is connected yeah, that ought to work. For this purpose, just for my own sanity, I usually make the image a file of ascending 32-bit numbers. Then you can use flashrom -r to make sure the things look right, as well as your -v trick. ron From leonw at mailcan.com Sat Feb 25 22:47:12 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sat, 25 Feb 2006 22:47:12 +0100 Subject: [LinuxBIOS] Checking if FlashROM pin A18 is connected? In-Reply-To: <4400CDAE.60708@lanl.gov> References: <4400CC7A.6090100@mailcan.com> <4400CDAE.60708@lanl.gov> Message-ID: <4400D060.5070800@mailcan.com> Hello, Ronald G Minnich wrote: > Leon Woestenberg wrote: >> dd if=/dev/random of=/tmp/random.bin bs=1024 count=512 >> >> flashrom -w /tmp/random.bin >> flashrom -v tmp/random.bin >> >> VERIFIED => A18 is connected > yeah, that ought to work. For this purpose, just for my own sanity, I > usually make the image a file of ascending 32-bit numbers. Then you > can use flashrom -r to make sure the things look right, as well as > your -v trick. Thanks. Just did this* and it seems that A18 is connected on my VIA EPIA-M10000. Regards, Leon *but instead of /dev/random I took a large vmlinuz file and truncated it at 512kBytes using dd. /dev/random was dead-slow (infunctional) on my EPIA. Maybe not enough entropy sources, dunno yet. From leonw at mailcan.com Sun Feb 26 00:22:15 2006 From: leonw at mailcan.com (Leon Woestenberg) Date: Sun, 26 Feb 2006 00:22:15 +0100 Subject: [LinuxBIOS] FILO Enabling VIA_SOUND breaks keyboard in Linux? [VIA EPIA-M10000] Message-ID: <4400E6A7.9040508@mailcan.com> Hello, further experimenting with EPIA-M10000: I am using the default FILO 0.4.2 "Config" for x86, except for the AUTOBOOT_FILE which I have set to: AUTOBOOT_FILE = "hdc1:/vmlinuz-2.6.12-10-386 initrd=hdc1:/initrd.img-2.6.12-10-386 root=/dev/hdc2 ro vga=771 console=tty0 console=ttyS0,115200" This time I tried enabling sound: SUPPORT_SOUND = 1 VIA_SOUND = 1 During booting it reported "No sound device found".* The next problem was I had keyboard control during the FILO console, but no longer in Linux. When I changed back to disabling sound and reflashing LinuxBIOS, this problem dissappeared. I have then fully reproduced this whole sequence again from the start. Can the FILO sound probe do this? I thought it is merely scanning PCI? Regards, Leon. * leon at nehemiah:~/sandbox/filo-0.4.2$ sudo lspci -s 00:11.5 0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) leon at nehemiah:~/sandbox/filo-0.4.2$ sudo lspci -n -s 00:11.5 0000:00:11.5 0401: 1106:3059 (rev 50) whereas: leon at nehemiah:~/sandbox/filo-0.4.2/drivers$ tail -n 3 via-sound.c struct sound_driver viasnd_driver[] __sound_driver = { {0x1106, 0x3058, &viasnd_ops}, /* VT82C686 AC97 Audio Controller */ }; From a.borisov at tesv.tmb.ru Sun Feb 26 16:00:07 2006 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Sun, 26 Feb 2006 18:00:07 +0300 Subject: [LinuxBIOS] How to ID flash chip type from software? Message-ID: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> Hello. There is a tricky case - I can't see which exactly flash chip installed in system. flashrom from v2161 was unable to identify it too. I found an interesting site - http://ctflasher.sourceforge.net - however this tool doesn't have bios-flasher yet. lspci -v 00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface Flags: bus master, fast devsel, latency 0 Memory at f8000000 (32-bit, prefetchable) [size=64M] Capabilities: [e4] #09 [0106] 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corp.: Unknown device 4246 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at f0000000 (32-bit, prefetchable) [size=128M] Memory at ffa00000 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Expansion ROM at [disabled] Capabilities: [d0] Power Management version 1 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: ff900000-ff9fffff 00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Intel Corp.: Unknown device 4246 Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at ffa0 [size=16] Memory at 1f000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) Subsystem: Intel Corp.: Unknown device 4246 Flags: medium devsel, IRQ 10 I/O ports at e800 [size=32] 01:01.0 Ethernet controller: Intel Corp.: Unknown device 107c (rev 05) Subsystem: Intel Corp.: Unknown device 1376 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 15 Memory at ff900000 (32-bit, non-prefetchable) [size=128K] Memory at ff920000 (32-bit, non-prefetchable) [size=128K] I/O ports at d800 [size=64] Expansion ROM at ff940000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. 01:02.0 Ethernet controller: Intel Corp.: Unknown device 107c (rev 05) Subsystem: Intel Corp.: Unknown device 1376 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10 Memory at ff960000 (32-bit, non-prefetchable) [size=128K] Memory at ff980000 (32-bit, non-prefetchable) [size=128K] I/O ports at d400 [size=64] Expansion ROM at ff9a0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] PCI-X non-bridge device. 01:08.0 Ethernet controller: Intel Corp. 82562EZ 10/100 Ethernet Controller (rev 01) Subsystem: Intel Corp.: Unknown device 302f Flags: bus master, medium devsel, latency 32, IRQ 5 Memory at ff9d0000 (32-bit, non-prefetchable) [size=4K] I/O ports at d000 [size=64] Capabilities: [dc] Power Management version 2 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 1 cpu MHz : 2994.007 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid xtpr bogomips : 5914.62 Thanks. -- Sincerely, Anton Borisov From stuge-linuxbios at cdy.org Sun Feb 26 16:55:54 2006 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 26 Feb 2006 16:55:54 +0100 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> Message-ID: <20060226155554.16626.qmail@cdy.org> On Sun, Feb 26, 2006 at 06:00:07PM +0300, Anton Borisov wrote: > Hello. > There is a tricky case - I can't see which exactly flash chip > installed in system. flashrom from v2161 was unable to identify it > too. I found an interesting site - http://ctflasher.sourceforge.net > - however this tool doesn't have bios-flasher yet. If the requirement is to use software only then perhaps you can make flashrom print vendor ID and product ID - and use that as reference? If you do have access to the hardware I suggest identifying the flash chip visually. http://wiki.linuxbios.org/index.php/FAQ#How_do_I_identify_the_BIOS_chip_on_my_mainboard.3F Peel the shiny sticker off the chip if there is one and copy the chip manufacturer name and model number to the list if you don't recognize them. //Peter From rminnich at lanl.gov Sun Feb 26 16:46:42 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sun, 26 Feb 2006 08:46:42 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> Message-ID: <4401CD62.2010109@lanl.gov> that's almost certainly going to be an intel firmware hub. The odds are that flashrom can't idea because there is a GPIO somewhere enforcing a write protect. What kind of system is this again? ron From a.borisov at tesv.tmb.ru Sun Feb 26 16:59:19 2006 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Sun, 26 Feb 2006 18:59:19 +0300 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226155554.16626.qmail@cdy.org> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> Message-ID: <20060226185919.07716046.a.borisov@tesv.tmb.ru> On Sun, 26 Feb 2006 16:55:54 +0100 Peter Stuge wrote: > On Sun, Feb 26, 2006 at 06:00:07PM +0300, Anton Borisov wrote: > > Hello. > > There is a tricky case - I can't see which exactly flash chip > > installed in system. flashrom from v2161 was unable to identify it > > too. I found an interesting site - http://ctflasher.sourceforge.net > > - however this tool doesn't have bios-flasher yet. > > If the requirement is to use software only then perhaps you can make > flashrom print vendor ID and product ID - and use that as reference? Alas, nothing informative. Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 788M loops per second OK, calibrated, now do the deed Trying Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Trying At29C040A, 512 KB probe_jedec: id1 0xff, id2 0xff Trying Mx29f002, 256 KB probe_29f002: id1 0xdf, id2 0x24 Trying SST29EE020A, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Trying SST39SF020A, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying SST39VF020, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying SST49LF040, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF002A/B, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying SST49LF003A/B, 384 KB probe_jedec: id1 0x47, id2 0x97 Trying SST49LF004A/B, 512 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF008A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying Pm49FL004, 512 KB probe_jedec: id1 0xff, id2 0xff Trying W29C011, 128 KB probe_jedec: id1 0xff, id2 0xff Trying W29C020C, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying W49F002U, 256 KB probe_jedec: id1 0xdf, id2 0x24 Trying M29F400BT, 512 KB probe_m29f400bt: id1 0xff, id2 0xff Trying 82802ab, 512 KB probe_82802ab: id1 0xff, id2 0xff Trying 82802ac, 1024 KB probe_82802ab: id1 0xff, id2 0xff Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB probe_md2802: probe_md2802: ******************************* probe_md2802: * THIS IS A PRE ALPHA VERSION * probe_md2802: * IN THE DEVELOPEMENT ********* probe_md2802: * PROCESS RIGHT NOW. ********** probe_md2802: ******************************* probe_md2802: * IF YOU ARE NOT A DEVELOPER ** probe_md2802: * THEN DO NOT TRY TO READ OR ** probe_md2802: * WRITE TO THIS DEVICE ******** probe_md2802: ******************************* probe_md2802: probe_md2802: switching off reset mode ... probe_md2802: switching off reset mode ... done probe_md2802: probe_md2802: switching off write protection ... probe_md2802: switching off write protection ... done probe_md2802: probe_md2802: IPL_0x0000: 0x00 probe_md2802: IPL_0x0001: 0x00 probe_md2802: IPL_0x0002: 0x00 probe_md2802: IPL_0x0003: 0x00 probe_md2802: probe_md2802: ChipID: 0x8c probe_md2802: DOCStatus: 0xc8 probe_md2802: FloorSelect: 0x00 probe_md2802: CDSNControl: 0xf0 probe_md2802: CDSNDeviceSelect: 0x3d probe_md2802: ECCConfiguration: 0x00 probe_md2802: CDSNSlowIO: 0x00 probe_md2802: ECCSyndrome0: 0xe3 probe_md2802: ECCSyndrome1: 0x8e probe_md2802: ECCSyndrome2: 0x00 probe_md2802: ECCSyndrome3: 0xf0 probe_md2802: ECCSyndrome4: 0x00 probe_md2802: ECCSyndrome5: 0x00 probe_md2802: AliasResolution: 0x00 probe_md2802: ConfigurationInput: 0x00 probe_md2802: ReadPipelineInitialization: 0x00 probe_md2802: LastDataRead: 0x00 probe_md2802: probe_md2802: checking ECCConfiguration toggle bit probe_md2802: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 probe_md2802: toggle result: 0/0 EEPROM not found > > If you do have access to the hardware I suggest identifying the flash > chip visually. Unfortunately, I don't have it. -- Sincerely, Anton Borisov From stepan at openbios.org Sun Feb 26 17:57:38 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sun, 26 Feb 2006 17:57:38 +0100 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226185919.07716046.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> Message-ID: <20060226165738.GA19093@openbios.org> This looks like you are very well able to recognize the flash chip, only the flashrom tool does not know about it: [..] probe_jedec: id1 0xdf, id2 0x24 [..] I don't have my list of IDs at hand at the moment, but this should not be too hard to fix. Also, you should update to a later version of flashrom (ie latest svn), there's development on that one here and there. Stefan * Anton Borisov [060226 16:59]: > On Sun, 26 Feb 2006 16:55:54 +0100 > Peter Stuge wrote: > > > On Sun, Feb 26, 2006 at 06:00:07PM +0300, Anton Borisov wrote: > > > Hello. > > > There is a tricky case - I can't see which exactly flash chip > > > installed in system. flashrom from v2161 was unable to identify it > > > too. I found an interesting site - http://ctflasher.sourceforge.net > > > - however this tool doesn't have bios-flasher yet. > > > > If the requirement is to use software only then perhaps you can make > > flashrom print vendor ID and product ID - and use that as reference? > > Alas, nothing informative. > > Calibrating timer since microsleep sucks ... takes a second > Setting up microsecond timing loop > 788M loops per second > OK, calibrated, now do the deed > Trying Am29F040B, 512 KB > probe_29f040b: id1 0xff, id2 0xff > Trying At29C040A, 512 KB > probe_jedec: id1 0xff, id2 0xff > Trying Mx29f002, 256 KB > probe_29f002: id1 0xdf, id2 0x24 > Trying SST29EE020A, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST28SF040A, 512 KB > probe_28sf040: id1 0xff, id2 0xff > Trying SST39SF020A, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST39VF020, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST49LF040, 512 KB > probe_jedec: id1 0xff, id2 0xff > Trying SST49LF080A, 1024 KB > probe_jedec: id1 0xff, id2 0xff > Trying SST49LF002A/B, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST49LF003A/B, 384 KB > probe_jedec: id1 0x47, id2 0x97 > Trying SST49LF004A/B, 512 KB > probe_jedec: id1 0xff, id2 0xff > Trying SST49LF008A, 1024 KB > probe_jedec: id1 0xff, id2 0xff > Trying Pm49FL004, 512 KB > probe_jedec: id1 0xff, id2 0xff > Trying W29C011, 128 KB > probe_jedec: id1 0xff, id2 0xff > Trying W29C020C, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying W49F002U, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying M29F400BT, 512 KB > probe_m29f400bt: id1 0xff, id2 0xff > Trying 82802ab, 512 KB > probe_82802ab: id1 0xff, id2 0xff > Trying 82802ac, 1024 KB > probe_82802ab: id1 0xff, id2 0xff > Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB > probe_md2802: > probe_md2802: ******************************* > probe_md2802: * THIS IS A PRE ALPHA VERSION * > probe_md2802: * IN THE DEVELOPEMENT ********* > probe_md2802: * PROCESS RIGHT NOW. ********** > probe_md2802: ******************************* > probe_md2802: * IF YOU ARE NOT A DEVELOPER ** > probe_md2802: * THEN DO NOT TRY TO READ OR ** > probe_md2802: * WRITE TO THIS DEVICE ******** > probe_md2802: ******************************* > probe_md2802: > probe_md2802: switching off reset mode ... > probe_md2802: switching off reset mode ... done > probe_md2802: > probe_md2802: switching off write protection ... > probe_md2802: switching off write protection ... done > probe_md2802: > probe_md2802: IPL_0x0000: 0x00 > probe_md2802: IPL_0x0001: 0x00 > probe_md2802: IPL_0x0002: 0x00 > probe_md2802: IPL_0x0003: 0x00 > probe_md2802: > probe_md2802: ChipID: 0x8c > probe_md2802: DOCStatus: 0xc8 > probe_md2802: FloorSelect: 0x00 > probe_md2802: CDSNControl: 0xf0 > probe_md2802: CDSNDeviceSelect: 0x3d > probe_md2802: ECCConfiguration: 0x00 > probe_md2802: CDSNSlowIO: 0x00 > probe_md2802: ECCSyndrome0: 0xe3 > probe_md2802: ECCSyndrome1: 0x8e > probe_md2802: ECCSyndrome2: 0x00 > probe_md2802: ECCSyndrome3: 0xf0 > probe_md2802: ECCSyndrome4: 0x00 > probe_md2802: ECCSyndrome5: 0x00 > probe_md2802: AliasResolution: 0x00 > probe_md2802: ConfigurationInput: 0x00 > probe_md2802: ReadPipelineInitialization: 0x00 > probe_md2802: LastDataRead: 0x00 > probe_md2802: > probe_md2802: checking ECCConfiguration toggle bit > probe_md2802: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > probe_md2802: toggle result: 0/0 > EEPROM not found > > > > > > If you do have access to the hardware I suggest identifying the flash > > chip visually. > > Unfortunately, I don't have it. > > > -- > Sincerely, Anton Borisov > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From smithbone at gmail.com Sun Feb 26 18:49:50 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 26 Feb 2006 11:49:50 -0600 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226165738.GA19093@openbios.org> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> <20060226165738.GA19093@openbios.org> Message-ID: <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> On 2/26/06, Stefan Reinauer wrote: > This looks like you are very well able to recognize the flash chip, only > the flashrom tool does not know about it: > > [..] > probe_jedec: id1 0xdf, id2 0x24 > [..] > > I don't have my list of IDs at hand at the moment, but this should not > be too hard to fix. According to the 106-k list I found 0xdf is PCMCIA. -- Richard A. Smith From stepan at openbios.org Sun Feb 26 19:25:26 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sun, 26 Feb 2006 19:25:26 +0100 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> <20060226165738.GA19093@openbios.org> <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> Message-ID: <20060226182526.GA29188@openbios.org> * Richard Smith [060226 18:49]: > > I don't have my list of IDs at hand at the moment, but this should not > > be too hard to fix. > > According to the 106-k list I found 0xdf is PCMCIA. which means the PCMCIA industry group rather than the interface. Haven't ever seen such a flash part though. Stefan From rminnich at lanl.gov Sun Feb 26 21:12:44 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sun, 26 Feb 2006 13:12:44 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226155554.16626.qmail@cdy.org> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> Message-ID: <44020BBC.2080106@lanl.gov> Peter Stuge wrote: > Peel the shiny sticker off the chip if there is one and copy the chip > manufacturer name and model number to the list if you don't recognize > them. yes, and if you find a really neat use for the shiny sticker, let us know :-) ron From rminnich at lanl.gov Sun Feb 26 21:15:52 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sun, 26 Feb 2006 13:15:52 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226185919.07716046.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> Message-ID: <44020C78.7050108@lanl.gov> Anton Boriso > Calibrating timer since microsleep sucks ... takes a second > Setting up microsecond timing loop > 788M loops per second > OK, calibrated, now do the deed > Trying Am29F040B, 512 KB > probe_29f040b: id1 0xff, id2 0xff > Trying At29C040A, 512 KB so it's almost certainly not a 512KB, since you are reading 0xff > probe_jedec: id1 0xff, id2 0xff > Trying Mx29f002, 256 KB > probe_29f002: id1 0xdf, id2 0x24 0xdf, 0x24 now you could try dumping the bios without flashrom. if the first two bytes are not df,24 then you are probably doing an ID cycle, and flashrom just doesn't know this ID. If the bytes ARE df,24, then write protection may be in effect. > Trying SST29EE020A, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST28SF040A, 512 KB > probe_28sf040: id1 0xff, id2 0xff > Trying SST39SF020A, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST39VF020, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST49LF040, 512 KB > probe_jedec: id1 0xff, id2 0xff > Trying SST49LF080A, 1024 KB > probe_jedec: id1 0xff, id2 0xff > Trying SST49LF002A/B, 256 KB > probe_jedec: id1 0xdf, id2 0x24 > Trying SST49LF003A/B, 384 KB > probe_jedec: id1 0x47, id2 0x97 interesting. based on this, I'm guessing a 256kB part. Let us know if you can get the #. ron From rminnich at lanl.gov Sun Feb 26 21:16:43 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Sun, 26 Feb 2006 13:16:43 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> <20060226165738.GA19093@openbios.org> <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> Message-ID: <44020CAB.6000200@lanl.gov> Richard Smith wrote: > On 2/26/06, Stefan Reinauer wrote: > >>This looks like you are very well able to recognize the flash chip, only >>the flashrom tool does not know about it: >> >>[..] >>probe_jedec: id1 0xdf, id2 0x24 >>[..] >> >>I don't have my list of IDs at hand at the moment, but this should not >>be too hard to fix. > > > According to the 106-k list I found 0xdf is PCMCIA. > eh? PCMCIA is not a vendor. What does this mean? ron From stepan at openbios.org Sun Feb 26 21:24:14 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sun, 26 Feb 2006 21:24:14 +0100 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <44020BBC.2080106@lanl.gov> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <44020BBC.2080106@lanl.gov> Message-ID: <20060226202414.GA6457@openbios.org> * Ronald G Minnich [060226 21:12]: > Peter Stuge wrote: > > > Peel the shiny sticker off the chip if there is one and copy the chip > > manufacturer name and model number to the list if you don't recognize > > them. > > yes, and if you find a really neat use for the shiny sticker, let us > know :-) This is an interesting topic. At home there's one on my ash tray but I usually put them on the wastebaskets... I'm always looking for better ideas ;-) Stefan From smithbone at gmail.com Sun Feb 26 21:24:27 2006 From: smithbone at gmail.com (Richard Smith) Date: Sun, 26 Feb 2006 14:24:27 -0600 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226182526.GA29188@openbios.org> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> <20060226165738.GA19093@openbios.org> <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> <20060226182526.GA29188@openbios.org> Message-ID: <8a0c36780602261224o80ebd71wfcda74ed78f09e8e@mail.gmail.com> > * Richard Smith [060226 18:49]: > > > I don't have my list of IDs at hand at the moment, but this should not > > > be too hard to fix. > > > > According to the 106-k list I found 0xdf is PCMCIA. > > which means the PCMCIA industry group rather than the interface. Haven't > ever seen such a flash part though. My google searches came up with nothing. Perhaps you should try to go about it by finding out what mainboard mfg it is and trying to find some specs on it. A lot of time they will list the flash size and sometimes the actual part. Attempting to flash a board that you don't have physical access to seems pretty bold. -- Richard A. Smith From stepan at openbios.org Sun Feb 26 21:26:45 2006 From: stepan at openbios.org (Stefan Reinauer) Date: Sun, 26 Feb 2006 21:26:45 +0100 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <44020CAB.6000200@lanl.gov> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060226185919.07716046.a.borisov@tesv.tmb.ru> <20060226165738.GA19093@openbios.org> <8a0c36780602260949n222e46c7xae75dfcf9f7d9717@mail.gmail.com> <44020CAB.6000200@lanl.gov> Message-ID: <20060226202645.GA7235@openbios.org> * Ronald G Minnich [060226 21:16]: > > eh? PCMCIA is not a vendor. What does this mean? It's this PCMCIA group, whatever, I assumed they made some demo parts at max. Maybe some other user is "misusing" the ID. Stefan From a.borisov at tesv.tmb.ru Mon Feb 27 08:21:37 2006 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Mon, 27 Feb 2006 10:21:37 +0300 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060226155554.16626.qmail@cdy.org> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> Message-ID: <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> On Sun, 26 Feb 2006 16:55:54 +0100 Peter Stuge wrote: > Peel the shiny sticker off the chip if there is one and copy the chip > manufacturer name and model number to the list if you don't recognize > them. There is no shiny sticker. It has a soldered chip. SST49LF004B. -- Sincerely, Anton Borisov From rminnich at lanl.gov Mon Feb 27 15:22:24 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Mon, 27 Feb 2006 07:22:24 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> Message-ID: <44030B20.9040609@lanl.gov> Anton Borisov wrote: > On Sun, 26 Feb 2006 16:55:54 +0100 > Peter Stuge wrote: > > >>Peel the shiny sticker off the chip if there is one and copy the chip >>manufacturer name and model number to the list if you don't recognize >>them. > > > There is no shiny sticker. It has a soldered chip. SST49LF004B. > > ah. LPC part, maybe firmware hub compatible. Since it could not be ID'ed by flashrom, and it is an included part, then it is protected by additional hardware. Unless it is just the ICH5 bios protect, which I just added support for. You can try to svn up and rebuild flashrom and try again. ron From smithbone at gmail.com Mon Feb 27 15:38:43 2006 From: smithbone at gmail.com (Richard Smith) Date: Mon, 27 Feb 2006 08:38:43 -0600 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> Message-ID: <8a0c36780602270638n2e60fdefyf1397be60ee3e4f7@mail.gmail.com> On 2/27/06, Anton Borisov wrote: > On Sun, 26 Feb 2006 16:55:54 +0100 > Peter Stuge wrote: > > > Peel the shiny sticker off the chip if there is one and copy the chip > > manufacturer name and model number to the list if you don't recognize > > them. > > There is no shiny sticker. It has a soldered chip. SST49LF004B. According to the datasheet I got from here: http://www.sst.com/products.xhtml/serial_flash/49/SST49LF004B The Mfg ID of that part is a 0xBF not 0xDF. -- Richard A. Smith From rminnich at lanl.gov Mon Feb 27 15:42:45 2006 From: rminnich at lanl.gov (Ronald G Minnich) Date: Mon, 27 Feb 2006 07:42:45 -0700 Subject: [LinuxBIOS] How to ID flash chip type from software? In-Reply-To: <8a0c36780602270638n2e60fdefyf1397be60ee3e4f7@mail.gmail.com> References: <20060226180007.605c996e.a.borisov@tesv.tmb.ru> <20060226155554.16626.qmail@cdy.org> <20060227102137.71e351ca.a.borisov@tesv.tmb.ru> <8a0c36780602270638n2e60fdefyf1397be60ee3e4f7@mail.gmail.com> Message-ID: <44030FE5.60607@lanl.gov> Richard Smith wrote: > On 2/27/06, Anton Borisov wrote: > >>On Sun, 26 Feb 2006 16:55:54 +0100 >>Peter Stuge wrote: >> >> >>>Peel the shiny sticker off the chip if there is one and copy the chip >>>manufacturer name and model number to the list if you don't recognize >>>them. >> >> There is no shiny sticker. It has a soldered chip. SST49LF004B. > > > According to the datasheet I got from here: > > http://www.sst.com/products.xhtml/serial_flash/49/SST49LF004B > > The Mfg ID of that part is a 0xBF not 0xDF. Right. I bet if he dumps the top 256KB of memory (fffc0000 -ffffffff) he will see df is the first byte of the bios. The writes to the part, which you need to do for ID purposes, are not happening. They are disabled by some external hardware. Vendors do this all the time --- hookup up a GPIO to an and or or gate and don't tell anyone. ron From ollie at lanl.gov Mon Feb 27 17:50:09 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon, 27 Feb 2006 09:50:09 -0700 Subject: [LinuxBIOS] EPIA-M VGA BIOS - X gives VIA(0): Bad V-BIOS checksum In-Reply-To: <43FDE6B8.5060009@mailcan.com> References: <43FDE6B8.5060009@mailcan.com> Message-ID: <1141059009.19385.46.camel@logarithm.lanl.gov> On Thu, 2006-02-23 at 17:45 +0100, Leon Woestenberg wrote: > Hello all, > > my target: VIA EPIA-M 10000 > > Latest linuxbios (rev 2177) > > I extracted the VIA VGA BIOS from the EPIA running official BIOS rev. 1.13. > > However, my X server reports: > > VIA(0): Bad V-BIOS checksum. > > Everything before that looks good. Upon boot, I *do* get VGA output of FILO. > > Would could be the cause? See below for details on what I did. > > Regards, > > Leon. > I am not too familiar how VGA BIOS is inited by LB for EPIA. Does LB copy the VGA BIOS image to 0xC0000 and the emulator does? -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Mon Feb 27 19:29:07 2006 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon, 27 Feb 2006 11:29:07 -0700 Subject: [LinuxBIOS] RES: RES: Rumba target and AMD RDK THINCLIENT In-Reply-To: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov> References: <200602241929.k1OJSxT6009241@proofpoint2.lanl.gov> Message-ID: <1141064948.19385.51.camel@logarithm.lanl.gov> On Fri, 2006-02-24 at 16:28 -0300, Jardel Silveira wrote: > Dear Li-Ta Lo, > > > I?ve just tried to compile rumba now and i?ve got this ouput? > > N_OFFSET='0x0' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xfffd0000' > -DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0' > -DCONFIG_UDELAY_IO='0' > /home/jardel/projetos/LinuxBIOSv2/src/mainboard/amd/rumba/auto.c -o auto.inc > raminit.c:3.61: > struct mem_controller undeclared > make[1]: ** [auto.inc] Erro 1 > make[1]: Leaving directory > `/home/jardel/projetos/LinuxBIOSv2/targets/amd/rumba/rumba/normal' > make: ** [normal/linuxbios.rom] Erro 1 > jardel at jardel:~/projetos/LinuxBIOSv2/targets/amd/rumba/rumba$ ls > > I just committed other part of the change. Could you try it again? -- Li-Ta Lo Los Alamos National Lab From talbotx at comcast.net Tue Feb 28 22:50:36 2006 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 28 Feb 2006 13:50:36 -0800 Subject: [LinuxBIOS] does any one have access to the VT8237 docs Message-ID: <4404C5AC.80808@comcast.net> Still trying to get my EBC3266 board to post with linux bios. That board is based on the VT8623 and VT8237 chips. I currently am unable to get any console. I would guess that is because I am unable to start the south bridge, where the vt1211 is attached. I was hoping that is was close enughf to the VT8235, but I guess I am wrong. OK, time to start trying to add support for the VT8237 south bridge. Does any one have access to the Docs for the VT8237? -Adam Talbot