From Yellow_onion at orcon.net.nz Wed Aug 1 00:11:01 2007 From: Yellow_onion at orcon.net.nz (Daniel) Date: Wed, 01 Aug 2007 10:11:01 +1200 Subject: [LinuxBIOS] Will it work? In-Reply-To: <20070730215221.GA3935@cosmic.amd.com> References: <46AE2DAD.6060300@orcon.net.nz> <20070730214416.20565.qmail@stuge.se> <20070730215221.GA3935@cosmic.amd.com> Message-ID: <46AFB375.7080100@orcon.net.nz> Jordan Crouse wrote: > On 30/07/07 23:44 +0200, Peter Stuge wrote: > >> Hi Daniel, >> >> On Tue, Jul 31, 2007 at 06:27:57AM +1200, Daniel Hill wrote: >> >>> Im just wondering if this is compatible with my computer >>> >>> AMD Athlon 64 Processor 3200+ (Venice) >>> MSI K8N Neo4 Platinum (PCB 1.0) (MS-7125) >>> >> The mainboard is not supported per se.. >> >> >> >>> 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller >>> (rev a3) >>> >> ..but K8 and CK804 are both supported, so it could probably be made >> to work if you're interested in getting into the code >> I have Basic Programming knowledge ( with C# also know a bit of bash and php) I think i will be able to pick up on C pretty easily >> >> >>> PLCC BIOS >>> >> Is it socketed? >> >> Not sure what you mean by socketed but it looks exactly the same as Pictured in your FAQ >>> Winbond W38627THF >>> >> W83627HF is supported so THF will probably work too, or only need >> minor changes in the code. >> >> >> >>> Also wondering if it will work using window x64? >>> >> I guess so, XP was booted by LB recently. >> >> Don't Use x64 much anymore hate the whole "restart for settings to take affect" I assume it will work as it basicly is the same as winxp but has 64bit binaries and doesn't use any BIOS calls and it does boot from grub >>> and I assume freeDOS wouldn't work either? >>> >> I don't see why it wouldn't work? The K8 can run 32-bit code? >> I would have thought that FreeDOS used alot of BIOS calls as it seams to work "as is" with out any drivers (based off the fact that it runs off a floppy) and by the way FreeDOS is 16bit and it runs on my computer just doesn't pick up extended partitions also since win9x is based off MS-DOS I would have thought that's why it uses BIOS calls > Of course. > > Jordan > > From corey.osgood at gmail.com Wed Aug 1 07:59:07 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 01 Aug 2007 01:59:07 -0400 Subject: [LinuxBIOS] Is Asrock 775VM800 supported? In-Reply-To: <200707291016.14902.athaba@inode.at> References: <200707291016.14902.athaba@inode.at> Message-ID: <46B0212B.9090209@gmail.com> Christian Sturm wrote: > Corey Osgood wrote: > > >> At this time, no. vt8237r is a work in progress, but afaik >> noone's working on the p4m800. >> > > Thanks for the answer! > > >> Can you please send the output of lspci -n and lspci -xxx? >> > > Of course. > Thanks for the info, and sorry for the delayed reply. Looking at your register dump, it seems that the two are very similar, but unfortunately your board uses ddr memory, and everything I've done is geared towards ddr2. Should have checked that out before I got all excited, I guess. If you're interested in doing testing and have all the necessary equipment (serial cable, spare flash chips, etc), I'll look into it further when I'm done my current project (which should a couple more weeks at the absolute most). Some C coding skills would also really help. -Corey From augusto.pedroza at gmail.com Wed Aug 1 13:00:54 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Wed, 1 Aug 2007 08:00:54 -0300 Subject: [LinuxBIOS] LinuxBIOS Memory Error / Windows Vista Message-ID: Hy guys, While trying to boot vista installation DVD using linuxBIOS/qemu I got the following: LinuxBIOS-3.0.0 Mon Jul 30 20:36:58 BRT 2007 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram'. LAR: Start 0xfffc0000 len 0x40000 LAR: current filename is normal/initram LAR: current filename is normal/option_table LAR: current filename is normal/payload LAR: current filename is normal/stage2 LAR: current filename is linuxbios.bootblock LAR: copy_file: No such file 'fallback/initram' LAR: Run file fallback/initram failed: No such file. Failed RAM init code Has anyone tried that? What modifications do you guys suggest? Thanks, -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 1 13:45:37 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 01 Aug 2007 13:45:37 +0200 Subject: [LinuxBIOS] Use Linux MTD framework for SPI flash? In-Reply-To: <20070731214421.GA12417@coresystems.de> References: <46A924E6.5090900@gmx.net> <20070726234312.29083.qmail@stuge.se> <20070731152807.GA32249@cosmic.amd.com> <20070731211945.GA7915@coresystems.de> <20070731213315.GD32720@cosmic.amd.com> <20070731214421.GA12417@coresystems.de> Message-ID: <46B07261.1050207@gmx.net> On 31.07.2007 23:44, Stefan Reinauer wrote: > * Jordan Crouse [070731 23:33]: >>> In this scenario, who loads the correct kernel module(s)? >> The user. >> >>> Which southbridges does the MTD SPI code support? Last time I checked >>> only some ARM embedded systems were possibly supported. >> Sure - but what SPI southbridges does flashrom support? > > Exactly as many as mtd for x86 based systems: 0 I don't know how difficult it will be for the existing chipset support drivers in the MTD framework to add SPI support, but maybe it is easier than we think. * Nvidia CK804 * AMD 76X * Intel ICHx > Are there any plans for mtd to do hardware detection like /dev/bios or > flashrom do? MTD sort of has autodetection for SPI flash chips once the SPI southbridge has a driver loaded. BTW, that is something that bothers me about flashrom: You have to add probing support for every single flash chip to the code even if a new chip is detected by probe_jedec. Some generic JEDEC detection run for different sizes followed by a lookup in a id table would be so much nicer. In case flashing needs special code we still have to read the data sheets now and this won't get worse in the future, but having a message "Your flash chip was detected as unknown (id $ID) from $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@" would surely help a lot for adoption of flashrom. Regards, Carl-Daniel From otavio.junior at gmail.com Wed Aug 1 13:50:30 2007 From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=) Date: Wed, 1 Aug 2007 08:50:30 -0300 Subject: [LinuxBIOS] PIRQ REF DES AMD LXUVCRDK In-Reply-To: <469BE596.8070602@amd.com> References: <751d98080706200608w63943f12la6631f91ce26a177@mail.gmail.com> <467954AF.6090100@amd.com> <751d98080706200945q101d7fdicbfb20586e048649@mail.gmail.com> <4679960A.1000000@amd.com> <751d98080707130712saade1i2c9bc8355c9f8ee@mail.gmail.com> <469BE596.8070602@amd.com> Message-ID: <751d98080708010450y2cf09e99y448b7aaae3f733fd@mail.gmail.com> Hello to all, Marc wrote: >Looks like the RAMDISK is blowing up. Try without it. Try running a >memory test. You can built memtest as a payload. I've used memtest as a payload and the test was sucessfully. Any other idea for the RAMDISK blow up? Bellow the log of the linuxbios + memtest try out. My board is similar to AMD RDK UVC. Thanks, Ot?vio Alc?ntara LinuxBIOS-2.0.0.0Fallback Qua Jul 25 07:18:07 BRT 2007 starting... _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000498:07de0020 Done cpuRegInit SMBUS READ ERROR:03 device:a2 Ram1.00 Ram2.00 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 Ram3 DRAM controller init done. RAM DLL lock Ram4 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Qua Jul 25 07:37:45 BRT 2007 booting... clocks_per_usec: 432 Enumerating buses... Enter northbridge_init_early writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003 sizeram: _MSR MC_CF07_DATA: 10077014:00004840 sizeram: sizem 0x200MB SysmemInit: enable for 512MBytes usable RAM: 536739839 bytes SysmemInit: MSR 0x10000028, val 0x2000001f:0xfdf00100 sizeram: _MSR MC_CF07_DATA: 10077014:00004840 sizeram: sizem 0x200MB SMMGL0Init: 536739840 bytes SMMGL0Init: offset is 0x80400000 SMMGL0Init: MSR 0x10000026, val 0x29fbe080:0x400fffe0 writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003 sizeram: _MSR MC_CF07_DATA: 10077014:00004840 sizeram: sizem 0x200MB SysmemInit: enable for 512MBytes usable RAM: 536739839 bytes SysmemInit: MSR 0x4000002a, val 0x2000001f:0xfdf00100 SMMGL1Init: SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x11FFDF00 CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 L2 cache enabled Enabling cache GLPCI R1: system msr.lo 0x00100130 msr.hi 0x1ffdf000 GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 Exit northbridge_init_early Done cpubug fixes Not Doing ChipsetFlashSetup() <<>> Graphics init... <>> VRC_VG value: 0xffff Before VSA: do_vsmbios buf ilen 35441 olen60466 buf 00060000 *buf 186 buf[256k] 255 buf[0x20] signature is b0:10:e6:80 Call real_mode_switch_call_vsm biosint: INT# 0x15 biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx 0x10000028 biosint: ebp 0x17ed4 esp 0xff0 edi 0x8a71 esi 0x38 biosint: ip 0x5b3 cs 0x6000 flags 0x46 biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 handleint21, eax 0xbea7 biosint: INT# 0x15 biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx 0x10000028 biosint: ebp 0x17ed4 esp 0xfee edi 0x8a71 esi 0x38 biosint: ip 0x5c1 cs 0x6000 flags 0x46 biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 handleint21, eax 0xbea4 do_vsmbios: VSA2 VR signature verified After VSA: <<>> Graphics init... <>> VRC_VG value: 0x2808 Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 00 PCI: 00:01.0 [1022/2080] enabled PCI: 00:01.1 [1022/2081] enabled PCI: 00:01.2 [1022/2082] enabled cs5536: southbridge_enable: dev is 00010180 Disabling static device: PCI: 00:0b.0 cs5536: southbridge_enable: dev is 00010420 Disabling static device: PCI: 00:0c.0 cs5536: southbridge_enable: dev is 000106c0 PCI: 00:0d.0 [10ec/8139] enabled cs5536: southbridge_enable: dev is 00010960 Disabling static device: PCI: 00:0e.0 cs5536: southbridge_enable: dev is 00010c00 PCI: 00:0f.0 [1022/2090] enabled cs5536: southbridge_enable: dev is 00010ea0 PCI: 00:0f.2 [1022/209a] enabled cs5536: southbridge_enable: dev is 00011140 PCI: 00:0f.3 [1022/2093] enabled cs5536: southbridge_enable: dev is 000113e0 PCI: 00:0f.4 [1022/2094] enabled cs5536: southbridge_enable: dev is 00011680 PCI: 00:0f.5 [1022/2095] enabled PCI: 00:0f.6 [1022/2096] enabled PCI: 00:0f.7 [1022/2097] enabled PCI: pci_scan_bus returning with max=000 done Allocating resources... Reading resources... Done reading resources. Setting resources... PCI: 00:01.1 10 <- [0x00fd000000 - 0x00fdffffff] mem PCI: 00:01.1 14 <- [0x00fe000000 - 0x00fe003fff] mem PCI: 00:01.1 18 <- [0x00fe004000 - 0x00fe007fff] mem PCI: 00:01.1 1c <- [0x00fe008000 - 0x00fe00bfff] mem PCI: 00:01.1 20 <- [0x00fe00c000 - 0x00fe00ffff] mem PCI: 00:01.2 10 <- [0x00fe010000 - 0x00fe013fff] mem PCI: 00:0d.0 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:0d.0 14 <- [0x00fe019000 - 0x00fe0190ff] mem PCI: 00:0f.0 10 <- [0x0000001cb0 - 0x0000001cb7] io PCI: 00:0f.0 14 <- [0x0000001400 - 0x00000014ff] io PCI: 00:0f.0 18 <- [0x0000001c00 - 0x0000001c3f] io PCI: 00:0f.0 1c <- [0x0000001c80 - 0x0000001c9f] io PCI: 00:0f.0 20 <- [0x0000001800 - 0x000000187f] io PCI: 00:0f.0 24 <- [0x0000001c40 - 0x0000001c7f] io PCI: 00:0f.2 20 <- [0x0000001ca0 - 0x0000001caf] io PCI: 00:0f.3 10 <- [0x0000001880 - 0x00000018ff] io PCI: 00:0f.4 10 <- [0x00fe016000 - 0x00fe016fff] mem PCI: 00:0f.5 10 <- [0x00fe017000 - 0x00fe017fff] mem PCI: 00:0f.6 10 <- [0x00fe014000 - 0x00fe015fff] mem PCI: 00:0f.7 10 <- [0x00fe018000 - 0x00fe018fff] mem Done setting resources. Done allocating resources. Enabling resources... PCI: 00:01.0 cmd <- 145 PCI: 00:01.1 subsystem <- 00/00 PCI: 00:01.1 cmd <- 142 PCI: 00:01.2 cmd <- 142 PCI: 00:0d.0 subsystem <- 00/00 PCI: 00:0d.0 cmd <- 143 cs5536: cs5536_pci_dev_enable_resources() PCI: 00:0f.0 cmd <- 149 PCI: 00:0f.2 cmd <- 141 PCI: 00:0f.3 subsystem <- 00/00 PCI: 00:0f.3 cmd <- 141 PCI: 00:0f.4 subsystem <- 00/00 PCI: 00:0f.4 cmd <- 142 PCI: 00:0f.5 subsystem <- 00/00 PCI: 00:0f.5 cmd <- 142 PCI: 00:0f.6 cmd <- 142 PCI: 00:0f.7 cmd <- 142 done. Initializing devices... Root Device init Norwich ENTER init Norwich EXIT init PCI: 00:01.0 init PCI: 00:01.1 init PCI: 00:0d.0 init PCI: 00:0f.0 init cs5536: southbridge_init RTC Init rct_init finished PCI: 00:0f.2 init PCI: 00:0f.3 init PCI: 00:0f.4 init PCI: 00:0f.5 init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device 5a2 CPU: family 05, model 0a, stepping 02 model_lx_init Enabling cache A20 (0x92): 2 A20 (0x92): 2 CPU model_lx_init DONE CPU #0 Initialized PCI: 00:01.2 init PCI: 00:0f.6 init PCI: 00:0f.7 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 /home/otavio/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routing_table() - checksum is: 0x00 but should be: 0x96 done. write_pirq_routing_table(8000785C, BAAB) PIR Entry 0 Dev/Fn: 8 Slot: 0 INT: A bitmap: 800 PIRQ: 11 INT: B bitmap: 0 PIRQ: 0 INT: C bitmap: 0 PIRQ: 0 INT: D bitmap: 0 PIRQ: 0 Assigning IRQ 11 to 0:1.1 Readback = 11 Assigning IRQ 11 to 0:1.2 Readback = 11 PIR Entry 1 Dev/Fn: 78 Slot: 0 INT: A bitmap: 800 PIRQ: 11 INT: B bitmap: 400 PIRQ: 10 INT: C bitmap: 400 PIRQ: 10 INT: D bitmap: 800 PIRQ: 11 Assigning IRQ 10 to 0:f.3 Readback = 10 Assigning IRQ 11 to 0:f.4 Readback = 11 Assigning IRQ 11 to 0:f.5 Readback = 11 PIR Entry 2 Dev/Fn: 68 Slot: 0 INT: A bitmap: 800 PIRQ: 11 INT: B bitmap: 0 PIRQ: 0 INT: C bitmap: 0 PIRQ: 0 INT: D bitmap: 0 PIRQ: 0 Assigning IRQ 11 to 0:d.0 Readback = 11 PIR Entry 3 Dev/Fn: 0 Slot: 0 INT: A bitmap: 0 PIRQ: 0 INT: B bitmap: 0 PIRQ: 0 INT: C bitmap: 0 PIRQ: 0 INT: D bitmap: 0 PIRQ: 0 PIR Entry 4 Dev/Fn: 0 Slot: 0 INT: A bitmap: 0 PIRQ: 0 INT: B bitmap: 0 PIRQ: 0 INT: C bitmap: 0 PIRQ: 0 INT: D bitmap: 0 PIRQ: 0 PIR Entry 5 Dev/Fn: 0 Slot: 0 INT: A bitmap: 0 PIRQ: 0 INT: B bitmap: 0 PIRQ: 0 INT: C bitmap: 0 PIRQ: 0 INT: D bitmap: 0 PIRQ: 0 Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0400 to 0x00100000 Wrote linuxbios table at: 00000530 - 000006c4 checksum 379e Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfff89000 - 0xfffeffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 New segment addr 0x10000 size 0x17790 offset 0x1000 filesize 0x17790 (cleaned up) New segment addr 0x10000 size 0x17790 offset 0x1000 filesize 0x17790 Loading Segment: addr: 0x000000001f7bc000 memsz: 0x000000000000c000 filesz: 0x000000000000c000 Loading Segment: addr: 0x000000000001c000 memsz: 0x000000000000b790 filesz: 0x000000000000b790 Jumping to boot code at 0x10000  onINE_SCROLL;24rMemtest-86 v3.3 LinuxBIOS0KL1 Cache: Unknown L2 Cache: Unknown Memory : 503MChipset : . MHz4317off503M: :Pass %Test %Test #Testing: Pattern: WallTime Cached RsvdMem MemMap Cache ECC Test Pass Errors ECC Errs--------- ------ ------- -------- ----- --- ---- ---- ------ --------Std00-----------------------------------------------------------------------------| | | | | (ESC)exit (c)configuration (SP)scroll_lock (CR)scroll_unlock112K- 504M503M0 [Address test, walking ones, no cache]off0000000025#########000000ffffffff50##########0000000075##########ffffffff100##########1 on Relocated 0636Koff 00000000 25#########ffffffff50##########0000000075##########ffffffff100########## on  112504M1 own address]   25#8##11#4#7#20#3#6##9#232#5#8#41#4##7#50#2#5#8#361#4#7##70#3#46#9#82#5##8#591#4#7#100##Relocated 0636K  50###################100#################### 112504M2 Moving inversions, ones & zeros]  00000000 01623#456#78#791081#293#45016#178#293201#24354#566#778 On 7/16/07, Marc Jones wrote: > > Looks like the RAMDISK is blowing up. Try without it. Try running a > memory test. You can built memtest as a payload. > Marc > > > Ot?vio Alc?ntara wrote: > > > > Marc wrote: > > > > > > > Ot?vio, > > > Correct, you can't get graphics until a driver is loaded. For a > > > test/debug setup that uses the filo menu will only be visable serial. > > > Please see this link for the Geode LX framebuffer support. > > > http://thread.gmane.org/gmane > > > > > .linux.fbdev.devel/10339 > > > > > Marc > > > > > > Marc, > > > > I've compiled the kernel image with LX framebuffer driver and the > > video got fine! But, for some reason a kernel panic happens when loading > > initrd, I've used this initrd on other projects and worked very well. > > I'm putting the serial log bellow. Is there any chance to be a problem > > created by my bios? > > > > Thanks, > > > > Ot?vio Alc?ntara > > > > > > > > > > LinuxBIOS-2.0.0.0Fallback Qua Jun 20 07:45:43 BRT 2007 starting... > > _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000498:00001820 > > Configuring PLL > > > > > > LinuxBIOS-2.0.0.0Fallback Qua Jun 20 07:45:43 BRT 2007 starting... > > _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000498:07de0020 > > Done cpuRegInit > > SMBUS READ ERROR:03 device:a2 > > Ram1.00 > > Ram2.00 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > SMBUS READ ERROR:03 device:a2 > > Ram3 > > DRAM controller init done. > > RAM DLL lock > > Ram4 > > Copying LinuxBIOS to ram. > > Jumping to LinuxBIOS. > > LinuxBIOS-2.0.0.0Fallback Sex Jul 13 08:29:57 BRT 2007 booting... > > clocks_per_usec: 432 > > Enumerating buses... > > >> Entering northbridge.c: pci_domain_enable > > Enter northbridge_init_early > > writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 > > writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 > > writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003 > > sizeram: _MSR MC_CF07_DATA: 10077014:00004840 > > sizeram: sizem 0x200MB > > SysmemInit: enable for 512MBytes > > usable RAM: 536739839 bytes > > SysmemInit: MSR 0x10000028, val 0x2000001f:0xfdf00100 > > sizeram: _MSR MC_CF07_DATA: 10077014:00004840 > > sizeram: sizem 0x200MB > > SMMGL0Init: 536739840 bytes > > SMMGL0Init: offset is 0x80400000 > > SMMGL0Init: MSR 0x10000026, val 0x29fbe080:0x400fffe0 > > writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 > > writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 > > writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 > > writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003 > > sizeram: _MSR MC_CF07_DATA: 10077014:00004840 > > sizeram: sizem 0x200MB > > SysmemInit: enable for 512MBytes > > usable RAM: 536739839 bytes > > SysmemInit: MSR 0x4000002a, val 0x2000001f:0xfdf00100 > > SMMGL1Init: > > SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 > > writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 > > writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 > > CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x11FFDF00 > > CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 > > L2 cache enabled > > Enabling cache > > GLPCI R1: system msr.lo 0x00100130 msr.hi 0x1ffdf000 > > GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 > > Exit northbridge_init_early > > Done cpubug fixes > > Not Doing ChipsetFlashSetup() > > VRC_VG value: 0xffff > > Before VSA: > > do_vsmbios > > buf ilen 35441 olen60466 > > buf 00060000 *buf 186 buf[256k] 1 > > buf[0x20] signature is b0:10:e6:80 > > Call real_mode_switch_call_vsm > > biosint: INT# 0x15 > > biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx 0x10000028 > > biosint: ebp 0x15ed4 esp 0xff0 edi 0x8a71 esi 0x38 > > biosint: ip 0x5b3 cs 0x6000 flags 0x46 > > biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 > > handleint21, eax 0xbea7 > > biosint: INT# 0x15 > > biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx 0x10000028 > > biosint: ebp 0x15ed4 esp 0xfee edi 0x8a71 esi 0x38 > > biosint: ip 0x5c1 cs 0x6000 flags 0x46 > > biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 > > handleint21, eax 0xbea4 > > do_vsmbios: VSA2 VR signature verified > > After VSA: > > <<>> Graphics init... > > <>> VRC_VG value: 0x2808 > > Finding PCI configuration type. > > PCI: Using configuration type 1 > > PCI_DOMAIN: 0000 enabled > > APIC_CLUSTER: 0 enabled > > PCI: pci_scan_bus for bus 00 > > PCI: 00:01.0 [1022/2080] enabled > > PCI: 00:01.1 [1022/2081] enabled > > PCI: 00:01.2 [1022/2082] enabled > > PCI: 00:0d.0 [10ec/8139] enabled > > PCI: 00:0f.0 [1022/2090] enabled > > PCI: 00: 0f.2 [1022/209a] enabled > > PCI: 00:0f.3 [1022/2093] enabled > > PCI: 00:0f.4 [1022/2094] enabled > > PCI: 00:0f.5 [1022/2095] enabled > > PCI: 00:0f.6 [1022/2096] enabled > > PCI: 00:0f.7 [1022/2097] enabled > > PCI: pci_scan_bus returning with max=000 > > done > > Allocating resources... > > Reading resources... > > Done reading resources. > > Setting resources... > > PCI: 00:01.1 10 <- [0x00fd000000 - 0x00fdffffff] mem > > PCI: 00:01.1 14 <- [0x00fe000000 - 0x00fe003fff] mem > > PCI: 00:01.1 18 <- [0x00fe004000 - 0x00fe007fff] mem > > PCI: 00:01.1 1c <- [0x00fe008000 - 0x00fe00bfff] mem > > PCI: 00:01.1 20 <- [0x00fe00c000 - 0x00fe00ffff] mem > > PCI: 00:01.2 10 <- [0x00fe010000 - 0x00fe013fff] mem > > PCI: 00:0d.0 10 <- [0x0000001000 - 0x00000010ff] io > > PCI: 00:0d.0 14 <- [0x00fe019000 - 0x00fe0190ff] mem > > PCI: 00:0f.0 10 <- [0x0000001cb0 - 0x0000001cb7] io > > PCI: 00:0f.0 14 <- [0x0000001400 - 0x00000014ff] io > > PCI: 00:0f.0 18 <- [0x0000001c00 - 0x0000001c3f] io > > PCI: 00:0f.0 1c <- [0x0000001c80 - 0x0000001c9f] io > > PCI: 00:0f.0 20 <- [0x0000001800 - 0x000000187f] io > > PCI: 00:0f.0 24 <- [0x0000001c40 - 0x0000001c7f] io > > PCI: 00:0f.2 20 <- [0x0000001ca0 - 0x0000001caf] io > > PCI: 00:0f.3 10 <- [0x0000001880 - 0x00000018ff] io > > PCI: 00:0f.4 10 <- [0x00fe016000 - 0x00fe016fff] mem > > PCI: 00:0f.5 10 <- [0x00fe017000 - 0x00fe017fff] mem > > PCI: 00:0f.6 10 <- [0x00fe014000 - 0x00fe015fff] mem > > PCI: 00:0f.7 10 <- [0x00fe018000 - 0x00fe018fff] mem > > Done setting resources. > > Done allocating resources. > > Enabling resources... > > PCI: 00:01.0 cmd <- 145 > > PCI: 00:01.1 subsystem <- 00/00 > > PCI: 00:01.1 cmd <- 142 > > PCI: 00:01.2 cmd <- 142 > > PCI: 00:0d.0 cmd <- 143 > > cs5536: cs5536_pci_dev_enable_resources() > > PCI: 00:0f.0 cmd <- 149 > > PCI: 00:0f.2 cmd <- 141 > > PCI: 00:0f.3 cmd <- 141 > > PCI: 00:0f.4 cmd <- 142 > > PCI: 00:0f.5 cmd <- 142 > > PCI: 00:0f.6 cmd <- 142 > > PCI: 00:0f.7 cmd <- 142 > > done. > > Initializing devices... > > Root Device init > > Norwich ENTER init > > Norwich EXIT init > > PCI: 00:01.0 init > > PCI: 00:01.1 init > > APIC_CLUSTER: 0 init > > Initializing CPU #0 > > CPU: vendor AMD device 5a2 > > CPU: family 05, model 0a, stepping 02 > > model_lx_init > > Enabling cache > > A20 (0x92): 2 > > A20 (0x92): 2 > > CPU model_lx_init DONE > > CPU #0 Initialized > > PCI: 00:01.2 init > > PCI: 00:0d.0 init > > PCI: 00:0f.0 init > > cs5536: southbridge_init > > RTC Init > > rct_init finished > > Disabling VPCI device: 0x0000106C > > Disabling VPCI device: 0x00001075 > > Disabling VPCI device: 0x0000107E > > Disabling VPCI device: 0x00001087 > > Disabling VPCI device: 0x00001090 > > Disabling VPCI device: 0x00001099 > > Disabling VPCI device: 0x000010A2 > > Disabling VPCI device: 0x000010AB > > PCI: 00:0f.2 init > > PCI: 00:0f.3 init > > PCI: 00:0f.4 init > > PCI: 00:0f.5 init > > PCI: 00:0f.6 init > > PCI: 00:0f.7 init > > Devices initialized > > Copying IRQ routing tables to 0xf0000...done. > > Verifing copy of IRQ routing tables at 0xf0000...done > > Checking IRQ routing table consistency... > > check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 > > /home/otavio/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: > > 36:check_pirq_routing_table() - checksum is: 0x00 but should be: 0x96 > > done. > > write_pirq_routing_table(8000785C, BAAB) > > PIR Entry 0 Dev/Fn: 8 Slot: 0 > > INT: A bitmap: 800 PIRQ: 11 > > INT: B bitmap: 0 PIRQ: 0 > > INT: C bitmap: 0 PIRQ: 0 > > INT: D bitmap: 0 PIRQ: 0 > > Assigning IRQ 11 to 0: 1.1 > > Readback = 11 > > Assigning IRQ 11 to 0:1.2 > > Readback = 11 > > PIR Entry 1 Dev/Fn: 78 Slot: 0 > > INT: A bitmap: 800 PIRQ: 11 > > INT: B bitmap: 400 PIRQ: 10 > > INT: C bitmap: 400 PIRQ: 10 > > INT: D bitmap: 800 PIRQ: 11 > > Assigning IRQ 10 to 0:f.3 > > Readback = 10 > > Assigning IRQ 11 to 0:f.4 > > Readback = 11 > > Assigning IRQ 11 to 0:f.5 > > Readback = 11 > > PIR Entry 2 Dev/Fn: 68 Slot: 0 > > INT: A bitmap: 800 PIRQ: 11 > > INT: B bitmap: 0 PIRQ: 0 > > INT: C bitmap: 0 PIRQ: 0 > > INT: D bitmap: 0 PIRQ: 0 > > Assigning IRQ 11 to 0:d.0 > > Readback = 11 > > PIR Entry 3 Dev/Fn: 0 Slot: 0 > > INT: A bitmap: 0 PIRQ: 0 > > INT: B bitmap: 0 PIRQ: 0 > > INT: C bitmap: 0 PIRQ: 0 > > INT: D bitmap: 0 PIRQ: 0 > > PIR Entry 4 Dev/Fn: 0 Slot: 0 > > INT: A bitmap: 0 PIRQ: 0 > > INT: B bitmap: 0 PIRQ: 0 > > INT: C bitmap: 0 PIRQ: 0 > > INT: D bitmap: 0 PIRQ: 0 > > PIR Entry 5 Dev/Fn: 0 Slot: 0 > > INT: A bitmap: 0 PIRQ: 0 > > INT: B bitmap: 0 PIRQ: 0 > > INT: C bitmap: 0 PIRQ: 0 > > INT: D bitmap: 0 PIRQ: 0 > > Moving GDT to 0x500...ok > > Adjust low_table_end from 0x00000530 to 0x00001000 > > Adjust rom_table_end from 0x000f0400 to 0x00100000 > > Wrote linuxbios table at: 00000530 - 000006c4 checksum ec7f > > > > Welcome to elfboot, the open sourced starter. > > January 2002, Eric Biederman. > > Version 1.3 > > > > rom_stream: 0xfff89000 - 0xfffeffff > > Found ELF candidate at offset 0 > > header_offset is 0 > > Try to load at offset 0x0 > > New segment addr 0x100000 size 0x306e0 offset 0xc0 filesize 0xb248 > > (cleaned up) New segment addr 0x100000 size 0x306e0 offset 0xc0 filesize > > 0xb248 > > New segment addr 0x1306e0 size 0x48 offset 0xb320 filesize 0x48 > > (cleaned up) New segment addr 0x1306e0 size 0x48 offset 0xb320 filesize > 0x48 > > Dropping non PT_LOAD segment > > Dropping non PT_LOAD segment > > Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000306e0 > > filesz: 0x000000000000b248 > > Clearing Segment: addr: 0x000000000010b248 memsz: 0x0000000000025498 > > Loading Segment: addr: 0x00000000001306e0 memsz: 0x0000000000000048 > > filesz: 0x0000000000000048 > > Jumping to boot code at 0x108bdc > > FILO version 0.5 (otavio at labdes15) Fri Jul 13 08:05:08 BRT 2007 > > collect_linuxbios_info: Searching for LinuxBIOS tables... > > find_lb_table: Found canidate at: 00000530 > > find_lb_table: header checksum o.k. > > find_lb_table: table checksum o.k. > > find_lb_table: record count o.k. > > collect_linuxbios_info: Found LinuxBIOS table at: 00000530 > > convert_memmap: 0x00000000000000 0x00000000001000 16 > > convert_memmap: 0x00000000001000 0x0000000009f000 1 > > convert_memmap: 0x000000000f0000 0x00000000010000 16 > > convert_memmap: 0x00000000100000 0x0000001f6e0000 1 > > Press for default boot, or for boot prompt... 2 1 > > boot: hda1:/boot/vmlinuz root=/dev/hda1 initrd=/boot/initrd console=tty0 > > console=ttyS0,115200 > > hda: LBA 40GB: ST340014A > > Mounted ext2fs > > Found Linux version 2.6.18 (root at alexandre) #3 SMP Fri Jul 13 09:40:07 > > BRT 2007 (protocol 0x204) (loadflags 0x1) bzImage. > > init_linux_params: Setting up paramters at 0x90000 > > set_memory_size: 0000000000001000 - 00000000000a0000 > > set_memory_size: 0000000000100000 - 000000001f7e0000 > > set_memory_size: ramtop=0x1f7e0000 > > set_memory_size: ext_mem_k=64512, alt_mem_k=514944 > > parse_command_line: original command line: "root=/dev/hda1 > > initrd=/boot/initrd console=tty0 console=ttyS0,115200" > > parse_command_line: kernel command line at 0x91000 > > parse_command_line: initrd=/boot/initrd > > parse_command_line: kernel command line (48 bytes): "root=/dev/hda1 > > console=tty0 console=ttyS0,115200" > > load_linux_kernel: offset=0x1e00 addr=0x100000 size=0x11b91c > > Loading kernel... ok > > load_initrd: start=0x1f391000 end=0x1f7af000 > > Loading initrd... ok > > start_linux: eip=0x100000 > > Jumping to entry point... > > Linux version 2.6.18 (root at alexandre) (gcc version 4.1.2 20061115 > > (prerelease) (Debian 4.1.1-21)) #3 SMP Fri Jul 13 09:40:07 BRT 2007 > > BIOS-provided physical RAM map: > > BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) > > BIOS-e820: 0000000000100000 - 000000001f7e0000 (usable) > > 0MB HIGHMEM available. > > 503MB LOWMEM available. > > DMI not present or invalid. > > Allocating PCI resources starting at 20000000 (gap: 1f7e0000:e0820000) > > Detected 431.642 MHz processor. > > Built 1 zonelists. Total pages: 128992 > > Kernel command line: root=/dev/hda1 console=tty0 console=ttyS0,115200 > > No local APIC present or hardware disabled > > Initializing CPU#0 > > PID hash table entries: 2048 (order: 11, 8192 bytes) > > Console: colour dummy device 80x25 > > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > > Memory: 504340k/515968k available (1421k kernel code, 11104k reserved, > > 546k data, 160k init, 0k highmem) > > Checking if this processor honours the WP bit even in supervisor mode... > > Ok. > > Calibrating delay using timer specific routine.. 864.59 BogoMIPS > > (lpj=1729182) > > Security Framework v1.0.0 initialized > > SELinux: Disabled at boot. > > Capability LSM initialized > > Mount-cache hash table entries: 512 > > CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) > > CPU: L2 Cache: 128K (32 bytes/line) > > Compat vDSO mapped to ffffe000. > > Checking 'hlt' instruction... OK. > > SMP alternatives: switching to UP code > > Freeing SMP alternatives: 12k freed > > CPU0: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02 > > SMP motherboard not detected. > > Local APIC not detected. Using dummy APIC emulation. > > Brought up 1 CPUs > > migration_cost=0 > > checking if image is initramfs...it isn't (bad gzip magic numbers); > > looks like an initrd > > Freeing initrd memory: 4216k freed > > NET: Registered protocol family 16 > > PCI: Using configuration type 1 > > Setting up standard PCI resources > > Linux Plug and Play Support v0.97 (c) Adam Belay > > PnPBIOS: Scanning system for PnP BIOS support... > > PnPBIOS: PnP BIOS support was not detected. > > PCI: Probing PCI hardware > > PCI: Using IRQ router default [1022/2090] at 0000:00: 0f.0 > > PCI: Ignore bogus resource 6 [0:0] of 0000:00:01.1 > > NET: Registered protocol family 2 > > IP route cache hash table entries: 4096 (order: 2, 16384 bytes) > > TCP established hash table entries: 16384 (order: 5, 131072 bytes) > > TCP bind hash table entries: 8192 (order: 4, 65536 bytes) > > TCP: Hash tables configured (established 16384 bind 8192) > > TCP reno registered > > audit: initializing netlink socket (disabled) > > audit(943920012.588:1): initialized > > VFS: Disk quotas dquot_6.5.1 > > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > > Initializing Cryptographic API > > io scheduler noop registered > > io scheduler anticipatory registered > > io scheduler deadline registered > > io scheduler cfq registered (default) > > PCI: Guessed IRQ 11 for device 0000:00:01.1 > > PCI: Sharing IRQ 11 with 0000:00:01.2 > > PCI: Sharing IRQ 11 with 0000:00:0d.0 > > lxfb 0000:00:01.1: 8192 KB of video memory at 0xfd000000 > > Console: switching to colour frame buffer device 80x25 > > fb0: Geode LX frame buffer device > > vga16fb: mapped to 0xc00a0000 > > fb1: VGA16 VGA frame buffer device > > isapnp: Scanning for PnP cards... > > isapnp: No Plug & Play device found > > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled > > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > > loop: loaded (max 8 devices) > > nbd: registered device at major 43 > > 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004) > > 8139cp 0000:00:0d.0: This (id 10ec:8139 rev 10) is not an 8139C+ > > compatible chip > > 8139cp 0000:00:0d.0: Try the "8139too" driver instead. > > 8139too Fast Ethernet driver 0.9.27 > > PCI: Guessed IRQ 11 for device 0000:00:0d.0 > > PCI: Sharing IRQ 11 with 0000:00:01.1 > > PCI: Sharing IRQ 11 with 0000:00:01.2 > > eth0: RealTek RTL8139 at 0x1000, 00:11:9e:c0:0a:e5, IRQ 11 > > PNP: No PS/2 controller found. Probing ports directly. > > i8042.c: Can't read CTR while initializing i8042. > > mice: PS/2 mouse device common for all mice > > TCP bic registered > > NET: Registered protocol family 1 > > NET: Registered protocol family 17 > > Using IPI No-Shortcut mode > > RAMDISK: cramfs filesystem found at block 0 > > Time: tsc clocksource has been installed. > > RAMDISK: Loading 4216KiB [1 disk] into ram disk... | / - \ | / - \ | / - > \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - > \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / > > > > > > > > On 6/20/07, *Marc Jones* > > wrote: > > > > > > > > Ot?vio Alc?ntara wrote: > > > Thanks for the help. But I have another doubt, I'm not getting > video > > > working even after the linux kernel boots. What do I do to change > the > > > console to video? I've configured Filo to use video console, but > the > > > stream goes only to serial interface. > > > > > > Regards, > > > > > > Ot?vio Alc?ntara > > > > > > > Ot?vio, > > Correct, you can't get graphics until a driver is loaded. For a > > test/debug setup that uses the filo menu will only be visable > serial. > > Please see this link for the Geode LX framebuffer support. > > http://thread.gmane.org/gmane.linux.fbdev.devel/10339 > > > > Marc > > > > > > > > > > > > > On 6/20/07, *Marc Jones* > > > > >> wrote: > > > > > > > > > > > > Ot?vio Alc?ntara wrote: > > > > Hello to all, > > > > > > > > I'm porting a linuxbios v2 version for a board > > ref des > > > > LXUVCRDK (http://www.amd.com/geodelxuvcrdk > > > > > ) based on norwich board. > I've > > > > already got to boot linux from HD, but it seems to halt in > > some point > > > > (see log below captured from serial). Although, I'm using > VSA > > > > (lx_vsa.36k.bin) and I got no output from video VGA. > > > > I'd like some help for setting up the PIRQ table > > and > > > for VGA > > > > setup. > > > > > > > > PS: The schematics for this board are publicly available > > from AMD > > > > Embedded Developer Web Site. > > > > > > > > Thanks, > > > > > > > > -- > > > > Ot?vio Alc?ntara > > > > "I'll never cross to the Dark Side." > > > > > > > > > > > > > > > > > > I took a quick look at the schematics and I think that this > > is what the > > > PIRQ table should look like. > > > > > > /* If you change the number of entries, change the > IRQ_SLOT_COUNT > > > above! */ > > > /* bus, dev|fn, {link, bitmap}, {link, > bitmap}, > > > {link, bitmap}, {link, bitmap}, slot, rfu */ > > > {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, > > {0x00, > > > 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* cpu */ > > > {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, > > M_PIRQB}, > > > {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* > > chipset */ > > > {0x00, (0x0D << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, > > {0x00, > > > 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* ethernet */ > > > > > > Make sure to change IRQ_SLOT_COUNT in the mainboard > > Options.lb > > > > > > > > > As Jordan pointed out, you should use the Linux framebuffer > > and X > > > drivers instead of VGA. That means that you should also set > > > CONFIG_CONSOLE_VGA=0 and CONFIG_PCI_ROM_RUN=0 in Options.lb > > > > > < http://Options.lb> > > > > > > > > > It also looks like there is something funny going on with the > > > Config.lb . > > > Try using the norwich one without modifications. > > > > > > > cs5536: southbridge_init: enable_ide_nand_flash is 36 > > > If you want to boot from IDE enable_ide_nand_flash should be > 0 > > > > > > > Disabling VPCI device: 0x0000106C > > > > Disabling VPCI device: 0x00001075 > > > > Disabling VPCI device: 0x0000107E > > > > Disabling VPCI device: 0x00001087 > > > > Disabling VPCI device: 0x00001090 > > > > Disabling VPCI device: 0x00001099 > > > > Disabling VPCI device: 0x000010A2 > > > > Disabling VPCI device: 0x000010AB > > > This is a very strange list. > > > > > > > > > I don't have one of these boards so when you get it working > > please > > > submit a patch! > > > Let me know if there is anything else I can do to help > > > > > > Marc > > > > > > > > > > > > > > > > > LinuxBIOS-2.0.0.0Fallback Qua Jun 20 07:45:43 BRT 2007 > > starting... > > > > _MSR GLCP_SYS_RSTPLL (4c000014) value is: > 00000498:00001820 > > > > Configuring PLL > > > > > > > > > > > > LinuxBIOS-2.0.0.0Fallback Qua Jun 20 07:45:43 BRT 2007 > > starting... > > > > _MSR GLCP_SYS_RSTPLL (4c000014) value is: > 00000498:07de0020 > > > > Done cpuRegInit > > > > SMBUS READ ERROR:03 device:a2 > > > > Ram1.00 > > > > Ram2.00 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > SMBUS READ ERROR:03 device:a2 > > > > Ram3 > > > > DRAM controller init done. > > > > RAM DLL lock > > > > Ram4 > > > > Copying LinuxBIOS to ram. > > > > Jumping to LinuxBIOS. > > > > LinuxBIOS-2.0.0.0Fallback Qua Jun 20 08:56:35 BRT 2007 > > booting... > > > > clocks_per_usec: 432 > > > > Enumerating buses... > > > > >> Entering northbridge.c: pci_domain_enable > > > > Enter northbridge_init_early > > > > writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80 > > > > writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0 > > > > writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003 > > > > sizeram: _MSR MC_CF07_DATA: 10076112:00004840 > > > > sizeram: sizem 0x100MB > > > > SysmemInit: enable for 256MBytes > > > > usable RAM: 268304383 bytes > > > > SysmemInit: MSR 0x10000028, val 0x2000000f:0xfdf00100 > > > > sizeram: _MSR MC_CF07_DATA: 10076112:00004840 > > > > sizeram: sizem 0x100MB > > > > SMMGL0Init: 268304384 bytes > > > > SMMGL0Init: offset is 0x80400000 > > > > SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0 > > > > writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003 > > > > writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80 > > > > writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0 > > > > writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003 > > > > sizeram: _MSR MC_CF07_DATA: 10076112:00004840 > > > > sizeram: sizem 0x100MB > > > > SysmemInit: enable for 256MBytes > > > > usable RAM: 268304383 bytes > > > > SysmemInit: MSR 0x4000002a, val 0x2000000f:0xfdf00100 > > > > SMMGL1Init: > > > > SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0 > > > > writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001 > > > > writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0 > > > > CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x10FFDF00 > > > > CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000 > > > > L2 cache enabled > > > > Enabling cache > > > > GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000 > > > > GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000 > > > > Exit northbridge_init_early > > > > Done cpubug fixes > > > > Not Doing ChipsetFlashSetup() > > > > <<>> Graphics init... > > > > <>> VRC_VG value: 0xffff > > > > Before VSA: > > > > do_vsmbios > > > > buf ilen 35441 olen60466 > > > > buf 00060000 *buf 186 buf[256k] 0 > > > > buf[0x20] signature is b0:10:e6:80 > > > > Call real_mode_switch_call_vsm > > > > biosint: INT# 0x15 > > > > biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx > 0x10000028 > > > > biosint: ebp 0x15ed4 esp 0xff0 edi 0x8a71 esi 0x38 > > > > biosint: ip 0x5b3 cs 0x6000 flags 0x46 > > > > biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 > > > > handleint21, eax 0xbea7 > > > > biosint: INT# 0x15 > > > > biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx > 0x10000028 > > > > biosint: ebp 0x15ed4 esp 0xfee edi 0x8a71 esi 0x38 > > > > biosint: ip 0x5c1 cs 0x6000 flags 0x46 > > > > biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0 > > > > handleint21, eax 0xbea4 > > > > do_vsmbios: VSA2 VR signature verified > > > > After VSA: > > > > <<>> Graphics init... > > > > <>> VRC_VG value: 0x2808 > > > > Finding PCI configuration type. > > > > PCI: Using configuration type 1 > > > > PCI_DOMAIN: 0000 enabled > > > > APIC_CLUSTER: 0 enabled > > > > PCI: pci_scan_bus for bus 00 > > > > PCI: 00:01.0 [1022/2080] enabled > > > > PCI: 00:01.1 [1022/2081] enabled > > > > PCI: 00:01.2 [1022/2082] enabled > > > > PCI: 00: 0d.0 [10ec/8139] enabled > > > > PCI: 00:0f.0 [1022/2090] enabled > > > > PCI: 00:0f.2 [1022/209a] enabled > > > > PCI: 00: 0f.3 [1022/2093] enabled > > > > PCI: 00:0f.4 [1022/2094] enabled > > > > PCI: 00:0f.5 [1022/2095] enabled > > > > PCI: 00: 0f.6 [1022/2096] enabled > > > > PCI: 00:0f.7 [1022/2097] enabled > > > > PCI: pci_scan_bus returning with max=000 > > > > done > > > > Allocating resources... > > > > Reading resources... > > > > Done reading resources. > > > > Setting resources... > > > > PCI: 00: 01.1 10 <- [0x00fd000000 - 0x00fdffffff] mem > > > > PCI: 00:01.1 14 <- [0x00fe000000 - 0x00fe003fff] mem > > > > PCI: 00:01.1 18 <- [0x00fe004000 - 0x00fe007fff] mem > > > > PCI: 00:01.1 1c <- [0x00fe008000 - 0x00fe00bfff] mem > > > > PCI: 00:01.1 20 <- [0x00fe00c000 - 0x00fe00ffff] mem > > > > PCI: 00:01.2 10 <- [0x00fe010000 - 0x00fe013fff] mem > > > > PCI: 00:0d.0 10 <- [0x0000001000 - 0x00000010ff] io > > > > PCI: 00:0d.0 14 <- [0x00fe019000 - 0x00fe0190ff] mem > > > > PCI: 00:0f.0 10 <- [0x0000001cb0 - 0x0000001cb7] io > > > > PCI: 00:0f.0 14 <- [0x0000001400 - 0x00000014ff] io > > > > PCI: 00:0f.0 18 <- [0x0000001c00 - 0x0000001c3f] io > > > > PCI: 00:0f.0 1c <- [0x0000001c80 - 0x0000001c9f] io > > > > PCI: 00:0f.0 20 <- [0x0000001800 - 0x000000187f] io > > > > PCI: 00: 0f.0 24 <- [0x0000001c40 - 0x0000001c7f] io > > > > PCI: 00:0f.2 20 <- [0x0000001ca0 - 0x0000001caf] io > > > > PCI: 00:0f.3 10 <- [0x0000001880 - 0x00000018ff] io > > > > PCI: 00:0f.4 10 <- [0x00fe016000 - 0x00fe016fff] mem > > > > PCI: 00:0f.5 10 <- [0x00fe017000 - 0x00fe017fff] mem > > > > PCI: 00:0f.6 10 <- [0x00fe014000 - 0x00fe015fff] mem > > > > PCI: 00:0f.7 10 <- [0x00fe018000 - 0x00fe018fff] mem > > > > Done setting resources. > > > > Done allocating resources. > > > > Enabling resources... > > > > PCI: 00:01.0 cmd <- 145 > > > > PCI: 00: 01.1 subsystem <- 00/00 > > > > PCI: 00:01.1 cmd <- 142 > > > > PCI: 00:01.2 cmd <- 142 > > > > PCI: 00: 0d.0 cmd <- 143 > > > > cs5536: cs5536_pci_dev_enable_resources() > > > > PCI: 00:0f.0 cmd <- 149 > > > > PCI: 00:0f.2 cmd <- 141 > > > > PCI: 00:0f.3 cmd <- 141 > > > > PCI: 00:0f.4 cmd <- 142 > > > > PCI: 00: 0f.5 cmd <- 142 > > > > PCI: 00: 0f.6 cmd <- 142 > > > > PCI: 00:0f.7 cmd <- 142 > > > > done. > > > > Initializing devices... > > > > Root Device init > > > > Norwich ENTER init > > > > Norwich EXIT init > > > > PCI: 00: 01.0 init > > > > PCI: 00:01.1 init > > > > APIC_CLUSTER: 0 init > > > > Initializing CPU #0 > > > > CPU: vendor AMD device 5a2 > > > > CPU: family 05, model 0a, stepping 02 > > > > model_lx_init > > > > Enabling cache > > > > A20 (0x92): 2 > > > > A20 (0x92): 2 > > > > CPU model_lx_init DONE > > > > CPU #0 Initialized > > > > PCI: 00:01.2 init > > > > PCI: 00: 0d.0 init > > > > PCI: 00:0f.0 init > > > > cs5536: southbridge_init > > > > RTC Init > > > > rct_init finished > > > > cs5536: southbridge_init: enable_ide_nand_flash is 36 > > > > Disabling VPCI device: 0x0000106C > > > > Disabling VPCI device: 0x00001075 > > > > Disabling VPCI device: 0x0000107E > > > > Disabling VPCI device: 0x00001087 > > > > Disabling VPCI device: 0x00001090 > > > > Disabling VPCI device: 0x00001099 > > > > Disabling VPCI device: 0x000010A2 > > > > Disabling VPCI device: 0x000010AB > > > > PCI: 00:0f.2 init > > > > PCI: 00:0f.3 init > > > > PCI: 00:0f.4 init > > > > PCI: 00:0f.5 init > > > > PCI: 00:0f.6 init > > > > PCI: 00:0f.7 init > > > > Devices initialized > > > > Copying IRQ routing tables to 0xf0000...done. > > > > Verifing copy of IRQ routing tables at 0xf0000...done > > > > Checking IRQ routing table consistency... > > > > check_pirq_routing_table() - irq_routing_table located at: > > 0x000f0000 > > > > > /home/otavio/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: > > > > 36:check_pirq_routing_table() - checksum is: 0x00 but > > should be: > > > 0xfd > > > > done. > > > > write_pirq_routing_table(8000785C, BAAA) > > > > PIR Entry 0 Dev/Fn: 8 Slot: 0 > > > > INT: A bitmap: 400 PIRQ: 10 > > > > INT: B bitmap: 0 PIRQ: 0 > > > > INT: C bitmap: 0 PIRQ: 0 > > > > INT: D bitmap: 0 PIRQ: 0 > > > > Assigning IRQ 10 to 0: 1.1 > > > > Readback = 10 > > > > Assigning IRQ 10 to 0:1.2 > > > > Readback = 10 > > > > PIR Entry 1 Dev/Fn: 78 Slot: 0 > > > > INT: A bitmap: 400 PIRQ: 10 > > > > INT: B bitmap: 400 PIRQ: 10 > > > > INT: C bitmap: 400 PIRQ: 10 > > > > INT: D bitmap: 800 PIRQ: 11 > > > > Assigning IRQ 10 to 0:f.3 > > > > Readback = 10 > > > > Assigning IRQ 11 to 0: f.4 > > > > Readback = 11 > > > > Assigning IRQ 11 to 0:f.5 > > > > Readback = 11 > > > > PIR Entry 2 Dev/Fn: 68 Slot: 1 > > > > INT: A bitmap: 400 PIRQ: 10 > > > > INT: B bitmap: 400 PIRQ: 10 > > > > INT: C bitmap: 800 PIRQ: 11 > > > > INT: D bitmap: 400 PIRQ: 10 > > > > Assigning IRQ 10 to 0: d.0 > > > > Readback = 10 > > > > PIR Entry 3 Dev/Fn: 70 Slot: 2 > > > > INT: A bitmap: 400 PIRQ: 10 > > > > INT: B bitmap: 800 PIRQ: 11 > > > > INT: C bitmap: 400 PIRQ: 10 > > > > INT: D bitmap: 400 PIRQ: 10 > > > > PIR Entry 4 Dev/Fn: 58 Slot: 3 > > > > INT: A bitmap: 800 PIRQ: 11 > > > > INT: B bitmap: 400 PIRQ: 10 > > > > INT: C bitmap: 400 PIRQ: 10 > > > > INT: D bitmap: 400 PIRQ: 10 > > > > PIR Entry 5 Dev/Fn: 60 Slot: 4 > > > > INT: A bitmap: 400 PIRQ: 10 > > > > INT: B bitmap: 400 PIRQ: 10 > > > > INT: C bitmap: 400 PIRQ: 10 > > > > INT: D bitmap: 800 PIRQ: 11 > > > > Moving GDT to 0x500...ok > > > > Adjust low_table_end from 0x00000530 to 0x00001000 > > > > Adjust rom_table_end from 0x000f0400 to 0x00100000 > > > > Wrote linuxbios table at: 00000530 - 000006c4 checksum > fba9 > > > > > > > > Welcome to elfboot, the open sourced starter. > > > > January 2002, Eric Biederman. > > > > Version 1.3 > > > > > > > > rom_stream: 0xfff89000 - 0xfffeffff > > > > Found ELF candidate at offset 0 > > > > header_offset is 0 > > > > Try to load at offset 0x0 > > > > New segment addr 0x100000 size 0x306e0 offset 0xc0 > > filesize 0xb248 > > > > (cleaned up) New segment addr 0x100000 size 0x306e0 offset > > 0xc0 > > > filesize > > > > 0xb248 > > > > New segment addr 0x1306e0 size 0x48 offset 0xb320 filesize > > 0x48 > > > > (cleaned up) New segment addr 0x1306e0 size 0x48 offset > 0xb320 > > > filesize 0x48 > > > > Dropping non PT_LOAD segment > > > > Dropping non PT_LOAD segment > > > > Loading Segment: addr: 0x0000000000100000 memsz: > > 0x00000000000306e0 > > > > filesz: 0x000000000000b248 > > > > Clearing Segment: addr: 0x000000000010b248 memsz: > > 0x0000000000025498 > > > > Loading Segment: addr: 0x00000000001306e0 memsz: > > 0x0000000000000048 > > > > filesz: 0x0000000000000048 > > > > Jumping to boot code at 0x108bdc > > > > FILO version 0.5 (otavio at labdes15) Wed Jun 20 08:56:24 BRT > > 2007 > > > > collect_linuxbios_info: Searching for LinuxBIOS tables... > > > > find_lb_table: Found canidate at: 00000530 > > > > find_lb_table: header checksum o.k. > > > > find_lb_table: table checksum o.k. > > > > find_lb_table: record count o.k. > > > > collect_linuxbios_info: Found LinuxBIOS table at: 00000530 > > > > convert_memmap: 0x00000000000000 0x00000000001000 16 > > > > convert_memmap: 0x00000000001000 0x0000000009f000 1 > > > > convert_memmap: 0x000000000f0000 0x00000000010000 16 > > > > convert_memmap: 0x00000000100000 0x0000000f6e0000 1 > > > > Press for default boot, or for boot > > prompt... 2 1 > > > > timed out > > > > boot: hda1:/boot/vmlinuz root=/dev/hda1 > initrd=/boot/initrd > > > > console=tty0 console=ttyS0,115200 > > > > hda: LBA 40GB: ST340014A > > > > Mounted ext2fs > > > > Found Linux version 2.6.8-2-386 > > > (horms at tabatha.lab.ultramonkey.org > > > > > > > > > > > > > > > > >>) #1 Thu May 19 17:40:50 > JST > > > > 2005 (protocol 0x203) (loadflags 0x1) bzImage. > > > > init_linux_params: Setting up paramters at 0x90000 > > > > set_memory_size: 0000000000001000 - 00000000000a0000 > > > > set_memory_size: 0000000000100000 - 000000000f7e0000 > > > > set_memory_size: ramtop=0xf7e0000 > > > > set_memory_size: ext_mem_k=64512, alt_mem_k=252800 > > > > parse_command_line: original command line: "root=/dev/hda1 > > > > initrd=/boot/initrd console=tty0 console=ttyS0,115200" > > > > parse_command_line: kernel command line at 0x91000 > > > > parse_command_line: initrd=/boot/initrd > > > > parse_command_line: kernel command line (48 bytes): > > "root=/dev/hda1 > > > > console=tty0 console=ttyS0,115200" > > > > load_linux_kernel: offset=0x1600 addr=0x100000 > size=0x10a8cb > > > > Loading kernel... ok > > > > load_initrd: start=0xf391000 end=0xf7af000 > > > > Loading initrd... ok > > > > start_linux: eip=0x100000 > > > > Jumping to entry point... > > > > Linux version 2.6.8-2-386 ( > > horms at tabatha.lab.ultramonkey.org > > > > > > > > > > > > > > > > >>) (gcc version 3.3.5(Debian > > > > 1:3.3.5-12)) #1 Thu May 19 17:40:50 JST 2005 > > > > > > > > BIOS-provided physical RAM map: > > > > > > > > BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) > > > > > > > > BIOS-e820: 0000000000100000 - 000000000f7e0000 (usable) > > > > > > > > 247MB LOWMEM available. > > > > > > > > DMI not present. > > > > > > > > ACPI: Unable to locate RSDP > > > > > > > > Built 1 zonelists > > > > > > > > Kernel command line: root=/dev/hda1 console=tty0 > > console=ttyS0,115200 > > > > > > > > No local APIC present or hardware disabled > > > > > > > > Initializing CPU#0 > > > > > > > > PID hash table entries: 1024 (order 10: 8192 bytes) > > > > > > > > Detected 431.857 MHz processor. > > > > > > > > Using tsc for high-res timesource > > > > > > > > Console: colour dummy device 80x25 > > > > > > > > Dentry cache hash table entries: 32768 (order: 5, 131072 > > bytes) > > > > > > > > Inode-cache hash table entries: 16384 (order: 4, 65536 > bytes) > > > > > > > > Memory: 244168k/253824k available (1336k kernel code, > > 8916k reserved, > > > > 732k data, 204k init, 0k highmem) > > > > > > > > Checking if this processor honours the WP bit even in > > supervisor > > > mode... > > > > Ok. > > > > > > > > Calibrating delay loop... 845.82 BogoMIPS > > > > > > > > Security Scaffold v1.0.0 initialized > > > > > > > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > > > > > > > CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 > > bytes/line) > > > > > > > > CPU: L2 Cache: 128K (32 bytes/line) > > > > > > > > CPU: AMD Geode(TM) Integrated Processor by AMD PCS > > stepping 02 > > > > > > > > Checking 'hlt' instruction... OK. > > > > > > > > Checking for popad bug... OK. > > > > > > > > checking if image is initramfs...it isn't (ungzip failed); > > looks > > > like an > > > > initrd > > > > > > > > Freeing initrd memory: 4216k freed > > > > > > > > NET: Registered protocol family 16 > > > > > > > > EISA bus registered > > > > > > > > PCI: Using configuration type 1 > > > > > > > > mtrr: v2.0 (20020519) > > > > > > > > ACPI: Subsystem revision 20040326 > > > > > > > > ACPI: Interpreter disabled. > > > > > > > > Linux Plug and Play Support v0.97 (c) Adam Belay > > > > > > > > PnPBIOS: Scanning system for PnP BIOS support... > > > > > > > > PnPBIOS: PnP BIOS support was not detected. > > > > > > > > PCI: Probing PCI hardware > > > > > > > > PCI: Probing PCI hardware (bus 00) > > > > > > > > PCI: Using IRQ router default [1022/2090] at 0000:00: 0f.0 > > > > > > > > VFS: Disk quotas dquot_6.5.1 > > > > > > > > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > > > > > > > > devfs: 2004-01-31 Richard Gooch ( rgooch at atnf.csiro.au > > > > > > > > > > > > >>) > > > > > > > > devfs: boot_options: 0x0 > > > > > > > > Initializing Cryptographic API > > > > > > > > isapnp: Scanning for PnP cards... > > > > > > > > isapnp: No Plug & Play device found > > > > > > > > Serial: 8250/16550 driver $Revision: 1.90 $ 54 ports, IRQ > > sharing > > > enabled > > > > > > > > ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > > > > > > > RAMDISK driver initialized: 16 RAM disks of 8192K size > > 1024 blocksize > > > > > > > > i8042.c : Can't read CTR while initializing i8042. > > > > > > > > EISA: Probing bus 0 at eisa0 > > > > > > > > Cannot allocate resource for EISA slot 1 > > > > > > > > EISA: Detected 0 cards. > > > > > > > > NET: Registered protocol family 2 > > > > > > > > IP: routing cache hash table of 2048 buckets, 16Kbytes > > > > > > > > TCP: Hash tables configured (established 16384 bind 32768) > > > > > > > > NET: Registered protocol family 8 > > > > > > > > NET: Registered protocol family 20 > > > > > > > > RAMDISK: cramfs filesystem found at block 0 > > > > > > > > RAMDISK: Loading 4216 blocks [1 disk] into ram disk... | / > > - \ | > > > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ > > | / - > > > \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / > > - \ | > > > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ > > | / - > > > \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / > > - \ | > > > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ > > | / - > > > \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / > > - \ | > > > / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ > > | / - > > > \ | / - \ | / - \ | / - \ | / - \ | / - \ done. > > > > > > > > > > > > VFS: Mounted root (cramfs filesystem) readonly. > > > > > > > > Freeing unused kernel memory: 204k freed > > > > > > > > vesafb: probe of vesafb0 failed with error -6 > > > > > > > > NET: Registered protocol family 1 > > > > > > > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > > > > > > > > ide: Assuming 33MHz system bus speed for PIO modes; > > override with > > > idebus=xx > > > > > > > > hda: ST340014A, ATA DISK drive > > > > > > > > Using anticipatory io scheduler > > > > > > > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > > > > > > > > hda: max request size: 128KiB > > > > > > > > hda: 78165360 sectors (40020 MB) w/2048KiB Cache, > > CHS=65535/16/63 > > > > > > > > /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 > > > > > > > > > > > > > > > -- > > > Marc Jones > > > Senior Software Engineer > > > (970) 226-9684 Office > > > mailto:Marc.Jones at amd.com > > > > > > http://www.amd.com/embeddedprocessors > > > > > > > > > > > > > > > > > > > > -- > > > Ot?vio Alc?ntara > > > "I'll never cross to the Dark Side." > > > > > > > -- > > Marc Jones > > Senior Software Engineer > > (970) 226-9684 Office > > mailto:Marc.Jones at amd.com > > http://www.amd.com/embeddedprocessors > > > > > > > > > > > > -- > > Ot?vio Alc?ntara > > "I'll never cross to the Dark Side." > > -- > Marc Jones > Senior Software Engineer > (970) 226-9684 Office > mailto:Marc.Jones at amd.com > http://www.amd.com/embeddedprocessors > > > -- Ot?vio Alc?ntara "I'll never cross to the Dark Side." -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at coresystems.de Wed Aug 1 14:28:39 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Aug 2007 14:28:39 +0200 Subject: [LinuxBIOS] Use Linux MTD framework for SPI flash? In-Reply-To: <46B07261.1050207@gmx.net> References: <46A924E6.5090900@gmx.net> <20070726234312.29083.qmail@stuge.se> <20070731152807.GA32249@cosmic.amd.com> <20070731211945.GA7915@coresystems.de> <20070731213315.GD32720@cosmic.amd.com> <20070731214421.GA12417@coresystems.de> <46B07261.1050207@gmx.net> Message-ID: <20070801122839.GD9207@coresystems.de> * Carl-Daniel Hailfinger [070801 13:45]: > On 31.07.2007 23:44, Stefan Reinauer wrote: > > * Jordan Crouse [070731 23:33]: > >>> In this scenario, who loads the correct kernel module(s)? > >> The user. > >> > >>> Which southbridges does the MTD SPI code support? Last time I checked > >>> only some ARM embedded systems were possibly supported. > >> Sure - but what SPI southbridges does flashrom support? > > > > Exactly as many as mtd for x86 based systems: 0 > > I don't know how difficult it will be for the existing chipset support > drivers in the MTD framework to add SPI support, but maybe it is easier > than we think. Sure it is not difficult, it just has to be done by someone with datasheets. > * Nvidia CK804 > * AMD 76X > * Intel ICHx The code in mtd is completely useless. It just enables mapping the flash to memory. For SPI the actual flash logic (same as a flash chip driver for pre-spi flash) goes into the southbridge code. Practically this means that generic SPI support is completely useless unless you have your specific southbridge supported. > MTD sort of has autodetection for SPI flash chips once the SPI > southbridge has a driver loaded. With autodetection I was rather thinking about detection of the modules to load. Auto detection of SPI flash is a de facto nop, since all the logic is in the southbridge driver, which you just loaded manually. > BTW, that is something that bothers me about flashrom: You have to add > probing support for every single flash chip to the code even if a new > chip is detected by probe_jedec. Why would you add probing support for chips if probe_jedec does the job already? The reason you have to have a function pointer for probing is that some flash chips answer to the wrong probing commands with non-ID data. So some few flash chips need their own probing function. SPI will also get its own probing function probe_spi which calls into the southbridge specific code to do the job. > Some generic JEDEC detection run for > different sizes followed by a lookup in a id table would be so much > nicer. Why? Searching in positions where a chip can't possibly be anyways can have pretty bad side effects. > In case flashing needs special code we still have to read the > data sheets now and this won't get worse in the future, but having a > message "Your flash chip was detected as unknown (id $ID) from > $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@" > would surely help a lot for adoption of flashrom. This can easily be done already by just adding a small snippet to probe_jedec. just read the memory location before and after the ID command and test if it changed. -- 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 peter at stuge.se Wed Aug 1 15:49:41 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Aug 2007 15:49:41 +0200 Subject: [LinuxBIOS] PIRQ REF DES AMD LXUVCRDK In-Reply-To: <751d98080708010450y2cf09e99y448b7aaae3f733fd@mail.gmail.com> References: <751d98080706200608w63943f12la6631f91ce26a177@mail.gmail.com> <467954AF.6090100@amd.com> <751d98080706200945q101d7fdicbfb20586e048649@mail.gmail.com> <4679960A.1000000@amd.com> <751d98080707130712saade1i2c9bc8355c9f8ee@mail.gmail.com> <469BE596.8070602@amd.com> <751d98080708010450y2cf09e99y448b7aaae3f733fd@mail.gmail.com> Message-ID: <20070801134941.7113.qmail@stuge.se> On Wed, Aug 01, 2007 at 08:50:30AM -0300, Ot?vio Alc?ntara wrote: > I've used memtest as a payload and the test was sucessfully. How long did you leave it running? 24 hours is good to make sure. > Any other idea for the RAMDISK blow up? It's usually because of bad RAM, unless there is a configuration error in the initrd. > Bellow the log of the linuxbios + memtest try out. My board is > similar to AMD RDK UVC. Sorry, the ANSI codes make the memtest output unlegible for me. :\ //Peter From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 1 15:52:09 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 01 Aug 2007 15:52:09 +0200 Subject: [LinuxBIOS] flashrom: mcp55 enable bit comment wrong? Message-ID: <46B09009.1050705@gmx.net> Hi, > static int enable_flash_mcp55(struct pci_dev *dev, char *name) > { > unsigned char old, new, byte; > unsigned short word; > > /* Set the 4MB enable bit bit */ wrong comment, probably copy-pasted? > byte = pci_read_byte(dev, 0x88); > byte |= 0xff; /* 256K */ > pci_write_byte(dev, 0x88, byte); > byte = pci_read_byte(dev, 0x8c); > byte |= 0xff; /* 1M */ > pci_write_byte(dev, 0x8c, byte); > word = pci_read_word(dev, 0x90); > word |= 0x7fff; /* 15M */ ^^^ Shouldn't that be 16M? > pci_write_word(dev, 0x90, word); Regards, Carl-Daniel From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 1 16:17:20 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 01 Aug 2007 16:17:20 +0200 Subject: [LinuxBIOS] Use Linux MTD framework for SPI flash? In-Reply-To: <20070801122839.GD9207@coresystems.de> References: <46A924E6.5090900@gmx.net> <20070726234312.29083.qmail@stuge.se> <20070731152807.GA32249@cosmic.amd.com> <20070731211945.GA7915@coresystems.de> <20070731213315.GD32720@cosmic.amd.com> <20070731214421.GA12417@coresystems.de> <46B07261.1050207@gmx.net> <20070801122839.GD9207@coresystems.de> Message-ID: <46B095F0.3030501@gmx.net> On 01.08.2007 14:28, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [070801 13:45]: >> On 31.07.2007 23:44, Stefan Reinauer wrote: >>> * Jordan Crouse [070731 23:33]: >>>>> In this scenario, who loads the correct kernel module(s)? >>>> The user. >>>> >>>>> Which southbridges does the MTD SPI code support? Last time I checked >>>>> only some ARM embedded systems were possibly supported. >>>> Sure - but what SPI southbridges does flashrom support? >>> Exactly as many as mtd for x86 based systems: 0 >> I don't know how difficult it will be for the existing chipset support >> drivers in the MTD framework to add SPI support, but maybe it is easier >> than we think. > > Sure it is not difficult, it just has to be done by someone with > datasheets. > >> * Nvidia CK804 >> * AMD 76X >> * Intel ICHx > > The code in mtd is completely useless. It just enables mapping the flash > to memory. Not really. At least for ck804, it also enables flashing. Just look for pci_read_config_byte in ck804xrom.c and notice the similarities with chipset_enable.c from flashrom. > For SPI the actual flash logic (same as a flash chip driver for pre-spi > flash) goes into the southbridge code. Practically this means that > generic SPI support is completely useless unless you have your specific > southbridge supported. I see. >> MTD sort of has autodetection for SPI flash chips once the SPI >> southbridge has a driver loaded. > > With autodetection I was rather thinking about detection of the modules > to load. > > Auto detection of SPI flash is a de facto nop, since all the logic is in > the southbridge driver, which you just loaded manually. The pci device table ist there, so if somebody automatically loads all pci drivers matching his hardware, he is covered. >> BTW, that is something that bothers me about flashrom: You have to add >> probing support for every single flash chip to the code even if a new >> chip is detected by probe_jedec. > > Why would you add probing support for chips if probe_jedec does the job > already? I don't want to do that. > The reason you have to have a function pointer for probing is that some > flash chips answer to the wrong probing commands with non-ID data. So > some few flash chips need their own probing function. Sure. > SPI will also get its own probing function probe_spi which calls into > the southbridge specific code to do the job. > >> Some generic JEDEC detection run for >> different sizes followed by a lookup in a id table would be so much >> nicer. > > Why? Searching in positions where a chip can't possibly be anyways can > have pretty bad side effects. probe_jedec is called for every supported chip in the list with probe_jedec as probe function. Calling probe_jedec only once for every possible/reasonable chip size would be a lot more efficient. >> In case flashing needs special code we still have to read the >> data sheets now and this won't get worse in the future, but having a >> message "Your flash chip was detected as unknown (id $ID) from >> $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@" >> would surely help a lot for adoption of flashrom. > > This can easily be done already by just adding a small snippet to probe_jedec. > just read the memory location before and after the ID command and test > if it changed. That would be nice. Regards, Carl-Daniel From eswierk at arastra.com Wed Aug 1 16:19:08 2007 From: eswierk at arastra.com (Ed Swierk) Date: Wed, 1 Aug 2007 07:19:08 -0700 Subject: [LinuxBIOS] flashrom: mcp55 enable bit comment wrong? In-Reply-To: <46B09009.1050705@gmx.net> References: <46B09009.1050705@gmx.net> Message-ID: On 8/1/07, Carl-Daniel Hailfinger wrote: > Hi, > > > static int enable_flash_mcp55(struct pci_dev *dev, char *name) > > { > > unsigned char old, new, byte; > > unsigned short word; > > > > /* Set the 4MB enable bit bit */ > wrong comment, probably copy-pasted? > > > byte = pci_read_byte(dev, 0x88); > > byte |= 0xff; /* 256K */ > > pci_write_byte(dev, 0x88, byte); > > byte = pci_read_byte(dev, 0x8c); > > byte |= 0xff; /* 1M */ > > pci_write_byte(dev, 0x8c, byte); > > word = pci_read_word(dev, 0x90); > > word |= 0x7fff; /* 15M */ > ^^^ > Shouldn't that be 16M? > > > pci_write_word(dev, 0x90, word); Yes and yes. --Ed From peter at stuge.se Wed Aug 1 16:49:49 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Aug 2007 16:49:49 +0200 Subject: [LinuxBIOS] Use Linux MTD framework for SPI flash? In-Reply-To: <46B095F0.3030501@gmx.net> References: <46A924E6.5090900@gmx.net> <20070726234312.29083.qmail@stuge.se> <20070731152807.GA32249@cosmic.amd.com> <20070731211945.GA7915@coresystems.de> <20070731213315.GD32720@cosmic.amd.com> <20070731214421.GA12417@coresystems.de> <46B07261.1050207@gmx.net> <20070801122839.GD9207@coresystems.de> <46B095F0.3030501@gmx.net> Message-ID: <20070801144949.17213.qmail@stuge.se> On Wed, Aug 01, 2007 at 04:17:20PM +0200, Carl-Daniel Hailfinger wrote: > >> * Nvidia CK804 > >> * AMD 76X > >> * Intel ICHx > > > > The code in mtd is completely useless. > > Not really. Yes, really. > At least for ck804, it also enables flashing. Just look for > pci_read_config_byte in ck804xrom.c and notice the similarities > with chipset_enable.c from flashrom. ..because they both only do parallel flash. There's nothing in the MTD code that supports SPI flash on the above hardware. It's completely different from parallel flash. //Peter From stepan at coresystems.de Wed Aug 1 17:04:05 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 1 Aug 2007 17:04:05 +0200 Subject: [LinuxBIOS] Use Linux MTD framework for SPI flash? In-Reply-To: <46B095F0.3030501@gmx.net> References: <46A924E6.5090900@gmx.net> <20070726234312.29083.qmail@stuge.se> <20070731152807.GA32249@cosmic.amd.com> <20070731211945.GA7915@coresystems.de> <20070731213315.GD32720@cosmic.amd.com> <20070731214421.GA12417@coresystems.de> <46B07261.1050207@gmx.net> <20070801122839.GD9207@coresystems.de> <46B095F0.3030501@gmx.net> Message-ID: <20070801150405.GB14772@coresystems.de> * Carl-Daniel Hailfinger [070801 16:17]: > >> * Nvidia CK804 > >> * AMD 76X > >> * Intel ICHx > > > > The code in mtd is completely useless. It just enables mapping the flash > > to memory. > > Not really. At least for ck804, it also enables flashing. Just look for > pci_read_config_byte in ck804xrom.c and notice the similarities with > chipset_enable.c from flashrom. Correct. Unfortunately SPI is a completely different kettle of fish. > > have pretty bad side effects. > > probe_jedec is called for every supported chip in the list with > probe_jedec as probe function. Calling probe_jedec only once for every > possible/reasonable chip size would be a lot more efficient. Ok. But how do you go for the other probing functions then? We could build an array of probe addresses/probe functions and do a "sort unique" ;-) 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 c-d.hailfinger.devel.2006 at gmx.net Wed Aug 1 17:05:32 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 01 Aug 2007 17:05:32 +0200 Subject: [LinuxBIOS] Tracing BIOS flash calls for newer SPI-based GA-M57SLI? Message-ID: <46B0A13C.4090602@gmx.net> Hi Darmawan, would it be possible to trace what the DOS vendor flashing tool for the Gigabyte M57SLI rev2.0 board does? The board is using SPI and looking at the SPI flash procedure may help us write a driver for the SPI controller (probably located in MCP55) on the board. Download location is: http://www.gigabyte.com.tw/Support/Motherboard/BIOS_DownloadFile.aspx?FileType=BIOS&FileID=12862 The file you can download is a self-unpacking RAR archive with the following contents: autoexec.bat FLASH895.EXE m57sls42.fb FLASH895.EXE uses the CauseWay DOS Extender and seems to be an Award flash utility. Regards, Carl-Daniel From peter at stuge.se Wed Aug 1 17:30:55 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 1 Aug 2007 17:30:55 +0200 Subject: [LinuxBIOS] Tracing BIOS flash calls for newer SPI-based GA-M57SLI? In-Reply-To: <46B0A13C.4090602@gmx.net> References: <46B0A13C.4090602@gmx.net> Message-ID: <20070801153055.24650.qmail@stuge.se> On Wed, Aug 01, 2007 at 05:05:32PM +0200, Carl-Daniel Hailfinger wrote: > would it be possible to trace what the DOS vendor flashing tool for > the Gigabyte M57SLI rev2.0 board does? The board is using SPI and > looking at the SPI flash procedure may help us write a driver for > the SPI controller (probably located in MCP55) on the board. DOS flash utilities usually call hooks in the BIOS to do the flashing so I doubt it, but it would be great if it worked out! //Peter From otavio.junior at gmail.com Wed Aug 1 19:18:13 2007 From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=) Date: Wed, 1 Aug 2007 14:18:13 -0300 Subject: [LinuxBIOS] PIRQ REF DES AMD LXUVCRDK In-Reply-To: <20070801134941.7113.qmail@stuge.se> References: <751d98080706200608w63943f12la6631f91ce26a177@mail.gmail.com> <467954AF.6090100@amd.com> <751d98080706200945q101d7fdicbfb20586e048649@mail.gmail.com> <4679960A.1000000@amd.com> <751d98080707130712saade1i2c9bc8355c9f8ee@mail.gmail.com> <469BE596.8070602@amd.com> <751d98080708010450y2cf09e99y448b7aaae3f733fd@mail.gmail.com> <20070801134941.7113.qmail@stuge.se> Message-ID: <751d98080708011018i454d088do88bda1847446a0a4@mail.gmail.com> Hello to all, On 8/1/07, Peter Stuge wrote: >How long did you leave it running? 24 hours is good to make sure. We spent more than a day on test, but today I've tried another initrd and the boot was okay, just some problems with USB keyboard. Thanks, Otavio Alc?ntara On 8/1/07, Peter Stuge wrote: > > On Wed, Aug 01, 2007 at 08:50:30AM -0300, Ot?vio Alc?ntara wrote: > > I've used memtest as a payload and the test was sucessfully. > > How long did you leave it running? 24 hours is good to make sure. > > > > Any other idea for the RAMDISK blow up? > > It's usually because of bad RAM, unless there is a configuration > error in the initrd. > > > > Bellow the log of the linuxbios + memtest try out. My board is > > similar to AMD RDK UVC. > > Sorry, the ANSI codes make the memtest output unlegible for me. :\ > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -- Ot?vio Alc?ntara "I'll never cross to the Dark Side." -------------- next part -------------- An HTML attachment was scrubbed... URL: From acassis at gmail.com Thu Aug 2 00:45:28 2007 From: acassis at gmail.com (Alan Carvalho de Assis) Date: Wed, 1 Aug 2007 19:45:28 -0300 Subject: [LinuxBIOS] Running X Server on QEMU Message-ID: <37367b3a0708011545o4aa83f2ai46e4a8c8e7ab5690@mail.gmail.com> Hi Guys, I am trying to place kdrive to run on QEMU but I'm facing some problems. First I applied the patch on QEMU to accept bios.bin with more than 256KB, I update this info on wiki page: http://www.linuxbios.org/QEMU_Build_Tutorial Then compiled a minimal linux kernel with rootfs inside and tested it in qemu: qemu -kernel tinyxmatchbox.img -hda /dev/null Note: tinyxmatchbox.img is just one bzImage with rootfs inside, then I don't need -hda pointing the any disc. It run fine like in my video in youtube. You can test it just downloading: http://lbdistro.sourceforge.net/files/tinyxmatchbox.img and executing the above command. Then I converted this image to ELF: mkelfImage --append="console=tty0" tinyxmatchbox.img linux.elf Then compiled LinuxBIOSv3 using this linux.elf. I need active the LZMA compression because linux.elf size is about 1.99MB. Everything goes fine, but when I try to execute qemu using the bios.bin (the file vgabios-cirrus.bin is at same directory as well) I receive this error: $ qemu -L ~ -hda /dev/null qemu: fatal: Trying to execute code outside RAM or ROM at 0x31e1b77c EAX=31e1b77c EBX=31c3b000 ECX=00000000 EDX=00000000 ESI=00090000 EDI=31c3b000 EBP=00100000 ESP=00090040 EIP=31e1b77c EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00000000 ffffffff 00cf9300 CS =0010 00000000 ffffffff 00cf9a00 SS =0018 00000000 ffffffff 00cf9300 DS =0018 00000000 ffffffff 00cf9300 FS =0018 00000000 ffffffff 00cf9300 GS =0018 00000000 ffffffff 00cf9300 LDT=0000 00000000 0000ffff 00008000 TR =0000 00000000 0000ffff 00008000 GDT= 00091000 0000006f IDT= 00000000 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 CCS=00000004 CCD=31c3b000 CCO=EFLAGS FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 Aborted (core dumped) I searched about this error message. This is a generic error, but I can't found any solution. Some suggestion? Cheers, Alan From Libo.Feng at amd.com Thu Aug 2 11:21:05 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Thu, 2 Aug 2007 17:21:05 +0800 Subject: [LinuxBIOS] No keyboard. Message-ID: Hi, all, Today, I almost finish LinuxBIOS on Tyan s3992. A text-mode RedHat is booted, and a "Hello, World" is written and run. Thank a lot of people here. The mistake I made is building LinuxBIOS on a FC machine and testing it on another RH machine, many machine check panics arose. The one thing left is that keyboard is not enabled in Linux. It seems it is not correctly configured in LinuxBIOS. I have to use a serial port and terminal to access the machine. Where the keyboard is enabled in LinuxBIOS? And maybe easier, Linux has some kind of application like Windows to configure keyboard or not? Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -------------- next part -------------- An HTML attachment was scrubbed... URL: From selmys at lotuspond.ca Thu Aug 2 16:38:53 2007 From: selmys at lotuspond.ca (john) Date: Thu, 02 Aug 2007 10:38:53 -0400 Subject: [LinuxBIOS] GA-M57SLI - Benchmarks In-Reply-To: <20070729044529.23116.qmail@stuge.se> References: <46A6ACD9.7090204@lotuspond.ca> <20070725130225.5533.qmail@stuge.se> <46A775FB.9080201@lotuspond.ca> <46ABFE8F.7030406@lotuspond.ca> <20070729044529.23116.qmail@stuge.se> Message-ID: <46B1EC7D.9040608@lotuspond.ca> On 07/29/2007 12:45 AM, Peter Stuge wrote: > On Sat, Jul 28, 2007 at 10:42:23PM -0400, john wrote: > >> 3. I now can load kvm_amd (without locking up my system) and use >> hardware acceleration to speed up my virtual machines. >> > > Have you been able to make any performance measurements yet? > > //Peter > I have attached a *totally unscientific* benchmark comparison I made. I used openBench for my three (3) tests - Using original Award BIOS, using LinuxBIOS and finally a KVM. John ============== -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Aug 2 17:31:57 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 2 Aug 2007 08:31:57 -0700 Subject: [LinuxBIOS] No keyboard. In-Reply-To: References: Message-ID: <13426df10708020831h4b6edce1l6a3eb9ad18abd608@mail.gmail.com> On 8/2/07, Feng, Libo wrote: > > > > > Hi, all, > > Today, I almost finish LinuxBIOS on Tyan s3992. A text-mode RedHat is > booted, and a "Hello, World" is written and run. Thank a lot of people here. > The mistake I made is building LinuxBIOS on a FC machine and testing it on > another RH machine, many machine check panics arose. > > The one thing left is that keyboard is not enabled in Linux. It seems it is > not correctly configured in LinuxBIOS. I have to use a serial port and > terminal to access the machine. Where the keyboard is enabled in LinuxBIOS? > And maybe easier, Linux has some kind of application like Windows to > configure keyboard or not? This is great news! What chip is the keyboard connected to? Then we can see how to enable it. ron From svn at openbios.org Thu Aug 2 18:08:02 2007 From: svn at openbios.org (LinuxBIOS) Date: Thu, 02 Aug 2007 16:08:02 -0000 Subject: [LinuxBIOS] #86: filo sata boot delay patch Message-ID: <041.7350c29c43b0c1714ac99d5554d073a9@openbios.org> #86: filo sata boot delay patch --------------------------------+------------------------------------------- Reporter: ward | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: patch needs work | --------------------------------+------------------------------------------- I've been using the attached patch to filo on machines that need to boot from SATA disks. It's only necessary on cold boot, as the problem is the physical spin-up of the drives. The patch is very crude, and there have been reports that a shorter delay is sufficient. I have not had time to test a shorter delay, and I suspect that the length of the delay might depend somewhat on the drives used. Ideally there would be a way for FILO to see if the boot was cold or warm so that it could apply the delay in the cold-boot case only. Also, this delay should be configurable in FILO's Config file. -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Thu Aug 2 19:34:01 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 2 Aug 2007 19:34:01 +0200 Subject: [LinuxBIOS] GSoC status report: lbmenu Message-ID: <20070802173401.GE23143@greenwood> Hi all, here's my (first) status report for the lbmenu project I'm working on as part of the Google Summer of Code. I should have done this a lot earlier, sorry for the delay. What is lbmenu? --------------- lbmenu is a simple payload which provides a LinuxBIOS config menu, which allows you to change some config options at "runtime", i.e. after LinuxBIOS did the hardware init, but before any bootloader or OS is started. Planned features, design goals (mostly copied from my GSoC proposal) -------------------------------------------------------------------- - Text-mode (Kconfig-like) console UI for changing LinuxBIOS settings. - Bootsplash screen (text mode only for now) where the user can press a certain (configurable) key to enter the configuration tool. - The tool should also be accessible over serial console (for headless clients, servers or debugging scenarios), as well as (if feasible) over telnet or ssh (given a big enough ROM chip and Linux + busybox in ROM). - The tool should work both in ROM (as part of LinuxBIOS), and as a standalone application on a Linux system. The GUI should be the same (or similar) in both cases. The standalone version might enable some options which cannot be used in the embedded version because of size constraints. To investigate: Implement the standalone tool as a frontend of lxbios? Or include the lxbios code in the standalone tool? - The tool needs to fit into flash ROM (together with LinuxBIOS and at least one LinuxBIOS payload), so size is important. Typical sizes of flash ROM chips today range from 256 KB to 2 MB. - It should be reasonably easy to extend the tool. For example, it should be possible to (later) add a graphical user-interface on top of the generic, UI-independent code of this tool. A graphical user-interface is _not_ part of this GSoC project, though! - "BIOS password" feature for setting a LinuxBIOS password. Without the correct password, no payload should be executed/booted. Random possible ideas for after GSoC ------------------------------------ - Internationalization support (using gettext or something similar). The strings in the UI should be fully translatable into other languages. Changing the language at run-time would require the strings of all supported languages to be placed into ROM (size constraints), so this will probably be a compile-time option only. - Configurable UI-Themes (colors, layouts, key mappings, text-based or (later) graphical splash screens etc.) - Payload selection mechanism to choose at runtime which payload to boot (if multiple payloads are included in the ROM chip). This would make it theoretically possible to choose between GRUB2, EFI, Open Firmware and other payloads upon each system boot. It's not yet clear if this should be done in lbmenu, or as a mechanism in LinuxBIOS itself, or maybe as part of lbgrub2. - LinuxBIOS Device Tree browser which shows the device tree for this mainboard (maybe even allows changes?). Implementation plan/notes ------------------------- - Written in C code (minimal assembly code, if required). - The code will be documented using Doxygen-style code comments. - A manpage will explain the usage and parameters of the tool. Optionally, there will be some help texts in the tool (configurable, as that increases the size of the tool). - Ideally, the building of the tool will be integrated in the normal LinuxBIOSv3 build process, with hooks for adapting some defaults or settings of the tool at compile-time. - QEMU will be used for testing the implementation. - License: GPL, version 2 or later. Status ------ - I have written a minimalist ncurses-implementation called tinycurses, which allows some basic primitives such as printing characters on screen, moving the cursor, reading keys from keyboard, beeping etc. It (sort of) supports both, VGA text console, and serial; more work is needed, though. This is designed as a general purpose payload library, which can also be used by other payloads which need console text support, serial output, keyboard services, beep() etc. - The alternative would be to use the stock ncurses, but there are various problems: - Too big; tinycurses is stripped down to just provide the most important functions and features (e.g. no wide character support). - Requires syscalls, term library, and generally an OS. I _do_ have a first test version which is compiled/linked against newlib (http://sourceware.org/newlib/), a small libc implementation which has stubs for OS-less builds (which we need in LinuxBIOS + payloads). However, making this really fully work will require a lot more work. Also, the smallest lbmenu payload size when using newlib I've been able to get so far, is 130 KB or so (which is quite a lot). My plan is to be able to use lbmenu with 256K ROM chips, and you need to put LinuxBIOS (30-70 KB) in there, as well as at least one payload (say FILO, ~60-80 KB), and lbmenu. So size is very important. On the long term the lbmenu implementation should probably rely on the tinycurses implementation for that reason (which is currently smaller than 10 KB or so, and doesn't require newlib). - The final goal of all of this would be to use plain Kconfig _within_ lbmenu (at runtime) to display lbmenu's options and let the user change them. Thus ncurses or tinycurses needs to be complete enough to be able to compile kconfig. If this is absolutely not feasible, well, I'll have to implement a small menu system from scratch, but I hope that won't be necessary. - The compile-time options of lbmenu are configured via kconfig, just like the options of LinuxBIOSv3 itself. - So far my draft implementation of lbmenu can be booted, prints a text banner (VGA and/or serial), can react on a (configurable) keypress, e.g. ESC, then enter a "menu" (which is a stub right now), and reboot upon another ESC keypress. TODO ---- - Finish tinycurses and/or ncurses+newlib so they're usable with kconfig. - Figure out a mechanism to select between various payloads included in the ROM (_if_ this will be done in lbmenu, discussions welcome). - Implement read/write of CMOS values. - The configuration menu within lbmenu will be "dynamically" generated (or that's my plan at least) from Kconfig.lbmenu files in the LinuxBIOSv3 tree. The same parser which is used in Kconfig should parse all *.lbmenu files and construct the lbmenu main menu from that. So you can have southbridge/amd/cs5536/Kconfig.lbmenu which provides lbmenu menu items which are CS5536-specific (e.g. enable/disable IDE). Another mainboard/amd/norwich/Kconfig.lbmenu would provide mainboard- specific menu items etc. etc. - Probably a few other things I cannot think of right now. No code yet, sorry, but I'll try to put together a small demo soon which I can post here. I intend to put tinycurses into the global util/ directory, as it's independant of LinuxBIOS and generally usable for other payloads. Same for lbmenu, it should be in util/ and gets its tinycurses implementation via svn:externals (as should all other payloads which use it)... Any comments and suggestions welcome! Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From peter at stuge.se Thu Aug 2 22:42:45 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 2 Aug 2007 22:42:45 +0200 Subject: [LinuxBIOS] No keyboard. In-Reply-To: References: Message-ID: <20070802204245.1951.qmail@stuge.se> Hi, On Thu, Aug 02, 2007 at 05:21:05PM +0800, Feng, Libo wrote: > Today, I almost finish LinuxBIOS on Tyan s3992. A text-mode RedHat > is booted, and a "Hello, World" is written and run. Excellent! :) > Thank a lot of people here. The mistake I made is building > LinuxBIOS on a FC machine and testing it on another RH machine, > many machine check panics arose. The GNU toolchain (gcc and binutils) in the FC system may be unable to build LB correctly. Can you tell us what version of gcc and binutils you were using in the FC system that produced bad results, and what version you have used to produce a working result? > The one thing left is that keyboard is not enabled in Linux. It > seems it is not correctly configured in LinuxBIOS. I have to use a > serial port and terminal to access the machine. Where the keyboard > is enabled in LinuxBIOS? That depends on what the keyboard connects to. Is it a USB keyboard or a PS/2 keyboard? Whatever it is, could you also try the other? Also see Ron's question about which chip the keyboard is connected to. > And maybe easier, Linux has some kind of application like Windows > to configure keyboard or not? Not always an application, but there are configuration files in most if not all Linux distributions for setting up the keymap. That doesn't help if the kernel can't see the keyboard however. Feel free to send a serial port capture from a full boot with LB to the mailing list, we'll look at it and see if we can find something pointing to the error. //Peter From outlander_wei at yahoo.com Fri Aug 3 08:58:00 2007 From: outlander_wei at yahoo.com (Richard Wei) Date: Thu, 2 Aug 2007 23:58:00 -0700 (PDT) Subject: [LinuxBIOS] Tyan S2885 memreset problem!! Message-ID: <890057.97515.qm@web33506.mail.mud.yahoo.com> Help help ... I have checked out from the first time the source code of Tyan s2885 is placed on v2.1090 to v2.2140. (I have tried 1100, 1150, 1322, 1390, 1430, 1530, 1550 ... 2010, 2050, 2090) I wasn't able to build images successfully for Tyan s2885 until v2.2140. Probably it's my environment's problem. Somehow, the system still stop at memreset. Does it means that I have to spend DOLLARs? .... Richard Wei ----- Original Message ---- From: yhlu To: Richard Wei Cc: linuxbios at linuxbios.org Sent: Tuesday, July 31, 2007 12:38:42 PM Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! On 7/30/07, Richard Wei wrote: > Oh... I check it again. > The information right on the AMD Opteron processor is OSA240CC05AH. > By the last two digit, I think I have Rev. B3. > > > AD CPUID?Model4ESRev.C0?0.13um > AG CPUID?Model5(max.1CPU)Rev.B3-0,13umSledgehammer core > AH CPUID?Model5(max.2CPU)Rev.B3-0,13umSledgehammer core > AI CPUID?Model5(max.8CPU)Rev.B3-0,13umSledgehammer core > AK CPUID?Model5(max.1CPU)Rev.C0-0,13umSledgehammer core > AL CPUID?Model5(max.2CPU)Rev.C0-0,13umSledgehammer core > AMCPUID?Model5(max.8CPU)Rev.C0-0,13umSledgehammer core > wow, how can you get that? it seems only LANL's big cluster is using that. that cpu can not reset memory directly, so it need SB's help to reset memory... I wonder if support cache_as_ram too... I suggest you may download some old tar to test that. or i could send you one image that i buld in blind to try luck... YH ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From Libo.Feng at amd.com Fri Aug 3 09:12:55 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Fri, 3 Aug 2007 15:12:55 +0800 Subject: [LinuxBIOS] Tyan S2885 memreset problem!! In-Reply-To: <890057.97515.qm@web33506.mail.mud.yahoo.com> References: <890057.97515.qm@web33506.mail.mud.yahoo.com> Message-ID: We seemed to have the same problem before. We just set DQS_TRAIN_DEBUG 1 in /northbridge/amd/amdk8/raminit_f_dqs.c to solve the problem. We don't know the reason. Mr. Lu Yinghai once suggested to use a new version gcc to actually solve the problem. You can try it. We use LB 2584, and gcc is 4.0.0. Because we just want to get some BIOS experience by learning LinuxBIOS, so the version is very old. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Wei Sent: Friday, August 03, 2007 2:58 PM To: yhlu Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! Help help ... I have checked out from the first time the source code of Tyan s2885 is placed on v2.1090 to v2.2140. (I have tried 1100, 1150, 1322, 1390, 1430, 1530, 1550 ... 2010, 2050, 2090) I wasn't able to build images successfully for Tyan s2885 until v2.2140. Probably it's my environment's problem. Somehow, the system still stop at memreset. Does it means that I have to spend DOLLARs? .... Richard Wei ----- Original Message ---- From: yhlu To: Richard Wei Cc: linuxbios at linuxbios.org Sent: Tuesday, July 31, 2007 12:38:42 PM Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! On 7/30/07, Richard Wei wrote: > Oh... I check it again. > The information right on the AMD Opteron processor is OSA240CC05AH. > By the last two digit, I think I have Rev. B3. > > > AD CPUID?Model4ESRev.C0?0.13um > AG CPUID?Model5(max.1CPU)Rev.B3-0,13umSledgehammer core AH > CPUID?Model5(max.2CPU)Rev.B3-0,13umSledgehammer core AI > CPUID?Model5(max.8CPU)Rev.B3-0,13umSledgehammer core AK > CPUID?Model5(max.1CPU)Rev.C0-0,13umSledgehammer core AL > CPUID?Model5(max.2CPU)Rev.C0-0,13umSledgehammer core > AMCPUID?Model5(max.8CPU)Rev.C0-0,13umSledgehammer core > wow, how can you get that? it seems only LANL's big cluster is using that. that cpu can not reset memory directly, so it need SB's help to reset memory... I wonder if support cache_as_ram too... I suggest you may download some old tar to test that. or i could send you one image that i buld in blind to try luck... YH ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios From corey.osgood at gmail.com Fri Aug 3 11:49:19 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 03 Aug 2007 05:49:19 -0400 Subject: [LinuxBIOS] GSoC status report: lbmenu In-Reply-To: <20070802173401.GE23143@greenwood> References: <20070802173401.GE23143@greenwood> Message-ID: <46B2FA1F.3060309@gmail.com> Uwe Hermann wrote: > Hi all, > > here's my (first) status report for the lbmenu project I'm working on as > part of the Google Summer of Code. > Good work, can't wait to see the end result! -Corey From Libo.Feng at amd.com Fri Aug 3 12:22:25 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Fri, 3 Aug 2007 18:22:25 +0800 Subject: [LinuxBIOS] No keyboard. In-Reply-To: <13426df10708020831h4b6edce1l6a3eb9ad18abd608@mail.gmail.com> References: <13426df10708020831h4b6edce1l6a3eb9ad18abd608@mail.gmail.com> Message-ID: Hi, The Super IO is nsc-87417, there is a directory for the chip. I have enabled the keyboard device in mainboard Config.lb, as below, Device pnp 2e.6 on io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 End However, in super/nsc/pc87417/superio.c, the keyboard pnp_info is {&ops, PC87417_KBCK, PNP_IO0 | PNP_IO1 | PNP_IRQ0, {0x7f8, 0}, {0x7f8, 4}}, is it correct? I think it should be PNP_IRQ1, {0x60, 0} and {0x60, 4}, I changed it, but still no keyboard. What should I do next? Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: ron minnich [mailto:rminnich at gmail.com] Sent: Thursday, August 02, 2007 11:32 PM To: Feng, Libo Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] No keyboard. On 8/2/07, Feng, Libo wrote: > > > > > Hi, all, > > Today, I almost finish LinuxBIOS on Tyan s3992. A text-mode RedHat is > booted, and a "Hello, World" is written and run. Thank a lot of people here. > The mistake I made is building LinuxBIOS on a FC machine and testing > it on another RH machine, many machine check panics arose. > > The one thing left is that keyboard is not enabled in Linux. It seems > it is not correctly configured in LinuxBIOS. I have to use a serial > port and terminal to access the machine. Where the keyboard is enabled in LinuxBIOS? > And maybe easier, Linux has some kind of application like Windows to > configure keyboard or not? This is great news! What chip is the keyboard connected to? Then we can see how to enable it. ron From Libo.Feng at amd.com Fri Aug 3 12:34:23 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Fri, 3 Aug 2007 18:34:23 +0800 Subject: [LinuxBIOS] No keyboard. In-Reply-To: <20070802204245.1951.qmail@stuge.se> References: <20070802204245.1951.qmail@stuge.se> Message-ID: Hi, I built LinuxBIOS on Linux version 2.6.11-1.1369_FC4smp and gcc version 4.0.0 20050525, then tested LinuxBIOS on Linux version 2.6.9-22 Elsmp and gcc version 3.4.4 20050721. There were always many kind of machine check panics. Now I build and test on Linux version 2.6.9-22 Elsmp and gcc version 3.4.4 20050721. I have tried both USB and PS/2 keyboard, neither can work. I changed some code, it still doesn't work. Maybe I miss something. In Linux, kudzu can do some hardware detect, but don't work in this case. The attached is a log, maybe you can help me find some clue. Thank you. We just want to gain some BIOS experience, so the LinuxBIOS version is very old. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Peter Stuge Sent: Friday, August 03, 2007 4:43 AM To: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] No keyboard. Hi, On Thu, Aug 02, 2007 at 05:21:05PM +0800, Feng, Libo wrote: > Today, I almost finish LinuxBIOS on Tyan s3992. A text-mode RedHat is > booted, and a "Hello, World" is written and run. Excellent! :) > Thank a lot of people here. The mistake I made is building LinuxBIOS > on a FC machine and testing it on another RH machine, many machine > check panics arose. The GNU toolchain (gcc and binutils) in the FC system may be unable to build LB correctly. Can you tell us what version of gcc and binutils you were using in the FC system that produced bad results, and what version you have used to produce a working result? > The one thing left is that keyboard is not enabled in Linux. It seems > it is not correctly configured in LinuxBIOS. I have to use a serial > port and terminal to access the machine. Where the keyboard is enabled > in LinuxBIOS? That depends on what the keyboard connects to. Is it a USB keyboard or a PS/2 keyboard? Whatever it is, could you also try the other? Also see Ron's question about which chip the keyboard is connected to. > And maybe easier, Linux has some kind of application like Windows to > configure keyboard or not? Not always an application, but there are configuration files in most if not all Linux distributions for setting up the keymap. That doesn't help if the kernel can't see the keyboard however. Feel free to send a serial port capture from a full boot with LB to the mailing list, we'll look at it and see if we can find something pointing to the error. //Peter -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: boot.txt URL: From george at kami.ru Fri Aug 3 18:35:52 2007 From: george at kami.ru (George V. Adamov) Date: Fri, 03 Aug 2007 16:35:52 +0000 Subject: [LinuxBIOS] MSI ms 7250 (based on Giga57Sli) none SMP kernel IRQ problem Message-ID: <46B35968.9040907@kami.ru> If I understood correctly it's possible to change IRQs for pci slots via mp_table.c /*I have a dual core CPU 3800+ but running LB linux with smp kernel shows only one cpu (((*/ But when booting none smp mp_table seems to be ignored (as well as pirq). Is there any way to control interrupts assigned to PCI slots? /*should I programm interrupt controller directly*/ G. From peter at stuge.se Fri Aug 3 15:48:48 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 3 Aug 2007 15:48:48 +0200 Subject: [LinuxBIOS] No keyboard. In-Reply-To: References: <20070802204245.1951.qmail@stuge.se> Message-ID: <20070803134848.6646.qmail@stuge.se> On Fri, Aug 03, 2007 at 06:34:23PM +0800, Feng, Libo wrote: > I built LinuxBIOS on Linux version 2.6.11-1.1369_FC4smp and gcc > version 4.0.0 20050525, then tested LinuxBIOS on Linux version > 2.6.9-22 Elsmp and gcc version 3.4.4 20050721. There were always > many kind of machine check panics. > > Now I build and test on Linux version 2.6.9-22 Elsmp and gcc > version 3.4.4 20050721. Kernel versions should not matter, but both kernels are patched (RedHat?) so we can't be sure. I don't trust patched kernels. gcc version is the same on both the non-working system and the currently working system. Can you also check the version of binutils on old and new system? (e.g. by running ld --version or nm --version) > I have tried both USB and PS/2 keyboard, neither can work. From peter at stuge.se Fri Aug 3 15:53:26 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 3 Aug 2007 15:53:26 +0200 Subject: [LinuxBIOS] MSI ms 7250 (based on Giga57Sli) none SMP kernel IRQ problem In-Reply-To: <46B35968.9040907@kami.ru> References: <46B35968.9040907@kami.ru> Message-ID: <20070803135326.7310.qmail@stuge.se> On Fri, Aug 03, 2007 at 04:35:52PM +0000, George V. Adamov wrote: > If I understood correctly it's possible to change IRQs for pci > slots via mp_table.c Well, not arbitrarily. Which IRQ you can assign to a PCI slot is ultimately determined by the signal routing on the mainboard. > /*I have a dual core CPU 3800+ but running LB linux with smp kernel > shows only one cpu (((*/ This sounds bad. Does LB say anything about multiple cores? (Should it?) > But when booting none smp mp_table seems to be ignored (as well as > pirq). This also sounds bad. Is there ACPI for this board? That would cause mptable and pirq to be ignored by Linux. > Is there any way to control interrupts assigned to PCI slots? Not arbitrarily, no. :\ //Peter From otavio.junior at gmail.com Fri Aug 3 18:31:45 2007 From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=) Date: Fri, 3 Aug 2007 13:31:45 -0300 Subject: [LinuxBIOS] W83267HF Keyboard Setup Message-ID: <751d98080708030931y760b6c8ewa9a661eb91e67123@mail.gmail.com> Hello to all, I'm trying to port linuxbios to a AMD RDK UVC similar board, using the norwich board code. I've just got to boot the board, but the keyboard doesn't work. My board uses an extension I/O board based on WINBOND W83627HF connected to LPC bus, I've already setup the superio serial. I've tried to include in cache_as_ram_auto.c the superio.c (from w83627hf directory), and use the w83627_init() routine, but there are some compilations problems. How can I set up the PC keyboard in linuxbios, using the W83267HF chipset? Regards, Ot?vio Alc?ntara "I'll never cross to the Dark Side." -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Fri Aug 3 18:41:36 2007 From: marc.jones at amd.com (Marc Jones) Date: Fri, 03 Aug 2007 10:41:36 -0600 Subject: [LinuxBIOS] W83267HF Keyboard Setup In-Reply-To: <751d98080708030931y760b6c8ewa9a661eb91e67123@mail.gmail.com> References: <751d98080708030931y760b6c8ewa9a661eb91e67123@mail.gmail.com> Message-ID: <46B35AC0.8070404@amd.com> Ot?vio Alc?ntara wrote: > Hello to all, > > I'm trying to port linuxbios to a AMD RDK UVC similar board, > using the norwich board code. I've just got to boot the board, but the > keyboard doesn't work. My board uses an extension I/O board based on > WINBOND W83627HF connected to LPC bus, I've already setup the superio > serial. > I've tried to include in cache_as_ram_auto.c the superio.c > (from w83627hf directory), and use the w83627_init() routine, but there > are some compilations problems. > How can I set up the PC keyboard in linuxbios, using the > W83267HF chipset? > > Regards, > > Ot?vio Alc?ntara > "I'll never cross to the Dark Side." > Otavio, The amd\db800 is the platform you want to base your changes on. It does the W83627HF setup and the keyboard should just work. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From yinghailu at gmail.com Fri Aug 3 19:40:29 2007 From: yinghailu at gmail.com (yhlu) Date: Fri, 3 Aug 2007 10:40:29 -0700 Subject: [LinuxBIOS] No keyboard. In-Reply-To: References: <20070802204245.1951.qmail@stuge.se> Message-ID: <2ea3fae10708031040y77b5fe13g8b5d48af3025e2eb@mail.gmail.com> please check if bcm5785 bcm5780 is in the first ht link in your MB Config.lb. Or send out your MB Config.lb. YH From rasasi78 at gmail.com Sat Aug 4 01:51:59 2007 From: rasasi78 at gmail.com (=?UTF-8?B?UmHDumwgU8OhbmNoZXogU2lsZXM=?=) Date: Sat, 04 Aug 2007 01:51:59 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. Message-ID: Hello all: I was interested in upgrading my computer BIOS. This is a laptop Dell Inspiron 510m. The mother board is an ICH4, more details on request. So I came across flashroom and I tried to use it, and since the motherboard was recognised, there wasn't that luck with the BIOS chip. After all this I effectively did the upgrade but using the manufacturer recommended biosdisk method (it worked). But after that I wanted to know more and aafter some talk with someone at the channel, he (sorry I can't remember your name) told me to send the flashrom -V report here and here I am: flashrom -V Calibrating delay loop... 376M loops per second. ok No LinuxBIOS table found. Found chipset "ICH4-M": Enabling flash write... OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0xea, id2 0xf0 Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for At29C040A, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for At29C020, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for Mx29f002, 256 KB probe_29f002: id1 0xea, id2 0xf0 Probing for SST29EE020A, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST28SF040A, 512 KB probe_28sf040: id1 0xea, id2 0xf0 Probing for SST39SF010A, 128 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST39SF020A, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST39SF040, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST39VF020, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF040B, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF040, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF020A, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF002A/B, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF003A/B, 384 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF008A, 1024 KB probe_jedec: id1 0xea, id2 0xf0 Probing for Pm49FL002, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for SST49LF004C, 512 KB probe_49lfxxxc: id1 0xea, id2 0xf0 Probing for SST49LF008C, 1024 KB probe_49lfxxxc: id1 0xea, id2 0xf0 Probing for SST49LF016C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST49LF160C, 2048 KB probe_49lfxxxc: id1 0xff, id2 0xff Probing for Pm49FL004, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W29C011, 128 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W29C020C, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W49F002U, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W49V002A, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W49V002FA, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W39V040FA, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W39V040A, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W39V040B, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for W39V080A, 1024 KB probe_jedec: id1 0xea, id2 0xf0 Probing for M29F002B, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for M29F002T/NT, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for M29F400BT, 512 KB probe_m29f400bt: id1 0xea, id2 0xf0 Probing for M29F040B, 512 KB probe_29f040b: id1 0xea, id2 0xf0 Probing for 82802ab, 512 KB probe_82802ab: id1 0xea, id2 0xf0 Probing for 82802ac, 1024 KB probe_82802ab: id1 0xea, id2 0xf0 Probing for F49B002UA, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for LHF00L04, 1024 KB probe_lhf00l04: id1 0xea, id2 0xf0 Probing for S29C51001T, 128 KB probe_jedec: id1 0xea, id2 0xf0 Probing for S29C51002T, 256 KB probe_jedec: id1 0xea, id2 0xf0 Probing for S29C51004T, 512 KB probe_jedec: id1 0xea, id2 0xf0 Probing for S29C31004T, 512 KB probe_jedec: id1 0xea, id2 0xf0 No EEPROM/flash device found. Regards, From c-d.hailfinger.devel.2006 at gmx.net Sat Aug 4 03:36:20 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 04 Aug 2007 03:36:20 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: References: Message-ID: <46B3D814.4010001@gmx.net> On 04.08.2007 01:51, Ra?l S?nchez Siles wrote: > Hello all: > > I was interested in upgrading my computer BIOS. This is a laptop Dell > Inspiron 510m. The mother board is an ICH4, more details on request. Probably a board specific enable routine is needed. > So I came across flashroom and I tried to use it, and since the motherboard > was recognised, there wasn't that luck with the BIOS chip. After all this I > effectively did the upgrade but using the manufacturer recommended biosdisk > method (it worked). > > flashrom -V > Calibrating delay loop... 376M loops per second. ok > No LinuxBIOS table found. > Found chipset "ICH4-M": Enabling flash write... OK. > Probing for Am29F040B, 512 KB > probe_29f040b: id1 0xea, id2 0xf0 > Probing for Am29F016D, 2048 KB > probe_29f040b: id1 0xff, id2 0xff Summary: id1=0xea, id2=0xf0 for every flash size up to and including 1024 kb. Since this happens regardless of the identification routine used, I assume it is not an ID at all, but some value stored every 128 kb on the flash chip. This can be verified by using the Dell flash utility to backup the existing bios and look at the first 2 bytes of the resulting image. However, using the Dell flash utility to find out the name of the flash chip would also be helpful. Regards, Carl-Daniel From eyal at cohenim.net Sat Aug 4 08:44:59 2007 From: eyal at cohenim.net (Eyal Cohen) Date: Sat, 04 Aug 2007 09:44:59 +0300 Subject: [LinuxBIOS] Kernel does nothing Message-ID: <1186209899.23157.12.camel@mainmachine> Hello. I have a GX1+CS5530A+PC97317 board that I would like LinuxBIOS to work (properly) on. I have managed to compile LinuxBIOSv2 for this configuration using FILO as payload and burned the bios flash with it. To my relief it began outputting data to the serial port so it seemed like everything was working. It said it found ram and the hardware and all was fine. After seeing that I have connected a hard drive and tried to boot a kernel. FILO said it finds the file and seemed to load it to memory,but... Once FILO jumped to the kernel no more output was transmitted nor to the com port nor the screen. I have also patched this kernel with a patch by Juergen Beisert to add support for the CS5530's IRQ router. The kernel I have used has build in support for standard UART, and from using another (same kind) board with this kernel I can guarantee the COM port works. What is wrong? Why doesn't the kernel boot? Attached is the output log from the COM port. Thank you very much EyalC -------------- next part -------------- LinuxBIOS-2.0.0.0Fallback Sun Jul 1 06:27:14 IDT 2007 starting... Setting up default parameters for memory Sizing memory Probing for DIMM0 Found DIMM0 Page Size: 00001000 Component Banks: 4 Module Banks: 2 DIMM size: 08000000 Probing for DIMM1 MC_BANK_CFG = 00705520 Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Sun Jul 1 06:27:14 IDT 2007 booting... end 4b7fc3fe, start 0 32-bit delta 449 calibrate_tsc 32-bit result is 449 clocks_per_usec: 449 Enumerating buses... scan_static_bus for Root Device northbridge.c:enable_dev() DEVICE_PATH_PCI_DOMAIN Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 00 northbridge.c:enable_dev() device path type 2 PCI: 00:00.0 [1078/0001] ops PCI: 00:00.0 [1078/0001] enabled PCI: devfn 0x8, bad id 0xffffffff PCI: devfn 0x10, bad id 0xffffffff PCI: devfn 0x18, bad id 0xffffffff PCI: devfn 0x20, bad id 0xffffffff PCI: devfn 0x28, bad id 0xffffffff PCI: devfn 0x30, bad id 0xffffffff PCI: devfn 0x38, bad id 0xffffffff PCI: devfn 0x40, bad id 0xffffffff PCI: devfn 0x48, bad id 0xffffffff PCI: devfn 0x50, bad id 0xffffffff PCI: devfn 0x58, bad id 0xffffffff malloc Enter, size 668, free_mem_ptr 00016000 malloc 0x00016000 PCI: 00:0c.0 [10ec/8139] enabled PCI: devfn 0x68, bad id 0xffffffff PCI: devfn 0x70, bad id 0xffffffff PCI: devfn 0x79, bad id 0xffffffff PCI: devfn 0x7a, bad id 0xffffffff PCI: devfn 0x7b, bad id 0xffffffff PCI: devfn 0x7c, bad id 0xffffffff PCI: devfn 0x7d, bad id 0xffffffff PCI: devfn 0x7e, bad id 0xffffffff PCI: devfn 0x7f, bad id 0xffffffff PCI: devfn 0x80, bad id 0xffffffff PCI: devfn 0x88, bad id 0xffffffff PCI: 00:12.0 [1078/0100] bus ops southbridge_enable: dev is 0000e040 PCI: 00:12.0 [1078/0100] enabled PCI: 00:12.1 [1078/0101] disabled PCI: 00:12.2 [1078/0102] ops cs5530_ide: ide_enable PCI: 00:12.2 [1078/0102] enabled PCI: 00:12.3 [1078/0103] enabled PCI: 00:12.4 [1078/0104] enabled PCI: devfn 0x95, bad id 0xffffffff PCI: devfn 0x96, bad id 0xffffffff PCI: devfn 0x97, bad id 0xffffffff PCI: 00:13.0 [0e11/a0f8] enabled PCI: devfn 0xa0, bad id 0xffffffff PCI: devfn 0xa8, bad id 0xffffffff PCI: devfn 0xb0, bad id 0xffffffff PCI: devfn 0xb8, bad id 0xffffffff PCI: devfn 0xc0, bad id 0xffffffff PCI: devfn 0xc8, bad id 0xffffffff PCI: devfn 0xd0, bad id 0xffffffff PCI: devfn 0xd8, bad id 0xffffffff PCI: devfn 0xe0, bad id 0xffffffff PCI: devfn 0xe8, bad id 0xffffffff PCI: devfn 0xf0, bad id 0xffffffff PCI: devfn 0xf8, bad id 0xffffffff scan_static_bus for PCI: 00:12.0 malloc Enter, size 668, free_mem_ptr 0001629c malloc 0x0001629c malloc Enter, size 668, free_mem_ptr 00016538 malloc 0x00016538 malloc Enter, size 668, free_mem_ptr 000167d4 malloc 0x000167d4 malloc Enter, size 668, free_mem_ptr 00016a70 malloc 0x00016a70 malloc Enter, size 668, free_mem_ptr 00016d0c malloc 0x00016d0c malloc Enter, size 668, free_mem_ptr 00016fa8 malloc 0x00016fa8 malloc Enter, size 668, free_mem_ptr 00017244 malloc 0x00017244 malloc Enter, size 668, free_mem_ptr 000174e0 malloc 0x000174e0 PNP: 002e.4 enabled PNP: 002e.a enabled PNP: 002e.e enabled PNP: 002e.f disabled PNP: 002e.10 enabled PNP: 002e.12 enabled PNP: 002e.0 enabled PNP: 002e.1 enabled PNP: 002e.2 enabled PNP: 002e.3 enabled PNP: 002e.5 enabled PNP: 002e.6 enabled PNP: 002e.7 enabled PNP: 002e.8 enabled scan_static_bus for PCI: 00:12.0 done PCI: pci_scan_bus returning with max=000 scan_static_bus for Root Device done done Allocating resources... Reading resources... Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 northbridge.c:pci_domain_read_resources() PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done PCI: 00:0c.0 10 * [0x00000400 - 0x000004ff] io PCI: 00:12.2 20 * [0x00000800 - 0x0000087f] io Root Device compute_allocate_io: base: 00000880 size: 00000480 align: 8 gran: 0 done Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:12.4 10 * [0x00000000 - 0x00000fff] mem PCI: 00:13.0 10 * [0x00001000 - 0x00001fff] mem PCI: 00:0c.0 14 * [0x00002000 - 0x000020ff] mem PCI: 00:12.3 10 * [0x00003000 - 0x0000307f] mem Root Device compute_allocate_mem: base: 00003080 size: 00003080 align: 12 gran: 0 done Done reading resources. Setting resources... Root Device compute_allocate_io: base: 00001000 size: 00000480 align: 8 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:0c.0 10 * [0x00001000 - 0x000010ff] io PCI: 00:12.2 20 * [0x00001400 - 0x0000147f] io Root Device compute_allocate_io: base: 00001480 size: 00000480 align: 8 gran: 0 done Root Device compute_allocate_mem: base: febfc000 size: 00003080 align: 12 gran: 0 Root Device read_resources bus 0 link: 0 Root Device read_resources bus 0 link: 0 done PCI: 00:12.4 10 * [0xfebfc000 - 0xfebfcfff] mem PCI: 00:13.0 10 * [0xfebfd000 - 0xfebfdfff] mem PCI: 00:0c.0 14 * [0xfebfe000 - 0xfebfe0ff] mem PCI: 00:12.3 10 * [0xfebff000 - 0xfebff07f] mem Root Device compute_allocate_mem: base: febff080 size: 00003080 align: 12 gran: 0 done Root Device assign_resources, bus 0 link: 0 BC_DRAM_TOP = 0x07bfffff MC_GBASE_ADD = 0x000000f8 I would set ram size to 124 Mbytes PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:0c.0 10 <- [0x0000001000 - 0x00000010ff] io PCI: 00:0c.0 14 <- [0x00febfe000 - 0x00febfe0ff] mem PCI: 00:12.2 20 <- [0x0000001400 - 0x000000147f] io PCI: 00:12.3 10 <- [0x00febff000 - 0x00febff07f] mem PCI: 00:12.4 10 <- [0x00febfc000 - 0x00febfcfff] mem PCI: 00:13.0 10 <- [0x00febfd000 - 0x00febfdfff] mem PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 147 PCI: 00:0c.0 cmd <- 143 cs5530.c: cs5530_pci_dev_enable_resources() PCI: 00:12.0 cmd <- 14f PNP: 002e.a missing enable_resources PNP: 002e.e missing enable_resources PNP: 002e.10 missing enable_resources PNP: 002e.12 missing enable_resources PCI: 00:12.2 cmd <- 141 PCI: 00:12.3 subsystem <- 00/00 PCI: 00:12.3 cmd <- 142 PCI: 00:12.4 subsystem <- 00/00 PCI: 00:12.4 cmd <- 142 PCI: 00:13.0 subsystem <- 00/00 PCI: 00:13.0 cmd <- 142 done. Initializing devices... Root Device init PCI: 00:00.0 init northbridge: northbridge_init() Calling enable_cache() PCI: 00:12.0 init cs5530: southbridge_init PNP: 002e.4 init PCI: 00:12.2 init cs5530_ide: ide_init PCI: 00:12.3 init PCI: 00:12.4 init PCI: 00:13.0 init PCI: 00:0c.0 init PNP: 002e.0 init PNP: 002e.1 init PNP: 002e.2 init PNP: 002e.3 init PNP: 002e.5 init PNP: 002e.6 init PNP: 002e.7 init PNP: 002e.8 init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 /home/eyal/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routi ng_table() - checksum is: 0x2d but should be: 0x63 done. Moving GDT to 0x500...ok Adjust low_table_end from 0x00000530 to 0x00001000 Adjust rom_table_end from 0x000f0400 to 0x00100000 Wrote linuxbios table at: 00000530 - 000006b4 checksum 18c4 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 malloc Enter, size 32, free_mem_ptr 0001777c malloc 0x0001777c New segment addr 0x100000 size 0x20e80 offset 0xc0 filesize 0x6ec8 (cleaned up) New segment addr 0x100000 size 0x20e80 offset 0xc0 filesize 0x6ec8 lb: [0x0000000000004000, 0x000000000001a000) malloc Enter, size 32, free_mem_ptr 0001779c malloc 0x0001779c New segment addr 0x120e80 size 0x48 offset 0x6fa0 filesize 0x48 (cleaned up) New segment addr 0x120e80 size 0x48 offset 0x6fa0 filesize 0x48 lb: [0x0000000000004000, 0x000000000001a000) Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000020e80 filesz: 0x00 00000000006ec8 [ 0x0000000000100000, 0000000000106ec8, 0x0000000000120e80) <- 00000000000000c0 Clearing Segment: addr: 0x0000000000106ec8 memsz: 0x0000000000019fb8 Loading Segment: addr: 0x0000000000120e80 memsz: 0x0000000000000048 filesz: 0x00 00000000000048 [ 0x0000000000120e80, 0000000000120ec8, 0x0000000000120ec8) <- 0000000000006fa0 Loaded segments verified segments closed down stream Jumping to boot code at 0x10513c entry = 0x0010513c lb_start = 0x00004000 lb_size = 0x00016000 adjust = 0x07be6000 buffer = 0x07bd4000 elf_boot_notes = 0x00010280 adjusted_boot_notes = 0x07bf6280 FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 Press for default boot, or for boot prompt... timed out boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 hda: LBA 40GB: ST340810A Mounted ext2fs Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 ID T 2007 bzImage. Loading kernel... ok Jumping to entry point... From corey.osgood at gmail.com Sat Aug 4 10:40:05 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 04 Aug 2007 04:40:05 -0400 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <1186209899.23157.12.camel@mainmachine> References: <1186209899.23157.12.camel@mainmachine> Message-ID: <46B43B65.4070903@gmail.com> Eyal Cohen wrote: > FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 > Press for default boot, or for boot prompt... timed out > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > hda: LBA 40GB: ST340810A > Mounted ext2fs > Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 ID > T 2007 bzImage. > Loading kernel... ok > Jumping to entry point... > It looks like your kernel may not be compiled with serial console support. The best check I know of is to boot the system up with the stock bios, then interrupt grub, edit the kernel options to include "console=tty0 console=ttyS0,115200", and then see what happens on your serial terminal. If that can't be easily done, check your kernel config file, and make sure serial support is compiled in (no modules, unless you want to load an initrd), along with serial console, etc, etc. Also, make sure you allow the kernel some time to load, it does take a bit. If you're interested in speeding it up, look for Peter Stuge's FILO IDE Speedup patch in the archives, which is for filo-0.5 (which can be grabbed with svn co svn://openbios.org/filo/trunk/filo-0.5) hope this helps -Corey From popkonserve at gmx.de Sat Aug 4 13:23:28 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 04 Aug 2007 13:23:28 +0200 Subject: [LinuxBIOS] ALi M1621 support Message-ID: <46B461B0.8080301@gmx.de> i know it's been a while, but finally i found time to almost finish the dram detection for the ALi Aladdin Pro II (M1621) as found on the PcChips M726/M727/M729. the multibanking detetion is still missing and i've not bothered about any ram timings or other northbridge (performance) settings yet. and i haven't compiled the source yet, it may be still full of typing errors.. anyway, i included the important files just if someone wants to have a quick glance on the code. oh, and please excuse the horrible size detection monster..i'll try to beautify it later. Holger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m1621.h URL: From rminnich at gmail.com Sat Aug 4 19:33:48 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 4 Aug 2007 10:33:48 -0700 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <46B43B65.4070903@gmail.com> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> Message-ID: <13426df10708041033nebd22ddv48f482eb245f91ec@mail.gmail.com> two other things. First, you can interrupt file with ESC and pass in those console args by hand. Second, earlyprintk is a lifesaver. earlyprint=ttyS0,115200,keep VERY handy. ron From peter at stuge.se Sat Aug 4 19:35:05 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 4 Aug 2007 19:35:05 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: <46B3D814.4010001@gmx.net> References: <46B3D814.4010001@gmx.net> Message-ID: <20070804173505.8845.qmail@stuge.se> On Sat, Aug 04, 2007 at 03:36:20AM +0200, Carl-Daniel Hailfinger wrote: > This can be verified by using the Dell flash utility to backup the > existing bios and look at the first 2 bytes of the resulting image. Is this something Dell always do? I haven't seen the 2 byte id in the actual contents before. (When the chip is in ID state it sends out the ids instead of flash contents.) //Peter From popkonserve at gmx.de Sat Aug 4 19:51:33 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 04 Aug 2007 19:51:33 +0200 Subject: [LinuxBIOS] ALi M1621 support Message-ID: <46B4BCA5.5050901@gmx.de> okay, i've cleaned up all the evil typos (many..duh!), split the column address type detection and the size detection into separate functions, rewrote the size detection and made the functions a bit safer (where did my const go?). gcc still doesn't like my way of calling functions..i'll go figure out how to fix that. as soon as i can get my hands on a mainboard with the northbridge chip i'm going to test it. if you've questions: feel free to ask. in the meantime i'll write some more raminits for slot1/s370/socket7 chipsets. any particular wishes? Holger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: m1621.h URL: From stepan at coresystems.de Sat Aug 4 20:11:25 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 4 Aug 2007 20:11:25 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: <46B3D814.4010001@gmx.net> References: <46B3D814.4010001@gmx.net> Message-ID: <20070804181125.GA16755@coresystems.de> * Carl-Daniel Hailfinger [070804 03:36]: > Summary: id1=0xea, id2=0xf0 for every flash size up to and including > 1024 kb. Since this happens regardless of the identification routine > used, I assume it is not an ID at all, but some value stored every 128 > kb on the flash chip. What is the actual flash chip vendor/device of that system? On some chips the jedec ID command returns flash sector protection information instead of the ID. It might also be that the ID mode is never left again, which makes it always return the same values. 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 eyal at cohenim.net Sun Aug 5 02:35:03 2007 From: eyal at cohenim.net (Eyal Cohen) Date: Sun, 05 Aug 2007 03:35:03 +0300 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <46B43B65.4070903@gmail.com> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> Message-ID: <1186274103.4805.1.camel@mainmachine> Using the original BIOS and the same kernel with "console=ttyS0,115200" works. On Sat, 2007-08-04 at 04:40 -0400, Corey Osgood wrote: > Eyal Cohen wrote: > > FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 > > Press for default boot, or for boot prompt... timed out > > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > > hda: LBA 40GB: ST340810A > > Mounted ext2fs > > Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 ID > > T 2007 bzImage. > > Loading kernel... ok > > Jumping to entry point... > > > > It looks like your kernel may not be compiled with serial console > support. The best check I know of is to boot the system up with the > stock bios, then interrupt grub, edit the kernel options to include > "console=tty0 console=ttyS0,115200", and then see what happens on your > serial terminal. If that can't be easily done, check your kernel config > file, and make sure serial support is compiled in (no modules, unless > you want to load an initrd), along with serial console, etc, etc. > > Also, make sure you allow the kernel some time to load, it does take a > bit. If you're interested in speeding it up, look for Peter Stuge's FILO > IDE Speedup patch in the archives, which is for filo-0.5 (which can be > grabbed with svn co svn://openbios.org/filo/trunk/filo-0.5) > > hope this helps > -Corey From eyal at cohenim.net Sun Aug 5 02:37:34 2007 From: eyal at cohenim.net (Eyal Cohen) Date: Sun, 05 Aug 2007 03:37:34 +0300 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <13426df10708041033nebd22ddv48f482eb245f91ec@mail.gmail.com> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> <13426df10708041033nebd22ddv48f482eb245f91ec@mail.gmail.com> Message-ID: <1186274254.4805.5.camel@mainmachine> Doesn't help. Output: --------------------- FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 Press for default boot, or for boot prompt... boot: hda1:/vmlinuz console=ttyS0,115200 earlyprint=ttyS0,115200,keep irqpoll hda: LBA 40GB: ST340810A Mounted ext2fs Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 I. Loading kernel... ok Jumping to entry point... --------------------- Same goes without the irqpoll On Sat, 2007-08-04 at 10:33 -0700, ron minnich wrote: > two other things. First, you can interrupt file with ESC and pass in > those console args by hand. Second, earlyprintk is a lifesaver. > > earlyprint=ttyS0,115200,keep > > VERY handy. > > ron From eyal at cohenim.net Sun Aug 5 03:48:21 2007 From: eyal at cohenim.net (Eyal Cohen) Date: Sun, 05 Aug 2007 04:48:21 +0300 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <1186274103.4805.1.camel@mainmachine> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> <1186274103.4805.1.camel@mainmachine> Message-ID: <1186278501.4805.7.camel@mainmachine> I have resolved the issue by using FILO 0.5 instead of 0.4.2. Thank you all. On Sun, 2007-08-05 at 03:35 +0300, Eyal Cohen wrote: > Using the original BIOS and the same kernel with "console=ttyS0,115200" > works. > > > On Sat, 2007-08-04 at 04:40 -0400, Corey Osgood wrote: > > Eyal Cohen wrote: > > > FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 > > > Press for default boot, or for boot prompt... timed out > > > boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 > > > hda: LBA 40GB: ST340810A > > > Mounted ext2fs > > > Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 ID > > > T 2007 bzImage. > > > Loading kernel... ok > > > Jumping to entry point... > > > > > > > It looks like your kernel may not be compiled with serial console > > support. The best check I know of is to boot the system up with the > > stock bios, then interrupt grub, edit the kernel options to include > > "console=tty0 console=ttyS0,115200", and then see what happens on your > > serial terminal. If that can't be easily done, check your kernel config > > file, and make sure serial support is compiled in (no modules, unless > > you want to load an initrd), along with serial console, etc, etc. > > > > Also, make sure you allow the kernel some time to load, it does take a > > bit. If you're interested in speeding it up, look for Peter Stuge's FILO > > IDE Speedup patch in the archives, which is for filo-0.5 (which can be > > grabbed with svn co svn://openbios.org/filo/trunk/filo-0.5) > > > > hope this helps > > -Corey > > From rminnich at gmail.com Sun Aug 5 03:34:16 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 4 Aug 2007 18:34:16 -0700 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <1186274254.4805.5.camel@mainmachine> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> <13426df10708041033nebd22ddv48f482eb245f91ec@mail.gmail.com> <1186274254.4805.5.camel@mainmachine> Message-ID: <13426df10708041834i2caeac30l706e81152388289f@mail.gmail.com> On 8/4/07, Eyal Cohen wrote: > Doesn't help. > Output: > > --------------------- > FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 > Press for default boot, or for boot prompt... > boot: hda1:/vmlinuz console=ttyS0,115200 earlyprint=ttyS0,115200,keep that's supposed to be earlyprintk not earlyprint does that help? ron From corey.osgood at gmail.com Sun Aug 5 05:25:33 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 04 Aug 2007 23:25:33 -0400 Subject: [LinuxBIOS] Kernel does nothing In-Reply-To: <1186278501.4805.7.camel@mainmachine> References: <1186209899.23157.12.camel@mainmachine> <46B43B65.4070903@gmail.com> <1186274103.4805.1.camel@mainmachine> <1186278501.4805.7.camel@mainmachine> Message-ID: <46B5432D.1040600@gmail.com> Eyal Cohen wrote: > I have resolved the issue by using FILO 0.5 instead of 0.4.2. > Thank you all. > Good to hear! Thought that might help, but I wasn't sure. And sorry about my previous email, after reading about Jurgen's patch my mind wandered, and I went straight to the log. -Corey > On Sun, 2007-08-05 at 03:35 +0300, Eyal Cohen wrote: > >> Using the original BIOS and the same kernel with "console=ttyS0,115200" >> works. >> >> >> On Sat, 2007-08-04 at 04:40 -0400, Corey Osgood wrote: >> >>> Eyal Cohen wrote: >>> >>>> FILO version 0.4.2 (eyal at mainmachine) Sun Jul 1 06:26:04 IDT 2007 >>>> Press for default boot, or for boot prompt... timed out >>>> boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 >>>> hda: LBA 40GB: ST340810A >>>> Mounted ext2fs >>>> Found Linux version 2.6.21.5 (eyal at mainmachine) #5 PREEMPT Thu Jul 5 11:50:44 ID >>>> T 2007 bzImage. >>>> Loading kernel... ok >>>> Jumping to entry point... >>>> >>>> >>> It looks like your kernel may not be compiled with serial console >>> support. The best check I know of is to boot the system up with the >>> stock bios, then interrupt grub, edit the kernel options to include >>> "console=tty0 console=ttyS0,115200", and then see what happens on your >>> serial terminal. If that can't be easily done, check your kernel config >>> file, and make sure serial support is compiled in (no modules, unless >>> you want to load an initrd), along with serial console, etc, etc. >>> >>> Also, make sure you allow the kernel some time to load, it does take a >>> bit. If you're interested in speeding it up, look for Peter Stuge's FILO >>> IDE Speedup patch in the archives, which is for filo-0.5 (which can be >>> grabbed with svn co svn://openbios.org/filo/trunk/filo-0.5) >>> >>> hope this helps >>> -Corey >>> >> > > > From darmawan.salihun at gmail.com Sun Aug 5 08:50:02 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Sun, 05 Aug 2007 13:50:02 +0700 Subject: [LinuxBIOS] GSoC status report: lbmenu In-Reply-To: <20070802173401.GE23143@greenwood> References: <20070802173401.GE23143@greenwood> Message-ID: <46B5731A.1080708@gmail.com> Uwe Hermann wrote: > Hi all, > > here's my (first) status report for the lbmenu project I'm working on as > part of the Google Summer of Code. I should have done this a lot > earlier, sorry for the delay. > > > What is lbmenu? > --------------- > > lbmenu is a simple payload which provides a LinuxBIOS config menu, > which allows you to change some config options at "runtime", i.e. > after LinuxBIOS did the hardware init, but before any bootloader or > OS is started. > > > Planned features, design goals (mostly copied from my GSoC proposal) > -------------------------------------------------------------------- > > - Text-mode (Kconfig-like) console UI for changing LinuxBIOS settings. > > - Bootsplash screen (text mode only for now) where the user can press a > certain (configurable) key to enter the configuration tool. > > - The tool should also be accessible over serial console (for headless > clients, servers or debugging scenarios), as well as (if feasible) over > telnet or ssh (given a big enough ROM chip and Linux + busybox in ROM). > > - The tool should work both in ROM (as part of LinuxBIOS), and as a > standalone application on a Linux system. The GUI should be the same > (or similar) in both cases. The standalone version might enable some > options which cannot be used in the embedded version because of > size constraints. > > To investigate: Implement the standalone tool as a frontend of lxbios? > Or include the lxbios code in the standalone tool? > > - The tool needs to fit into flash ROM (together with LinuxBIOS and at > least one LinuxBIOS payload), so size is important. Typical sizes of > flash ROM chips today range from 256 KB to 2 MB. > > - It should be reasonably easy to extend the tool. For example, it should > be possible to (later) add a graphical user-interface on top of the > generic, UI-independent code of this tool. > > A graphical user-interface is _not_ part of this GSoC project, though! > > - "BIOS password" feature for setting a LinuxBIOS password. > Without the correct password, no payload should be executed/booted. > > > Random possible ideas for after GSoC > ------------------------------------ > > - Internationalization support (using gettext or something similar). > The strings in the UI should be fully translatable into other languages. > Changing the language at run-time would require the strings of all > supported languages to be placed into ROM (size constraints), so this > will probably be a compile-time option only. > > - Configurable UI-Themes (colors, layouts, key mappings, > text-based or (later) graphical splash screens etc.) > > - Payload selection mechanism to choose at runtime which > payload to boot (if multiple payloads are included in the ROM chip). > This would make it theoretically possible to choose between GRUB2, EFI, > Open Firmware and other payloads upon each system boot. > > It's not yet clear if this should be done in lbmenu, or as a > mechanism in LinuxBIOS itself, or maybe as part of lbgrub2. > > - LinuxBIOS Device Tree browser which shows the device tree > for this mainboard (maybe even allows changes?). > > > Implementation plan/notes > ------------------------- > > - Written in C code (minimal assembly code, if required). > > - The code will be documented using Doxygen-style code comments. > > - A manpage will explain the usage and parameters of the tool. > Optionally, there will be some help texts in the tool (configurable, as > that increases the size of the tool). > > - Ideally, the building of the tool will be integrated in the normal > LinuxBIOSv3 build process, with hooks for adapting some defaults or > settings of the tool at compile-time. > > - QEMU will be used for testing the implementation. > > - License: GPL, version 2 or later. > > > Status > ------ > > - I have written a minimalist ncurses-implementation called tinycurses, > which allows some basic primitives such as printing characters on > screen, moving the cursor, reading keys from keyboard, beeping etc. > > It (sort of) supports both, VGA text console, and serial; more work > is needed, though. > > This is designed as a general purpose payload library, which can also > be used by other payloads which need console text support, serial > output, keyboard services, beep() etc. > > - The alternative would be to use the stock ncurses, but there are > various problems: > > - Too big; tinycurses is stripped down to just provide the most > important functions and features (e.g. no wide character support). > > - Requires syscalls, term library, and generally an OS. I _do_ have > a first test version which is compiled/linked against newlib > (http://sourceware.org/newlib/), a small libc implementation which > has stubs for OS-less builds (which we need in LinuxBIOS + payloads). > > However, making this really fully work will require a lot more > work. Also, the smallest lbmenu payload size when using newlib > I've been able to get so far, is 130 KB or so (which is quite a lot). > > My plan is to be able to use lbmenu with 256K ROM chips, and you > need to put LinuxBIOS (30-70 KB) in there, as well as at least one > payload (say FILO, ~60-80 KB), and lbmenu. So size is very important. > > On the long term the lbmenu implementation should probably rely on > the tinycurses implementation for that reason (which is currently > smaller than 10 KB or so, and doesn't require newlib). > > - The final goal of all of this would be to use plain Kconfig _within_ > lbmenu (at runtime) to display lbmenu's options and let the user > change them. Thus ncurses or tinycurses needs to be complete enough > to be able to compile kconfig. > > If this is absolutely not feasible, well, I'll have to implement a > small menu system from scratch, but I hope that won't be necessary. > > - The compile-time options of lbmenu are configured via kconfig, just > like the options of LinuxBIOSv3 itself. > > - So far my draft implementation of lbmenu can be booted, prints a text > banner (VGA and/or serial), can react on a (configurable) keypress, > e.g. ESC, then enter a "menu" (which is a stub right now), and > reboot upon another ESC keypress. > > > TODO > ---- > > - Finish tinycurses and/or ncurses+newlib so they're usable with kconfig. > > - Figure out a mechanism to select between various payloads included in > the ROM (_if_ this will be done in lbmenu, discussions welcome). > > - Implement read/write of CMOS values. > > - The configuration menu within lbmenu will be "dynamically" generated > (or that's my plan at least) from Kconfig.lbmenu files in the > LinuxBIOSv3 tree. The same parser which is used in Kconfig should > parse all *.lbmenu files and construct the lbmenu main menu from that. > > So you can have southbridge/amd/cs5536/Kconfig.lbmenu which provides > lbmenu menu items which are CS5536-specific (e.g. enable/disable IDE). > Another mainboard/amd/norwich/Kconfig.lbmenu would provide mainboard- > specific menu items etc. etc. > > - Probably a few other things I cannot think of right now. > > > No code yet, sorry, but I'll try to put together a small demo soon which > I can post here. > > I intend to put tinycurses into the global util/ directory, as it's > independant of LinuxBIOS and generally usable for other payloads. > > Same for lbmenu, it should be in util/ and gets its tinycurses implementation > via svn:externals (as should all other payloads which use it)... > > > Any comments and suggestions welcome! > > > Uwe. > This is really interesting. I think I will have a use for it in the future. Even if it's only for experiments but it should speed up the task. --Darmawan Salihun From lemenkov at gmail.com Sun Aug 5 13:02:06 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 5 Aug 2007 15:02:06 +0400 Subject: [LinuxBIOS] flashrom statically linked on linux - is this intentional? Message-ID: Hello All! Subj. I have no clue why should I build it statically. Maybe some reasons does exists? -- With best regards! From stepan at coresystems.de Sun Aug 5 13:11:17 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 05 Aug 2007 13:11:17 +0200 Subject: [LinuxBIOS] flashrom statically linked on linux - is this intentional? In-Reply-To: References: Message-ID: <46B5B055.7060003@coresystems.de> Peter Lemenkov wrote: > Hello All! > Subj. > I have no clue why should I build it statically. Maybe some reasons > does exists? Just convenience. If you put it into a rescue system it should not have any dependencies. It's not a requirement -- 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 peter at stuge.se Sun Aug 5 13:17:08 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 5 Aug 2007 13:17:08 +0200 Subject: [LinuxBIOS] flashrom statically linked on linux - is this intentional? In-Reply-To: References: Message-ID: <20070805111708.31426.qmail@stuge.se> On Sun, Aug 05, 2007 at 03:02:06PM +0400, Peter Lemenkov wrote: > Hello All! > Subj. > I have no clue why should I build it statically. Maybe some reasons > does exists? The idea is that the flashrom binary may be copied from development system to target system and the two may not have compatible libc. That said, please make sure that the libc on the development system is compiled so that it actually works on the target. During the LinuxTag workshop we found out that libc in one SuSE system was compiled to use i686 instructions that are missing from the C3 CPU on the EPIA board so the binary didn't actually work anyway. The EPIA system had a recent enough libc so we got it to work by linking flashrom dynamically. We've discussed making that the default again. //Peter From lemenkov at gmail.com Sun Aug 5 13:27:04 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Sun, 5 Aug 2007 15:27:04 +0400 Subject: [LinuxBIOS] flashrom statically linked on linux - is this intentional? In-Reply-To: <46B5B055.7060003@coresystems.de> References: <46B5B055.7060003@coresystems.de> Message-ID: 2007/8/5, Stefan Reinauer : > Peter Lemenkov wrote: > > Hello All! > > Subj. > > I have no clue why should I build it statically. Maybe some reasons > > does exists? > > Just convenience. If you put it into a rescue system it should not have > any dependencies. > > It's not a requirement Thanks, understood. -- With best regards! From joe at smittys.pointclark.net Sun Aug 5 19:43:44 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 05 Aug 2007 13:43:44 -0400 Subject: [LinuxBIOS] GSoC status report: lbmenu In-Reply-To: <46B5731A.1080708@gmail.com> References: <20070802173401.GE23143@greenwood> <46B5731A.1080708@gmail.com> Message-ID: <20070805134344.9lz19nvqos88cogk@www.smittys.pointclark.net> Quoting Darmawan Salihun : > Uwe Hermann wrote: >> Hi all, >> >> here's my (first) status report for the lbmenu project I'm working on as >> part of the Google Summer of Code. I should have done this a lot >> earlier, sorry for the delay. >> >> >> What is lbmenu? >> --------------- >> >> lbmenu is a simple payload which provides a LinuxBIOS config menu, >> which allows you to change some config options at "runtime", i.e. >> after LinuxBIOS did the hardware init, but before any bootloader or >> OS is started. >> >> >> Planned features, design goals (mostly copied from my GSoC proposal) >> -------------------------------------------------------------------- >> >> - Text-mode (Kconfig-like) console UI for changing LinuxBIOS settings. >> >> - Bootsplash screen (text mode only for now) where the user can press a >> certain (configurable) key to enter the configuration tool. >> >> - The tool should also be accessible over serial console (for headless >> clients, servers or debugging scenarios), as well as (if feasible) over >> telnet or ssh (given a big enough ROM chip and Linux + busybox in ROM). >> >> - The tool should work both in ROM (as part of LinuxBIOS), and as a >> standalone application on a Linux system. The GUI should be the same >> (or similar) in both cases. The standalone version might enable some >> options which cannot be used in the embedded version because of >> size constraints. >> >> To investigate: Implement the standalone tool as a frontend of lxbios? >> Or include the lxbios code in the standalone tool? >> >> - The tool needs to fit into flash ROM (together with LinuxBIOS and at >> least one LinuxBIOS payload), so size is important. Typical sizes of >> flash ROM chips today range from 256 KB to 2 MB. >> >> - It should be reasonably easy to extend the tool. For example, it should >> be possible to (later) add a graphical user-interface on top of the >> generic, UI-independent code of this tool. >> >> A graphical user-interface is _not_ part of this GSoC project, though! >> >> - "BIOS password" feature for setting a LinuxBIOS password. >> Without the correct password, no payload should be executed/booted. >> >> >> Random possible ideas for after GSoC >> ------------------------------------ >> >> - Internationalization support (using gettext or something similar). >> The strings in the UI should be fully translatable into other languages. >> Changing the language at run-time would require the strings of all >> supported languages to be placed into ROM (size constraints), so this >> will probably be a compile-time option only. >> >> - Configurable UI-Themes (colors, layouts, key mappings, >> text-based or (later) graphical splash screens etc.) >> >> - Payload selection mechanism to choose at runtime which >> payload to boot (if multiple payloads are included in the ROM chip). >> This would make it theoretically possible to choose between GRUB2, EFI, >> Open Firmware and other payloads upon each system boot. >> >> It's not yet clear if this should be done in lbmenu, or as a >> mechanism in LinuxBIOS itself, or maybe as part of lbgrub2. >> >> - LinuxBIOS Device Tree browser which shows the device tree >> for this mainboard (maybe even allows changes?). >> >> >> Implementation plan/notes >> ------------------------- >> >> - Written in C code (minimal assembly code, if required). >> >> - The code will be documented using Doxygen-style code comments. >> >> - A manpage will explain the usage and parameters of the tool. >> Optionally, there will be some help texts in the tool (configurable, as >> that increases the size of the tool). >> >> - Ideally, the building of the tool will be integrated in the normal >> LinuxBIOSv3 build process, with hooks for adapting some defaults or >> settings of the tool at compile-time. >> >> - QEMU will be used for testing the implementation. >> >> - License: GPL, version 2 or later. >> >> >> Status >> ------ >> >> - I have written a minimalist ncurses-implementation called tinycurses, >> which allows some basic primitives such as printing characters on >> screen, moving the cursor, reading keys from keyboard, beeping etc. >> >> It (sort of) supports both, VGA text console, and serial; more work >> is needed, though. >> >> This is designed as a general purpose payload library, which can also >> be used by other payloads which need console text support, serial >> output, keyboard services, beep() etc. >> >> - The alternative would be to use the stock ncurses, but there are >> various problems: >> >> - Too big; tinycurses is stripped down to just provide the most >> important functions and features (e.g. no wide character support). >> >> - Requires syscalls, term library, and generally an OS. I _do_ have >> a first test version which is compiled/linked against newlib >> (http://sourceware.org/newlib/), a small libc implementation which >> has stubs for OS-less builds (which we need in LinuxBIOS + payloads). >> >> However, making this really fully work will require a lot more >> work. Also, the smallest lbmenu payload size when using newlib >> I've been able to get so far, is 130 KB or so (which is quite a lot). >> >> My plan is to be able to use lbmenu with 256K ROM chips, and you >> need to put LinuxBIOS (30-70 KB) in there, as well as at least one >> payload (say FILO, ~60-80 KB), and lbmenu. So size is very important. >> >> On the long term the lbmenu implementation should probably rely on >> the tinycurses implementation for that reason (which is currently >> smaller than 10 KB or so, and doesn't require newlib). >> >> - The final goal of all of this would be to use plain Kconfig _within_ >> lbmenu (at runtime) to display lbmenu's options and let the user >> change them. Thus ncurses or tinycurses needs to be complete enough >> to be able to compile kconfig. >> >> If this is absolutely not feasible, well, I'll have to implement a >> small menu system from scratch, but I hope that won't be necessary. >> >> - The compile-time options of lbmenu are configured via kconfig, just >> like the options of LinuxBIOSv3 itself. >> >> - So far my draft implementation of lbmenu can be booted, prints a text >> banner (VGA and/or serial), can react on a (configurable) keypress, >> e.g. ESC, then enter a "menu" (which is a stub right now), and >> reboot upon another ESC keypress. >> >> >> TODO >> ---- >> >> - Finish tinycurses and/or ncurses+newlib so they're usable with kconfig. >> >> - Figure out a mechanism to select between various payloads included in >> the ROM (_if_ this will be done in lbmenu, discussions welcome). >> >> - Implement read/write of CMOS values. >> >> - The configuration menu within lbmenu will be "dynamically" generated >> (or that's my plan at least) from Kconfig.lbmenu files in the >> LinuxBIOSv3 tree. The same parser which is used in Kconfig should >> parse all *.lbmenu files and construct the lbmenu main menu from that. >> >> So you can have southbridge/amd/cs5536/Kconfig.lbmenu which provides >> lbmenu menu items which are CS5536-specific (e.g. enable/disable IDE). >> Another mainboard/amd/norwich/Kconfig.lbmenu would provide mainboard- >> specific menu items etc. etc. >> >> - Probably a few other things I cannot think of right now. >> >> >> No code yet, sorry, but I'll try to put together a small demo soon which >> I can post here. >> >> I intend to put tinycurses into the global util/ directory, as it's >> independant of LinuxBIOS and generally usable for other payloads. >> >> Same for lbmenu, it should be in util/ and gets its tinycurses >> implementation >> via svn:externals (as should all other payloads which use it)... >> >> >> Any comments and suggestions welcome! >> >> >> Uwe. >> > > This is really interesting. I think I will have a use for it in the > future. Even if it's only for experiments but it should speed up the task. > > --Darmawan Salihun > Yes, I am very intrigued by this also :-) Thanks - Joe From rasasi78 at gmail.com Sun Aug 5 21:45:44 2007 From: rasasi78 at gmail.com (=?UTF-8?B?UmHDumwgU8OhbmNoZXogU2lsZXM=?=) Date: Sun, 05 Aug 2007 21:45:44 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> Message-ID: Stefan Reinauer wrote: > * Carl-Daniel Hailfinger [070804 > 03:36]: >> Summary: id1=0xea, id2=0xf0 for every flash size up to and including >> 1024 kb. Since this happens regardless of the identification routine >> used, I assume it is not an ID at all, but some value stored every 128 >> kb on the flash chip. > > What is the actual flash chip vendor/device of that system? > I'm sorry but I've been unable to get that info from the Dell flash utility. When loaded it's no chance to get any info like that. The only option I'm given is to reflash the BIOS again. I would be glad to test any other tool/method you propose to get the info. Thanks. From tsylla at gmail.com Sun Aug 5 21:59:51 2007 From: tsylla at gmail.com (Tom Sylla) Date: Sun, 05 Aug 2007 15:59:51 -0400 Subject: [LinuxBIOS] [PATCH] [ADLO] Booting Windows XP and Windows 2000 In-Reply-To: References: <46A55DED.6080101@gmx.net> Message-ID: <46B62C37.8070201@gmail.com> Has anyone actually installed and/or booted WinXP on real hardware with these changes? Augusto Pedroza wrote: > My fault, I forgot to attach it, Sorry guys!! > Signed-off-by: Augusto Pedroza > > Index: util/ADLO/loader.s > =================================================================== > --- util/ADLO/loader.s (revision 2739) > +++ util/ADLO/loader.s (working copy) > @@ -177,10 +177,10 @@ > ; 0x02 - hdd > ; In future there will be 'fd failover'option in bochs. > > -mov al, #0x3d ;; cmos_reg > -out 0x70, al > -mov al, #0x02 ;; val (hdd) > -out 0x71, al > +;mov al, #0x3d ;; cmos_reg > +;out 0x70, al > +;mov al, #0x02 ;; val (hdd) > +;out 0x71, al > > ;----------------------------------------------------- > ; IV) tell BOCHS' BIOS length of our mem block @ 1mb. > Index: util/ADLO/bochs/bios/rombios.c > =================================================================== > --- util/ADLO/bochs/bios/rombios.c (revision 2739) > +++ util/ADLO/bochs/bios/rombios.c (working copy) > @@ -147,7 +147,7 @@ > #define LINUXBIOS 1 > > #define BX_USE_ATADRV 1 > -//#define BX_ELTORITO_BOOT 1 > +#define BX_ELTORITO_BOOT 1 > > #define BX_MAX_ATA_INTERFACES 4 > #define BX_MAX_ATA_DEVICES (BX_MAX_ATA_INTERFACES*2) > From c-d.hailfinger.devel.2006 at gmx.net Sun Aug 5 23:51:46 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 05 Aug 2007 23:51:46 +0200 Subject: [LinuxBIOS] [PATCH] [ADLO] Booting Windows XP and Windows 2000 In-Reply-To: <46B62C37.8070201@gmail.com> References: <46A55DED.6080101@gmx.net> <46B62C37.8070201@gmail.com> Message-ID: <46B64672.7030602@gmx.net> On 05.08.2007 21:59, Tom Sylla wrote: > Has anyone actually installed and/or booted WinXP on real hardware with > these changes? I believe not. Augusto uses LinuxBIOS v3 instead of v2 and I have no idea if any of the v3 supported real hardware can run Windows XP. AFAIK the Geode LX needs a non-redistributable VSA binary for VGA support and Windows needs VGA. Regards, Carl-Daniel From peter at stuge.se Mon Aug 6 01:16:08 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Aug 2007 01:16:08 +0200 Subject: [LinuxBIOS] [PATCH] [ADLO] Booting Windows XP and Windows 2000 In-Reply-To: <46B64672.7030602@gmx.net> References: <46A55DED.6080101@gmx.net> <46B62C37.8070201@gmail.com> <46B64672.7030602@gmx.net> <20070724015830.15804.qmail@stuge.se> Message-ID: <20070805231608.20453.qmail@stuge.se> On Mon, Jul 23, 2007 at 11:04:01PM -0300, Augusto Pedroza wrote: > These changes are only necessary to install windows, after > installed they are no longer needed. On Sun, Aug 05, 2007 at 11:51:46PM +0200, Carl-Daniel Hailfinger wrote: > On 05.08.2007 21:59, Tom Sylla wrote: > > Has anyone actually installed and/or booted WinXP on real > > hardware with these changes? > > I believe not. Augusto uses LinuxBIOS v3 instead of v2 But since ADLO is doing the heavy lifting, and there were no substantial changes made to ADLO I think v2 should work too. Please try it out if you can. //Peter From augusto.pedroza at gmail.com Mon Aug 6 04:15:30 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Sun, 5 Aug 2007 23:15:30 -0300 Subject: [LinuxBIOS] [PATCH] [ADLO] Booting Windows XP and Windows 2000 In-Reply-To: <20070805231608.20453.qmail@stuge.se> References: <46A55DED.6080101@gmx.net> <46B62C37.8070201@gmail.com> <20070724015830.15804.qmail@stuge.se> <46B64672.7030602@gmx.net> <20070805231608.20453.qmail@stuge.se> Message-ID: > > Has anyone actually installed and/or booted WinXP on real > > > hardware with these changes? Unfortunately I have not tried that on real hardware since I don't have one available. If you guys have some free time to try that please do it and give me some feedback. I intend to acquire a compatible mother board soon. > > > I believe not. Augusto uses LinuxBIOS v3 instead of v2 I used LinuxBIOSv2 is most of my debugging and development, I have switched to v3 maybe a month ago. So I guess it works fine with both. We have been working hard on Vista now. Thanks, -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From Libo.Feng at amd.com Mon Aug 6 06:27:06 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Mon, 6 Aug 2007 12:27:06 +0800 Subject: [LinuxBIOS] No keyboard. In-Reply-To: <2ea3fae10708031040y77b5fe13g8b5d48af3025e2eb@mail.gmail.com> References: <20070802204245.1951.qmail@stuge.se> <2ea3fae10708031040y77b5fe13g8b5d48af3025e2eb@mail.gmail.com> Message-ID: Hi, Mr. Lu, You are quit right. I commented out two statements in Config.lb as you suggest, the keyboard can work now. The attached is the modified file, a BTDC tag indicates where I modified. Thank you a lot. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Saturday, August 04, 2007 1:40 AM To: Feng, Libo Cc: Peter Stuge; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] No keyboard. please check if bcm5785 bcm5780 is in the first ht link in your MB Config.lb. Or send out your MB Config.lb. YH -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 12626 bytes Desc: Config.lb URL: From linuxbios at bloms.de Mon Aug 6 08:58:21 2007 From: linuxbios at bloms.de (Dieter Bloms) Date: Mon, 6 Aug 2007 08:58:21 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: <20070806050739.GA4551@bloms.de> References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <20070806050739.GA4551@bloms.de> Message-ID: <20070806065821.GA5040@bloms.de> Hi, On Sun, Aug 05, Ra?l S?nchez Siles wrote: > I'm sorry but I've been unable to get that info from the Dell flash > utility. When loaded it's no chance to get any info like that. The only > option I'm given is to reflash the BIOS again. > > I would be glad to test any other tool/method you propose to get the info. I use uniflash from: http://www.uniflash.org/ it tells you that info. -- Gru? Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From frederic at placenet.org Mon Aug 6 09:53:34 2007 From: frederic at placenet.org (frederic at placenet.org) Date: Mon, 6 Aug 2007 09:53:34 +0200 (CEST) Subject: [LinuxBIOS] PC protection Message-ID: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> is it possible to put in linuxbios an option that protect your pc to be stolen. for example: ping one time an wan ip adress when ethernet interface if up ? is this idea is possible ? bst regards. Frederic From ceri.coburn at googlemail.com Mon Aug 6 12:32:52 2007 From: ceri.coburn at googlemail.com (Ceri Coburn) Date: Mon, 06 Aug 2007 11:32:52 +0100 Subject: [LinuxBIOS] PC protection In-Reply-To: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> References: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> Message-ID: <46B6F8D4.7050702@googlemail.com> frederic at placenet.org wrote: > is it possible to put in linuxbios an option that protect your pc to be > stolen. for example: > > ping one time an wan ip adress when ethernet interface if up ? > > is this idea is possible ? It's possible to write code to do most things, but what would stop the thief loading a normal proprietary BIOS? What exactly would you want to do. > > bst regards. > Frederic > > From frederic at placenet.org Mon Aug 6 13:48:40 2007 From: frederic at placenet.org (frederic at placenet.org) Date: Mon, 6 Aug 2007 13:48:40 +0200 (CEST) Subject: [LinuxBIOS] PC protection In-Reply-To: <46B6F8D4.7050702@googlemail.com> References: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> <46B6F8D4.7050702@googlemail.com> Message-ID: <34011.217.119.180.154.1186400920.squirrel@www.placenet.org> > frederic at placenet.org wrote: >> is it possible to put in linuxbios an option that protect your pc to be >> stolen. for example: >> >> ping one time an wan ip adress when ethernet interface if up ? >> >> is this idea is possible ? > > It's possible to write code to do most things, but what would stop the > thief loading a normal proprietary BIOS? What exactly would you want to > do. > when pc start and bios is launch, i would that bios if special option is active to get an ip with gateway (if some dhcp runing) and try an ping to an given ip or wget and special ip address. if something stay resident when pc OS is running to try only one time a smooth ping or wget. like this if the computer is stolen by someone and this computer will be use somewhere with internet (today is high probality), we can trace the computer and retreive it... if this possible to include that kind of script (up network interface, dhcp,ping and boot) when linuxbios is used and installed on a motherboard (in my case is Intel D946GZIS). I am interesting to do that. bst regards. Frederic > >> >> bst regards. >> Frederic >> >> > > From ceri.coburn at googlemail.com Mon Aug 6 14:40:51 2007 From: ceri.coburn at googlemail.com (Ceri Coburn) Date: Mon, 06 Aug 2007 13:40:51 +0100 Subject: [LinuxBIOS] PC protection In-Reply-To: <34011.217.119.180.154.1186400920.squirrel@www.placenet.org> References: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> <46B6F8D4.7050702@googlemail.com> <34011.217.119.180.154.1186400920.squirrel@www.placenet.org> Message-ID: <46B716D3.8020103@googlemail.com> frederic at placenet.org wrote: >> frederic at placenet.org wrote: >>> is it possible to put in linuxbios an option that protect your pc to be >>> stolen. for example: >>> >>> ping one time an wan ip adress when ethernet interface if up ? >>> >>> is this idea is possible ? >> It's possible to write code to do most things, but what would stop the >> thief loading a normal proprietary BIOS? What exactly would you want to >> do. >> > > when pc start and bios is launch, i would that bios if special option is > active to get an ip with gateway (if some dhcp runing) and try an ping to > an given ip or wget and special ip address. > > if something stay resident when pc OS is running to try only one time a > smooth ping or wget. > > > like this if the computer is stolen by someone and this computer will be > use somewhere with internet (today is high probality), we can trace the > computer and retreive it... So I take it the machine would do this ping of some kind every time the machine boots, regardless of it being stolen or not. Etherboot already has the functionality to retrieve an IP via DHCP etc... If you were interested in adding the functionality you are talking about, I personally would start there. C > > > if this possible to include that kind of script (up network interface, > dhcp,ping and boot) when linuxbios is used and installed on a motherboard > (in my case is Intel D946GZIS). I am interesting to do that. > > bst regards. > Frederic > >>> bst regards. >>> Frederic >>> >>> >> > > > From peter at stuge.se Mon Aug 6 15:57:49 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Aug 2007 15:57:49 +0200 Subject: [LinuxBIOS] PC protection In-Reply-To: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> References: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> Message-ID: <20070806135749.13416.qmail@stuge.se> On Mon, Aug 06, 2007 at 09:53:34AM +0200, frederic at placenet.org wrote: > is it possible to put in linuxbios an option that protect your pc > to be stolen. for example: It's open source so anything is possible, as others have said. Ceri's advice about looking at Etherboot is a good idea. However, so far this discussion is only of academic interest, since no laptops are supported by LB yet. Once laptops are supported we can have lots of fun. :) //Peter From luis.f.correia at gmail.com Mon Aug 6 17:17:13 2007 From: luis.f.correia at gmail.com (Luis Correia) Date: Mon, 6 Aug 2007 16:17:13 +0100 Subject: [LinuxBIOS] Alix boards Message-ID: Hi, is there anyone working on LinuxBIOS for this board? http://pcengines.ch/alix1b.htm Thanks, Luis Correia From peter at stuge.se Mon Aug 6 17:39:55 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Aug 2007 17:39:55 +0200 Subject: [LinuxBIOS] Alix boards In-Reply-To: References: Message-ID: <20070806153955.29648.qmail@stuge.se> On Mon, Aug 06, 2007 at 04:17:13PM +0100, Luis Correia wrote: > is there anyone working on LinuxBIOS for this board? > http://pcengines.ch/alix1b.htm Not that I know of. For anyone interested, amd/norwich or artecgroup/dbe61 would be a good starting point. The boards have a handy LPC header with an ISP signal that can be used to disable the onboard flash chip so an external LPC flash chip or emulator can be used instead. An adapter with just some wires is needed to boot from Artec's LPC dongle. //Peter From jordan.crouse at amd.com Mon Aug 6 17:31:54 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 6 Aug 2007 09:31:54 -0600 Subject: [LinuxBIOS] Alix boards In-Reply-To: References: Message-ID: <20070806153153.GA5638@cosmic.amd.com> On 06/08/07 16:17 +0100, Luis Correia wrote: > Hi, > > is there anyone working on LinuxBIOS for this board? > > http://pcengines.ch/alix1b.htm The CPU and southbridge are supported. I don't think anybody has been working on the mainboard, though. Looking at the chips on the board, it looks like it might be similar to the db800 mainboard, but there are probably some differences. If you can get the schematics, then it should be fairly simple to get LinuxBIOS working on this board (probably just a few changes to the mainboard code). Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From luis.f.correia at gmail.com Mon Aug 6 17:47:39 2007 From: luis.f.correia at gmail.com (Luis Correia) Date: Mon, 6 Aug 2007 16:47:39 +0100 Subject: [LinuxBIOS] Alix boards In-Reply-To: <20070806153153.GA5638@cosmic.amd.com> References: <20070806153153.GA5638@cosmic.amd.com> Message-ID: Hi! On 8/6/07, Jordan Crouse wrote: > On 06/08/07 16:17 +0100, Luis Correia wrote: > > Hi, > > > > is there anyone working on LinuxBIOS for this board? > > > > http://pcengines.ch/alix1b.htm > > The CPU and southbridge are supported. I don't think anybody has been > working on the mainboard, though. Looking at the chips on the board, > it looks like it might be similar to the db800 mainboard, but there > are probably some differences. > > If you can get the schematics, then it should be fairly simple to get > LinuxBIOS working on this board (probably just a few changes to the > mainboard code). Yes, I've got some information about the board, but not the board itself. The PCEngines engineer told me that 'someone on the US is already working on LinuxBIOS for it'. Therefore I asked :) > > Jordan > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. Answering also to Peter Stuge, yes, LPC flash add-on is possible and will be the best way to test and develop LinuxBIOS for this particular board :) Luis Correia From popkonserve at gmx.de Mon Aug 6 17:52:24 2007 From: popkonserve at gmx.de (popkonserve) Date: Mon, 06 Aug 2007 17:52:24 +0200 Subject: [LinuxBIOS] PC protection In-Reply-To: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> References: <39844.217.119.180.154.1186386814.squirrel@www.placenet.org> Message-ID: <46B743B8.1090804@gmx.de> what if no network card is installed? what if an installed network card is removed? what if another network card (with another chip) is installed? what if the pc isn't connected to any network? (okay, you ruled that out..) what if you have the ip? how do you get the person/place that ip belongs to? ask the isp? do you think that they would give away their customers' name/address? what if the network doesn't belong to the thief(university, internet cafe, hacked/open wlan)? what if the device was already sold to someone else? even if they would be forced by law to give out the address..what would you do then? go there by yourself and kindly ask them to give the hardware back? ask for a house search (that the police would have to do)? i doubt that some network card pinging something is a proof for anything. there are special programs and firms that include data destroying software into the os and bios. if a stolen device is connected to the internet (and the software is still installed and the ports it uses are not blocked (that's what those firms don't like to talk about)) it connects to a server. now the destruction routine could jump in..an ip detection routine, too. but still they won't have a name or a place. technically however it is possible as long as the nic remains in place and there is a connection to what's called the internet. Holger From peter at stuge.se Mon Aug 6 18:32:29 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Aug 2007 18:32:29 +0200 Subject: [LinuxBIOS] Alix boards In-Reply-To: References: <20070806153153.GA5638@cosmic.amd.com> Message-ID: <20070806163229.5868.qmail@stuge.se> On Mon, Aug 06, 2007 at 04:47:39PM +0100, Luis Correia wrote: > > The CPU and southbridge are supported. I don't think anybody has > > been working on the mainboard, though. Looking at the chips on > > the board, it looks like it might be similar to the db800 > > mainboard, but there are probably some differences. > > > > If you can get the schematics, then it should be fairly simple to > > get LinuxBIOS working on this board (probably just a few changes > > to the mainboard code). > > Yes, I've got some information about the board, but not the board > itself. Is it possible to order them? > The PCEngines engineer AFAIK it's a one man show. Pascal subcontracts manufacturing of course, but I think it's just him in the company. > told me that 'someone on the US is already working on LinuxBIOS for > it'. LB is a good fit. PC Engines also offers tinyBIOS, a somewhat commercial/somewhat open source BIOS for embedded systems, much like Soekris offers comBIOS. I spoke with S?ren (the founder) at LinuxForum in Copenhagen in March and I did not get the impression that he was particularly interested in selling boards with LB. I guess there's a market for comBIOS. > Answering also to Peter Stuge, yes, LPC flash add-on is possible > and will be the best way to test and develop LinuxBIOS for this > particular board :) Aye. //Peter From peter at stuge.se Mon Aug 6 21:51:57 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 6 Aug 2007 21:51:57 +0200 Subject: [LinuxBIOS] uvesafb, framebuffer by emulation Message-ID: <20070806195157.6351.qmail@stuge.se> http://dev.gentoo.org/~spock/projects/uvesafb/ From corey.osgood at gmail.com Mon Aug 6 22:09:17 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 06 Aug 2007 16:09:17 -0400 Subject: [LinuxBIOS] uvesafb, framebuffer by emulation In-Reply-To: <20070806195157.6351.qmail@stuge.se> References: <20070806195157.6351.qmail@stuge.se> Message-ID: <46B77FED.40806@gmail.com> Peter Stuge wrote: > http://dev.gentoo.org/~spock/projects/uvesafb/ > > Checking it out, thanks! -Corey From jordan.crouse at amd.com Mon Aug 6 22:16:50 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 6 Aug 2007 14:16:50 -0600 Subject: [LinuxBIOS] uvesafb, framebuffer by emulation In-Reply-To: <20070806195157.6351.qmail@stuge.se> References: <20070806195157.6351.qmail@stuge.se> Message-ID: <20070806201650.GF5638@cosmic.amd.com> On 06/08/07 21:51 +0200, Peter Stuge wrote: > http://dev.gentoo.org/~spock/projects/uvesafb/ That looks like its a healthy combination of clever and evil. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From nuklearzelph at gmail.com Tue Aug 7 00:33:58 2007 From: nuklearzelph at gmail.com (Nuklear Zelph) Date: Mon, 6 Aug 2007 16:33:58 -0600 Subject: [LinuxBIOS] would sending you hardware help any? Message-ID: i have a toshiba portege laptop that has no screen and i can't really use it, but it does work. i also have some other desktop mainboards that are pretty old if any of that may help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey.osgood at gmail.com Tue Aug 7 02:04:50 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 06 Aug 2007 20:04:50 -0400 Subject: [LinuxBIOS] would sending you hardware help any? In-Reply-To: References: Message-ID: <46B7B722.4080703@gmail.com> Nuklear Zelph wrote: > i have a toshiba portege laptop that has no screen and i can't really > use it, but it does work. i also have some other desktop mainboards > that are pretty old if any of that may help. Just curious, what model is the protege? And does it have an external vga connector? Thanks, Corey From rminnich at gmail.com Tue Aug 7 06:47:29 2007 From: rminnich at gmail.com (ron minnich) Date: Mon, 6 Aug 2007 21:47:29 -0700 Subject: [LinuxBIOS] [patch 2/5] New LAR access functions In-Reply-To: <20070725205532.4319.qmail@stuge.se> References: <20070723160602.511777000@cosmic.amd.com> <20070723161035.445067000@cosmic.amd.com> <20070725183803.16048.qmail@stuge.se> <20070725195611.GC23932@coresystems.de> <20070725205532.4319.qmail@stuge.se> Message-ID: <13426df10708062147v53e2dcd5tf1163e88055f5b3e@mail.gmail.com> Guys, this patch appears to be stuck in limbo. It is holding up the GX port. Did we resolve this or did it just sort of die? Can we get it worked out? We need to jumpstart things again. thanks ron On 7/25/07, Peter Stuge wrote: > On Wed, Jul 25, 2007 at 09:56:11PM +0200, Stefan Reinauer wrote: > > * Peter Stuge [070725 20:38]: > > > Please use mkdirp_below() and pass "." for the parent parameter. > > > > We should include the "." in the function if we never call it with > > any other directory. > > Sure. > > I made it a parameter because it is good for when lar gets a -C (ie. > extract into that directory over there) but we can change back > if/when that happens. > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > From jordan.crouse at amd.com Tue Aug 7 16:55:04 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 7 Aug 2007 08:55:04 -0600 Subject: [LinuxBIOS] acpitool Message-ID: <20070807145504.GI5638@cosmic.amd.com> Here is something that will probably be of interest to LinuxBIOS - this could make the effort of porting that much easier: http://kernelslacker.livejournal.com/88243.html Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From rminnich at gmail.com Tue Aug 7 19:49:10 2007 From: rminnich at gmail.com (ron minnich) Date: Tue, 7 Aug 2007 10:49:10 -0700 Subject: [LinuxBIOS] acpitool In-Reply-To: <20070807145504.GI5638@cosmic.amd.com> References: <20070807145504.GI5638@cosmic.amd.com> Message-ID: <13426df10708071049n63e08ec9sa0383424708136d0@mail.gmail.com> On 8/7/07, Jordan Crouse wrote: > Here is something that will probably be of interest to LinuxBIOS - this > could make the effort of porting that much easier: > > http://kernelslacker.livejournal.com/88243.html Wiki entry? ron From r.marek at assembler.cz Wed Aug 8 01:19:01 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Wed, 08 Aug 2007 01:19:01 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status Message-ID: <46B8FDE5.5040808@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I'm typing this message in Thunderbird from LinuxBIOS booted system. Yeah I told this last time, but I have still some issues left. 1) Single channel memory problems I have two 512MB dimms in singe channel, because LinuxBIOS does not handle dualchannel for unbuffered Dimms. However when I'm using 512-1024MB of the RAM systems forces to random reboot when booting kernel or when in X. Booting with mem=512MB works like a charm 2) Reboot does not work. I dont know what I have wrong, but my fallback image just produces the initial string when console is initialized and nothing more. I have no clue what is wrong. I dont know what failover and fallback is precisely... 3) DMA to 0xE0000-0xEFFFF fails This is under investigation. I asked VIA about this. 4) no HPET and no ACPI, no PCI MCONFIG yet 5) I have some issues with LB itself when preparing various init files. The resource system have some serious trouble if I add my file for the PCIe bridge init. If I call the function not from init or enable methods but from general init and via pci_find_device, everything will work again. This seems like some issue with the infrastructure of LB rather than HW problem. I may write more about my issues if only someone is willing to help ;) I can put my code online somewhere. Maybe it would be good to check it in even if the code for NB is a bit of mess. USB/sound/SATA/IDE/PCIe/Network/Serial/Graphics/APIC works do far... Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuP3l3J9wPJqZRNURAh9zAJoDQ1pIlVH5ZD0Lg4NdIlp6BlLnTgCfZnOO sj9O/OW5vn8+1PGl8gMLVYA= =i4Xk -----END PGP SIGNATURE----- From corey.osgood at gmail.com Wed Aug 8 03:26:33 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 07 Aug 2007 21:26:33 -0400 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46B8FDE5.5040808@assembler.cz> References: <46B8FDE5.5040808@assembler.cz> Message-ID: <46B91BC9.4040409@gmail.com> Rudolf Marek wrote: > I'm typing this message in Thunderbird from LinuxBIOS booted system. Yeah I told > this last time, but I have still some issues left. Great job! > 2) Reboot does not work. > I dont know what I have wrong, but my fallback image just produces the > initial string when console is initialized and nothing more. I have no > clue what > is wrong. I dont know what failover and fallback is precisely... > <...> > 5) > I have some issues with LB itself when preparing various init files. The > resource system have some serious trouble if I add my file for the > PCIe bridge > init. If I call the function not from init or enable methods but from > general > init and via pci_find_device, everything will work again. This seems > like some > issue with the infrastructure of LB rather than HW problem. > Both of these should be solved with ACPI tables, one of the Epia-M pages in the wiki has some good info on using iasl. Also make sure HAVE_HARD_RESET = 0 in mainboard Options.lb > I may write more about my issues if only someone is willing to help ;) > I can put > my code online somewhere. Maybe it would be good to check it in even > if the code > for NB is a bit of mess. That's your call, but I doubt it could hurt. First check that your code is at least fairly clean and follows the coding guidelines (check the wiki). You might also want to check with Via and make sure that's okay, I don't know what your status is regarding NDAs. If you don't have one at all, you should be fine. > USB/sound/SATA/IDE/PCIe/Network/Serial/Graphics/APIC works do far... USB works? Have you made any fixes or are you using the code I sent you as-is? And for graphics, are you using onboard or a seperate card? Thanks, Corey From corey.osgood at gmail.com Wed Aug 8 04:19:46 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 7 Aug 2007 22:19:46 -0400 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46B91BC9.4040409@gmail.com> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> Message-ID: On 8/7/07, Corey Osgood wrote: > > Rudolf Marek wrote: > > I'm typing this message in Thunderbird from LinuxBIOS booted system. > Yeah I told > > this last time, but I have still some issues left. > > Great job! > > > 2) Reboot does not work. > > I dont know what I have wrong, but my fallback image just produces > the > > initial string when console is initialized and nothing more. I have no > > clue what > > is wrong. I dont know what failover and fallback is precisely... > > > <...> > > 5) > > I have some issues with LB itself when preparing various init files. The > > resource system have some serious trouble if I add my file for the > > PCIe bridge > > init. If I call the function not from init or enable methods but from > > general > > init and via pci_find_device, everything will work again. This seems > > like some > > issue with the infrastructure of LB rather than HW problem. > > > > Both of these should be solved with ACPI tables, one of the Epia-M pages > in the wiki has some good info on using iasl. Also make sure > HAVE_HARD_RESET = 0 in mainboard Options.lb Whoops, that was supposed to be 2) and 4)... And on 2, it actually tries to reboot but stops after printing the inital banner? No attempt at ram init or anything? It might be that yhlu has set up the k8 to not re-do ram init after a reboot, but I'm not sure. -Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic at placenet.org Tue Aug 7 17:52:40 2007 From: frederic at placenet.org (frederic at placenet.org) Date: Tue, 7 Aug 2007 17:52:40 +0200 (CEST) Subject: [LinuxBIOS] Install bios in Asus A6T. Message-ID: <43595.217.119.180.154.1186501960.squirrel@www.placenet.org> i do not see anything in wiki. somebody has experience about: laptop Asus A6T. chipset : C51MV(C61)+MCP51 flashrom give: Calibrating delay loop... ok No LinuxBIOS table found. Enabling flash write on NVidia MCP51...OK Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) OK, only ENABLING flash write, but NOT FLASHING. lshw give: description: Notebook product: A6T vendor: ASUSTeK Computer INC. version: 1.0 serial: NB-XXXXXXXX width: 32 bits capabilities: smbios-2.4 dmi-2.4 configuration: boot=normal chassis=notebook uuid=00020003-0004-0005-0006-000700080009 *-core description: Motherboard product: A6T vendor: ASUSTeK Computer INC. physical id: 0 version: 1.00 serial: NB-0123456789 slot: To Be Filled By O.E.M. *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 080012 (08/09/2006) size: 64KB capacity: 448KB capabilities: isa pci pcmcia pnp apm upgrade shadowing escd cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb ls120boot zipboot biosbootspecification *-cpu:0 description: CPU product: AMD Turion(tm) 64 X2 Mobile Technology TL-52 vendor: Advanced Micro Devices [AMD] physical id: 1 bus info: cpu at 0 version: AMD Turion(tm) 64 X2 Mobile Technology TL-52 serial: To Be Filled By O.E.M. slot: CPU 1 size: 1600MHz capacity: 1600MHz width: 64 bits clock: 200MHz capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp x86-64 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy cpufreq *-cache:0 description: L1 cache physical id: 5 slot: L1-Cache size: 128KB capacity: 128KB capabilities: pipeline-burst internal varies data *-cache:1 description: L2 cache physical id: 6 slot: L2-Cache size: 1MB capacity: 1MB capabilities: pipeline-burst internal varies unified *-cache:2 DISABLED description: L3 cache physical id: 7 slot: L3-Cache capabilities: internal *-cpu:1 description: CPU product: (To Be Filled By O.E.M.) physical id: 8 bus info: cpu at 1 serial: To Be Filled By O.E.M. slot: CPU 2 size: 1600MHz capacity: 2GHz capabilities: cpufreq *-cache:0 DISABLED description: L1 cache physical id: 9 slot: L1-Cache capabilities: internal *-cache:1 DISABLED description: L2 cache physical id: a slot: L2-Cache capabilities: internal *-cache:2 DISABLED description: L3 cache physical id: b slot: L3-Cache capabilities: internal *-memory:0 description: System Memory physical id: 2d slot: System board or motherboard size: 2GB *-bank:0 description: DIMM Synchronous 333 MHz (3.0 ns) product: PartNum0 vendor: Manufacturer0 physical id: 0 serial: SerNum0 slot: DIMM0 size: 1GB width: 64 bits clock: 333MHz (3.0ns) *-bank:1 description: DIMM Synchronous 333 MHz (3.0 ns) product: PartNum1 vendor: Manufacturer1 physical id: 1 serial: SerNum1 slot: DIMM1 size: 1GB width: 64 bits clock: 333MHz (3.0ns) *-memory:1 UNCLAIMED description: RAM memory product: C51 Host Bridge vendor: nVidia Corporation physical id: 2 bus info: pci at 00:00.0 version: a2 width: 32 bits clock: 66MHz (15.2ns) capabilities: bus_master cap_list configuration: latency=0 *-memory:2 UNCLAIMED description: RAM memory product: C51 Memory Controller 0 vendor: nVidia Corporation physical id: 0.1 bus info: pci at 00:00.1 version: a2 width: 32 bits clock: 66MHz (15.2ns) configuration: latency=0 *-memory:3 UNCLAIMED description: RAM memory product: C51 Memory Controller 1 vendor: nVidia Corporation physical id: 0.2 bus info: pci at 00:00.2 version: a2 width: 32 bits clock: 66MHz (15.2ns) configuration: latency=0 *-memory:4 UNCLAIMED description: RAM memory product: C51 Memory Controller 5 vendor: nVidia Corporation physical id: 0.3 bus info: pci at 00:00.3 version: a2 width: 32 bits clock: 66MHz (15.2ns) configuration: latency=0 *-memory:5 UNCLAIMED description: RAM memory product: C51 Memory Controller 4 vendor: nVidia Corporation physical id: 0.4 bus info: pci at 00:00.4 version: a2 width: 32 bits clock: 66MHz (15.2ns) capabilities: bus_master configuration: latency=0 *-memory:6 UNCLAIMED description: RAM memory product: C51 Host Bridge vendor: nVidia Corporation physical id: 0.5 bus info: pci at 00:00.5 version: a2 width: 32 bits clock: 66MHz (15.2ns) capabilities: bus_master cap_list configuration: latency=0 *-memory:7 UNCLAIMED description: RAM memory product: C51 Memory Controller 3 vendor: nVidia Corporation physical id: 0.6 bus info: pci at 00:00.6 version: a2 width: 32 bits clock: 66MHz (15.2ns) configuration: latency=0 *-memory:8 UNCLAIMED description: RAM memory product: C51 Memory Controller 2 vendor: nVidia Corporation physical id: 0.7 bus info: pci at 00:00.7 version: a2 width: 32 bits clock: 66MHz (15.2ns) configuration: latency=0 *-pci:0 description: PCI bridge product: C51 PCI Express Bridge vendor: nVidia Corporation physical id: 3 bus info: pci at 00:03.0 version: a1 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport-driver *-network description: Ethernet interface product: RTL8111/8168B PCI Express Gigabit Ethernet controller vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci at 01:00.0 logical name: eth0 version: 01 serial: 00:18:f3:XX:XX:XX size: 1GB/s capacity: 1GB/s width: 64 bits clock: 33MHz capabilities: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.2LK duplex=full ip=XX.XX.1.199 latency=0 link=yes multicast=yes port=twisted pair speed=1GB/s resources: ioport:c800-c8ff iomemory:dcfff000-dcffffff irq:11 *-pci:1 description: PCI bridge product: C51 PCI Express Bridge vendor: nVidia Corporation physical id: 100 bus info: pci at 00:04.0 version: a1 width: 32 bits clock: 33MHz capabilities: pci normal_decode bus_master cap_list configuration: driver=pcieport-driver *-display description: VGA compatible controller product: G70 [GeForce Go 7600] vendor: nVidia Corporation physical id: 0 bus info: pci at 02:00.0 version: a1 size: 256MB width: 64 bits clock: 33MHz capabilities: vga bus_master cap_list configuration: driver=nvidia latency=0 resources: iomemory:de000000-deffffff iomemory:c0000000-cfffffff iomemory:dd000000-ddffffff ioport:dc00-dc7f irq:11 *-memory:9 UNCLAIMED description: RAM memory product: MCP51 Host Bridge vendor: nVidia Corporation physical id: 9 bus info: pci at 00:09.0 version: a2 width: 32 bits clock: 66MHz (15.2ns) capabilities: bus_master cap_list configuration: latency=0 *-isa description: ISA bridge product: MCP51 LPC Bridge vendor: nVidia Corporation physical id: a bus info: pci at 00:0a.0 version: a3 width: 32 bits clock: 66MHz capabilities: isa bus_master configuration: latency=0 *-serial description: SMBus product: MCP51 SMBus vendor: nVidia Corporation physical id: a.1 bus info: pci at 00:0a.1 version: a3 width: 32 bits clock: 66MHz capabilities: cap_list configuration: driver=nForce2_smbus latency=0 resources: ioport:600-63f ioport:700-73f irq:5 *-processor UNCLAIMED description: Co-processor product: MCP51 PMU vendor: nVidia Corporation physical id: a.3 bus info: pci at 00:0a.3 version: a3 width: 32 bits clock: 66MHz capabilities: bus_master configuration: latency=0 maxlatency=1 mingnt=3 resources: iomemory:dcec0000-dcefffff irq:10 *-usb:0 description: USB Controller product: MCP51 USB Controller vendor: nVidia Corporation physical id: b bus info: pci at 00:0b.0 version: a3 width: 32 bits clock: 66MHz capabilities: ohci bus_master cap_list configuration: driver=ohci_hcd latency=0 maxlatency=1 mingnt=3 resources: iomemory:dcebe000-dcebefff irq:11 *-usbhost product: OHCI Host Controller vendor: Linux 2.6.20-16-generic ohci_hcd physical id: 1 bus info: usb at 1 logical name: usb1 version: 2.06 capabilities: usb-1.10 configuration: driver=hub maxpower=0mA slots=8 speed=12.0MB/s *-usb:0 description: Mouse product: Optical USB Mouse vendor: Logitech physical id: 2 bus info: usb at 1:2 version: 3.40 capabilities: usb-2.00 configuration: driver=usbhid maxpower=100mA speed=1.5MB/s *-usb:1 description: Bluetooth wireless interface physical id: 7 bus info: usb at 1:7 version: 19.15 serial: 0194E8-5B-0002 capabilities: bluetooth usb-2.00 configuration: driver=hci_usb maxpower=0mA speed=12.0MB/s *-usb:1 description: USB Controller product: MCP51 USB Controller vendor: nVidia Corporation physical id: b.1 bus info: pci at 00:0b.1 version: a3 width: 32 bits clock: 66MHz capabilities: ehci bus_master cap_list configuration: driver=ehci_hcd latency=0 maxlatency=1 mingnt=3 resources: iomemory:dcebfc00-dcebfcff irq:7 *-usbhost product: EHCI Host Controller vendor: Linux 2.6.20-16-generic ehci_hcd physical id: 1 bus info: usb at 2 logical name: usb2 version: 2.06 capabilities: usb-2.00 configuration: driver=hub maxpower=0mA slots=8 speed=480.0MB/s *-usb UNCLAIMED description: Generic USB device product: USB2.0 vendor: Syntek physical id: 5 bus info: usb at 2:5 version: 0.05 capabilities: usb-2.00 configuration: maxpower=500mA speed=480.0MB/s *-ide description: IDE interface product: MCP51 IDE vendor: nVidia Corporation physical id: d bus info: pci at 00:0d.0 version: a1 width: 32 bits clock: 66MHz capabilities: ide bus_master cap_list configuration: driver=AMD_IDE latency=0 maxlatency=1 mingnt=3 resources: iomemory:1f0-1f7 iomemory:3f0-3ef iomemory:170-177 iomemory:370-36f ioport:ffa0-ffaf *-ide:0 description: IDE Channel 0 physical id: 0 bus info: ide at 0 logical name: ide0 clock: 66MHz *-cdrom description: DVD-RAM writer product: HL-DT-ST DVDRAM GSA-T10N physical id: 0 bus info: ide at 0.0 logical name: /dev/hda version: PR03 serial: K0F697A2022 capabilities: packet atapi cdrom removable nonmagnetic dma lba iordy pm audio cd-r cd-rw dvd dvd-r dvd-ram configuration: mode=udma2 *-disc physical id: 0 logical name: /dev/hda *-ide:1 description: IDE Channel 1 physical id: 1 bus info: ide at 1 logical name: ide1 clock: 66MHz *-disk description: ATA Disk product: Hitachi HTS541212H9AT00 vendor: Hitachi physical id: 0 bus info: ide at 1.0 logical name: /dev/hdc version: HP4OA23C serial: HP0400BEG0P32A size: 111GB capacity: 111GB capabilities: ata dma lba iordy smart security pm apm partitioned partitioned:dos configuration: apm=off mode=udma5 smart=on *-volume:0 description: Linux filesystem partition physical id: 1 bus info: ide at 1.0,1 logical name: /dev/hdc1 capacity: 486MB capabilities: primary bootable *-volume:1 description: Linux swap / Solaris partition physical id: 2 bus info: ide at 1.0,2 logical name: /dev/hdc2 capacity: 3812MB capabilities: primary nofs *-volume:2 description: Linux filesystem partition physical id: 3 bus info: ide at 1.0,3 logical name: /dev/hdc3 capacity: 14GB capabilities: primary *-volume:3 description: Extended partition physical id: 4 bus info: ide at 1.0,4 logical name: /dev/hdc4 size: 93GB capacity: 93GB capabilities: primary extended partitioned partitioned:extended *-logicalvolume:0 description: Linux filesystem partition physical id: 5 logical name: /dev/hdc5 capacity: 37GB *-logicalvolume:1 description: Linux filesystem partition physical id: 6 logical name: /dev/hdc6 capacity: 54GB *-logicalvolume:2 description: Linux filesystem partition physical id: 7 logical name: /dev/hdc7 capacity: 1937MB *-pci:2 description: PCI bridge product: MCP51 PCI Bridge vendor: nVidia Corporation physical id: 10 bus info: pci at 00:10.0 version: a2 width: 32 bits clock: 66MHz capabilities: pci subtractive_decode bus_master cap_list *-pcmcia description: CardBus bridge product: RL5c476 II vendor: Ricoh Co Ltd physical id: 1 bus info: pci at 03:01.0 version: b3 width: 64 bits clock: 33MHz capabilities: pcmcia bus_master cap_list configuration: driver=yenta_cardbus latency=176 maxlatency=5 mingnt=131 resources: iomemory:df800000-df800fff iomemory:b00704030-b0070402f irq:11 *-firewire description: FireWire (IEEE 1394) product: R5C552 IEEE 1394 Controller vendor: Ricoh Co Ltd physical id: 1.1 bus info: pci at 03:01.1 version: 08 width: 32 bits clock: 33MHz capabilities: ohci bus_master cap_list configuration: driver=ohci1394 latency=64 maxlatency=4 mingnt=2 resources: iomemory:df7ff000-df7ff7ff irq:5 *-system:0 description: Generic system peripheral product: R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter vendor: Ricoh Co Ltd physical id: 1.2 bus info: pci at 03:01.2 version: 17 width: 32 bits clock: 33MHz capabilities: bus_master cap_list configuration: driver=sdhci latency=64 resources: iomemory:df7ff800-df7ff8ff irq:5 *-system:1 UNCLAIMED description: System peripheral product: R5C592 Memory Stick Bus Host Adapter vendor: Ricoh Co Ltd physical id: 1.3 bus info: pci at 03:01.3 version: 08 width: 32 bits clock: 33MHz capabilities: cap_list configuration: latency=0 resources: iomemory:df7ffc00-df7ffcff irq:5 *-network description: Wireless interface product: BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller vendor: Broadcom Corporation physical id: 3 bus info: pci at 03:03.0 logical name: eth1 version: 02 serial: 00:18:f3:ab:e7:42 width: 32 bits clock: 33MHz capabilities: bus_master ethernet physical wireless configuration: broadcast=yes driver=bcm43xx driverversion=2.6.20-16-generic latency=64 link=no multicast=yes wireless=IEEE 802.11b/g resources: iomemory:df7fc000-df7fdfff irq:11 *-multimedia description: Audio device product: MCP51 High Definition Audio vendor: nVidia Corporation physical id: 10.1 bus info: pci at 00:10.1 version: a2 width: 32 bits clock: 66MHz capabilities: bus_master cap_list configuration: driver=HDA Intel latency=0 maxlatency=5 mingnt=2 resources: iomemory:dceb8000-dcebbfff irq:10 *-pci:3 description: Host bridge product: K8 [Athlon64/Opteron] HyperTransport Technology Configuration vendor: Advanced Micro Devices [AMD] physical id: 101 bus info: pci at 00:18.0 version: 00 width: 32 bits clock: 33MHz *-pci:4 description: Host bridge product: K8 [Athlon64/Opteron] Address Map vendor: Advanced Micro Devices [AMD] physical id: 102 bus info: pci at 00:18.1 version: 00 width: 32 bits clock: 33MHz *-pci:5 description: Host bridge product: K8 [Athlon64/Opteron] DRAM Controller vendor: Advanced Micro Devices [AMD] physical id: 103 bus info: pci at 00:18.2 version: 00 width: 32 bits clock: 33MHz *-pci:6 description: Host bridge product: K8 [Athlon64/Opteron] Miscellaneous Control vendor: Advanced Micro Devices [AMD] physical id: 104 bus info: pci at 00:18.3 version: 00 width: 32 bits clock: 33MHz bst regards. Frederic From augusto.pedroza at gmail.com Wed Aug 8 15:02:26 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Wed, 8 Aug 2007 10:02:26 -0300 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC Message-ID: <#>Hi guys, I have tried in the last few days to debug windows VISTA installation process in different ways. All my tests have been doing using qemu. At first I tried to debug windows vista using WinGdb, but it seems to work only when windows is already installed since it requires some modifications in the boot.ini file. So was unable to connect wingdb to qemu through a pipe. My second option was to try to use windows debug mode when pressing F8 during the beginning of the installation process but the only info I found was this: Debugging Mode: This option turns on debug mode in Windows. Debugging information can be sent across a serial cable to another computer that is running a debugger. This mode is configured to use COM2. Does anyone knows how to capture COM2 output when using qemu? Maybe using a real hardware makes it easier since I can use a different computer connected to the guest through a NULL cable. Since I have gotten some random results when using qemu with its original bios, I have been unable to install windows vista on a hard disk image. Yesterday i almost got it but i created a image file too small, Vista requires at least 6Gb. I guess if I get that i'll be able to use wingdb more easily. Thanks, -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 8 19:33:39 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 08 Aug 2007 19:33:39 +0200 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC In-Reply-To: References: Message-ID: <46B9FE73.8010202@gmx.net> On 08.08.2007 15:02, Augusto Pedroza wrote: > > Since I have gotten some random results when using qemu with its original > bios, I have been unable to install windows vista on a hard disk image. > Yesterday i almost got it but i created a image file too small, Vista > requires at least 6Gb. I guess if I get that i'll be able to use wingdb more > easily. Does that mean you can't even get Vista to install without problems in normal Qemu? Regards, Carl-Daniel From augusto.pedroza at gmail.com Wed Aug 8 20:22:59 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Wed, 8 Aug 2007 15:22:59 -0300 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC In-Reply-To: <46B9FE73.8010202@gmx.net> References: <46B9FE73.8010202@gmx.net> Message-ID: Exactly!! I think I can find out why using the qemu option -serial /dev/ttyS1 and enabling debugging mode during windows start up. I just wonder if i can connect another computer to the one running qemu and still get the output send by qemu to emulated /dev/ttyS1. I'll test that tonight. Regrads, Augusto Pedroza On 8/8/07, Carl-Daniel Hailfinger wrote: > > On 08.08.2007 15:02, Augusto Pedroza wrote: > > > > Since I have gotten some random results when using qemu with its > original > > bios, I have been unable to install windows vista on a hard disk image. > > Yesterday i almost got it but i created a image file too small, Vista > > requires at least 6Gb. I guess if I get that i'll be able to use wingdb > more > > easily. > > Does that mean you can't even get Vista to install without problems in > normal Qemu? > > Regards, > Carl-Daniel > -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From popkonserve at gmx.de Wed Aug 8 22:10:03 2007 From: popkonserve at gmx.de (popkonserve) Date: Wed, 08 Aug 2007 22:10:03 +0200 Subject: [LinuxBIOS] Generic RAM detection routine In-Reply-To: References: <46B9FE73.8010202@gmx.net> Message-ID: <46BA231B.6080901@gmx.de> Hi, i'll have a generic ram detection routine ready by the end of the week that it able to detect any size of EDO/FPM (and maybe SDRAM too) just by reading/writing data. it doesn't need to access any smbus. i'll use this routine to support DRAM initialization on almost any socket 7 chipset..just have a little patience. the routine will not be able to determine any memory latencies by itself, so it may require user interactity or it will just set default values. the chipsets that will be supported: ALi Aladdin III/IV/IV/V AMD 640 Intel 430FX/HX/VX/TX SiS 5501,5502,5503/5120/5571/5581,5582/5591,5592/5597,5598/530 VIA 570M/580VP(VP1)/580VPX(VPX)/595(VP2)/597(VP3)/598(MVP3) before you ask: yes, i'll write a separate raminit.c for all those chipsets..so it may take a while. anyway, the all use the same ram detection routine that, as said before, will be finished by the end of the week. any help is appreciated. if the ram detection works for sdram as well (i didn't took a closer look but i guess it works just like the edo/fpm detection) i'll write routines for various Slot1 chipsets, too. Intel LX/BX first i guess. btw. if you happen to live in germany and you want to donate some of the above listed hardware for testing purpose: drop me a line :) Holger From r.marek at assembler.cz Wed Aug 8 22:29:59 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Wed, 08 Aug 2007 22:29:59 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46B91BC9.4040409@gmail.com> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> Message-ID: <46BA27C7.5030905@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Corey, > Both of these should be solved with ACPI tables, one of the Epia-M pages > in the wiki has some good info on using iasl. Also make sure > HAVE_HARD_RESET = 0 in mainboard Options.lb Ok have there =1 will try it. > >> I may write more about my issues if only someone is willing to help ;) >> I can put >> my code online somewhere. Maybe it would be good to check it in even >> if the code >> for NB is a bit of mess. > > That's your call, but I doubt it could hurt. First check that your code > is at least fairly clean and follows the coding guidelines (check the > wiki). You might also want to check with Via and make sure that's okay, > I don't know what your status is regarding NDAs. If you don't have one > at all, you should be fine. I have NDA. I cant just publish the specs in unaltered form. I must publish my code under GPL, comments in code are OK. I cannot create any other document except the source code (which describes VIA stuff). > >> USB/sound/SATA/IDE/PCIe/Network/Serial/Graphics/APIC works do far... > > USB works? Have you made any fixes or are you using the code I sent you > as-is? And for graphics, are you using onboard or a seperate card? I think I sent you some code already too. It is ATI Radeon X300SE (rv370) in PCIe slot. So separate. > And on 2, it actually tries to reboot but stops after printing the inital banner? No attempt at ram init or anything? It might be that yhlu has set up the k8 to not re-do ram init after a reboot, but I'm not sure. Yes just only one line... Well lets try with = 0 first. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuifH3J9wPJqZRNURAso5AJ9jQHK1wJHqyQyn8lhQ4T93mqFfBACfSte0 FdjhX3w0H2Cz9+fTA0F4IgI= =EUae -----END PGP SIGNATURE----- From r.marek at assembler.cz Thu Aug 9 01:24:37 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 09 Aug 2007 01:24:37 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46B91BC9.4040409@gmail.com> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> Message-ID: <46BA50B5.70805@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm I tried to set some bits for socket 939 in fun2 0x90 and 0x94, seems that RAM works now for two dimms ;) Perhaps I need to develop some fix? I will write about this later. > USB works? Yes USB does work. I tried again with my USB stick. Nothing needs to be programmed into the PCI regs, just enabled in SB as device. Thats all. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGulC13J9wPJqZRNURAgk6AJ0R619cjS4nQ9v70AWV9VR/73i4CgCeL/8B X3blHefvaALLJggpySTCX4Y= =FNPk -----END PGP SIGNATURE----- From corey.osgood at gmail.com Thu Aug 9 03:36:22 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Wed, 08 Aug 2007 21:36:22 -0400 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46BA50B5.70805@assembler.cz> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> <46BA50B5.70805@assembler.cz> Message-ID: <46BA6F96.40600@gmail.com> Rudolf Marek wrote: > Hmm I tried to set some bits for socket 939 in fun2 0x90 and 0x94, > seems that > RAM works now for two dimms ;) Perhaps I need to develop some fix? > I will write about this later. > > > USB works? > > Yes USB does work. I tried again with my USB stick. Nothing needs to be > programmed into the PCI regs, just enabled in SB as device. Thats all. Hmm, probably should have tried that first, I suppose. I did a bunch of init for it, and it currently causes a kernel panic. Thanks! -Corey From r.marek at assembler.cz Thu Aug 9 07:27:05 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 09 Aug 2007 07:27:05 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46BA50B5.70805@assembler.cz> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> <46BA50B5.70805@assembler.cz> Message-ID: <46BAA5A9.60501@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > hmm, probably should have tried that first, I suppose. I did a bunch of > init for it, and it currently causes a kernel panic. Thanks! It has only set some bits for the SMM by BIOS, which we dont need. So nothing is needed. Hre is mu promised update: > Hmm I tried to set some bits for socket 939 in fun2 0x90 and 0x94, seems that > RAM works now for two dimms ;) Perhaps I need to develop some fix? I will > write about this later. Just after some S3 ;) - - PCI_ADDR(0, 0x18, 2, 0x8c), 0xff8fe08e, (0 << 20)|(0 << 8)|(0 << 4)|(0 << 0), + PCI_ADDR(0, 0x18, 2, 0x8c), 0xff8fe08e, (0 << 20)|(0 << 8)|(0 << 4)|(1 << 0), //change! I enlarged the Write-to-Read Delay to 2 clocks as my AW is doing. - - PCI_ADDR(0, 0x18, 2, 0x90), 0xf0000000, + PCI_ADDR(0, 0x18, 2, 0x90), 0xc0000000, + (1 << 29)| //change (4 << 25)|(0 << 24)| (0 << 23)|(0 << 22)|(0 << 21)|(0 << 20)| (1 << 19)|(0 << 18)|(1 << 17)|(0 << 16)| (2 << 14)|(0 << 13)|(0 << 12)| - - (0 << 11)|(0 << 10)|(0 << 9)|(0 << 8)| + (0 << 11)|(0 << 10)|(1 << 9)|(0 << 8)| //CHANGE DUAL DIMM ENABLE (0 << 3) |(0 << 1) |(0 << 0), And then also bit9 Dual DIMM Enable (DualDimmEn)--Bit 9. When this bit is set, the A copy of the memory address bus is enabled, regardless of the MC0_EN (Function 2, Offset 94h) value, and the B copy of the memory bus is disabled if 939 package with 128-bit bus is not used. This bit should be set if unbuffered DIMMs are used, and two DIMM sockets are connected to the A copy of the memory address bus, as in SODIMM or 939 package configurations. See "Register Differences in Revisions of the AMD AthlonTM 64 and AMD OpteronTM Processors" on page 29 for revision information about this field. And 29: Upper Chip Select Mapping (UpperCSMap)--Bit 29. When this bit is set, chip select pins CS[7:4] are copies of chip select pins CS[3:0]. This bit should be set if the 939 package is used. See "Register Differences in Revisions of the AMD AthlonTM 64 and AMD OpteronTM Processors" on page 29 for revision information about this field. After that my 2 DIMMS works fine it seems. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuqWp3J9wPJqZRNURAk2yAKCDpjuzT06Forqv6BVpguAbbvMdKQCcCtZz vDgqt1YiM5KUtHVKZWpBA8A= =yL+X -----END PGP SIGNATURE----- From joe at smittys.pointclark.net Thu Aug 9 09:59:32 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 09 Aug 2007 03:59:32 -0400 Subject: [LinuxBIOS] Generic RAM detection routine In-Reply-To: <46BA231B.6080901@gmx.de> References: <46B9FE73.8010202@gmx.net> <46BA231B.6080901@gmx.de> Message-ID: <20070809035932.y8el0r4feo0kckcc@www.smittys.pointclark.net> Quoting popkonserve : > Hi, > i'll have a generic ram detection routine ready by the end of the week > that it able to detect any size of EDO/FPM (and maybe SDRAM too) just by > reading/writing data. it doesn't need to access any smbus. i'll use this > routine to support DRAM initialization on almost any socket 7 > chipset..just have a little patience. the routine will not be able to > determine any memory latencies by itself, so it may require user > interactity or it will just set default values. > the chipsets that will be supported: > ALi Aladdin III/IV/IV/V > AMD 640 > Intel 430FX/HX/VX/TX > SiS 5501,5502,5503/5120/5571/5581,5582/5591,5592/5597,5598/530 > VIA 570M/580VP(VP1)/580VPX(VPX)/595(VP2)/597(VP3)/598(MVP3) > before you ask: yes, i'll write a separate raminit.c for all those > chipsets..so it may take a while. anyway, the all use the same ram > detection routine that, as said before, will be finished by the end of > the week. any help is appreciated. > if the ram detection works for sdram as well (i didn't took a closer > look but i guess it works just like the edo/fpm detection) i'll write > routines for various Slot1 chipsets, too. Intel LX/BX first i guess. > btw. if you happen to live in germany and you want to donate some of the > above listed hardware for testing purpose: drop me a line :) > Holger > > -- Interesting. How will this work without reading SPD data without the smbus? Will it just be able to detect if memory is populated? Size? Other important info to set northbridge registers? Do tell.... Thanks - Joe From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 9 14:27:12 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Aug 2007 14:27:12 +0200 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC In-Reply-To: References: <46B9FE73.8010202@gmx.net> Message-ID: <46BB0820.7010704@gmx.net> On 08.08.2007 20:22, Augusto Pedroza wrote: > On 8/8/07, Carl-Daniel Hailfinger wrote: > > > > Does that mean you can't even get Vista to install without problems in > > normal Qemu? > > Exactly!! As it turns out, current Bochs can run Vista and since we depend on the Bochs BIOS for ADLO, updating the codebase could result in a working Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the success message. Regards, Carl-Daniel From augusto.pedroza at gmail.com Thu Aug 9 14:43:17 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Thu, 9 Aug 2007 09:43:17 -0300 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC In-Reply-To: <46BB0820.7010704@gmx.net> References: <46B9FE73.8010202@gmx.net> <46BB0820.7010704@gmx.net> Message-ID: > As it turns out, current Bochs can run Vista and since we depend on the > Bochs BIOS for ADLO, updating the codebase could result in a working > Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the > success message. > > We are using one of the newest versions of bochs bios and it does work ... sometimes. For some reason it works 1 out of 10 times. Most of the times It shows a blue screen related to ACPI or PAGE_FAULT. Yesterday I almost finished installing vista on a disk image but it displayed a message saying it couldn't set my locale and canceled the installation, can you believe that? I'm trying very hard to connect the virtual serial COM2 port of qemu to my real COM2/ttyS1 port so we can get some messages when turning on debugging mode. I have tried different settings but no sucess up to now. I'll email Stanislav to fins out if he faced the same problems. Thanks a lot, -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 9 16:17:45 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Aug 2007 16:17:45 +0200 Subject: [LinuxBIOS] Help Debugging Windows VISTA - GSoC In-Reply-To: References: <46B9FE73.8010202@gmx.net> <46BB0820.7010704@gmx.net> Message-ID: <46BB2209.6060109@gmx.net> On 09.08.2007 14:43, Augusto Pedroza wrote: >> As it turns out, current Bochs can run Vista and since we depend on the >> Bochs BIOS for ADLO, updating the codebase could result in a working >> Vista. See http://marc.info/?l=bochs-dev&m=118650789913052&w=2 for the >> success message. >> > We are using one of the newest versions of bochs bios and it does work ... The 16bit or the 32bit version of the BIOS? Can you check if the current Bochs code still works with W2k/WXP? If the current code still works, please send a patch updating the code to the list and commit after an Ack. > sometimes. For some reason it works 1 out of 10 times. Most of the times It > shows a blue screen related to ACPI or PAGE_FAULT. > Yesterday I almost finished installing vista on a disk image but it > displayed a message saying it couldn't set my locale and canceled the > installation, can you believe that? Heh. That is pure excellence by Microsoft... > I'll email Stanislav to fins out if he faced the same problems. AFAIK Stanislas ran Vista on Bochs, not on Qemu with a Bochs BIOS. Regards, Carl-Daniel From popkonserve at gmx.de Thu Aug 9 16:49:47 2007 From: popkonserve at gmx.de (popkonserve) Date: Thu, 09 Aug 2007 16:49:47 +0200 Subject: [LinuxBIOS] Generic RAM detection routine In-Reply-To: <20070809035932.y8el0r4feo0kckcc@www.smittys.pointclark.net> References: <46B9FE73.8010202@gmx.net> <46BA231B.6080901@gmx.de> <20070809035932.y8el0r4feo0kckcc@www.smittys.pointclark.net> Message-ID: <46BB298B.7090204@gmx.de> > Interesting. How will this work without reading SPD data without the > smbus? Will it just be able to detect if memory is populated? Size? > Other important info to set northbridge registers? Do tell.... since EDO/FPM don't have a SPD eeprom there's no need trying to get any data out of it :) size and internal organisation detection is done by a simple algorithm. i hope i'll have a sample of it ready later. it'll feature the ram init and detection of the Intel 430FX chipset and will have lots of comments :) the rest should be a bit of datasheet surfing and register adapting (more or less). Holger From joe at smittys.pointclark.net Thu Aug 9 17:03:09 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 09 Aug 2007 11:03:09 -0400 Subject: [LinuxBIOS] Generic RAM detection routine In-Reply-To: <46BB298B.7090204@gmx.de> References: <46B9FE73.8010202@gmx.net> <46BA231B.6080901@gmx.de> <20070809035932.y8el0r4feo0kckcc@www.smittys.pointclark.net> <46BB298B.7090204@gmx.de> Message-ID: <20070809110309.rzkxu7s600kwgw0w@www.smittys.pointclark.net> Quoting popkonserve : >> Interesting. How will this work without reading SPD data without the >> smbus? Will it just be able to detect if memory is populated? Size? >> Other important info to set northbridge registers? Do tell.... > > since EDO/FPM don't have a SPD eeprom there's no need trying to get any > data out of it :) > size and internal organisation detection is done by a simple algorithm. > i hope i'll have a sample of it ready later. it'll feature the ram init > and detection of the Intel 430FX chipset and will have lots of comments > :) the rest should be a bit of datasheet surfing and register adapting > (more or less). > Holger > > -- Cool for simms, but not sure how this would work out for SDRAM, DDR, DDR2, etc. There is alot of data that comes from the SPD eeprom that the nothbridge needs to set up its registers, and check for compatability, etc. That's where the SMBUS needs to come in.... Still, I am very interested. Can you elaborate on what kind of data the "simple algorithm" will be able to produce? Thanks - Joe From peter at stuge.se Thu Aug 9 17:21:06 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Aug 2007 17:21:06 +0200 Subject: [LinuxBIOS] Generic RAM detection routine In-Reply-To: <20070809110309.rzkxu7s600kwgw0w@www.smittys.pointclark.net> References: <46B9FE73.8010202@gmx.net> <46BA231B.6080901@gmx.de> <20070809035932.y8el0r4feo0kckcc@www.smittys.pointclark.net> <46BB298B.7090204@gmx.de> <20070809110309.rzkxu7s600kwgw0w@www.smittys.pointclark.net> Message-ID: <20070809152106.30685.qmail@stuge.se> On Thu, Aug 09, 2007 at 11:03:09AM -0400, Joseph Smith wrote: > > since EDO/FPM don't have a SPD eeprom > > Cool for simms, Which I think is the scope of the code. > but not sure how this would work out for SDRAM, DDR, DDR2, etc. I don't think it's a good idea to try to cover all types of RAM with one piece of code. The different memory types need different init so it will be more like a library. > There is alot of data that comes from the SPD eeprom that > the nothbridge needs to set up its registers, and check for > compatability, etc. That's where the SMBUS needs to come in.... Yep. There's been some work to unify SPD already, but I think most of the improvements here will be in v3. //Peter From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 9 18:57:58 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Aug 2007 18:57:58 +0200 Subject: [LinuxBIOS] LBv3 under Bochs Message-ID: <46BB4796.3070302@gmx.net> Hi, since Qemu can't boot Windows Vista reliably and Bochs can, I wondered whether Bochs can run LinuxBIOS v3. Patrick Georgi tried it and even got to the GRUB2 welcome screen, where it crashed with a triple fault. This is what Patrick wrote in IRC: > http://openbios.org/~oxygene/lbv3.bochs is the config I used (to be > started from lbv3's root directory) > it's configured to send serial0 to /dev/stdout > I get "Welcome to GRUB!" now, but then it crashes on a triple fault :) > http://pastebin.com/m749c3e36 bochs output Will we try to get LBv3 running in Bochs? Benefits would be: * One more soft hardware platform to test code with (although the emulated hardware is very similar to that of Qemu) * Bochs seems to support Vista and we may have success running Vista with LBv3 in Bochs Regards, Carl-Daniel From patrick at georgi-clan.de Thu Aug 9 20:07:53 2007 From: patrick at georgi-clan.de (Patrick Georgi) Date: Thu, 09 Aug 2007 20:07:53 +0200 Subject: [LinuxBIOS] LBv3 under Bochs In-Reply-To: <46BB4796.3070302@gmx.net> References: <46BB4796.3070302@gmx.net> Message-ID: Carl-Daniel Hailfinger schrieb: > This is what Patrick wrote in IRC: >> http://openbios.org/~oxygene/lbv3.bochs is the config I used (to be >> started from lbv3's root directory) >> it's configured to send serial0 to /dev/stdout >> I get "Welcome to GRUB!" now, but then it crashes on a triple fault :) >> http://pastebin.com/m749c3e36 bochs output > > Will we try to get LBv3 running in Bochs? Some more information (Thanks to Peter, who found that piece): (excerpt from the paste bin above): 00027185764i[CPU0 ] | CS:0010( 0002| 0| 0) 00000000 000fffff 1 1 00027185764i[CPU0 ] | DS:0018( 0003| 0| 0) 00000000 000fffff 1 1 00027185764i[CPU0 ] | SS:0018( 0003| 0| 0) 00000000 000fffff 1 1 00027185764i[CPU0 ] | ES:0018( 0003| 0| 0) 00000000 000fffff 1 1 00027185764i[CPU0 ] | FS:0018( 0003| 0| 0) 00000000 000fffff 1 1 00027185764i[CPU0 ] | GS:0018( 0003| 0| 0) 00000000 000fffff 1 1 Those should be (00000000,ffffffff), but aren't on bochs. On qemu they _are_ all set to (00000000,ffffffff). But I have no idea what the reason could be and no time to debug it at the moment. Regards, Patrick Georgi From uwe at hermann-uwe.de Thu Aug 9 22:31:39 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 9 Aug 2007 22:31:39 +0200 Subject: [LinuxBIOS] Install bios in Asus A6T. In-Reply-To: <43595.217.119.180.154.1186501960.squirrel@www.placenet.org> References: <43595.217.119.180.154.1186501960.squirrel@www.placenet.org> Message-ID: <20070809203139.GD30154@greenwood> Hi, On Tue, Aug 07, 2007 at 05:52:40PM +0200, frederic at placenet.org wrote: > i do not see anything in wiki. > > somebody has experience about: laptop Asus A6T. No laptops are supported at the moment, sorry. > chipset : C51MV(C61)+MCP51 The MCP51 is not supported either, but the MCP55 and the CK804 NVIDIA chipsets are supported (just in case that helps you). Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From talbotx at comcast.net Thu Aug 9 22:56:45 2007 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 09 Aug 2007 13:56:45 -0700 Subject: [LinuxBIOS] KVM over IP, fully embedded in LinuxBIOS? Message-ID: <46BB7F8D.6010801@comcast.net> An idea that I wanted to bounce around. KVM over IP, fully embedded in LinuxBIOS? In a production class server room, there are mainly two ways to gain video console on a server. Crash cart, or a KVM over IP solution. It has been proven that LinuxBIOS can do console over IP... How much of a stretch would it be to implant something like VNC server into LinuxBIOS? Just a crazy idea, what up/downs do you see? -Adam From peter at stuge.se Thu Aug 9 23:00:21 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Aug 2007 23:00:21 +0200 Subject: [LinuxBIOS] KVM over IP, fully embedded in LinuxBIOS? In-Reply-To: <46BB7F8D.6010801@comcast.net> References: <46BB7F8D.6010801@comcast.net> Message-ID: <20070809210021.26358.qmail@stuge.se> On Thu, Aug 09, 2007 at 01:56:45PM -0700, Adam Talbot wrote: > An idea that I wanted to bounce around. KVM over IP, fully > embedded in LinuxBIOS? LB is removed/forgotten by design once the payload is started. SSH on management VLAN instead? //Peter From talbotx at comcast.net Thu Aug 9 23:08:01 2007 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 09 Aug 2007 14:08:01 -0700 Subject: [LinuxBIOS] KVM over IP, fully embedded in LinuxBIOS? In-Reply-To: <20070809210021.26358.qmail@stuge.se> References: <46BB7F8D.6010801@comcast.net> <20070809210021.26358.qmail@stuge.se> Message-ID: <46BB8231.1@comcast.net> Fork at the payload? VNC server for one payload and the boot loader for a different payload, run both? SSH on privet VLAN only works if the computer is running. What happens in the case of a kernel panic? How do you recover? -Adam Peter Stuge wrote: > On Thu, Aug 09, 2007 at 01:56:45PM -0700, Adam Talbot wrote: > >> An idea that I wanted to bounce around. KVM over IP, fully >> embedded in LinuxBIOS? >> > > LB is removed/forgotten by design once the payload is started. > > SSH on management VLAN instead? > > > //Peter > > From peter at stuge.se Thu Aug 9 23:21:55 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Aug 2007 23:21:55 +0200 Subject: [LinuxBIOS] KVM over IP, fully embedded in LinuxBIOS? In-Reply-To: <46BB8231.1@comcast.net> References: <46BB7F8D.6010801@comcast.net> <20070809210021.26358.qmail@stuge.se> <46BB8231.1@comcast.net> Message-ID: <20070809212155.29553.qmail@stuge.se> On Thu, Aug 09, 2007 at 02:08:01PM -0700, Adam Talbot wrote: > Fork at the payload? There is no multitasking. > VNC server for one payload and the boot loader for a different > payload, run both? Then LB would be an operating system, which it is designed not to be. > SSH on privet VLAN only works if the computer is running. What > happens in the case of a kernel panic? How do you recover? To make it reliable I would say with dedicated hardware. The RSA in IBM e330 e.g. Or a watchdog, that's much simpler, but it also gets the job done. That said, if you use Linux as the payload you could run the "system" with KVM or XEN or some other virtualization, and have the hypervisor be remotely accessible for management. Of course, that can still blow up. Bottom line; it's impossible to have software recover from a fatal machine error caused by some other software running on the same machine. //Peter From rminnich at gmail.com Thu Aug 9 23:27:26 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 9 Aug 2007 14:27:26 -0700 Subject: [LinuxBIOS] LBv3 under Bochs In-Reply-To: <46BB4796.3070302@gmx.net> References: <46BB4796.3070302@gmx.net> Message-ID: <13426df10708091427u388a3f75gdb22ad74338b1975@mail.gmail.com> I used to boot just fine on bochs and in fact I think I did today, but am not certain :-) Yes, booting under bochs is really valuable! ron From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 9 23:32:36 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 09 Aug 2007 23:32:36 +0200 Subject: [LinuxBIOS] LBv3 under Bochs In-Reply-To: <13426df10708091427u388a3f75gdb22ad74338b1975@mail.gmail.com> References: <46BB4796.3070302@gmx.net> <13426df10708091427u388a3f75gdb22ad74338b1975@mail.gmail.com> Message-ID: <46BB87F4.9000806@gmx.net> On 09.08.2007 23:27, ron minnich wrote: > I used to boot just fine on bochs and in fact I think I did today, but > am not certain :-) Hm. Can you post your bochs config? And was this with v2 or v3? > Yes, booting under bochs is really valuable! I'll prepare a patch to say so in Kconfig in v3. Regards, Carl-Daniel From popkonserve at gmx.de Fri Aug 10 00:09:36 2007 From: popkonserve at gmx.de (popkonserve) Date: Fri, 10 Aug 2007 00:09:36 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX Message-ID: <46BB90A0.2050805@gmx.de> hi, as promised the ram init routine for the intel 430fx chipset. completely untested yet, but seems to compile without errors (at least those i could have typed in ;)) the datasheet for the chipset is here: http://download.intel.com/design/chipsets/datashts/29051801.pdf the routine does the following: 1. disable all caches 2. set ram size to 0 3. take one row and set its ram size to the maximum value and its type to edo 4. write some data in the row 5. enable edo detection 6. read the data back 7. if the data read is the data written it is edo 8. if the data read is NOT the data written, write some more data 9. read the data back (without edo detection) 10. if the data read is the data written it is fpm 11. if the data read is NOT the data written, the row is empty 12. detect the real size of the row and the dram technology (i'll write some more about that tomorrow, sorry, it's late already :)) 13. clear all settings for the current row 14. restart at 3. as long as not all rows have been processed 15. write the size and type (edo/fpm) of all rows 16. turn the caches back on ;) the routine isn't doing any tests on dram timings yet. this COULD be implemented or we should ask the user to enter something useful. upto now the slowest dram timings are used which is not that nice but still it should work. anyway, i could implement some more chipset settings regarding pci performance and behaviour but i guess it doesn't belong in the raminit.c, does it? now have a look at the code and try to understand it ;) Holger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: raminit.h URL: From peter at stuge.se Fri Aug 10 00:30:49 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Aug 2007 00:30:49 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX In-Reply-To: <46BB90A0.2050805@gmx.de> References: <46BB90A0.2050805@gmx.de> Message-ID: <20070809223049.7698.qmail@stuge.se> On Fri, Aug 10, 2007 at 12:09:36AM +0200, popkonserve wrote: > /* > * This file is part of the LinuxBIOS project. > * > * Copyright (C) Please add 2007 Holger Yourlastname > static void initialize_row(const struct mem_controller* ctrl, > const uint8_t u8_row) { > > uint8_t u8_DRAMSize = 0; > uint8_t u8_DRAMType = 1; > > /* Initialize the current row to EDO and 32MB (maximum size) */ > u8_DRAMType <<= u8_row; > u8_DRAMSize == SIMM_ROW_SIZE_MAX / SIMM_GRANULARITY; Typo == instead of = ? > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_ROW_BOUNDARY_BASE) + u8_row, > u8_DRAMSize); ..will always write 0 otherwise. > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_ROW_TYPE), > u8_DRAMType); Does this want to be a set_row_type() function? > /* Enable EDO detection mode */ > u8_DRAMC = pci_read_config8(ctrl->d0, > ((uint8_t)e_DRAM_CONTROL)); > > u8_DRAMC |= ((uint8_t)e_DRAMC_EDO_DETECT); > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_CONTROL), > u8_DRAMC); Maybe also candidate for a separate function? > static void detect_size(const struct mem_controller* ctrl, [..] > for(;;) { [..] > /* Quit if the size of the current row was detected or an error occured */ > if((u8_size_detected != 0) || > au8_DRAMSize[u8_row] == ((uint8_t)e_EMPTY)){ > break; > } > } Please change the for() into do {} while(); to improve readability. > /* Turn off cache (L1 & L2) */ Isn't there a function for this already? If not, should there be? > /* Set size of DRAM to 0 for all rows */ > for(u8_row = 0; u8_row < SIMM_SOCKETS; u8_row++) { > au8_DRAMSize[u8_row] = 0; > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_ROW_BOUNDARY_BASE) + u8_row, > au8_DRAMSize); > } > > /* Detect RAM presence and type in all rows */ > for(u8_row = 0; u8_row < SIMM_SOCKETS; u8_row++) { > All rows need to be zeroed first to make this reliable? > /* Detect type of ram in the current row */ > detect_type(ctrl, > au8_DRAMSize, > &u8_DRAMType, > u8_row); > > /* Check if any DRAM was found in this row */ > if(au8_DRAMSize[u8_row] == 0) { > /* No DRAM found. Skip the rest. */ > continue; > } A bit unexpected to have detect_type() return meaningful data in a Size parameter. Maybe a return value from detect_type() would be nicer? Looks good! :) //Peter From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 10 01:09:52 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 10 Aug 2007 01:09:52 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings Message-ID: <46BB9EC0.8080806@gmx.net> This patch removes all printk format warnings from my LBv3 build (Qemu x86 config). This was tested with gcc 4.1.0 on x86. However, the code at various locations is not 64bit clean at all and will probably break down once we have more than 4GB of RAM. My patch doesn't change that, it is merely intended to fix the warnings for improper printk usage. Beware: Before the patch is committed, a diff of the output of a LB boot (before and after the patch) needs to be verified. Each change of output should look reasonable, if not, please holler so I can fix the code. Signed-off-by: Carl-Daniel Hailfinger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios3_fix_printk_warnings.diff URL: From popkonserve at gmx.de Fri Aug 10 08:22:44 2007 From: popkonserve at gmx.de (popkonserve) Date: Fri, 10 Aug 2007 08:22:44 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX In-Reply-To: <20070809223049.7698.qmail@stuge.se> References: <46BB90A0.2050805@gmx.de> <20070809223049.7698.qmail@stuge.se> Message-ID: <46BC0434.70605@gmx.de> >> * This file is part of the LinuxBIOS project. >> * >> * Copyright (C) > > > Please add 2007 Holger Yourlastname fixed. left it out as it isn't tested at all..and shouldn't be used as long as it isn't. > Typo == instead of = ? fixed, too :) >> pci_write_config8(ctrl->d0, >> ((uint8_t)e_DRAM_ROW_TYPE), >> u8_DRAMType); > > > Does this want to be a set_row_type() function? hmm, wouldn't make much sense here i guess. the register that stores the type of drams used is a single register for all rows. so the only thing the function would do would be a single write to the same register for all rows. only the data would change. >> /* Enable EDO detection mode */ > Maybe also candidate for a separate function? then i would have to write a disable_edo_detection, too. and again all they would to is to write one special register. both calls are alread inside a function that is called detect_type and that's where they belong :) > Please change the for() into do {} while(); to improve readability. done. >> /* Turn off cache (L1 & L2) */ > Isn't there a function for this already? If not, should there be? there should be..i didn't look. while L1 cache could be switched off on socket 7 processors, the L2 cache is controlled by the chipset. i don't know if there's a 'disable L2 cache' pin on socket 7 processors that would tell the chipset to ignore its L2 cache. so i used the chipset's function rather than leaving it as TODO. >> /* Set size of DRAM to 0 for all rows */ >> for(u8_row = 0; u8_row < SIMM_SOCKETS; u8_row++) { >> au8_DRAMSize[u8_row] = 0; >> pci_write_config8(ctrl->d0, >> ((uint8_t)e_DRAM_ROW_BOUNDARY_BASE) + u8_row, >> au8_DRAMSize); >> } >> >> /* Detect RAM presence and type in all rows */ >> for(u8_row = 0; u8_row < SIMM_SOCKETS; u8_row++) { >> > > > All rows need to be zeroed first to make this reliable? well, there are two kind answers: yes and no. if i do not set all rows to zero, the writes in the type and size detection routines would have to be recalculated for each row. they would have to take into account that there already is ram in front of them and they would have to write to ex. OFFSET + AA0 just to avoid some more mind breaking calculation i decided to set the ram size to zero for all rows before the detection starts and set it back to zero for the current row when the detection is over. if there's a problem with that i could rewrite the functions to use offsets, too. >> /* Detect type of ram in the current row */ >> detect_type(ctrl, >> au8_DRAMSize, >> &u8_DRAMType, >> u8_row); >> >> /* Check if any DRAM was found in this row */ >> if(au8_DRAMSize[u8_row] == 0) { >> /* No DRAM found. Skip the rest. */ >> continue; >> } > > > A bit unexpected to have detect_type() return meaningful data in a > Size parameter. i use the size parameter as indication if the row is populated at all and thus skipping the rest of the detection process (why trying to detect anything else if there's no ram in there?). > Maybe a return value from detect_type() would be nicer? yes, maybe. no problem to change it if the others agree on this one. i would want to reuse the code for the other socket 7 chipsets, too. even with a return parameter reuseability wouldn't be hurt at all. Holger From darmawan.salihun at gmail.com Fri Aug 10 10:08:26 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Fri, 10 Aug 2007 15:08:26 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46ADF604.5070005@dls.net> References: <46886eb7.27ed720a.5795.ffffedbb@mx.google.com> <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> Message-ID: <46BC1CFA.4060308@gmail.com> Roman Kononov wrote: > Darmawan Salihun wrote: >> As I couldn't find any better replacement to the PCI direct I/O >> function at the moment (which is needed in chipset_enable and >> board_enable), I will try to implement them using a quite old kernel >> mode API, i.e. HalGetBusData and HalSetBusData. I hope the kernel >> "emulates" these functions so that it works like in NT4 and Windows >> 2000. > > A more "portable" way: > > Make all CPUs spinning inside a DPC function: > KeQueryActiveProcessors() is used to get all processors. > KeSetTargetProcessorDpc() is used to tie the DPC function and particular > SMP processors. > When all CPUs are spinning inside the function, one of them does IO > (CF8/CFC) to the PCI configuration space. > After the IO completes, let all DPC functions finish. > > Roman > After discussing about the access method at length with more experienced Windows driver developers. I think if HalGetBusData is not working at all then direct I/O port access with your "multiprocessor-aware kernel thread protection" is the "safest" method. --Darmawan Salihun From peter at stuge.se Fri Aug 10 12:16:24 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Aug 2007 12:16:24 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46BC1CFA.4060308@gmail.com> References: <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> Message-ID: <20070810101624.25036.qmail@stuge.se> On Fri, Aug 10, 2007 at 03:08:26PM +0700, Darmawan Salihun wrote: > Roman Kononov wrote: > > Make all CPUs spinning inside a DPC function: > > After discussing about the access method at length with more > experienced Windows driver developers. I think if HalGetBusData is > not working at all then direct I/O port access with your > "multiprocessor-aware kernel thread protection" is the "safest" > method. But PCI config accesses are not atomic operations. Is there a guarantee that the other CPUs are not in the middle of doing a PCI access already? And even if they are actually doing something else, perhaps they (erroneously? but we don't want to break them anyway) rely on 0xcfc being what they set it to in the last PCI config access? I really prefer using whatever API Windows offers. //Peter From darmawan.salihun at gmail.com Fri Aug 10 12:21:11 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Fri, 10 Aug 2007 17:21:11 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070810101624.25036.qmail@stuge.se> References: <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> Message-ID: <46BC3C17.5040409@gmail.com> Peter Stuge wrote: > On Fri, Aug 10, 2007 at 03:08:26PM +0700, Darmawan Salihun wrote: >> Roman Kononov wrote: >>> Make all CPUs spinning inside a DPC function: >> After discussing about the access method at length with more >> experienced Windows driver developers. I think if HalGetBusData is >> not working at all then direct I/O port access with your >> "multiprocessor-aware kernel thread protection" is the "safest" >> method. > > But PCI config accesses are not atomic operations. Is there a > guarantee that the other CPUs are not in the middle of doing a PCI > access already? > > And even if they are actually doing something else, perhaps they > (erroneously? but we don't want to break them anyway) rely on 0xcfc > being what they set it to in the last PCI config access? > > I really prefer using whatever API Windows offers. That's why I'm trying this Hal***BusDataByOffset right now. Some developers say that they work in some platform and not in others. That's why I want to test it first hand ;-). I'm completing/reviewing the code right now before testing it in my testbed machines. Stay tuned :-) Darmawan Salihun From peter at stuge.se Fri Aug 10 14:30:52 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Aug 2007 14:30:52 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46BC3C17.5040409@gmail.com> References: <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC3C17.5040409@gmail.com> Message-ID: <20070810123052.14705.qmail@stuge.se> On Fri, Aug 10, 2007 at 05:21:11PM +0700, Darmawan Salihun wrote: > > I really prefer using whatever API Windows offers. > > That's why I'm trying this Hal***BusDataByOffset right now. Aye. > Some developers say that they work in some platform and not in > others. It's marked as deprecated in MSDN since Windows 2000 and it is suggested to use the PnP manager instead. These code snippets look useful: http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html I also found a code snippet from PLX (who make PCI interface chips) saying that sending IRPs crashes Windows 98. I would easily sacrifice Win98/ME in favor of Vista or even XP if neccessary. > That's why I want to test it first hand ;-). I'm > completing/reviewing the code right now before testing it in my > testbed machines. > > Stay tuned :-) Great! I'm looking forward to the results! :) //Peter From kononov at dls.net Fri Aug 10 15:38:34 2007 From: kononov at dls.net (Roman Kononov) Date: Fri, 10 Aug 2007 08:38:34 -0500 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070810101624.25036.qmail@stuge.se> References: <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> Message-ID: <46BC6A5A.6080609@dls.net> Peter Stuge wrote: > But PCI config accesses are not atomic operations. Is there a > guarantee that the other CPUs are not in the middle of doing a PCI > access already? > > And even if they are actually doing something else, perhaps they > (erroneously? but we don't want to break them anyway) rely on 0xcfc > being what they set it to in the last PCI config access? > By making all the CPUs spinning inside your DPC you avoid these problems. The Windoze kernel protects itself and does not execute scheduled DPC when the CPU is in the middle of a PCI access or anything similar. For sure, when a CPU makes a PCI access its "IRQL" is raised to "HIGH_LEVEL", which means that a dedicated spin lock is acquired and that CPU's interrupts are disabled. I did not take the above statement about IRQL from an official document, I made it based on my experience and common sense. Regards, Roman From svn at openbios.org Fri Aug 10 15:48:59 2007 From: svn at openbios.org (svn at openbios.org) Date: Fri, 10 Aug 2007 15:48:59 +0200 Subject: [LinuxBIOS] r465 - LinuxBIOSv3/util/x86emu/include/x86emu Message-ID: Author: stepan Date: 2007-08-10 15:48:59 +0200 (Fri, 10 Aug 2007) New Revision: 465 Modified: LinuxBIOSv3/util/x86emu/include/x86emu/types.h Log: trivial: explicitly make signed types signed as ommiting the "signed" keyword might not do what we want. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/x86emu/include/x86emu/types.h =================================================================== --- LinuxBIOSv3/util/x86emu/include/x86emu/types.h 2007-07-23 23:18:41 UTC (rev 464) +++ LinuxBIOSv3/util/x86emu/include/x86emu/types.h 2007-08-10 13:48:59 UTC (rev 465) @@ -74,15 +74,15 @@ typedef unsigned long long u64; #endif -typedef char s8; -typedef short s16; -typedef int s32; +typedef signed char s8; +typedef signed short s16; +typedef signed int s32; #ifdef __HAS_LONG_LONG__ -typedef long long s64; +typedef signed long long s64; #endif -typedef unsigned int uint; -typedef int sint; +typedef unsigned int uint; +typedef signed int sint; typedef u16 X86EMU_pioAddr; From uwe at hermann-uwe.de Fri Aug 10 15:58:59 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 10 Aug 2007 15:58:59 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX In-Reply-To: <46BB90A0.2050805@gmx.de> References: <46BB90A0.2050805@gmx.de> Message-ID: <20070810135859.GC32751@greenwood> Hi, On Fri, Aug 10, 2007 at 12:09:36AM +0200, popkonserve wrote: > the routine does the following: > 1. disable all caches > 2. set ram size to 0 > 3. take one row and set its ram size to the maximum value and its type to > edo > 4. write some data in the row > 5. enable edo detection > 6. read the data back > 7. if the data read is the data written it is edo > 8. if the data read is NOT the data written, write some more data > 9. read the data back (without edo detection) > 10. if the data read is the data written it is fpm > 11. if the data read is NOT the data written, the row is empty > 12. detect the real size of the row and the dram technology (i'll write > some more about that tomorrow, sorry, it's late already :)) > 13. clear all settings for the current row > 14. restart at 3. as long as not all rows have been processed > 15. write the size and type (edo/fpm) of all rows > 16. turn the caches back on ;) Please add this documentation to the source code as a (Doygen) comment. > /*----------------------------------------------------------------------------- > EDO/FP/SDRAM detection routine. > ----------------------------------------------------------------------------*/ > > /** > * Initializes a row before it can be checked for DRAM > */ > static void initialize_row(const struct mem_controller* ctrl, > const uint8_t u8_row) { Please don't encode type information in variable names. "row" is fine. > uint8_t u8_DRAMSize = 0; > uint8_t u8_DRAMType = 1; Use all-lowercase variable and function names, please. There are many other coding style issues in the code, please read http://linuxbios.org/Development_Guidelines#Coding_Guidelines http://lxr.linux.no/source/Documentation/CodingStyle and fix the code to use the Linux kernel coding style. > /* Initialize the current row to EDO and 32MB (maximum size) */ > u8_DRAMType <<= u8_row; > u8_DRAMSize == SIMM_ROW_SIZE_MAX / SIMM_GRANULARITY; > > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_ROW_BOUNDARY_BASE) + u8_row, Is the (uint8_t) cast really needed? Otherwise please drop it. > u8_DRAMSize); > > pci_write_config8(ctrl->d0, > ((uint8_t)e_DRAM_ROW_TYPE), > u8_DRAMType); > } > > /** > * Clears a row after it has been checked for DRAM > */ > static void clear_row(const struct mem_controller* ctrl, > const uint8_t u8_row) { I think the 'const' for u8_row is not needed (not needed for integer types in general, I think). > /** > * Detects DRAM row size > */ > static void detect_size(const struct mem_controller* ctrl, > uint8_t* au8_DRAMSize, > const uint8_t u8_row) > { > uint32_t u32_AA0 = 0x0; > uint32_t u32_AA8 = 1; > uint32_t u32_DD1 = 0x55555555UL; > uint32_t u32_DD2 = 0xAAAAAAAAUL; > uint32_t u32_DD3 = 0xFEDCBA98UL; > uint32_t u32_DD4 = 0; > uint8_t u8_size_detected = 0; > uint8_t u8_type = 0; > > for(;;) { > /* Write some data */ > dimm_write32(u32_AA0, u32_DD1); > > switch (au8_DRAMSize[u8_row]) { > case e_4MB : { [...] > case e_8MB : { [...] > case e_16MB : { The code here looks pretty similar, can it be generalized in a common function? > static struct S_DRAMTechnology s_DRAMT32MB[] = { You can make this static const struct S_DRAMTechnology s_DRAMT32MB[] for structs with purely constant content. > {24, 22}, > {23, 24} > }; Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From rminnich at gmail.com Fri Aug 10 17:55:58 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 10 Aug 2007 08:55:58 -0700 Subject: [LinuxBIOS] Fwd: hypervisor in flash In-Reply-To: <13426df10708100853n1d026ene68531a861d6f28d@mail.gmail.com> References: <46BC6F64.4090008@atl.lmco.com> <13426df10708100853n1d026ene68531a861d6f28d@mail.gmail.com> Message-ID: <13426df10708100855t7f632456y246410415951855c@mail.gmail.com> So, I wish we had already done this, but we've been doing linux in flash forever; anyone out there want to make a linux-kvm payload, boot it, load windows, and show us that it's been done? It would be nice to beat Dell to the punch :-) I was actually going to do this as soon as I got a suitable mobo, but v3 has been consuming all my linuxbios cycles. thanks ron ---------- Forwarded message ---------- From: ron minnich Date: Aug 10, 2007 8:53 AM Subject: Re: hypervisor in flash To: On 8/10/07, wrote: > Neat hardware platform for linuxbios if true. > > http://arstechnica.com/news.ars/post/20070808-dell-virtualization-on-motherboards.html > From rminnich at gmail.com Fri Aug 10 18:31:28 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 10 Aug 2007 09:31:28 -0700 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <46BB9EC0.8080806@gmx.net> References: <46BB9EC0.8080806@gmx.net> Message-ID: <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> Thanks very much for this. I have a suggestion. Nowadays, for things that are pointers, even if they are not typed as such, I've taken to this style: On 8/9/07, Carl-Daniel Hailfinger wrote: > + printk(BIOS_SPEW, "base = 0x%04lx, reg = 0x%02x, value = 0x%02x\r\n", base, reg,value); vvv vvvvvvv printk(BIOS_SPEW, "base = %p, reg = 0x%02x, value = 0x%02x\r\n", (void *) base, reg,value); > + printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev), > rom_address); vvvvv printk(BIOS_DEBUG, "ROM address for %s = %p\n", dev_path(dev),(void *) rom_address); Why do this? It's actually more portable, even across plan 9 and linux. It will probably work correctly in 64 bit mode. And, that rom_address really *is* an address. I am wondering what people think of this idea. Comments? On another note, we're experimenting, for various reasons, with -fPIC mode on v3, so as to support execute-in-place. I have a question I would like to toss at some willing experimenters. If anyone is interested I will ask in this forum. Let me know. thanks again ron From peter at stuge.se Fri Aug 10 18:56:44 2007 From: peter at stuge.se (Peter Stuge) Date: Fri, 10 Aug 2007 18:56:44 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> Message-ID: <20070810165644.27699.qmail@stuge.se> On Fri, Aug 10, 2007 at 09:31:28AM -0700, ron minnich wrote: > %p > > I am wondering what people think of this idea. Comments? It's the right thing to do. Are there any drawbacks? > On another note, we're experimenting, for various reasons, with > -fPIC mode on v3, so as to support execute-in-place. I have a > question I would like to toss at some willing experimenters. If > anyone is interested I will ask in this forum. Let me know. This makes sense too. What are the drawbacks? :) //Peter From joe at smittys.pointclark.net Fri Aug 10 19:36:51 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Fri, 10 Aug 2007 13:36:51 -0400 Subject: [LinuxBIOS] strange build error Message-ID: <20070810133651.jtyh9s07ack0g0ok@simittys.pointclark.net> Getting this strange build error of the latest v2 snapshot, any clues?? ------------------------------------------------- Configuring DIR /cpu/intel/microcode/Config.lb Trying to find END on line 188: > > ^ List of nearby tokens: (@5326) HEX_NUM = '6' (@5328) ON = 'on' (@5331) END = 'end' (@5374) END = 'end' (@5380) END = 'end' (@5386) CHIP = 'chip' (@5391) PATH = 'cpu/intel/socket_PGA370' (@5417) END = 'end' (@5422) END = 'end' (@5429) EOF = '' ===> ERROR: Could not parse file rca/rm4100/Config.lb:0 mainboard/rca/rm4100/Config.lb:0 ---------------------------------------------------------- Thanks - Joe From joe at smittys.pointclark.net Fri Aug 10 19:41:15 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Fri, 10 Aug 2007 13:41:15 -0400 Subject: [LinuxBIOS] strange build error In-Reply-To: <20070810133651.jtyh9s07ack0g0ok@simittys.pointclark.net> References: <20070810133651.jtyh9s07ack0g0ok@simittys.pointclark.net> Message-ID: <20070810134115.ke8togu144kskckc@simittys.pointclark.net> Quoting Joseph Smith : > Getting this strange build error of the latest v2 snapshot, any clues?? > ------------------------------------------------- > Configuring DIR /cpu/intel/microcode/Config.lb > Trying to find END on line 188: >> > >> ^ > List of nearby tokens: > (@5326) HEX_NUM = '6' > (@5328) ON = 'on' > (@5331) END = 'end' > (@5374) END = 'end' > (@5380) END = 'end' > (@5386) CHIP = 'chip' > (@5391) PATH = 'cpu/intel/socket_PGA370' > (@5417) END = 'end' > (@5422) END = 'end' > (@5429) EOF = '' > ===> ERROR: Could not parse file > rca/rm4100/Config.lb:0 > mainboard/rca/rm4100/Config.lb:0 > ---------------------------------------------------------- > > Thanks - Joe > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > Nevermind I was missing a "end" in mainboard/rca/rm4100/Config.lb Thanks - Joe From stefan.reinauer at coresystems.de Fri Aug 10 19:42:58 2007 From: stefan.reinauer at coresystems.de (Stefan Reinauer) Date: Fri, 10 Aug 2007 19:42:58 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <20070810165644.27699.qmail@stuge.se> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <20070810165644.27699.qmail@stuge.se> Message-ID: <46BCA3A2.8000405@coresystems.de> Peter Stuge wrote:: >> On another note, we're experimenting, for various reasons, with >> -fPIC mode on v3, so as to support execute-in-place. I have a >> question I would like to toss at some willing experimenters. If >> anyone is interested I will ask in this forum. Let me know. >> > > This makes sense too. What are the drawbacks? :) > One of four registers gets permanently reserved. The code gets bigger and about 10% slower. Stefan From rminnich at gmail.com Fri Aug 10 20:02:50 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 10 Aug 2007 11:02:50 -0700 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <46BCA3A2.8000405@coresystems.de> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <20070810165644.27699.qmail@stuge.se> <46BCA3A2.8000405@coresystems.de> Message-ID: <13426df10708101102v61df8380x86681752ed8c1696@mail.gmail.com> On 8/10/07, Stefan Reinauer wrote: > > This makes sense too. What are the drawbacks? :) > > > > One of four registers gets permanently reserved. The code gets bigger > and about 10% slower. but linuxbios is infinitely fast, and hence takes 0 time. 110% * 0 is 0. Therefore I prove that it is fine :-) ron From stepan at coresystems.de Fri Aug 10 20:45:33 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Aug 2007 20:45:33 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <13426df10708101102v61df8380x86681752ed8c1696@mail.gmail.com> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <20070810165644.27699.qmail@stuge.se> <46BCA3A2.8000405@coresystems.de> <13426df10708101102v61df8380x86681752ed8c1696@mail.gmail.com> Message-ID: <46BCB24D.30707@coresystems.de> ron minnich wrote: > On 8/10/07, Stefan Reinauer wrote: > > >>> This makes sense too. What are the drawbacks? :) >>> >>> >> One of four registers gets permanently reserved. The code gets bigger >> and about 10% slower. >> > > but linuxbios is infinitely fast, and hence takes 0 time. > > 110% * 0 is 0. Therefore I prove that it is fine :-) > > ron > > The speed is no issue in an O(1) environment, sure. The size might be. Award & Co have an 8K bootblock. We're planning on going from 16 to 64k now? With tomorrows flashes getting bigger, we might not have that problem forever. -- 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 stepan at coresystems.de Fri Aug 10 21:01:40 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 10 Aug 2007 21:01:40 +0200 Subject: [LinuxBIOS] [patch 2/5] New LAR access functions In-Reply-To: <13426df10708062147v53e2dcd5tf1163e88055f5b3e@mail.gmail.com> References: <20070723160602.511777000@cosmic.amd.com> <20070723161035.445067000@cosmic.amd.com> <20070725183803.16048.qmail@stuge.se> <20070725195611.GC23932@coresystems.de> <20070725205532.4319.qmail@stuge.se> <13426df10708062147v53e2dcd5tf1163e88055f5b3e@mail.gmail.com> Message-ID: <20070810190140.GA30569@coresystems.de> * ron minnich [070807 06:47]: > Guys, this patch appears to be stuck in limbo. It is holding up the GX port. > > Did we resolve this or did it just sort of die? Can we get it worked > out? We need to jumpstart things again. go ahead and we fix it later if its broken. Feel free to beat me afterwards for it, but we need some progress: Acked-by: Stefan Reinauer -- 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 rminnich at gmail.com Fri Aug 10 21:13:48 2007 From: rminnich at gmail.com (ron minnich) Date: Fri, 10 Aug 2007 12:13:48 -0700 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <46BCB24D.30707@coresystems.de> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <20070810165644.27699.qmail@stuge.se> <46BCA3A2.8000405@coresystems.de> <13426df10708101102v61df8380x86681752ed8c1696@mail.gmail.com> <46BCB24D.30707@coresystems.de> Message-ID: <13426df10708101213l57b0a192u7c27007f68164c27@mail.gmail.com> On 8/10/07, Stefan Reinauer wrote: > Award & Co have an 8K bootblock. We're planning on going from 16 to 64k now? If Award is 8K, then we can argue that smaller bios'es suck more. I would like to take a chance on betting on flash getting bigger. I just talked to a company yesterday and they said "we can't afford to buy a smaller flash than 32 MB, so we did not worry about making our plan 9 install more compact" ron From juergen127 at kreuzholzen.de Fri Aug 10 21:33:08 2007 From: juergen127 at kreuzholzen.de (Juergen Beisert) Date: Fri, 10 Aug 2007 21:33:08 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <13426df10708101213l57b0a192u7c27007f68164c27@mail.gmail.com> References: <46BB9EC0.8080806@gmx.net> <46BCB24D.30707@coresystems.de> <13426df10708101213l57b0a192u7c27007f68164c27@mail.gmail.com> Message-ID: <200708102133.08652.juergen127@kreuzholzen.de> On Friday 10 August 2007 21:13, ron minnich wrote: > On 8/10/07, Stefan Reinauer wrote: > > Award & Co have an 8K bootblock. We're planning on going from 16 to 64k > > now? > > If Award is 8K, then we can argue that smaller bios'es suck more. > > I would like to take a chance on betting on flash getting bigger. I > just talked to a company yesterday and they said "we can't afford to > buy a smaller flash than 32 MB, so we did not worry about making our > plan 9 install more compact" Please consider not all chipsets can handle such large devices. So its sometimes not important if you can buy larger flash devices: You can't use it (on my system the BIOS window is only up to 16MiB, so how to handle 32MiB or more?). But maybe my system is too old... Juergen From segher at kernel.crashing.org Fri Aug 10 22:20:39 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Fri, 10 Aug 2007 22:20:39 +0200 Subject: [LinuxBIOS] [PATCH] LBv3: fix printk format warnings In-Reply-To: <46BCA3A2.8000405@coresystems.de> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <20070810165644.27699.qmail@stuge.se> <46BCA3A2.8000405@coresystems.de> Message-ID: <8486b47eaa5ee6cc7c29107827ceec6e@kernel.crashing.org> >>> On another note, we're experimenting, for various reasons, with >>> -fPIC mode on v3, so as to support execute-in-place. I have a >>> question I would like to toss at some willing experimenters. If >>> anyone is interested I will ask in this forum. Let me know. >> >> This makes sense too. What are the drawbacks? :) > > One of four registers gets permanently reserved. Two of eight instead of one of eight, or three of eight instead of two of eight when you have a frame pointer (but you shouldn't, it doesn't help anything). > The code gets bigger and about 10% slower. Yes. Segher From rasasi78 at gmail.com Sat Aug 11 00:26:26 2007 From: rasasi78 at gmail.com (=?UTF-8?B?UmHDumwgU8OhbmNoZXogU2lsZXM=?=) Date: Sat, 11 Aug 2007 00:26:26 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <20070806050739.GA4551@bloms.de> <20070806065821.GA5040@bloms.de> Message-ID: Dieter Bloms wrote: > Hi, > > On Sun, Aug 05, Ra?l S?nchez Siles wrote: > >> I'm sorry but I've been unable to get that info from the Dell flash >> utility. When loaded it's no chance to get any info like that. The only >> option I'm given is to reflash the BIOS again. >> >> I would be glad to test any other tool/method you propose to get the >> info. > > I use uniflash from: > > http://www.uniflash.org/ > > it tells you that info. > > I tried it, but not much successfully. It kinda work (as an app) but it didn't get the needed info. I got this: (FFFF,FFFF) Flash ROM Chip: unknown Organisation: N/A (is write protect disabled?) PCI chipset: Intel 852GM(E)/855GM(E) Last write status: not available ROM Base: FFFE0000, memory dump at FFFE0000->F0EAF0F0 I tried saving a CMOS copy (seemed to work, but no I didn't have the file later) and also a BIOS copy(same here). On this 2nd uniflash hanged (and the whole system) At first I thought it was a disk access problem but then I run uniflash, quit and the run again. The system hanged again so my BIOS should be really crappy. I don't know how much info could you extract from these lines, but I'm afraid there's little to do with this board. Thanks. -- Ra?l From lverhaegen at suse.de Fri Aug 10 23:02:42 2007 From: lverhaegen at suse.de (Luc Verhaegen) Date: Fri, 10 Aug 2007 23:02:42 +0200 Subject: [LinuxBIOS] flashrom: add board enable for epox ep-bx3 Message-ID: <20070810210242.GB23406@ridcully.suse.de> Luc Verhaegen. -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_epox_ep_bx3.diff Type: text/x-patch Size: 1347 bytes Desc: not available URL: From lverhaegen at suse.de Fri Aug 10 23:09:06 2007 From: lverhaegen at suse.de (Luc Verhaegen) Date: Fri, 10 Aug 2007 23:09:06 +0200 Subject: [LinuxBIOS] flashrom: add board enable for epox ep-bx3 In-Reply-To: <20070810210242.GB23406@ridcully.suse.de> References: <20070810210242.GB23406@ridcully.suse.de> Message-ID: <20070810210906.GC23406@ridcully.suse.de> On Fri, Aug 10, 2007 at 11:02:42PM +0200, Luc Verhaegen wrote: > Luc Verhaegen. Hrm, This version has some comments :) Luc Verhaegen. -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_epox_ep_bx3.diff Type: text/x-patch Size: 1505 bytes Desc: not available URL: From eswierk at arastra.com Sat Aug 11 03:58:06 2007 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 10 Aug 2007 18:58:06 -0700 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify Message-ID: We've been using flashrom quite successfully for months to program an SST49LF160C chip, but today we came across one flash image that flashrom kept failing to verify after writing it. When we dumped the contents of the flash after the verify, we saw that one byte at offset 0x1e5555 was getting changed from 0x4c to 0x08. I managed to narrow down the corruption to the chip probe process, when probe_28sf040() is called followed by probe_jedec(). The comments in probe_28sf040() indicate that it's trying to restore the value at offset 0 after writing probe commands to that location. But the chip interprets the write to offset 0 as the beginning of a command, and the reads and writes in the subsequent call to probe_jedec() somehow forms a write-byte command if some magic values are present in the flash (is it a coincidence that the part ID is 0x4c?). All of this sounds ridiculously unlikely, and without understanding the details of the flash protocols it's hard to know whether I'm misdiagnosing the problem. The attached patch removes the seemingly unnecessary restoring of the value at location 0 in probe_28sf040(), and indeed fixes the problem. --Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-300-flashrom-bug.patch Type: text/x-patch Size: 760 bytes Desc: not available URL: From peter at stuge.se Sat Aug 11 04:20:18 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Aug 2007 04:20:18 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <20070806050739.GA4551@bloms.de> <20070806065821.GA5040@bloms.de> Message-ID: <20070811022018.19937.qmail@stuge.se> On Sat, Aug 11, 2007 at 12:26:26AM +0200, Ra?l S?nchez Siles wrote: > > I use uniflash from: > > I tried it, but not much successfully. It kinda work (as an app) > but it didn't get the needed info. I got this: > > (FFFF,FFFF) Flash ROM Chip: unknown > Organisation: N/A (is write protect disabled?) > PCI chipset: Intel 852GM(E)/855GM(E) > Last write status: not available It does ID your chipset but it seems the flash chip is write protected with some unknown GPIO, which makes it impossible to identify or write the flash chip from software. You could perhaps identify the flash chip by visual inspection but that won't allow us to write it anyway. :\ I would really like to set up a sandbox for proprietary flashers so that we can easily learn what they are doing. > I don't know how much info could you extract from these lines, None, unfortunately. > but I'm afraid there's little to do with this board. Unless the BIOS chip is socketed and you have a way of flashing the chip outside of the system. (Using another, supported, mainboard e.g.) //Peter From peter at stuge.se Sat Aug 11 04:21:57 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Aug 2007 04:21:57 +0200 Subject: [LinuxBIOS] flashrom: add board enable for epox ep-bx3 In-Reply-To: <20070810210906.GC23406@ridcully.suse.de> References: <20070810210242.GB23406@ridcully.suse.de> <20070810210906.GC23406@ridcully.suse.de> Message-ID: <20070811022157.20229.qmail@stuge.se> On Fri, Aug 10, 2007 at 11:09:06PM +0200, Luc Verhaegen wrote: > flashrom: Add board enable for the EPOX EP-BX3. > > Signed-off-by: Luc Verhaegen Acked-by: Peter Stuge From peter at stuge.se Sat Aug 11 04:41:58 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Aug 2007 04:41:58 +0200 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: References: Message-ID: <20070811024158.23323.qmail@stuge.se> On Fri, Aug 10, 2007 at 06:58:06PM -0700, Ed Swierk wrote: > All of this sounds ridiculously unlikely, and without understanding > the details of the flash protocols it's hard to know whether I'm > misdiagnosing the problem. No, your diagnosis is correct. 1. flashrom needs to do certain writes in order to read the device ID from an SST28SF040 chip. (Although they don't seem to exist. Datasheet?) 2. When the ID fails noone knows what effect those certain writes had on the system. :\ This isn't safe. Tricky. > The attached patch removes the seemingly unnecessary restoring of > the value at location 0 in probe_28sf040(), and indeed fixes the > problem. We can't say if that restore really is neccessary or not. Erring on the side of caution would be good, but the damage may already have been done by those certain writes that are needed to do the ID. Maybe we should just not probe for 28sf040 by default? It's a really old chip. //Peter From corey.osgood at gmail.com Sat Aug 11 05:15:10 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 10 Aug 2007 23:15:10 -0400 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: <20070811022018.19937.qmail@stuge.se> References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <20070806050739.GA4551@bloms.de> <20070806065821.GA5040@bloms.de> <20070811022018.19937.qmail@stuge.se> Message-ID: <46BD29BE.9080903@gmail.com> Peter Stuge wrote: > On Sat, Aug 11, 2007 at 12:26:26AM +0200, Ra?l S?nchez Siles wrote: > >>> I use uniflash from: >>> >> I tried it, but not much successfully. It kinda work (as an app) >> but it didn't get the needed info. I got this: >> >> (FFFF,FFFF) Flash ROM Chip: unknown >> Organisation: N/A (is write protect disabled?) >> PCI chipset: Intel 852GM(E)/855GM(E) >> Last write status: not available >> > > It does ID your chipset but it seems the flash chip is write > protected with some unknown GPIO, which makes it impossible to > identify or write the flash chip from software. > I think this is a bigger problem, something to do with the ICH flash enable in flashrom. Remember G?rkan Seng?n's post: http://article.gmane.org/gmane.linux.bios/24892 Not a single ICHx board worked. I know that it's possible that _all_ of them have GPIO protection, but I have trouble believing it. I've been planning to look at it, but I simply don't have time, the cn700's eating what little I have. I think something may have gotten changed at some point that broke it, but I don't have anything to back up that theory. Can anyone report flashrom actually working on any ICH board? If so, what version and board? -Corey From joe at smittys.pointclark.net Sat Aug 11 06:58:40 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 00:58:40 -0400 Subject: [LinuxBIOS] dump spd?? Message-ID: <20070811005840.re0jq8xdwk048k0s@www.smittys.pointclark.net> Isn't there a function to dump the spd data? Thanks - Joe From joe at smittys.pointclark.net Sat Aug 11 07:46:52 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 01:46:52 -0400 Subject: [LinuxBIOS] Read SPD issue Message-ID: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> Hello, I am having a problem with raminit.c reading SPD data. When I use the smbus_read_byte function it is only returning a value of 0xFF. smbus_read_byte(ctrl->channel0[i], 2) No matter what SPD Byte I try I am just getting 0xFF. What could this be? Please help. On another note I am finally getting console output on the i82830 chipset:-) Getting closer.... Thanks - Joe From popkonserve at gmx.de Sat Aug 11 12:42:57 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 11 Aug 2007 12:42:57 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX and memory sizing In-Reply-To: <20070810135859.GC32751@greenwood> References: <46BB90A0.2050805@gmx.de> <20070810135859.GC32751@greenwood> Message-ID: <46BD92B1.8070607@gmx.de> >>the routine does the following: >>[...] > Please add this documentation to the source code as a (Doygen) comment. i don't think that this belongs into the source code. i would rather put it into a separate document that describes the general sizing algorithm. or even in a document that describes the code used for the 430FX. here is an article on memory sizing: http://www.rcollins.org/articles/memsize/MemSizing.html (please note: the MA table is different for almost every chipset :( and please ignore the bank switching stuff..) i did fix some more errors in the code btw. and beautified it to fit the coding rules. i'll post a diff or a complete version (depends on the number of changes) soon. Holger From dieter at bloms.de Sat Aug 11 12:41:29 2007 From: dieter at bloms.de (Dieter Bloms) Date: Sat, 11 Aug 2007 12:41:29 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: <46BD29BE.9080903@gmail.com> References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <20070806050739.GA4551@bloms.de> <20070806065821.GA5040@bloms.de> <20070811022018.19937.qmail@stuge.se> <46BD29BE.9080903@gmail.com> Message-ID: <20070811104129.GA24781@bloms.de> Hi, On Fri, Aug 10, Corey Osgood wrote: > Can anyone report flashrom actually working on any ICH board? If so, > what version and board? I can't flash with flashrom, but I can flash my bios with uniflash. It is a commell lv671 board. http://www.commell.com.tw/Product/SBC/LV-671.HTM -- Gru? Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Sat Aug 11 13:03:39 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 11 Aug 2007 13:03:39 +0200 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> Message-ID: <46BD978B.5000603@coresystems.de> Joseph Smith wrote: > Hello, > I am having a problem with raminit.c reading SPD data. When I use the > smbus_read_byte function it is only returning a value of 0xFF. > > smbus_read_byte(ctrl->channel0[i], 2) > > your i2c bus functions of the southbridge code don't work. -- 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 peter at stuge.se Sat Aug 11 13:35:05 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Aug 2007 13:35:05 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX and memory sizing In-Reply-To: <46BD92B1.8070607@gmx.de> References: <46BB90A0.2050805@gmx.de> <20070810135859.GC32751@greenwood> <46BD92B1.8070607@gmx.de> Message-ID: <20070811113505.10159.qmail@stuge.se> On Sat, Aug 11, 2007 at 12:42:57PM +0200, popkonserve wrote: > >>the routine does the following: > >>[...] > > Please add this documentation to the source code as a (Doygen) comment. > > i don't think that this belongs into the source code. i would > rather put it into a separate document that describes the general > sizing algorithm. I like doxygen too. > or even in a document that describes the code used for the 430FX. Well, but then we would end up with 100s of documents like that.. Of course, any documentation effort on the wiki would be most welcome, but that's a whole new project in itself... //Peter From popkonserve at gmx.de Sat Aug 11 15:49:28 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 11 Aug 2007 15:49:28 +0200 Subject: [LinuxBIOS] RAM detection for Intel 430FX and memory sizing In-Reply-To: <20070811113505.10159.qmail@stuge.se> References: <46BB90A0.2050805@gmx.de> <20070810135859.GC32751@greenwood> <46BD92B1.8070607@gmx.de> <20070811113505.10159.qmail@stuge.se> Message-ID: <46BDBE68.7050901@gmx.de> i tried another approach, looks way nicer now. any comments? let me know :) Holger /* IN RAMINIT.H */ enum E_DRAM_TYPE { DRT_SYMMETRIC = 0, DRT_ASYMMETRIC = 1 }; struct S_DRAMTechnology { uint8_t row_address; uint8_t column_address; uint16_t row_size; enum E_DRAM_TYPE type; }; static const struct S_DRAMTechnology dram_technology[] = { { 0, 24, 32, DRT_SYMMETRIC}, {24, 22, 32, DRT_ASYMMETRIC}, {23, 22, 16, DRT_ASYMMETRIC}, { 0, 22, 8, DRT_SYMMETRIC}, {21, 11, 4, DRT_ASYMMETRIC}, { 0, 0, 0, DRT_SYMMETRIC} }; /* IN RAMINIT.C */ static void detect_size(const struct mem_controller* ctrl, uint8_t* dram_size, const uint8_t row) { uint32_t address0 = 0x0; uint32_t address8 = 1; uint32_t data1 = 0x55555555UL; uint32_t data2 = 0xAAAAAAAAUL; uint32_t data3 = 0xFEDCBA98UL; uint32_t data4 = 0; uint8_t detected = 0; uint8_t index = 0; do { /* FIXME: Not sure if this is really needed */ pci_write_config8(ctrl->d0, CR_DRAM_ROW_BOUNDARY_BASE + row, dram_technology[index].row_size / SIMM_GRANULARITY); /* Write some data */ dimm_write32(address0, data1); /* Prepare the first address */ address8 = (1 << dram_technology[index].column_address); /* Write some more data */ dimm_write32(address8, data2); /* Write even more data to yet another address for asymmetric DRAM */ if(dram_technology[index].type == DRT_ASYMMETRIC) { /* Prepare the second address */ address8 = (1 << dram_technology[index].row_address); /* Write even more data */ dimm_write32(address8, data3); } /* Read data back */ dimm_read32(address0, data4); if(data1 == data4) { /* Found DRAM with correct size and technology */ dram_size[row] = dram_technology[index].row_address / SIMM_GRANULARITY; detected = 1; break; } else { /* No RAM found yet. Try next addressing scheme. */ index++; } } while(detected == 0 || dram_technology[index].row_size != 0); if(detected == 0) { dram_size[row] = DRAM_EMPTY; } } From rmh at aybabtu.com Sat Aug 11 17:47:37 2007 From: rmh at aybabtu.com (Robert Millan) Date: Sat, 11 Aug 2007 17:47:37 +0200 Subject: [LinuxBIOS] hardware donation Message-ID: <20070811154737.GA13604@aragorn> Hi! Do you accept hardware donations? I have 3 spare (different) boards that are not supported and I don't have the time/skill to get them running. I would gladly donate them if that helps the linuxbios project. - MSI MS-6567 (SiS chipset. flashrom unsupported) - QDI Legend V (Intel 440LX. flashrom OK) - Unidentified vendor (Intel 440BX. flashrom unsupported) The bios rom of the latter one looks quite hard to unsolder. The other two are also soldered but look much more doable. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From popkonserve at gmx.de Sat Aug 11 18:08:44 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 11 Aug 2007 18:08:44 +0200 Subject: [LinuxBIOS] hardware donation In-Reply-To: <20070811154737.GA13604@aragorn> References: <20070811154737.GA13604@aragorn> Message-ID: <46BDDF0C.5080106@gmx.de> Hi Robert, i guess hardware donations are accepted but i don't know who's taking care of the 'distribution'. it only makes sense to me if the shipping costs wouldn't be too high (e.g. donate to someone living in your country). Please let us know where you are from so that we can find someone living somewhere near you. this is for all the others here, too: i've smd (de-)soldering equipment (hot air and pencil soldering iron) and good normal soldering equipment at home. i've been doing professional smd finepitch work for 3 years..just if someone would need some mainboard or bios fixed or a piggyback dual-bios. just keep in mind that i live in germany, so it wouldn't make any sense to send something over from the u.s. i guess :) Holger From joe at smittys.pointclark.net Sat Aug 11 18:52:54 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 12:52:54 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <46BD978B.5000603@coresystems.de> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> Message-ID: <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> Quoting Stefan Reinauer : > Joseph Smith wrote: >> Hello, >> I am having a problem with raminit.c reading SPD data. When I use the >> smbus_read_byte function it is only returning a value of 0xFF. >> >> smbus_read_byte(ctrl->channel0[i], 2) >> >> > your i2c bus functions of the southbridge code don't work. > > Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx src code. Corey, mabe you could shed some light on this?? Here is my serial console output, where it says "SPD is ff, ff, ff, ff" I just tried a bunch of different SPD bytes to see the return values. LinuxBIOS-2.0.0.0Fallback Sat Aug 11 01:30:14 EDT 2007 starting... Setting Initial Registers.... Initial registers have been set. SPD is ff, ff, ff, ff No DIMM found in slot 00, Setting DRA to 0xFF DRA 70 has been set to ff SPD is ff, ff, ff, ff No DIMM found in slot 01, Setting DRA to 0xFF DRA 71 has been set to ff RAM Enable 1: Apply NOP Sending RAM command 0x00000010 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x00000020 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x000000 RAM Enable 4: Mode register set Sending RAM command 0x00000030 to 0x00000000 RAM Enable 5: Normal operation Sending RAM command 0x20000170 to 0x00000000 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 75 35 06 00 10 20 04 00 00 06 00 00 00 00 10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e 50: 72 a0 00 00 00 00 00 00 00 30 33 33 33 33 33 60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00 70: ff ff ff ff 00 00 00 00 10 00 00 00 70 01 00 20 80: 00 00 00 00 00 00 00 00 00 70 d7 d4 00 00 00 00 90: 02 38 00 01 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00 f0: 11 11 01 00 00 00 0d 05 37 d6 30 d3 1f cf 1e Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. SMBus controller enabled Thanks - Joe From svn at openbios.org Sat Aug 11 18:59:11 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 11 Aug 2007 18:59:11 +0200 Subject: [LinuxBIOS] r2743 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-08-11 18:59:11 +0200 (Sat, 11 Aug 2007) New Revision: 2743 Modified: trunk/util/flashrom/README trunk/util/flashrom/board_enable.c Log: flashrom: Add board enable for the EPoX EP-BX3. Signed-off-by: Luc Verhaegen Acked-by: Peter Stuge Acked-by: Uwe Hermann Modified: trunk/util/flashrom/README =================================================================== --- trunk/util/flashrom/README 2007-07-27 03:32:45 UTC (rev 2742) +++ trunk/util/flashrom/README 2007-08-11 16:59:11 UTC (rev 2743) @@ -54,6 +54,7 @@ * Agami Aruma: use -m AGAMI:ARUMA * ASUS P5A: use -m asus:p5a * IBM x3455: use -m ibm:x3455 +* EPoX EP-BX3: use -m epox:ep-bx3 ROM Layout Support Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2007-07-27 03:32:45 UTC (rev 2742) +++ trunk/util/flashrom/board_enable.c 2007-08-11 16:59:11 UTC (rev 2743) @@ -261,6 +261,25 @@ return 0; } +/** + * Suited for EPoX EP-BX3, and maybe some other Intel 440BX based boards. + */ +static int board_epox_ep_bx3(const char *name) +{ + uint8_t tmp; + + /* Raise GPIO22. */ + tmp = inb(0x4036); + outb(tmp, 0xEB); + + tmp |= 0x40; + + outb(tmp, 0x4036); + outb(tmp, 0xEB); + + return 0; +} + /* * We use 2 sets of ids here, you're free to choose which is which. This * to provide a very high degree of certainty when matching a board on @@ -309,6 +328,8 @@ "asus", "p5a", "ASUS P5A", board_asus_p5a}, {0x1166, 0x0205, 0x1014, 0x0347, 0x0000, 0x0000, 0x0000, 0x0000, "ibm", "x3455", "IBM x3455", board_ibm_x3455}, + {0x8086, 0x7110, 0x0000, 0x0000, 0x8086, 0x7190, 0x0000, 0x0000, + "epox", "ep-bx3", "EPoX EP-BX3", board_epox_ep_bx3}, {0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL} /* Keep this */ }; From uwe at hermann-uwe.de Sat Aug 11 19:00:17 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sat, 11 Aug 2007 19:00:17 +0200 Subject: [LinuxBIOS] flashrom: add board enable for epox ep-bx3 In-Reply-To: <20070811022157.20229.qmail@stuge.se> References: <20070810210242.GB23406@ridcully.suse.de> <20070810210906.GC23406@ridcully.suse.de> <20070811022157.20229.qmail@stuge.se> Message-ID: <20070811170017.GB9418@greenwood> On Sat, Aug 11, 2007 at 04:21:57AM +0200, Peter Stuge wrote: > On Fri, Aug 10, 2007 at 11:09:06PM +0200, Luc Verhaegen wrote: > > flashrom: Add board enable for the EPOX EP-BX3. > > > > Signed-off-by: Luc Verhaegen > > Acked-by: Peter Stuge Yep, looks good, committed in r2743 with some coding style fixes. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From info at coresystems.de Sat Aug 11 19:03:38 2007 From: info at coresystems.de (LinuxBIOS information) Date: Sat, 11 Aug 2007 19:03:38 +0200 Subject: [LinuxBIOS] r2743 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2743 to the LinuxBIOS source repository and caused the following changes: Change Log: flashrom: Add board enable for the EPoX EP-BX3. Signed-off-by: Luc Verhaegen Acked-by: Peter Stuge Acked-by: Uwe Hermann Build Log: Compilation of agami:aruma has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=aruma&vendor=agami Compilation of amd:db800 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=db800&vendor=amd Compilation of amd:norwich has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=norwich&vendor=amd Compilation of amd:rumba has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=rumba&vendor=amd Compilation of amd:serengeti_cheetah has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=serengeti_cheetah&vendor=amd Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=hdama&vendor=arima Compilation of artecgroup:dbe61 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=dbe61&vendor=artecgroup Compilation of asi:mb_5blmp has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=mb_5blmp&vendor=asi Compilation of asus:a8n_e has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=a8n_e&vendor=asus Compilation of asus:mew-vm has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=mew-vm&vendor=asus Compilation of asus:p2b has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=p2b&vendor=asus Compilation of bitworks:ims has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=ims&vendor=bitworks Compilation of broadcom:blast has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=blast&vendor=broadcom Compilation of dell:s1850 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s1850&vendor=dell Compilation of digitallogic:adl855pc has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=adl855pc&vendor=digitallogic Compilation of digitallogic:msm586seg has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=msm586seg&vendor=digitallogic Compilation of digitallogic:msm800sev has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=msm800sev&vendor=digitallogic Compilation of eaglelion:5bcm has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=5bcm&vendor=eaglelion Compilation of emulation:qemu-i386 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=qemu-i386&vendor=emulation Compilation of gigabyte:m57sli has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=m57sli&vendor=gigabyte Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=juki-511p&vendor=iei Compilation of iei:nova4899r has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=nova4899r&vendor=iei Compilation of intel:jarrell has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=jarrell&vendor=intel Compilation of intel:xe7501devkit has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=xe7501devkit&vendor=intel Compilation of iwill:dk8_htx has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=dk8_htx&vendor=iwill Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=dk8x&vendor=iwill Compilation of lippert:frontrunner has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=frontrunner&vendor=lippert Compilation of msi:ms9185 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=ms9185&vendor=msi Compilation of msi:ms9282 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=ms9282&vendor=msi Compilation of newisys:khepri has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=khepri&vendor=newisys Compilation of nvidia:l1_2pvv has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=l1_2pvv&vendor=nvidia Compilation of olpc:btest has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=btest&vendor=olpc Compilation of olpc:rev_a has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=rev_a&vendor=olpc Compilation of sunw:ultra40 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=ultra40&vendor=sunw Compilation of supermicro:h8dmr has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=h8dmr&vendor=supermicro Compilation of supermicro:x6dai_g has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=x6dai_g&vendor=supermicro Compilation of supermicro:x6dhe_g has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=x6dhe_g&vendor=supermicro Compilation of supermicro:x6dhe_g2 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=x6dhe_g2&vendor=supermicro Compilation of supermicro:x6dhr_ig has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=x6dhr_ig&vendor=supermicro Compilation of supermicro:x6dhr_ig2 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=x6dhr_ig2&vendor=supermicro Compilation of technologic:ts5300 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=ts5300&vendor=technologic Compilation of tyan:s1846 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s1846&vendor=tyan Compilation of tyan:s2735 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2735&vendor=tyan Compilation of tyan:s2850 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2850&vendor=tyan Compilation of tyan:s2875 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2875&vendor=tyan Compilation of tyan:s2880 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2880&vendor=tyan Compilation of tyan:s2881 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2881&vendor=tyan Compilation of tyan:s2882 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2882&vendor=tyan Compilation of tyan:s2885 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2885&vendor=tyan Compilation of tyan:s2891 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2891&vendor=tyan Compilation of tyan:s2892 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2892&vendor=tyan Compilation of tyan:s2895 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2895&vendor=tyan Compilation of tyan:s2912 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s2912&vendor=tyan Compilation of tyan:s4880 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s4880&vendor=tyan Compilation of tyan:s4882 has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=s4882&vendor=tyan Compilation of via:epia has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=epia&vendor=via Compilation of via:epia-m has been broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2743&device=epia-m&vendor=via If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From stepan at coresystems.de Sat Aug 11 19:17:10 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 11 Aug 2007 19:17:10 +0200 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> Message-ID: <20070811171710.GA15184@coresystems.de> * Joseph Smith [070811 18:52]: > Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx > src code. > Corey, mabe you could shed some light on this?? Here is my serial > console output, where it says "SPD is ff, ff, ff, ff" I just tried a > bunch of different SPD bytes to see the return values. Hm. maybe the spd roms are on a different position then. I think Corey's code is known to work. They're usually at 0x50...0x53 but that may be different on any other board. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From rmh at aybabtu.com Sat Aug 11 20:02:09 2007 From: rmh at aybabtu.com (Robert Millan) Date: Sat, 11 Aug 2007 20:02:09 +0200 Subject: [LinuxBIOS] hardware donation In-Reply-To: <46BDDF0C.5080106@gmx.de> References: <20070811154737.GA13604@aragorn> <46BDDF0C.5080106@gmx.de> Message-ID: <20070811180209.GA18165@aragorn> On Sat, Aug 11, 2007 at 06:08:44PM +0200, popkonserve wrote: > Hi Robert, > i guess hardware donations are accepted but i don't know who's taking > care of the 'distribution'. it only makes sense to me if the shipping > costs wouldn't be too high (e.g. donate to someone living in your > country). Please let us know where you are from so that we can find > someone living somewhere near you. I live in southern Europe (Barcelona). International (even overseas) shipping shouldn't be a problem but in that case it would be preferred if all boards are sent in the same package (either for the same developer of for local redistribution), because costs are much more per-package than per-weight. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From svn at openbios.org Sat Aug 11 20:38:24 2007 From: svn at openbios.org (svn at openbios.org) Date: Sat, 11 Aug 2007 20:38:24 +0200 Subject: [LinuxBIOS] r466 - in LinuxBIOSv3: arch/x86 device lib northbridge/intel/i440bxemulation superio/winbond/w83627hf util/x86emu Message-ID: Author: stepan Date: 2007-08-11 20:38:24 +0200 (Sat, 11 Aug 2007) New Revision: 466 Modified: LinuxBIOSv3/arch/x86/linuxbios_table.c LinuxBIOSv3/device/device.c LinuxBIOSv3/device/device_util.c LinuxBIOSv3/device/pci_device.c LinuxBIOSv3/device/pci_rom.c LinuxBIOSv3/device/pnp_device.c LinuxBIOSv3/lib/elfboot.c LinuxBIOSv3/northbridge/intel/i440bxemulation/i440bx.c LinuxBIOSv3/superio/winbond/w83627hf/superio.c LinuxBIOSv3/util/x86emu/vm86.c Log: This patch removes all printk format warnings from my LBv3 build (Qemu x86 config). This was tested with gcc 4.1.0 on x86 and gcc 4.2.1 on x86_64. Signed-off-by: Carl-Daniel Hailfinger Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/linuxbios_table.c =================================================================== --- LinuxBIOSv3/arch/x86/linuxbios_table.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/arch/x86/linuxbios_table.c 2007-08-11 18:38:24 UTC (rev 466) @@ -177,8 +177,8 @@ { int entries; - printk(BIOS_DEBUG, "%s: start 0x%lx size 0x%lx\n", - __func__, (u32)start, (u32)size); + printk(BIOS_DEBUG, "%s: start 0x%Lx size 0x%Lx\n", + __func__, start, size); entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); mem->map[entries].start = pack_lb64(start); @@ -231,7 +231,7 @@ head->table_checksum = compute_ip_checksum(first_rec, head->table_bytes); head->header_checksum = 0; head->header_checksum = compute_ip_checksum(head, sizeof(*head)); - printk(BIOS_DEBUG,"Wrote LinuxBIOS table at: %p - %p checksum %lx\n", + printk(BIOS_DEBUG,"Wrote LinuxBIOS table at: %p - %p checksum %x\n", head, rec, head->table_checksum); return (unsigned long)rec; } @@ -243,8 +243,8 @@ entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); printk(BIOS_DEBUG, "%s: # entries %d\n", __func__, entries); for(i = 0; i < entries; i++) - printk(BIOS_INFO, " #%d: base 0x%x size 0x%x\n", - i, (u32)mem->map[i].start.lo, mem->map[i].size.lo); + printk(BIOS_INFO, " #%d: base 0x%08x size 0x%x\n", + i, mem->map[i].start.lo, mem->map[i].size.lo); /* Sort the lb memory ranges */ for(i = 0; i < entries; i++) { Modified: LinuxBIOSv3/device/device.c =================================================================== --- LinuxBIOSv3/device/device.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/device/device.c 2007-08-11 18:38:24 UTC (rev 466) @@ -130,10 +130,10 @@ int i; printk(BIOS_SPEW, "%s: find %s\n", __func__, dev_id_string(id)); for (i = 0; all_constructors[i]; i++) { - printk(BIOS_SPEW, "%s: check all_constructors[i] 0x%lx\n", + printk(BIOS_SPEW, "%s: check all_constructors[i] %p\n", __func__, all_constructors[i]); for (c = all_constructors[i]; c->ops; c++) { - printk(BIOS_SPEW, "%s: cons 0x%lx, cons id %s\n", + printk(BIOS_SPEW, "%s: cons %p, cons id %s\n", __func__, c, dev_id_string(&c->id)); if ((!c->ops) || (!c->ops->constructor)) { continue; @@ -164,7 +164,7 @@ struct constructor *c; c = find_constructor(id); - printk(BIOS_SPEW, "%s: constructor is 0x%lx\n", __func__, c); + printk(BIOS_SPEW, "%s: constructor is %p\n", __func__, c); if(c && c->ops && c->ops->constructor) c->ops->constructor(dev, c); @@ -485,7 +485,7 @@ base += size; printk(BIOS_SPEW, - "%s %02x * [0x%08Lx - 0x%08Lx] %s\n", + "%s %02lx * [0x%08Lx - 0x%08Lx] %s\n", dev_path(dev), resource->index, resource->base, Modified: LinuxBIOSv3/device/device_util.c =================================================================== --- LinuxBIOSv3/device/device_util.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/device/device_util.c 2007-08-11 18:38:24 UTC (rev 466) @@ -602,7 +602,7 @@ #endif } printk(BIOS_DEBUG, - "%s %02x <- [0x%010Lx - 0x%010Lx] %s%s%s\n", + "%s %02lx <- [0x%010Lx - 0x%010Lx] %s%s%s\n", dev_path(dev), resource->index, base, end, buf, resource_type(resource), comment); @@ -643,7 +643,7 @@ resource_search_t search, void *gp) { struct device *curdev; - printk(BIOS_SPEW, "%s: mask %x type %x \n", __func__, type_mask, type); + printk(BIOS_SPEW, "%s: mask %lx type %lx \n", __func__, type_mask, type); for (curdev = all_devices; curdev; curdev = curdev->next) { int i; printk(BIOS_SPEW, @@ -656,9 +656,9 @@ for (i = 0; i < curdev->resources; i++) { struct resource *resource = &curdev->resource[i]; printk(BIOS_SPEW, - "%s: dev %s, resource %d, flags %x base 0x%lx size 0x%lx\n", + "%s: dev %s, resource %d, flags %lx base 0x%Lx size 0x%Lx\n", __func__, curdev->dtsname, i, resource->flags, - (u32) resource->base, (u32) resource->size); + resource->base, resource->size); /* If it isn't the right kind of resource ignore it. */ if ((resource->flags & type_mask) != type) { continue; Modified: LinuxBIOSv3/device/pci_device.c =================================================================== --- LinuxBIOSv3/device/pci_device.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/device/pci_device.c 2007-08-11 18:38:24 UTC (rev 466) @@ -210,7 +210,7 @@ if (moving == 0) { if (value != 0) { printk(BIOS_DEBUG, - "%s register %02x(%08x), read-only ignoring it\n", + "%s register %02lx(%08lx), read-only ignoring it\n", dev_path(dev), index, value); } resource->flags = 0; @@ -309,7 +309,7 @@ if (moving == 0) { if (value != 0) { printk(BIOS_DEBUG, - "%s register %02x(%08x), read-only ignoring it\n", + "%s register %02lx(%08lx), read-only ignoring it\n", dev_path(dev), index, value); } resource->flags = 0; @@ -456,7 +456,7 @@ /* Make certain the resource has actually been set. */ if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk(BIOS_ERR, - "ERROR: %s %02x %s size: 0x%010Lx not assigned\n", + "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", dev_path(dev), resource->index, resource_type(resource), resource->size); return; @@ -537,7 +537,7 @@ } else { /* Don't let me think I stored the resource. */ resource->flags &= ~IORESOURCE_STORED; - printk(BIOS_ERR, "ERROR: invalid resource->index %x\n", + printk(BIOS_ERR, "ERROR: invalid resource->index %lx\n", resource->index); } report_resource_stored(dev, resource, ""); Modified: LinuxBIOSv3/device/pci_rom.c =================================================================== --- LinuxBIOSv3/device/pci_rom.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/device/pci_rom.c 2007-08-11 18:38:24 UTC (rev 466) @@ -47,7 +47,7 @@ return NULL; } - printk(BIOS_DEBUG, "ROM address for %s = %x\n", dev_path(dev), + printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev), rom_address); if (!dev->on_mainboard) { @@ -131,7 +131,7 @@ return NULL; // Only one VGA supported. #endif printk(BIOS_DEBUG, - "Copying VGA ROM image from 0x%x to 0x%x, 0x%x bytes\n", + "Copying VGA ROM image from %p to 0x%x, 0x%x bytes\n", rom_header, PCI_VGA_RAM_IMAGE_START, rom_size); memcpy((void *)PCI_VGA_RAM_IMAGE_START, rom_header, rom_size); vga_inited = 1; @@ -139,7 +139,7 @@ #endif } else { printk(BIOS_DEBUG, - "Copying non-VGA ROM image from 0x%x to 0x%x, 0x%x bytes\n", + "Copying non-VGA ROM image from %p to %p, 0x%x bytes\n", rom_header, pci_ram_image_start, rom_size); memcpy(pci_ram_image_start, rom_header, rom_size); pci_ram_image_start += rom_size; Modified: LinuxBIOSv3/device/pnp_device.c =================================================================== --- LinuxBIOSv3/device/pnp_device.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/device/pnp_device.c 2007-08-11 18:38:24 UTC (rev 466) @@ -87,7 +87,7 @@ { if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk(BIOS_ERR, - "ERROR: %s %02x %s size: 0x%010Lx not assigned\n", + "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", dev_path(dev), resource->index, resource_type(resource), resource->size); return; @@ -101,7 +101,7 @@ } else if (resource->flags & IORESOURCE_IRQ) { pnp_set_irq(dev, resource->index, resource->base); } else { - printk(BIOS_ERR, "ERROR: %s %02x unknown resource type\n", + printk(BIOS_ERR, "ERROR: %s %02lx unknown resource type\n", dev_path(dev), resource->index); return; } Modified: LinuxBIOSv3/lib/elfboot.c =================================================================== --- LinuxBIOSv3/lib/elfboot.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/lib/elfboot.c 2007-08-11 18:38:24 UTC (rev 466) @@ -36,14 +36,14 @@ #include static int valid_area(struct lb_memory *mem, - unsigned long start, unsigned long len) + u64 start, u64 len) { /* Check through all of the memory segments and ensure * the segment that was passed in is completely contained * in RAM. */ int i; - unsigned long end = start + len; + u64 end = start + len; unsigned long mem_entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); /* Walk through the table of valid memory ranges and see if I @@ -61,7 +61,7 @@ } if (i == mem_entries) { printk(BIOS_ERR, "No matching RAM area found for range:\n"); - printk(BIOS_ERR, " [0x%016lx, 0x%016lx)\n", start, end); + printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx)\n", start, end); printk(BIOS_ERR, "RAM areas\n"); for(i = 0; i < mem_entries; i++) { u64 mstart, mend; @@ -69,10 +69,8 @@ mtype = mem->map[i].type; mstart = unpack_lb64(mem->map[i].start); mend = mstart + unpack_lb64(mem->map[i].size); - printk(BIOS_ERR, " [0x%016lx, 0x%016lx) %s\n", - (unsigned long)mstart, - (unsigned long)mend, - (mtype == LB_MEM_RAM)?"RAM":"Reserved"); + printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx) %s\n", + mstart, mend, (mtype == LB_MEM_RAM)?"RAM":"Reserved"); } return 0; @@ -101,14 +99,14 @@ printk(BIOS_DEBUG, "Dropping empty segment\n"); continue; } - printk(BIOS_DEBUG, "New segment addr 0x%lx size 0x%lx offset 0x%lx filesize 0x%lx\n", + printk(BIOS_DEBUG, "New segment addr 0x%x size 0x%x offset 0x%x filesize 0x%x\n", phdr[i].p_paddr, phdr[i].p_memsz, phdr[i].p_offset, phdr[i].p_filesz); /* Clean up the values */ size = phdr[i].p_filesz; if (phdr[i].p_filesz > phdr[i].p_memsz) { size = phdr[i].p_memsz; } - printk(BIOS_DEBUG, "(cleaned up) New segment addr 0x%lx size 0x%lx offset 0x%lx\n", + printk(BIOS_DEBUG, "(cleaned up) New segment addr 0x%x size 0x%x offset 0x%x\n", phdr[i].p_paddr, size, phdr[i].p_offset); /* Verify the memory addresses in the segment are valid */ @@ -150,7 +148,7 @@ /* what the hell is boot_successful? */ //boot_successful(); - printk(BIOS_DEBUG, "Jumping to boot code at 0x%x\n", entry); + printk(BIOS_DEBUG, "Jumping to boot code at %p\n", entry); post_code(0xfe); /* Jump to kernel */ Modified: LinuxBIOSv3/northbridge/intel/i440bxemulation/i440bx.c =================================================================== --- LinuxBIOSv3/northbridge/intel/i440bxemulation/i440bx.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/northbridge/intel/i440bxemulation/i440bx.c 2007-08-11 18:38:24 UTC (rev 466) @@ -79,7 +79,7 @@ resource->size = ((resource_t) sizek) << 10; resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE | IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; - printk(BIOS_DEBUG, "%s: add ram resoource %d bytes\n", __func__, + printk(BIOS_DEBUG, "%s: add ram resoource %Ld bytes\n", __func__, resource->size); } Modified: LinuxBIOSv3/superio/winbond/w83627hf/superio.c =================================================================== --- LinuxBIOSv3/superio/winbond/w83627hf/superio.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/superio/winbond/w83627hf/superio.c 2007-08-11 18:38:24 UTC (rev 466) @@ -45,13 +45,13 @@ outb(0xaa, dev->path.u.pnp.port); } -static void pnp_write_index(unsigned long port_base, u8 reg, u8 value) +static void pnp_write_index(u16 port_base, u8 reg, u8 value) { outb(reg, port_base); outb(value, port_base + 1); } -static u8 pnp_read_index(unsigned long port_base, u8 reg) +static u8 pnp_read_index(u16 port_base, u8 reg) { outb(reg, port_base); return inb(port_base + 1); @@ -83,7 +83,7 @@ pnp_exit_ext_func_mode(dev); } -static void init_hwm(unsigned long base) +static void init_hwm(u16 base) { u8 reg, value; int i; Modified: LinuxBIOSv3/util/x86emu/vm86.c =================================================================== --- LinuxBIOSv3/util/x86emu/vm86.c 2007-08-10 13:48:59 UTC (rev 465) +++ LinuxBIOSv3/util/x86emu/vm86.c 2007-08-11 18:38:24 UTC (rev 466) @@ -543,14 +543,14 @@ eax, ebx, ecx, edx); printk(BIOS_DEBUG, "biosint: ebp 0x%lx esp 0x%lx edi 0x%lx esi 0x%lx\n", ebp, esp, edi, esi); - printk(BIOS_DEBUG, "biosint: ip 0x%x cs 0x%x flags 0x%x\n", + printk(BIOS_DEBUG, "biosint: ip 0x%lx cs 0x%lx flags 0x%lx\n", ip, cs, flags); // cases in a good compiler are just as good as your own tables. switch (intnumber) { case 0 ... 15: // These are not BIOS service, but the CPU-generated exceptions - printk(BIOS_INFO, "biosint: Oops, exception %u\n", intnumber); + printk(BIOS_INFO, "biosint: Oops, exception %lu\n", intnumber); if (esp < 0x1000) { printk(BIOS_DEBUG, "Stack contents: "); while (esp < 0x1000) { @@ -578,7 +578,7 @@ &ebx, &edx, &ecx, &eax, &flags); break; default: - printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%x\n", + printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%lx\n", intnumber); break; } From joe at smittys.pointclark.net Sat Aug 11 21:59:35 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 15:59:35 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811171710.GA15184@coresystems.de> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> Message-ID: <20070811155935.1u8r6p6qqswwws0c@www.smittys.pointclark.net> Quoting Stefan Reinauer : > * Joseph Smith [070811 18:52]: >> Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx >> src code. >> Corey, mabe you could shed some light on this?? Here is my serial >> console output, where it says "SPD is ff, ff, ff, ff" I just tried a >> bunch of different SPD bytes to see the return values. > > Hm. maybe the spd roms are on a different position then. I think Corey's > code is known to work. They're usually at 0x50...0x53 but that may be > different on any other board. > > > How would I go about finding out what it is on my board?? Thanks - Joe From corey.osgood at gmail.com Sat Aug 11 22:04:11 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 11 Aug 2007 16:04:11 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811171710.GA15184@coresystems.de> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> Message-ID: <46BE163B.20907@gmail.com> Stefan Reinauer wrote: > * Joseph Smith [070811 18:52]: > >> Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx >> src code. >> Corey, mabe you could shed some light on this?? Here is my serial >> console output, where it says "SPD is ff, ff, ff, ff" I just tried a >> bunch of different SPD bytes to see the return values. >> > > Hm. maybe the spd roms are on a different position then. I think Corey's > code is known to work. They're usually at 0x50...0x53 but that may be > different on any other board. Yeah, the code works for me, and was a hack up of the other 82801s, so it should work for just about any. Can you do me a favor and check that the smbus device is located at device 0x1f (ie 31) function 3? That was one big assumption I made, I checked most of the datasheets but not all of them, and datasheets do lie. I did throw in a check just as a failsafe, but that may not have worked either. Also check your factory bios's smbus IO base, it should be programmed at d31f3 rx20-21, and will have an extra 1 at the end. If that's not 0x0f00, then try plugging it in as SMBUS_IO_BASE in i82801xx.h. The current code also makes no attempt to do give any sort of warning if an smbus timeout/error occurs. It was something that I wanted to do, but other things came up. You could probably drop in some debugging info there, as the functions already do return negative values in case of an error. The other thought is, run smbus_enable before enabling serial/console, and also try to force a full smbus dump using the debug.c that I left in with the i82810 (oops, meant to move that). It may be that your smbus needs a little time to initialize, if you're smbus dump starts pulling good values after the first few transactions, this is the case. It it is, let me know and I can take care of it, and for the time being just do an smbus dump before attempting to do ram init. Last thought is, make sure your dimm actually has spd. I've never seen a dimm that didn't, but that doesn't mean they don't exist, especially with older sdram, and doesn't that board use so-dimms? lm_sensors dimms-detect.pl should be able to tell you if there is spd info to be found, and also the location of the spd. If I get some time, create a little program to dump the spd info from userspace, but dimms-detect.pl already does pretty much the same thing, except it translates it into dimm info (which is quite annoying if that's not what you want). Good luck! Corey From joe at smittys.pointclark.net Sat Aug 11 22:54:24 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 16:54:24 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <46BE163B.20907@gmail.com> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> Message-ID: <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> Quoting Corey Osgood : > Stefan Reinauer wrote: >> * Joseph Smith [070811 18:52]: >> >>> Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx >>> src code. >>> Corey, mabe you could shed some light on this?? Here is my serial >>> console output, where it says "SPD is ff, ff, ff, ff" I just tried a >>> bunch of different SPD bytes to see the return values. >>> >> >> Hm. maybe the spd roms are on a different position then. I think Corey's >> code is known to work. They're usually at 0x50...0x53 but that may be >> different on any other board. > > Yeah, the code works for me, and was a hack up of the other 82801s, so > it should work for just about any. Can you do me a favor and check that > the smbus device is located at device 0x1f (ie 31) function 3? That was > one big assumption I made, I checked most of the datasheets but not all > of them, and datasheets do lie. I did throw in a check just as a > failsafe, but that may not have worked either. Also check your factory > bios's smbus IO base, it should be programmed at d31f3 rx20-21, and will > have an extra 1 at the end. If that's not 0x0f00, then try plugging it > in as SMBUS_IO_BASE in i82801xx.h. > Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3 > The current code also makes no attempt to do give any sort of warning if > an smbus timeout/error occurs. It was something that I wanted to do, but > other things came up. You could probably drop in some debugging info > there, as the functions already do return negative values in case of an > error. The other thought is, run smbus_enable before enabling > serial/console, and also try to force a full smbus dump using the > debug.c that I left in with the i82810 (oops, meant to move that). It > may be that your smbus needs a little time to initialize, if you're > smbus dump starts pulling good values after the first few transactions, > this is the case. It it is, let me know and I can take care of it, and > for the time being just do an smbus dump before attempting to do ram init. > How would I call debug.c and from what file? I noticed in auto.c there is a dump_spd_registers(&memctrl[0]); commented out. Could I try this to dump the SPD data?? Thanks - Joe From Richard.Wilson at senokian.com Sat Aug 11 23:08:38 2007 From: Richard.Wilson at senokian.com (Richard Wilson) Date: Sat, 11 Aug 2007 22:08:38 +0100 Subject: [LinuxBIOS] RD1-PL - Am I having a laugh trying to find one? Message-ID: <46BE2556.5060807@senokian.com> Hullo all, I'm looking at playing round with LB on an EPIA MII-12000, but I don't so much like the idea of bricking the thing. From the documentation on the website, and from watching the mailing lists, it seems that an RD1-PL is the best way to avoid this. From the mailing list archives and my own research, it seems finding one of the things is likely to be the hardest part of the entire endeavour. The only place on the entire 'where to buy' list on the manufacturer website that seems to have any in stock, is in German, and even with the help of Google Translate, I'm a bit lost trying to work my way round the site. Does anyone know of anywhere that might have one? I don't mind buying from pretty much any country in Europe or America, if I can only find one! Alternatively, maybe someone bought a few, and would be prepared to sell me one? Heck, I'd even buy two and donate one to the project, if that would do some good. Anyone? Richard W From joe at smittys.pointclark.net Sun Aug 12 04:04:23 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 11 Aug 2007 22:04:23 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> Message-ID: <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> Quoting Joseph Smith : > Quoting Corey Osgood : > >> >> Can you do me a favor and check that >> the smbus device is located at device 0x1f (ie 31) function 3? > > Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3 > So, I tried the dump_spd_registers(&memctrl[0]); dump_smbus_registers(); from debug.c and here is the results: ----------------- LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting... dimm: 00.0: 50 00: bad device dimm: 01.0: 51 00: bad device smbus: 69 ---------------- HELP??? Thanks - Joe From pawn2be.wild at yahoo.de Sun Aug 12 04:35:37 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Sun, 12 Aug 2007 04:35:37 +0200 Subject: [LinuxBIOS] hypervisor in flash : LB + legacy BIOS available ? In-Reply-To: <13426df10708100855t7f632456y246410415951855c@mail.gmail.com> References: <46BC6F64.4090008@atl.lmco.com> <13426df10708100853n1d026ene68531a861d6f28d@mail.gmail.com> <13426df10708100855t7f632456y246410415951855c@mail.gmail.com> Message-ID: <46BE71F9.5050706@yahoo.de> the idea is kinda thrilling ... it would allow to have legacy bios available beside LinuxBIOS ? ron minnich wrote: > flash forever; anyone out there want to make a linux-kvm payload, boot > it, load windows, and show us that it's been done? >> http://arstechnica.com/news.ars/post/20070808-dell-virtualization-on-motherboards.html From vogel at ct.metrocast.net Sun Aug 12 04:59:55 2007 From: vogel at ct.metrocast.net (Robert Vogel) Date: Sat, 11 Aug 2007 22:59:55 -0400 Subject: [LinuxBIOS] Read SPD issue References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net><46BD978B.5000603@coresystems.de><20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> Message-ID: <003601c7dc8d$2a24c220$0200a8c0@your55e5f9e3d2> Simple questions. I hope you don't mind. The LinuxBios Product page does not seem to show a motherboard for a desktop machine. A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 motherboard. There are some problems (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To change the BIOS requires soldering a new socket onto the board and, even at that, there is a possibility that the board could be ruined in the process. I don't have the skills required to modify the board, so it is a modification that I need done by someone else. Would you recommend this machine for desktop use ? Is there a desktop AMD 64 Linux machine with LinuxBios available from a good commercial vendor ? Thanks in advance, Bob From corey.osgood at gmail.com Sun Aug 12 05:33:55 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 11 Aug 2007 23:33:55 -0400 Subject: [LinuxBIOS] RD1-PL - Am I having a laugh trying to find one? In-Reply-To: <46BE2556.5060807@senokian.com> References: <46BE2556.5060807@senokian.com> Message-ID: <46BE7FA3.1010909@gmail.com> Richard Wilson wrote: > Hullo all, > > I'm looking at playing round with LB on an EPIA MII-12000, but I don't > so much like the idea of bricking the thing. From the documentation on > the website, and from watching the mailing lists, it seems that an > RD1-PL is the best way to avoid this. From the mailing list archives and > my own research, it seems finding one of the things is likely to be the > hardest part of the entire endeavour. The only place on the entire > 'where to buy' list on the manufacturer website that seems to have any > in stock, is in German, and even with the help of Google Translate, I'm > a bit lost trying to work my way round the site. Does anyone know of > anywhere that might have one? I don't mind buying from pretty much any > country in Europe or America, if I can only find one! Alternatively, > maybe someone bought a few, and would be prepared to sell me one? Heck, > I'd even buy two and donate one to the project, if that would do some good. > > Anyone? > > Richard W > > All the vendors I know of are out of stock. Depending on your location though, there are distributors for just the flash chips, which you can then hot-swap in and out. Make sure you're getting chips of the correct voltage and flash type/size. The BIOS savior is essentially a more convenient way of doing the same thing. -Corey From corey.osgood at gmail.com Sun Aug 12 05:39:04 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 11 Aug 2007 23:39:04 -0400 Subject: [LinuxBIOS] GA M57SLI-S4 questions [was: Read SPD issue] In-Reply-To: <003601c7dc8d$2a24c220$0200a8c0@your55e5f9e3d2> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net><46BD978B.5000603@coresystems.de><20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <003601c7dc8d$2a24c220$0200a8c0@your55e5f9e3d2> Message-ID: <46BE80D8.2080204@gmail.com> Please create a new thread for new questions. Robert Vogel wrote: > Simple questions. I hope you don't mind. The LinuxBios Product page > does not seem to show a motherboard for a desktop machine. > > A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 > motherboard. > > There are some problems > (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To > change the BIOS requires soldering a new socket onto the board and, > even at that, there is a possibility that the board could be ruined in > the process. I don't have the skills required to modify the board, so > it is a modification that I need done by someone else. Would you > recommend this machine for desktop use ? > > Is there a desktop AMD 64 Linux machine with LinuxBios available from > a good commercial vendor ? http://www.linuxbios.org/Supported_Motherboards <- look at desktops/workstations, the first section. > > Thanks in advance, > Bob > > From pawn2be.wild at yahoo.de Sun Aug 12 05:52:25 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Sun, 12 Aug 2007 05:52:25 +0200 Subject: [LinuxBIOS] GIGABYTE GA-M57SLI-S4 & Xen 3.1 In-Reply-To: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com> References: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com> Message-ID: <46BE83F9.2080708@yahoo.de> F11beta legacy bios still has amd-v disbled, according to xenoppix, which boots, however --Q Allix Davis schrieb: > I have not yet installed it, at the moment i am using the proprietary > Award bios version F8 2007/03/20 . > > I wanted to use AMD-V with kvm or xen, unfortunately the bios has > disabled it and there is no option in the bios to enable it. > I found on a thread that before G stepping support disabling amd-v was > difficult and therefore bios companies left it enabled. From corey.osgood at gmail.com Sun Aug 12 06:13:27 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 12 Aug 2007 00:13:27 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> Message-ID: <46BE88E7.10902@gmail.com> Joseph Smith wrote: > Quoting Joseph Smith : > >> Quoting Corey Osgood : >> >>> >>> Can you do me a favor and check that >>> the smbus device is located at device 0x1f (ie 31) function 3? >> >> Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3 >> > So, I tried the > dump_spd_registers(&memctrl[0]); > dump_smbus_registers(); > from debug.c and here is the results: > ----------------- > LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting... > > dimm: 00.0: 50 > 00: bad device > > dimm: 01.0: 51 > 00: bad device > > > smbus: 69 > ---------------- > > HELP??? > > Thanks - Joe > In the attached debug.c is probe_spd_rom(). If your device has spd, it should be able to find it. You can use the whole file and #include it into the southbridge or mainboard or even northbridge code, or just copy and paste it into somewhere else. Call it whereever you called dump_spd_registers from. Note that it's not magic (yet), it won't actually use found spd locations, you'll have to do that manually. Also, what make/model is your dimm and board (I know you've told me, but my memory is terrible)? The datasheets may have more info, if they're available. -Corey -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.c Type: text/x-csrc Size: 303 bytes Desc: not available URL: From rminnich at gmail.com Sun Aug 12 06:23:58 2007 From: rminnich at gmail.com (ron minnich) Date: Sat, 11 Aug 2007 21:23:58 -0700 Subject: [LinuxBIOS] hypervisor in flash : LB + legacy BIOS available ? In-Reply-To: <46BE71F9.5050706@yahoo.de> References: <46BC6F64.4090008@atl.lmco.com> <13426df10708100853n1d026ene68531a861d6f28d@mail.gmail.com> <13426df10708100855t7f632456y246410415951855c@mail.gmail.com> <46BE71F9.5050706@yahoo.de> Message-ID: <13426df10708112123k3516376r8709f6a01d83e5@mail.gmail.com> On 8/11/07, Quux wrote: > the idea is kinda thrilling ... it would allow to have legacy bios > available beside LinuxBIOS ? I doubt it, as the legacy would still be proprietary. It would let you boot many OSes though. ron From joe at smittys.pointclark.net Sun Aug 12 08:03:35 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 12 Aug 2007 02:03:35 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <46BE88E7.10902@gmail.com> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> Message-ID: <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> Quoting Corey Osgood : >> So, I tried the >> dump_spd_registers(&memctrl[0]); >> dump_smbus_registers(); >> from debug.c and here is the results: >> ----------------- >> LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting... >> >> dimm: 00.0: 50 >> 00: bad device >> >> dimm: 01.0: 51 >> 00: bad device >> >> >> smbus: 69 >> ---------------- >> >> HELP??? >> >> Thanks - Joe >> > > In the attached debug.c is probe_spd_rom(). If your device has spd, it > should be able to find it. You can use the whole file and #include it > into the southbridge or mainboard or even northbridge code, or just copy > and paste it into somewhere else. Call it whereever you called > dump_spd_registers from. Note that it's not magic (yet), it won't > actually use found spd locations, you'll have to do that manually. Also, > what make/model is your dimm and board (I know you've told me, but my > memory is terrible)? The datasheets may have more info, if they're > available. > > -Corey > So I tried the probe_spd_rom() and it comes back with "bad device". Which I expected because this line in the function status = smbus_read_byte(i, 0); is my whole problem:( The smbus_read_byte function is what is not working in raminit.c so why would it work when called from auto.c?? No matter what byte I try to read it just comes back with a 0xFF ?? Here is a recap of the hardware: RCA RM4100 Embedded Set-top-box Low Voltage Intel? Celeron? processor (Micro-FC-BGA) 733MHz 128MB PC133 SDRAM on board (Embedded) (In Socket2) Intel i82830 (i830M4) Northbridge (Developing) Intel i82801DB Southbridge (Using i82801xx) SMSC lpc47m192 SuperIO (Using smscsuperio) This is making me crazy, I'm so confused? Thanks - Joe From corey.osgood at gmail.com Sun Aug 12 09:24:43 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 12 Aug 2007 03:24:43 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> Message-ID: <46BEB5BB.3090709@gmail.com> Joseph Smith wrote: > Quoting Corey Osgood : > >>> So, I tried the >>> dump_spd_registers(&memctrl[0]); >>> dump_smbus_registers(); >>> from debug.c and here is the results: >>> ----------------- >>> LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting... >>> >>> dimm: 00.0: 50 >>> 00: bad device >>> >>> dimm: 01.0: 51 >>> 00: bad device >>> >>> >>> smbus: 69 >>> ---------------- >>> >>> HELP??? >>> >>> Thanks - Joe >>> >> >> In the attached debug.c is probe_spd_rom(). If your device has spd, it >> should be able to find it. You can use the whole file and #include it >> into the southbridge or mainboard or even northbridge code, or just copy >> and paste it into somewhere else. Call it whereever you called >> dump_spd_registers from. Note that it's not magic (yet), it won't >> actually use found spd locations, you'll have to do that manually. Also, >> what make/model is your dimm and board (I know you've told me, but my >> memory is terrible)? The datasheets may have more info, if they're >> available. >> >> -Corey >> > So I tried the probe_spd_rom() and it comes back with "bad device". That's because I messed up and forgot to remove the break, so after checking the first location, it left the function. It should have (quite literally) filled your screen with bad device messages, with one message saying it found an spd rom. In hindsight, it was pretty damn stupid of me to leave that message there. Try the attached version, it should be fixed and is even simpler now. > Which I expected because this line in the function > > status = smbus_read_byte(i, 0); > > is my whole problem:( The smbus_read_byte function is what is not > working in raminit.c so why would it work when called from auto.c?? No > matter what byte I try to read it just comes back with a 0xFF ?? > > Here is a recap of the hardware: > RCA RM4100 Embedded Set-top-box > Low Voltage Intel? Celeron? processor (Micro-FC-BGA) 733MHz > 128MB PC133 SDRAM on board (Embedded) (In Socket2) > Intel i82830 (i830M4) Northbridge (Developing) > Intel i82801DB Southbridge (Using i82801xx) > SMSC lpc47m192 SuperIO (Using smscsuperio) > > > This is making me crazy, I'm so confused? > > Thanks - Joe > Essentially what seems to be going on here is the smbus is looking for data, but it can't find the spd rom. The "bad device" error is trying to say bad spd device, or at least that's the hope. Better parsing of the error code (-1 vs -2, etc) could tell us more, but that's the next step (mainly cuz I'm almost asleep right now). This is exploring stepan's theory that the device isn't located at the standard 0x50, etc, by checking the first byte (byte 0) at every address (denoted by i), through the first 256, and throwing up a message if it finds anything. Note that just because there's a device found it's not necessarily the spd rom, but there's a decent chance of it. The other possible problem is that, since your ram is embedded, there isn't any spd rom at all... -Corey -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.c Type: text/x-csrc Size: 297 bytes Desc: not available URL: From stepan at coresystems.de Sun Aug 12 12:20:14 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 12:20:14 +0200 Subject: [LinuxBIOS] hypervisor in flash : LB + legacy BIOS available ? In-Reply-To: <13426df10708112123k3516376r8709f6a01d83e5@mail.gmail.com> References: <46BC6F64.4090008@atl.lmco.com> <13426df10708100853n1d026ene68531a861d6f28d@mail.gmail.com> <13426df10708100855t7f632456y246410415951855c@mail.gmail.com> <46BE71F9.5050706@yahoo.de> <13426df10708112123k3516376r8709f6a01d83e5@mail.gmail.com> Message-ID: <20070812102014.GA24932@coresystems.de> * ron minnich [070812 06:23]: > On 8/11/07, Quux wrote: > > the idea is kinda thrilling ... it would allow to have legacy bios > > available beside LinuxBIOS ? > > I doubt it, as the legacy would still be proprietary. It would let you > boot many OSes though. It would have to have a legacy bios for that, but at least XEN and Co use the ADLO approach and use the Bochs/QEMU BIOS. :-) VMware licensed a Phoenix BIOS for their virtualization. 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 stepan at coresystems.de Sun Aug 12 12:24:35 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 12:24:35 +0200 Subject: [LinuxBIOS] GIGABYTE GA-M57SLI-S4 & Xen 3.1 In-Reply-To: <46BE83F9.2080708@yahoo.de> References: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com> <46BE83F9.2080708@yahoo.de> Message-ID: <20070812102435.GC24932@coresystems.de> * Quux [070812 05:52]: > F11beta legacy bios still has amd-v disbled, according to xenoppix, > which boots, however --Q Can't XEN just turn it on? AFAIK you can't lock the AMD-V bits forever, while on Intel-V the BIOS sets a lock bit and only the BIOS can turn it back on. Usually, if virtualization is disabled, XEN will just try to enable it and print a message if that worked or failed. 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From janek_listy at wp.pl Sun Aug 12 13:45:30 2007 From: janek_listy at wp.pl (Janek Kozicki) Date: Sun, 12 Aug 2007 13:45:30 +0200 Subject: [LinuxBIOS] test Message-ID: <20070812134530.0872f4f7@absurd> I'm sorry, I had a problem with subscription. I hope it's OK now. -- Janek Kozicki | From popkonserve at gmx.de Sun Aug 12 16:05:32 2007 From: popkonserve at gmx.de (popkonserve) Date: Sun, 12 Aug 2007 16:05:32 +0200 Subject: [LinuxBIOS] Intel DRB HOWTO .. a 1st draft. In-Reply-To: <20070812134530.0872f4f7@absurd> References: <20070812134530.0872f4f7@absurd> Message-ID: <46BF13AC.4040107@gmx.de> hi, maybe this would be a good start for a decent source code documentation. at least it should help understanding the code. Holger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HOWTO Intel DRB.txt URL: From joe at smittys.pointclark.net Sun Aug 12 16:49:19 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 12 Aug 2007 10:49:19 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <46BEB5BB.3090709@gmail.com> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> Message-ID: <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Quoting Corey Osgood : >> >>>> So, I tried the >>>> dump_spd_registers(&memctrl[0]); >>>> dump_smbus_registers(); >>>> from debug.c and here is the results: >>>> ----------------- >>>> LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting... >>>> >>>> dimm: 00.0: 50 >>>> 00: bad device >>>> >>>> dimm: 01.0: 51 >>>> 00: bad device >>>> >>>> >>>> smbus: 69 >>>> ---------------- >>>> >>>> HELP??? >>>> >>>> Thanks - Joe >>>> >>> >>> In the attached debug.c is probe_spd_rom(). If your device has spd, it >>> should be able to find it. You can use the whole file and #include it >>> into the southbridge or mainboard or even northbridge code, or just copy >>> and paste it into somewhere else. Call it whereever you called >>> dump_spd_registers from. Note that it's not magic (yet), it won't >>> actually use found spd locations, you'll have to do that manually. Also, >>> what make/model is your dimm and board (I know you've told me, but my >>> memory is terrible)? The datasheets may have more info, if they're >>> available. >>> >>> -Corey >>> >> So I tried the probe_spd_rom() and it comes back with "bad device". > > That's because I messed up and forgot to remove the break, so after > checking the first location, it left the function. It should have (quite > literally) filled your screen with bad device messages, with one message > saying it found an spd rom. In hindsight, it was pretty damn stupid of > me to leave that message there. Try the attached version, it should be > fixed and is even simpler now. > >> Which I expected because this line in the function >> >> status = smbus_read_byte(i, 0); >> >> is my whole problem:( The smbus_read_byte function is what is not >> working in raminit.c so why would it work when called from auto.c?? No >> matter what byte I try to read it just comes back with a 0xFF ?? >> >> Here is a recap of the hardware: >> RCA RM4100 Embedded Set-top-box >> Low Voltage Intel? Celeron? processor (Micro-FC-BGA) 733MHz >> 128MB PC133 SDRAM on board (Embedded) (In Socket2) >> Intel i82830 (i830M4) Northbridge (Developing) >> Intel i82801DB Southbridge (Using i82801xx) >> SMSC lpc47m192 SuperIO (Using smscsuperio) >> >> >> This is making me crazy, I'm so confused? >> >> Thanks - Joe >> > > Essentially what seems to be going on here is the smbus is looking for > data, but it can't find the spd rom. The "bad device" error is trying to > say bad spd device, or at least that's the hope. Better parsing of the > error code (-1 vs -2, etc) could tell us more, but that's the next step > (mainly cuz I'm almost asleep right now). This is exploring stepan's > theory that the device isn't located at the standard 0x50, etc, by > checking the first byte (byte 0) at every address (denoted by i), > through the first 256, and throwing up a message if it finds anything. > Note that just because there's a device found it's not necessarily the > spd rom, but there's a decent chance of it. The other possible problem > is that, since your ram is embedded, there isn't any spd rom at all... > > -Corey > Ok, so I tried this and it just returns a "SPD located at 0x69" is this correct? It is much different than the standard 0x50, etc. Is this because it is embedded?? Thanks for all help. Thanks - Joe From stepan at coresystems.de Sun Aug 12 17:15:20 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 17:15:20 +0200 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: References: Message-ID: <20070812151520.GA6607@coresystems.de> * Ed Swierk [070811 03:58]: > All of this sounds ridiculously unlikely, and without understanding > the details of the flash protocols it's hard to know whether I'm > misdiagnosing the problem. The attached patch removes the seemingly > unnecessary restoring of the value at location 0 in probe_28sf040(), > and indeed fixes the problem. I think you observed an interesting point. I wonder whether anything in that area will ever require that restoration. I am pretty close to say it's just bogus and dangerous and should be dropped, just as you do in your patch. > Index: LinuxBIOSv2-2571/util/flashrom/sst28sf040.c > =================================================================== > --- LinuxBIOSv2-2571.orig/util/flashrom/sst28sf040.c > +++ LinuxBIOSv2-2571/util/flashrom/sst28sf040.c > @@ -106,10 +106,7 @@ static __inline__ int write_sector_28sf0 > int probe_28sf040(struct flashchip *flash) > { > volatile uint8_t *bios = flash->virt_addr; > - uint8_t id1, id2, tmp; > - > - /* save the value at the beginning of the Flash */ > - tmp = *bios; > + uint8_t id1, id2; > > *bios = RESET; > myusec_delay(10); > @@ -127,8 +124,6 @@ int probe_28sf040(struct flashchip *flas > if (id1 == flash->manufacture_id && id2 == flash->model_id) > return 1; > > - /* if there is no SST28SF040, restore the original value */ > - *bios = tmp; > return 0; > } > -- 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 stepan at coresystems.de Sun Aug 12 17:18:49 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 17:18:49 +0200 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: <20070811024158.23323.qmail@stuge.se> References: <20070811024158.23323.qmail@stuge.se> Message-ID: <20070812151849.GB6607@coresystems.de> * Peter Stuge [070811 04:41]: > > The attached patch removes the seemingly unnecessary restoring of > > the value at location 0 in probe_28sf040(), and indeed fixes the > > problem. > > We can't say if that restore really is neccessary or not. Erring on > the side of caution would be good, but the damage may already have > been done by those certain writes that are needed to do the ID. I think it is not necessary nor safe for any flash media in that area. Of course, if we fear that we might find non-flash media in the 4G-size area, we need to think about restoring. > Maybe we should just not probe for 28sf040 by default? It's a really > old chip. Or remove the restore? The code only restores for the case that there is no 28sf040 anyways...? -- 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 corey.osgood at gmail.com Sun Aug 12 18:02:49 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sun, 12 Aug 2007 12:02:49 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> Message-ID: <46BF2F29.10000@gmail.com> Joseph Smith wrote: > Ok, so I tried this and it just returns a "SPD located at 0x69" is > this correct? > It is much different than the standard 0x50, etc. Is this because it > is embedded?? Thanks for all help. > > Thanks - Joe > I'd do an dump first, just to make sure that it really is an spd rom and not some other device on the smbus. Or else do a dump and try to use it in the same run, can't really hurt. -Corey From stepan at coresystems.de Sun Aug 12 18:13:28 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 18:13:28 +0200 Subject: [LinuxBIOS] Filo + USB-OHCI boot In-Reply-To: <20070727174159.GA20835@trinnov.com> References: <20070727174159.GA20835@trinnov.com> Message-ID: <20070812161328.GA18190@coresystems.de> * Remy Bruno [070727 19:41]: > Hello, > > It seems that the linuxBIOS mailing list also manages FILO, so I post this > here, please let me know if I'm wrong. > > I'm trying to boot on an USB key using Filo and an OHCI host, but without > success for now. I don't know if this is supposed to work (apparently yes). If > not, is there a means to achieve USB key boot without the BIOS? Can you try with the FILO builtin into etherboot and see if you get a different result with that? Thank you! -- 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 joe at smittys.pointclark.net Sun Aug 12 19:49:46 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 12 Aug 2007 13:49:46 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <46BF2F29.10000@gmail.com> References: <20070811014652.jk7e4kajk0cg0sg0@www.smittys.pointclark.net> <46BD978B.5000603@coresystems.de> <20070811125254.xrdjyg3hko8w4sso@www.smittys.pointclark.net> <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> <46BF2F29.10000@gmail.com> Message-ID: <20070812134946.umj5bzgkcg0o8wc4@www.smittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Ok, so I tried this and it just returns a "SPD located at 0x69" is >> this correct? >> It is much different than the standard 0x50, etc. Is this because it >> is embedded?? Thanks for all help. >> >> Thanks - Joe >> > > > I'd do an dump first, just to make sure that it really is an spd rom and > not some other device on the smbus. Or else do a dump and try to use it > in the same run, can't really hurt. > > -Corey > > OK, I think I know what is going on here. Here is a dump of my smbus with the legacy bios. 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX 70: XX XX XX XX XX XX XX XX SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock chip). So where do you think I should go from here? I could set up a *.c file in the mainboard directory to call a function to manually set the correct settings for socket2 (I know what the settings are supposed to be) after raminit.c dynamicly configures the register but before the sdram_enable function is called. It should be fairly simple to do and call from auto.c. What do you think? Thanks - Joe From stepan at coresystems.de Sun Aug 12 19:55:52 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sun, 12 Aug 2007 19:55:52 +0200 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070812134946.umj5bzgkcg0o8wc4@www.smittys.pointclark.net> References: <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> <46BF2F29.10000@gmail.com> <20070812134946.umj5bzgkcg0o8wc4@www.smittys.pointclark.net> Message-ID: <20070812175552.GA2119@coresystems.de> * Joseph Smith [070812 19:49]: > SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on > the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock > chip). Are these devices (sensor, clock chip) identified? Any chance there is an i2c mux somewhere? -- 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 joe at smittys.pointclark.net Sun Aug 12 20:09:11 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sun, 12 Aug 2007 14:09:11 -0400 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070812175552.GA2119@coresystems.de> References: <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> <46BF2F29.10000@gmail.com> <20070812134946.umj5bzgkcg0o8wc4@www.smittys.pointclark.net> <20070812175552.GA2119@coresystems.de> Message-ID: <20070812140911.jns07jt72800w4ok@www.smittys.pointclark.net> Quoting Stefan Reinauer : > * Joseph Smith [070812 19:49]: >> SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on >> the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock >> chip). > > Are these devices (sensor, clock chip) identified? Any chance there is > an i2c mux somewhere? > Not sure, what is the typical address for a i2c mux? I can probe for it. The only other device i think there is, is the on-board tv-out chip, and I think that is at 0x88. How come lm-sensors default is to only probe between address range 0x03-0x77? Thanks - Joe From ward at gnu.org Mon Aug 13 00:25:26 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 12 Aug 2007 18:25:26 -0400 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? Message-ID: <20070812222526.GA8039@countzero.vandewege.net> I'm looking to buy a new desktop machine today or tomorrow. There were several posts last November bout the MSI K9N Neo-F: http://www.openbios.org/pipermail/linuxbios/2006-November/thread.html Where are we with that board? It's cheap and on the face of it should be fairly easy to port - MCP55 chipset, etc. There was some concern about the ehternet card? I think I'll get this board or perhaps one of the Abit KN9 ones that are very similar to the Gigabyte M57SLI-S4. All have a PLCC socket which is a big plus. If anyone has been working on these boards give me a shout - I'd like to put some work into adding support for one of these. Thanks, Ward. -- Ward Vandewege From peter at stuge.se Mon Aug 13 01:29:11 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 01:29:11 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070812222526.GA8039@countzero.vandewege.net> References: <20070812222526.GA8039@countzero.vandewege.net> Message-ID: <20070812232912.6702.qmail@stuge.se> On Sun, Aug 12, 2007 at 06:25:26PM -0400, Ward Vandewege wrote: > Where are we with that board? I don't think anyone got around to it. > It's cheap and on the face of it should be fairly easy to port - > MCP55 chipset, etc. There was some concern about the ehternet card? For LB purposes the NIC is not likely to cause problems, I think the uncertainty was about a Linux driver for it. drivers/net/forcedeth.c does support the relevant PCI IDs (PCI_DEVICE_ID_NVIDIA_NVENET_14/15, 0x0372/0x0373) according to the FreeBSD nfe driver. > I think I'll get this board or perhaps one of the Abit KN9 ones > that are very similar to the Gigabyte M57SLI-S4. All have a PLCC > socket which is a big plus. > > If anyone has been working on these boards give me a shout - I'd > like to put some work into adding support for one of these. I don't know if Carl-Daniel got a response from the desktop BIOS people at MSI, I got the impression we'd be able to get some help from them if we needed it, but I suppose it would be easier for them to answer specific questions. //Peter From dhbarr at gozelle.com Mon Aug 13 02:25:17 2007 From: dhbarr at gozelle.com (David H. Barr) Date: Sun, 12 Aug 2007 19:25:17 -0500 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070812232912.6702.qmail@stuge.se> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> Message-ID: On 8/12/07, Peter Stuge wrote: > On Sun, Aug 12, 2007 at 06:25:26PM -0400, Ward Vandewege wrote: > > Where are we with that board? > > I don't think anyone got around to it. I never got around to it; stalled at flashrom support. I still have two of the boards sitting here, waiting for me to do my worst. AFIAK the only one in this "ultra-low-end" class that never got tried was the BIOSTAR Tforce 550 -dhbarr. From peter at stuge.se Mon Aug 13 02:46:53 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 02:46:53 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> Message-ID: <20070813004653.18174.qmail@stuge.se> On Sun, Aug 12, 2007 at 07:25:17PM -0500, David H. Barr wrote: > > > Where are we with that board? > > > > I don't think anyone got around to it. > > I never got around to it; stalled at flashrom support. Didn't flashrom work at least with the flash chip on the Gigabyte board? (I remember there were problems with BIOS savior, but seem to recall that flashing the chip alone worked OK.) PLCC in socket? Which flash part? Is the problem the flash chip or the southbridge? > I still have two of the boards sitting here, waiting for me to do > my worst. If you have another LPC board you could use that as a flasher with pushpinflash or a BIOS savior. (1Mbyte RD1-LPC8 is easy to get.) > AFIAK the only one in this "ultra-low-end" class that never got > tried was the BIOSTAR Tforce 550 The K9N NEO-F is even nicer on the budget over here. Wow. 2GHz dual core X2 + mobo + 2x512MB RAM = 140EUR! (ex 25% VAT) //Peter From kioshiro_ll at hotmail.com Mon Aug 13 03:48:07 2007 From: kioshiro_ll at hotmail.com (LOU Ludovic) Date: Mon, 13 Aug 2007 01:48:07 +0000 Subject: [LinuxBIOS] is linuxbios installable on a VAIO VGN-AR21SR? Message-ID: Hello everyone i hope i don't annoy you. I own a vaio VGN-AR21SR click or copy link to see spec http://www.vaio-link.com/specifications/specifications.asp?site=voe_en_gb_cons&c=-1&s=-1&m=2417 and i would like to install linuxbios is it compatible? will it erase BIOS config and password?. thank you and have a nice day. _________________________________________________________________ MSN Hotmail : cr?ez votre adresse e-mail gratuite & ? vie ! http://www.msn.fr/newhotmail/Default.asp?Ath=f From peter at stuge.se Mon Aug 13 03:56:37 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 03:56:37 +0200 Subject: [LinuxBIOS] is linuxbios installable on a VAIO VGN-AR21SR? In-Reply-To: References: Message-ID: <20070813015637.28544.qmail@stuge.se> On Mon, Aug 13, 2007 at 01:48:07AM +0000, LOU Ludovic wrote: > Hello everyone i hope i don't annoy you. No worries. > I own a vaio VGN-AR21SR > > click or copy link to see spec > > http://www.vaio-link.com/specifications/specifications.asp?site=voe_en_gb_cons&c=-1&s=-1&m=2417 > > and i would like to install linuxbios is it compatible? Unfortunately LB does not have support for any laptops yet. > will it erase BIOS config and password?. Yes, if the system was supported and you replaced the factory BIOS with LB there would be nothing left. Note that some laptop hard drives have password protection. LB does not currently offer any way to enter the password for such drives, but it will be simple enough to add that once there is support for the laptop itself. //Peter From ward at gnu.org Mon Aug 13 04:26:20 2007 From: ward at gnu.org (Ward Vandewege) Date: Sun, 12 Aug 2007 22:26:20 -0400 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070813004653.18174.qmail@stuge.se> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> Message-ID: <20070813022620.GA15475@countzero.vandewege.net> On Mon, Aug 13, 2007 at 02:46:53AM +0200, Peter Stuge wrote: > Didn't flashrom work at least with the flash chip on the Gigabyte > board? (I remember there were problems with BIOS savior, but seem > to recall that flashing the chip alone worked OK.) Yeah, it works fine. I was having some problems with flashrom while running LB (but *not* while running the proprietary bios) a few months ago, but I need to revisit that. I'll make a trac bug if the problem persists with the latest and greatest flashrom. > > AFIAK the only one in this "ultra-low-end" class that never got > > tried was the BIOSTAR Tforce 550 Yeah - it's out of stock here it seems. > The K9N NEO-F is even nicer on the budget over here. Wow. > 2GHz dual core X2 + mobo + 2x512MB RAM = 140EUR! (ex 25% VAT) Actually, the Neo-F also seems to be out of stock in most places. It seems that MCP55-based boards are disappearing from the market... Thanks, Ward. -- Ward Vandewege From outlander_wei at yahoo.com Mon Aug 13 05:21:37 2007 From: outlander_wei at yahoo.com (Richard Wei) Date: Sun, 12 Aug 2007 20:21:37 -0700 (PDT) Subject: [LinuxBIOS] Tyan S2885 memreset problem!! Message-ID: <187846.25022.qm@web33501.mail.mud.yahoo.com> Thanks for yinghailu and libos' help~ Now the new CPU has arrived, and most of Linuxbios's process is done. ^_^ ----- Original Message ---- From: "Feng, Libo" To: Richard Wei ; yhlu Cc: linuxbios at linuxbios.org Sent: Friday, August 3, 2007 3:12:55 PM Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! We seemed to have the same problem before. We just set DQS_TRAIN_DEBUG 1 in /northbridge/amd/amdk8/raminit_f_dqs.c to solve the problem. We don't know the reason. Mr. Lu Yinghai once suggested to use a new version gcc to actually solve the problem. You can try it. We use LB 2584, and gcc is 4.0.0. Because we just want to get some BIOS experience by learning LinuxBIOS, so the version is very old. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Wei Sent: Friday, August 03, 2007 2:58 PM To: yhlu Cc: linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! Help help ... I have checked out from the first time the source code of Tyan s2885 is placed on v2.1090 to v2.2140. (I have tried 1100, 1150, 1322, 1390, 1430, 1530, 1550 ... 2010, 2050, 2090) I wasn't able to build images successfully for Tyan s2885 until v2.2140. Probably it's my environment's problem. Somehow, the system still stop at memreset. Does it means that I have to spend DOLLARs? .... Richard Wei ----- Original Message ---- From: yhlu To: Richard Wei Cc: linuxbios at linuxbios.org Sent: Tuesday, July 31, 2007 12:38:42 PM Subject: Re: [LinuxBIOS] Tyan S2885 memreset problem!! On 7/30/07, Richard Wei wrote: > Oh... I check it again. > The information right on the AMD Opteron processor is OSA240CC05AH. > By the last two digit, I think I have Rev. B3. > > > AD CPUID?Model4ESRev.C0?0.13um > AG CPUID?Model5(max.1CPU)Rev.B3-0,13umSledgehammer core AH > CPUID?Model5(max.2CPU)Rev.B3-0,13umSledgehammer core AI > CPUID?Model5(max.8CPU)Rev.B3-0,13umSledgehammer core AK > CPUID?Model5(max.1CPU)Rev.C0-0,13umSledgehammer core AL > CPUID?Model5(max.2CPU)Rev.C0-0,13umSledgehammer core > AMCPUID?Model5(max.8CPU)Rev.C0-0,13umSledgehammer core > wow, how can you get that? it seems only LANL's big cluster is using that. that cpu can not reset memory directly, so it need SB's help to reset memory... I wonder if support cache_as_ram too... I suggest you may download some old tar to test that. or i could send you one image that i buld in blind to try luck... YH ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From peter at stuge.se Mon Aug 13 05:22:50 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 05:22:50 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070813022620.GA15475@countzero.vandewege.net> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> <20070813022620.GA15475@countzero.vandewege.net> Message-ID: <20070813032250.9057.qmail@stuge.se> On Sun, Aug 12, 2007 at 10:26:20PM -0400, Ward Vandewege wrote: > I was having some problems with flashrom while running LB (but > *not* while running the proprietary bios) a few months ago, but I > need to revisit that. I'll make a trac bug if the problem persists > with the latest and greatest flashrom. Great. > > > AFIAK the only one in this "ultra-low-end" class that never got > > > tried was the BIOSTAR Tforce 550 > > Yeah - it's out of stock here it seems. > > > The K9N NEO-F is even nicer on the budget over here. Wow. > > 2GHz dual core X2 + mobo + 2x512MB RAM = 140EUR! (ex 25% VAT) > > Actually, the Neo-F also seems to be out of stock in most places. I can still get both locally. Neo-F at 50EUR, Tforce at 65EUR. > It seems that MCP55-based boards are disappearing from the market... About time I guess, they're already what, 9-10 months old.. Crazy. If the hardware doesn't live longer than that, the vendors definately can't afford having software stuck in some legal department for two full months. //Peter From eswierk at arastra.com Mon Aug 13 05:46:26 2007 From: eswierk at arastra.com (Ed Swierk) Date: Sun, 12 Aug 2007 20:46:26 -0700 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: <20070812151849.GB6607@coresystems.de> References: <20070811024158.23323.qmail@stuge.se> <20070812151849.GB6607@coresystems.de> Message-ID: On 8/12/07, Stefan Reinauer wrote: > Or remove the restore? The code only restores for the case that there is > no 28sf040 anyways...? Makes sense to me :-) --Ed From eswierk at arastra.com Mon Aug 13 05:47:42 2007 From: eswierk at arastra.com (Ed Swierk) Date: Sun, 12 Aug 2007 20:47:42 -0700 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: References: <20070811024158.23323.qmail@stuge.se> <20070812151849.GB6607@coresystems.de> Message-ID: Signed-off-by: Ed Swierk --Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxbios-300-flashrom-bug.patch Type: application/octet-stream Size: 760 bytes Desc: not available URL: From peter at stuge.se Mon Aug 13 05:57:40 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 05:57:40 +0200 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: <20070812151849.GB6607@coresystems.de> References: <20070811024158.23323.qmail@stuge.se> <20070812151849.GB6607@coresystems.de> <20070811024158.23323.qmail@stuge.se> <20070812151849.GB6607@coresystems.de> Message-ID: <20070813035740.13969.qmail@stuge.se> On Sun, Aug 12, 2007 at 05:18:49PM +0200, Stefan Reinauer wrote: > Of course, if we fear that we might find non-flash media in the > 4G-size area, we need to think about restoring. Yeah. When we want to port flashrom to flash also on other archs, it will need a redesign. I don't care for now. > > Maybe we should just not probe for 28sf040 by default? It's a > > really old chip. > > Or remove the restore? I like that. No other probe_ functions restore like that. > The code only restores for the case that there is no 28sf040 > anyways...? And that's the problem - because typically there is none, so that byte will always get written. Most chips don't care, but apparently some do. //Peter From svn at openbios.org Mon Aug 13 06:10:32 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 13 Aug 2007 06:10:32 +0200 Subject: [LinuxBIOS] r2744 - trunk/util/flashrom Message-ID: Author: stuge Date: 2007-08-13 06:10:32 +0200 (Mon, 13 Aug 2007) New Revision: 2744 Modified: trunk/util/flashrom/sst28sf040.c Log: Fix bug in probe_28sf040() causing flash corruption on SST49LF160C verify. The first byte of the flash chip was read at the start of the function and later written back to address 0 if the flash chip was not identified as SST28SF040, which means most of the time. This write caused corruption of flash contents when verifying a SST49LF160C part. Signed-off-by: Ed Swierk Acked-by: Peter Stuge Modified: trunk/util/flashrom/sst28sf040.c =================================================================== --- trunk/util/flashrom/sst28sf040.c 2007-08-11 16:59:11 UTC (rev 2743) +++ trunk/util/flashrom/sst28sf040.c 2007-08-13 04:10:32 UTC (rev 2744) @@ -106,11 +106,8 @@ int probe_28sf040(struct flashchip *flash) { volatile uint8_t *bios = flash->virtual_memory; - uint8_t id1, id2, tmp; + uint8_t id1, id2; - /* save the value at the beginning of the Flash */ - tmp = *bios; - *bios = RESET; myusec_delay(10); @@ -127,8 +124,6 @@ if (id1 == flash->manufacture_id && id2 == flash->model_id) return 1; - /* if there is no SST28SF040, restore the original value */ - *bios = tmp; return 0; } From peter at stuge.se Mon Aug 13 06:10:44 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Aug 2007 06:10:44 +0200 Subject: [LinuxBIOS] [PATCH] Fix bug causing flash corruption during verify In-Reply-To: References: <20070811024158.23323.qmail@stuge.se> <20070812151849.GB6607@coresystems.de> Message-ID: <20070813041044.16095.qmail@stuge.se> On Sun, Aug 12, 2007 at 08:47:42PM -0700, Ed Swierk wrote: > Signed-off-by: Ed Swierk Acked, r2744 From info at coresystems.de Mon Aug 13 06:55:45 2007 From: info at coresystems.de (LinuxBIOS information) Date: Mon, 13 Aug 2007 06:55:45 +0200 Subject: [LinuxBIOS] r2744 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stuge" checked in revision 2744 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix bug in probe_28sf040() causing flash corruption on SST49LF160C verify. The first byte of the flash chip was read at the start of the function and later written back to address 0 if the flash chip was not identified as SST28SF040, which means most of the time. This write caused corruption of flash contents when verifying a SST49LF160C part. Signed-off-by: Ed Swierk Acked-by: Peter Stuge Build Log: Compilation of agami:aruma has been fixed Compilation of amd:db800 has been fixed Compilation of amd:norwich has been fixed Compilation of amd:rumba has been fixed Compilation of amd:serengeti_cheetah has been fixed Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=hdama&vendor=arima Compilation of artecgroup:dbe61 has been fixed Compilation of asi:mb_5blmp has been fixed Compilation of asus:a8n_e has been fixed Compilation of asus:mew-vm has been fixed Compilation of asus:p2b has been fixed Compilation of bitworks:ims has been fixed Compilation of broadcom:blast has been fixed Compilation of dell:s1850 has been fixed Compilation of digitallogic:adl855pc has been fixed Compilation of digitallogic:msm586seg has been fixed Compilation of digitallogic:msm800sev has been fixed Compilation of eaglelion:5bcm has been fixed Compilation of emulation:qemu-i386 has been fixed Compilation of gigabyte:m57sli has been fixed Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=juki-511p&vendor=iei Compilation of iei:nova4899r has been fixed Compilation of intel:jarrell has been fixed Compilation of intel:xe7501devkit has been fixed Compilation of iwill:dk8_htx has been fixed Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2744&device=dk8x&vendor=iwill Compilation of lippert:frontrunner has been fixed Compilation of msi:ms9185 has been fixed Compilation of msi:ms9282 has been fixed Compilation of newisys:khepri has been fixed Compilation of nvidia:l1_2pvv has been fixed Compilation of olpc:btest has been fixed Compilation of olpc:rev_a has been fixed Compilation of sunw:ultra40 has been fixed Compilation of supermicro:h8dmr has been fixed Compilation of supermicro:x6dai_g has been fixed Compilation of supermicro:x6dhe_g has been fixed Compilation of supermicro:x6dhe_g2 has been fixed Compilation of supermicro:x6dhr_ig has been fixed Compilation of supermicro:x6dhr_ig2 has been fixed Compilation of technologic:ts5300 has been fixed Compilation of tyan:s1846 has been fixed Compilation of tyan:s2735 has been fixed Compilation of tyan:s2850 has been fixed Compilation of tyan:s2875 has been fixed Compilation of tyan:s2880 has been fixed Compilation of tyan:s2881 has been fixed Compilation of tyan:s2882 has been fixed Compilation of tyan:s2885 has been fixed Compilation of tyan:s2891 has been fixed Compilation of tyan:s2892 has been fixed Compilation of tyan:s2895 has been fixed Compilation of tyan:s2912 has been fixed Compilation of tyan:s4880 has been fixed Compilation of tyan:s4882 has been fixed Compilation of via:epia has been fixed Compilation of via:epia-m has been fixed If something broke during this checkin please be a pain in stuge's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From pawn2be.wild at yahoo.de Mon Aug 13 11:48:25 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Mon, 13 Aug 2007 11:48:25 +0200 Subject: [LinuxBIOS] GIGABYTE GA-M57SLI-S4 & Xen 3.1 In-Reply-To: <20070812102435.GC24932@coresystems.de> References: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com> <46BE83F9.2080708@yahoo.de> <20070812102435.GC24932@coresystems.de> Message-ID: <46C028E9.1020906@yahoo.de> I assume that is what happens, but kernel messages are not fully logged. The screen just says that BIOS has AMD-V disabled, but all seems to work fine - albeit slow in a knoppix inside a knoppix (who are 2 DHCP clients) ... --Q Stefan Reinauer schrieb: > Usually, if virtualization is disabled, XEN will just try to enable it > and print a message if that worked or failed. From darmawan.salihun at gmail.com Mon Aug 13 15:17:26 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Mon, 13 Aug 2007 20:17:26 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070810123052.14705.qmail@stuge.se> References: <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC3C17.5040409@gmail.com> <20070810123052.14705.qmail@stuge.se> Message-ID: <46C059E6.9000502@gmail.com> Peter Stuge wrote: > On Fri, Aug 10, 2007 at 05:21:11PM +0700, Darmawan Salihun wrote: >>> I really prefer using whatever API Windows offers. >> That's why I'm trying this Hal***BusDataByOffset right now. > > Aye. OK. The good news is HalGetBusDataByOffset function _is_ working in my test system. But, I still have some bugs to "iron-out" because some offset seems to be read incorrectly. Perhaps, I missed something in the PCI configuration data structure returned by this function. Anyway, HalSetBusDataByOffset is still obscure. It may work but, the way I invoke the function is not right :-(. Regards, Darmawan From vogel at ct.metrocast.net Mon Aug 13 17:24:13 2007 From: vogel at ct.metrocast.net (Robert Vogel) Date: Mon, 13 Aug 2007 11:24:13 -0400 Subject: [LinuxBIOS] Desktop with LinuxBios ? References: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com><46BE83F9.2080708@yahoo.de> <20070812102435.GC24932@coresystems.de> <28473585.1186998569919.JavaMail.root@m48> Message-ID: <004e01c7ddbe$07fffc50$0200a8c0@your55e5f9e3d2> A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 motherboard. There are some problems (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To change the BIOS requires soldering a new socket onto the board and, even at that, there is a possibility that the board could be ruined in the process. I don't have the skills required to modify the board, so it is a modification that I need done by someone else. Would you recommend this machine for desktop use ? The LinuxBios Product page does not show a motherboard for a desktop machine. Is there a desktop AMD 64 Linux machine with LinuxBios available from a good commercial vendor ? If not, how far away is it ? Thanks for any response, Bob From pawn2be.wild at yahoo.de Mon Aug 13 17:52:21 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Mon, 13 Aug 2007 17:52:21 +0200 Subject: [LinuxBIOS] Desktop with LinuxBios ? In-Reply-To: <004e01c7ddbe$07fffc50$0200a8c0@your55e5f9e3d2> References: <9cbc15560707261646y2e770bcm8b12bfa0e9a2158c@mail.gmail.com><46BE83F9.2080708@yahoo.de> <20070812102435.GC24932@coresystems.de> <28473585.1186998569919.JavaMail.root@m48> <004e01c7ddbe$07fffc50$0200a8c0@your55e5f9e3d2> Message-ID: <46C07E35.6020003@yahoo.de> hi Robert, if you get a M57SLI for 84 ? it is good bang for the buck. Otherwise there is only the ASUS A8N-E wich is out of stock but many people try to get rid of it at ebay around 30? or so. A8N successors ar still with the dealers, but we need info, which SuperIO chips asf. the other mobos from the A8N series have. If they differ little then they can be made LB able quickly. greetinx Q-- Robert Vogel schrieb: > A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 > motherboard. > > There are some problems > (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To > change the BIOS requires soldering a new socket onto the board and, > even at > that, there is a possibility that the board could be ruined in the > process. > I don't have the skills required to modify the board, so it is a > modification that I need done by someone else. Would you recommend this > machine for desktop use ? > > The LinuxBios Product page does not show a motherboard for a desktop > machine. > Is there a desktop AMD 64 Linux machine with LinuxBios available from > a good > commercial vendor ? If not, how far away is it ? From svn at openbios.org Mon Aug 13 17:59:57 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 13 Aug 2007 15:59:57 -0000 Subject: [LinuxBIOS] #78: Implement larfs to handle GRUB2 modules in flash easily. In-Reply-To: <043.7a8969ad7de3bf70e577ae9aab36ad77@openbios.org> References: <043.7a8969ad7de3bf70e577ae9aab36ad77@openbios.org> Message-ID: <052.90899c729086e40e998ea0d1df40dc9c@openbios.org> #78: Implement larfs to handle GRUB2 modules in flash easily. ----------------------------+----------------------------------------------- Reporter: stepan | Owner: somebody Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch is ready to be committed ----------------------------+----------------------------------------------- Changes (by oxygene): * status: new => closed * type: defect => enhancement * patchstatus: there is no patch => patch is ready to be committed * resolution: => fixed Comment: The attached patch against grub2 implements this feature -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Aug 13 18:01:16 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 13 Aug 2007 16:01:16 -0000 Subject: [LinuxBIOS] #80: serial console in grub2 works In-Reply-To: <044.91a7bb7f03ea6b51b9f169cc4abb5027@openbios.org> References: <044.91a7bb7f03ea6b51b9f169cc4abb5027@openbios.org> Message-ID: <053.2d2695b44ebfc504174e0d15ca05fc27@openbios.org> #80: serial console in grub2 works ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Changes (by oxygene): * status: assigned => closed * patchstatus: patch needs work => patch needs review * resolution: => fixed -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Aug 13 18:06:29 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 13 Aug 2007 16:06:29 -0000 Subject: [LinuxBIOS] #83: grub2 needs to generate its memory map from LinuxBIOS In-Reply-To: <044.2586510260f6e152c12e60cadf17fdb8@openbios.org> References: <044.2586510260f6e152c12e60cadf17fdb8@openbios.org> Message-ID: <053.eaac45fe5949d4dab7b1a958f5011089@openbios.org> #83: grub2 needs to generate its memory map from LinuxBIOS ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: duplicate | Keywords: Dependencies: #82 | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Changes (by oxygene): * status: new => closed * resolution: => duplicate Comment: ticket #79 will include this code (doesn't make sense to split it) -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Aug 13 18:18:08 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 13 Aug 2007 16:18:08 -0000 Subject: [LinuxBIOS] #81: grub2 vga + keyboard works (text mode) In-Reply-To: <044.42d3b2959bb629e9751a77953af832ce@openbios.org> References: <044.42d3b2959bb629e9751a77953af832ce@openbios.org> Message-ID: <053.d345f73967d1cab87028250aaa129051@openbios.org> #81: grub2 vga + keyboard works (text mode) ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: duplicate | Keywords: Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Changes (by oxygene): * status: new => closed * resolution: => duplicate Comment: included in #79 -- Ticket URL: LinuxBIOS From svn at openbios.org Tue Aug 14 00:18:50 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 13 Aug 2007 22:18:50 -0000 Subject: [LinuxBIOS] #87: flashrom issues on m57sli-s4 Message-ID: <041.ecf9a38049d8bbbe15bbb6ff0a642599@openbios.org> #87: flashrom issues on m57sli-s4 ---------------------------------+------------------------------------------ Reporter: ward | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: code | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ There is a problem with flashrom; it won't work reliably when the machine is booted under LinuxBIOS on the m57sli-s4. This is what I used to see: It works maybe 1 out of 10 times - it always works when booted with the proprietary BIOS. I can tell while it's flashing if it is good or not good: the speed of the flashing is moderately fast for a good flash. For a bad flash, it is either too fast, too slow, or it varies a lot during the flash. This is what I'm seeing today (with the latest rev of flashrom, 2744): Flashrom jumps from page 15 to page 224 while flashing, and then fails to verify. I've tried with several different chis (all of the same type though). {{{ # ./flashrom -vvvv -w /home/ward/Desktop/buildrom/buildrom-devel/deploy /gigabyte-m57sli.rom -V Calibrating delay loop... 537M loops per second. ok Found canidate at: 00000530-00000e2c Found LinuxBIOS table at: 00000530 lb_table found at address 0xb7e40530 LinuxBIOS header(24) checksum: e2db table(2300) checksum: 826c entries: 14 vendor id: GIGABYTE part id: m57sli Found chipset "NVIDIA MCP55": Enabling flash write... OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0xff, id2 0xff Probing for Am29F016D, 2048 KB probe_29f040b: id1 0xff, id2 0xff Probing for AE49F2008, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0x5b Probing for At29C020, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for Mx29f002, 256 KB probe_29f002: id1 0xbf, id2 0x5b Probing for SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST28SF040A, 512 KB probe_28sf040: id1 0xff, id2 0xff Probing for SST39SF010A, 128 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST39SF020A, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST39SF040, 512 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST39VF020, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST49LF040B, 512 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST49LF040, 512 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST49LF020A, 256 KB probe_jedec: id1 0xbf, id2 0x5b Probing for SST49LF080A, 1024 KB probe_jedec: id1 0xbf, id2 0x5b SST49LF080A found at physical address: 0xfff00000 Flash part is SST49LF080A (1024 KB) LinuxBIOS last image size (not rom size) is 1048576 bytes. MANUFACTURER: GIGABYTE MAINBOARD ID: m57sli This firmware image matches this motherboard. Programming Page: 0255 at address: 0x000ff000 Verifying flash address: 0x00000000 - FAILED }}} I should note that I'm using a bios savior to swap flash chips, and that the socket has been soldered onto the board manually. But under the proprietary bios there is never a problem, so... -- Ticket URL: LinuxBIOS From darmawan.salihun at gmail.com Tue Aug 14 10:07:49 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 14 Aug 2007 15:07:49 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46BC6A5A.6080609@dls.net> References: <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> Message-ID: <46C162D5.7020302@gmail.com> Roman Kononov wrote: > Peter Stuge wrote: >> But PCI config accesses are not atomic operations. Is there a >> guarantee that the other CPUs are not in the middle of doing a PCI >> access already? >> >> And even if they are actually doing something else, perhaps they >> (erroneously? but we don't want to break them anyway) rely on 0xcfc >> being what they set it to in the last PCI config access? >> > By making all the CPUs spinning inside your DPC you avoid these > problems. The Windoze kernel protects itself and does not execute > scheduled DPC when the CPU is in the middle of a PCI access or anything > similar. For sure, when a CPU makes a PCI access its "IRQL" is raised to > "HIGH_LEVEL", which means that a dedicated spin lock is acquired and > that CPU's interrupts are disabled. > > I did not take the above statement about IRQL from an official document, > I made it based on my experience and common sense. > > Regards, > > Roman > Apparently, this is the only solution right now because the Hal***BusDataByOffset() function is _not_ working as expected. My latest test results with 2 different PCs with WIndows XP SP2 shows that HalGetBusDataByOffset() is not a stable function, it works in one of the test platform and crashes in others. While the HalSetBusDataByOffset() is _not_ working at all. I think the symbol is defined in the kernel but may not be implemented in Win XP SP2. Moreover, direct port I/O was working flawlessly with the older flashrom that I port to windows back then. I think the "DPC" trick will guarantee the atomic operation and will give us the level of confidence to do the direct port I/O. I'll be reporting as soon as the DPC version of the direct port I/O driver routine has been tested. Regards, Darmawan Salihun From corey.osgood at gmail.com Tue Aug 14 10:18:12 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 14 Aug 2007 04:18:12 -0400 Subject: [LinuxBIOS] Need help with the VGA bios Message-ID: <46C16544.6030900@gmail.com> Okay, I know I've been asking for a lot of help lately, and I'm really sorry. This should be the last time, for now ;-) The vga bios on the jetway j7f2we1g is causing errors any time I try to load it, sometimes boot continues anyways but vga never initializes. Attached are 2 patches (one for the vt8237r, the other for everything else, not ready for commit by any means) and a log file, for both vm86.c (hacked up from the epia-m) and x86emu. The VGA rom I've been using I extracted with awardeco and is available for now here: http://rapidshare.com/files/48880059/E14JTWAY.ROM.html (only for testing/inspection purposes, will be removed once this is running or upon request from Via or Jetway). I've tried roms from the original and latest jetway bios (that is from the original), and also one from a via epia-cn, all give the same result. Any help would be greatly appreciated. -Corey -------------- next part -------------- A non-text attachment was scrubbed... Name: vgabios.log Type: text/x-log Size: 13132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jetway_j7f2we.patch Type: text/x-patch Size: 813372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vt8237r.patch Type: text/x-patch Size: 36458 bytes Desc: not available URL: From drmario2007 at gmail.com Mon Aug 13 12:07:26 2007 From: drmario2007 at gmail.com (Donovan Lavinder) Date: Mon, 13 Aug 2007 04:07:26 -0600 Subject: [LinuxBIOS] Biostar K8T800-A7A Message-ID: <82ca492c0708130307n78c18120ob89aca22523ee14a@mail.gmail.com> I'm wondering if anybody are working on this particular model, K8T800-A7A motherboard? I would like to know, so I would like to have one flashed on my motherboard. Also, what's the recommend steps to flash it onto my motherboard while running Windows 2000? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Libo.Feng at amd.com Tue Aug 14 11:56:50 2007 From: Libo.Feng at amd.com (Feng, Libo) Date: Tue, 14 Aug 2007 17:56:50 +0800 Subject: [LinuxBIOS] Read SPD issue In-Reply-To: <20070812140911.jns07jt72800w4ok@www.smittys.pointclark.net> References: <20070811171710.GA15184@coresystems.de> <46BE163B.20907@gmail.com> <20070811165424.ug4j5jg9wkgc08k0@www.smittys.pointclark.net> <20070811220423.ds4gj3l4u8o0s4kw@simittys.pointclark.net> <46BE88E7.10902@gmail.com> <20070812020335.95lezuwq4o4ws0gw@simittys.pointclark.net> <46BEB5BB.3090709@gmail.com> <20070812104919.ehw3k1c2yskgg4w8@simittys.pointclark.net> <46BF2F29.10000@gmail.com> <20070812134946.umj5bzgkcg0o8wc4@www.smittys.pointclark.net> <20070812175552.GA2119@coresystems.de> <20070812140911.jns07jt72800w4ok@www.smittys.pointclark.net> Message-ID: Generally, I2C mux has some external pins to set its address. In my Tyan S3992, the address is 0x71, so the function activate_spd_rom is called before accessing SPD. Best Regards ??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406 -----Original Message----- From: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Joseph Smith Sent: Monday, August 13, 2007 2:09 AM To: Stefan Reinauer Cc: Corey Osgood; linuxbios at linuxbios.org Subject: Re: [LinuxBIOS] Read SPD issue Quoting Stefan Reinauer : > * Joseph Smith [070812 19:49]: >> SPD would show up at 0x50 or 0x51 right? It doesn't appear there is >> SPD on the on-board memory.I only show items at 0x2d (sensor) and >> 0x69 (clock chip). > > Are these devices (sensor, clock chip) identified? Any chance there is > an i2c mux somewhere? > Not sure, what is the typical address for a i2c mux? I can probe for it. The only other device i think there is, is the on-board tv-out chip, and I think that is at 0x88. How come lm-sensors default is to only probe between address range 0x03-0x77? Thanks - Joe -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios From stepan at coresystems.de Tue Aug 14 12:12:01 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 14 Aug 2007 12:12:01 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C16544.6030900@gmail.com> References: <46C16544.6030900@gmail.com> Message-ID: <20070814101201.GA18077@coresystems.de> * Corey Osgood [070814 10:18]: > Initiailizing VGA... > INSTALL REAL-MODE IDT > DO THE VGA BIOS > found VGA: vid=1106, did=3344 > rom base, size: fff80000 > bus/devfn = 0x100 > biosint: INT# 0x6 > biosint: eax 0x9f98 ebx 0x1c380 ecx 0x29f98 edx 0x12 > biosint: ebp 0x29f74 esp 0xff6 edi 0x3d esi 0x3b4 > biosint: ip 0x3 cs 0xc000 flags 0x46 > biosint: Oops, exception 6 > Stack contents: 0x0003 0xc000 0x0046 0x97e7 0x0000 > biosint: Bailing out > Enable VGA console > This is an "invalid opcode". Weird though, c0003 seems to be a normal jmp. Can you dump 0xc0000 to see if the copy worked? > PCI: 01:00.0 init > Initiailizing VGA... > Forcing rom load > copying VGA ROM Image from 0xfff80000 to 0xc0000, 0x10000 bytes > entering emulator > halt_sys: file /home/amp/linuxbios/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 5100 > -- 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 darmawan.salihun at gmail.com Tue Aug 14 13:45:10 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 14 Aug 2007 18:45:10 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46ADF604.5070005@dls.net> References: <46886eb7.27ed720a.5795.ffffedbb@mx.google.com> <4688C2BF.2040600@gmail.com> <20070702193703.21913.qmail@stuge.se> <4695D613.6080603@gmail.com> <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> Message-ID: <46C195C6.6030507@gmail.com> Roman Kononov wrote: > Darmawan Salihun wrote: >> As I couldn't find any better replacement to the PCI direct I/O >> function at the moment (which is needed in chipset_enable and >> board_enable), I will try to implement them using a quite old kernel >> mode API, i.e. HalGetBusData and HalSetBusData. I hope the kernel >> "emulates" these functions so that it works like in NT4 and Windows >> 2000. > > A more "portable" way: > > Make all CPUs spinning inside a DPC function: > KeQueryActiveProcessors() is used to get all processors. > KeSetTargetProcessorDpc() is used to tie the DPC function and particular > SMP processors. > When all CPUs are spinning inside the function, one of them does IO > (CF8/CFC) to the PCI configuration space. > After the IO completes, let all DPC functions finish. > Anyway, in your experience. Is this approach takes quite a lot "time slice" in the kernel space? Regards, Darmawan From uwe at hermann-uwe.de Tue Aug 14 14:09:54 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Aug 2007 14:09:54 +0200 Subject: [LinuxBIOS] Desktop with LinuxBios ? In-Reply-To: <46C07E35.6020003@yahoo.de> References: <20070812102435.GC24932@coresystems.de> <28473585.1186998569919.JavaMail.root@m48> <004e01c7ddbe$07fffc50$0200a8c0@your55e5f9e3d2> <46C07E35.6020003@yahoo.de> Message-ID: <20070814120953.GA21218@greenwood> Hi, On Mon, Aug 13, 2007 at 05:52:21PM +0200, Quux wrote: > if you get a M57SLI for 84 ? it is good bang for the buck. Otherwise > there is only the ASUS A8N-E wich is out of stock but many people try to > get rid of it at ebay around 30? or so. There's also the ASUS A8NE-FM/S (which I own), that mostly works fine. I sent a patch a few weeks ago. There are some TODOs which need fixing, but it boots Linux just fine already. It can be had for 30-40 Euros on eBay, too. HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Tue Aug 14 14:12:28 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Aug 2007 14:12:28 +0200 Subject: [LinuxBIOS] is linuxbios installable on a VAIO VGN-AR21SR? In-Reply-To: <20070813015637.28544.qmail@stuge.se> References: <20070813015637.28544.qmail@stuge.se> Message-ID: <20070814121228.GB21218@greenwood> On Mon, Aug 13, 2007 at 03:56:37AM +0200, Peter Stuge wrote: > > will it erase BIOS config and password?. > > Yes, if the system was supported and you replaced the factory BIOS > with LB there would be nothing left. > > Note that some laptop hard drives have password protection. LB does > not currently offer any way to enter the password for such drives, > but it will be simple enough to add that once there is support for > the laptop itself. I think he was talking about the "BIOS password" option, not a hard drive password. However, that's an interesting question, too. Is there public documentation about this type of hard drive password mechanism? Can we easily implement such a feature? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Tue Aug 14 14:21:22 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Aug 2007 14:21:22 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070813004653.18174.qmail@stuge.se> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> Message-ID: <20070814122122.GC21218@greenwood> On Mon, Aug 13, 2007 at 02:46:53AM +0200, Peter Stuge wrote: > PLCC in socket? Which flash part? For the MSI K9N Neo (MS-7260), which I happen to own: PLCC, in a socket. I'll test flashrom later, but IIRC correctly it didn't work out of the box when I first tried it. > Is the problem the flash chip or the southbridge? Not sure, but I'll find out. > > AFIAK the only one in this "ultra-low-end" class that never got > > tried was the BIOSTAR Tforce 550 > > The K9N NEO-F is even nicer on the budget over here. Wow. > 2GHz dual core X2 + mobo + 2x512MB RAM = 140EUR! (ex 25% VAT) Yep, the board alone is available for 50,- in Germany, for example. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From peter at stuge.se Tue Aug 14 14:50:02 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 14:50:02 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C16544.6030900@gmail.com> References: <46C16544.6030900@gmail.com> Message-ID: <20070814125002.7288.qmail@stuge.se> On Tue, Aug 14, 2007 at 04:18:12AM -0400, Corey Osgood wrote: > I've tried roms from the original and latest jetway bios (that is > from the original), and also one from a via epia-cn, all give the > same result. Any help would be greatly appreciated. Please do dump say 1024 bytes at 0xc0000 before doing the BIOS init. Oh, and please try to get it working without vgabios.c if you can, those files are just horrible. :\ //Peter From peter at stuge.se Tue Aug 14 14:56:06 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 14:56:06 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C162D5.7020302@gmail.com> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> Message-ID: <20070814125606.8319.qmail@stuge.se> On Tue, Aug 14, 2007 at 03:07:49PM +0700, Darmawan Salihun wrote: > Moreover, direct port I/O was working flawlessly with the older > flashrom that I port to windows back then. I think the "DPC" trick > will guarantee the atomic operation and will give us the level of > confidence to do the direct port I/O. I am not at all confident about that. Roman did make a good point about IRQL but that does not eliminate the problem, we will still be changing hardware state underneath the OS and that is ALWAYS a bad idea. Please look into: http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html for Windows 2000 and newer. I do think we should try to support NT 4 as well, and there the Hal API is good, so please don't throw the code away yet. //Peter From peter at stuge.se Tue Aug 14 14:58:25 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 14:58:25 +0200 Subject: [LinuxBIOS] Hard drive passwords In-Reply-To: <20070814121228.GB21218@greenwood> References: <20070813015637.28544.qmail@stuge.se> <20070814121228.GB21218@greenwood> Message-ID: <20070814125826.8860.qmail@stuge.se> On Tue, Aug 14, 2007 at 02:12:28PM +0200, Uwe Hermann wrote: > > Note that some laptop hard drives have password protection. LB does > > not currently offer any way to enter the password for such drives, > > but it will be simple enough to add that once there is support for > > the laptop itself. > > I think he was talking about the "BIOS password" option, not a hard > drive password. However, that's an interesting question, too. Is > there public documentation about this type of hard drive password > mechanism? Yes, it's part of ATA-6 or so. > Can we easily implement such a feature? It's pretty easy to implement. Commands should be sent blind to the hard drive, to unlock it, only then will it actually start responding on the bus. Usually you get three tries, before the drive starts ignoring you completely until power down. //Peter From ml at saxnet.de Tue Aug 14 15:00:18 2007 From: ml at saxnet.de (Thomas Buschhardt) Date: Tue, 14 Aug 2007 15:00:18 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips Message-ID: <46C1A762.4060803@saxnet.de> Hallo, I'm new to BIOS-flashing and have some questions and hopefully you can help me out. I got a Galep5 programmer with a DIL32 to PLCC32 Adapter and samples of some flash-memory chips SST 49LF004B (33-4C-NHE). These samples are from Gneral Software Inc. and Insyde Software. I backup the original BIOS to files and delete the chip after that I wrote my linuxbios.rom to the chip(s) and put it to the motherboard (AMD LX DB800), but nothing happen. After that I wrote the original BIOS back to the chip (compare shown ok) and put these into the MB but nothing happen (again). The MB is ok (I tested with other samples). Now my question: Its possible these samples have some "protection" against use with other BIOS (linuxbios :-) ) or how can I find the error? Thanx for answers. Thomas From pratish.ganguly at gmail.com Tue Aug 14 15:07:24 2007 From: pratish.ganguly at gmail.com (pratish ganguly) Date: Tue, 14 Aug 2007 18:37:24 +0530 Subject: [LinuxBIOS] EEPROM/flash device not found error Message-ID: Hi I am using flashrom to upgrade the BIOS on AMD Geode db800 motherboard. I am getting the following error EEPROM/flash device not found. Please suggest me some pointers to solve the problem. Regards. Pratish Ganguly -------------- next part -------------- An HTML attachment was scrubbed... URL: From is at eseco.de Tue Aug 14 15:14:40 2007 From: is at eseco.de (Ingmar Schraub) Date: Tue, 14 Aug 2007 15:14:40 +0200 Subject: [LinuxBIOS] PC Engines ALIX board - flashrom Message-ID: <46C1AAC0.9010204@eseco.de> Hi, I got a new PC Engines ALIX board, which comes with the Geode LX800 / CS5536 chip. Since Pascal Dornier from PC Engines has shipped another board to Ron Minnich a few days ago, I contacted him already. Ron is interested in helping, but away for the next two weeks. So I got started, trying to let 'flashrom' detect the pieces. Note: I am an absolutely beginner when it comes to LinuxBIOS! So please forgive me if I explain things a bitn odd or wrong. ;-) The chipset is not detected. FLASH_ENABLE enables[] need an entry for 0x1022, 0x2090 and a enable_flash function. That's problem #1. What must be done inside flash_enable for that flash? Problem #2: the flash device is not deteced. However, I read on the flash chip "SST 49LF040B". According to the flashrom sources it should be supported. Any idea what's wrong here or what I would need to do? Thanks a lot in advance!! regards, Ingmar From peter at stuge.se Tue Aug 14 15:26:13 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 15:26:13 +0200 Subject: [LinuxBIOS] PC Engines ALIX board - flashrom In-Reply-To: <46C1AAC0.9010204@eseco.de> References: <46C1AAC0.9010204@eseco.de> Message-ID: <20070814132613.13654.qmail@stuge.se> On Tue, Aug 14, 2007 at 03:14:40PM +0200, Ingmar Schraub wrote: > I got a new PC Engines ALIX board, which comes with the Geode LX800 > / CS5536 chip. > > Since Pascal Dornier from PC Engines has shipped another board to > Ron Minnich a few days ago, I contacted him already. Ron is > interested in helping, but away for the next two weeks. If PC Engines want to support LB I'd say that's an advantage over the competition. :) > So I got started, trying to let 'flashrom' detect the pieces. Note: > I am an absolutely beginner when it comes to LinuxBIOS! So please > forgive me if I explain things a bitn odd or wrong. ;-) > > The chipset is not detected. > > FLASH_ENABLE enables[] need an entry for 0x1022, 0x2090 and a > enable_flash function. That's problem #1. What must be done inside > flash_enable for that flash? Stepan told me what was needed for the LX at LinuxTag but I forgot. It wasn't too much. enable_flash_*() are used to set specified bits in the southbridge to allow writes to go out to the flash chip. > Problem #2: the flash device is not deteced. This is because of (1). Writes need to go through to the flash chip in order to successfully detect the chip type. There may also be a need for a new board_enable_alix() if some additional GPIO signals are protecting the write signal to the flash. > However, I read on the flash chip "SST 49LF040B". According to the > flashrom sources it should be supported. Yep, it is, but until flashrom can get access to it (through the southbridge) we lose. > Any idea what's wrong here or what I would need to do? Look up how to enable flash writes in the LX data book and implement enable_flash_geodelx() for a start. //Peter From uwe at hermann-uwe.de Tue Aug 14 15:28:10 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Aug 2007 15:28:10 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070814122122.GC21218@greenwood> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> <20070814122122.GC21218@greenwood> Message-ID: <20070814132810.GA24494@greenwood> On Tue, Aug 14, 2007 at 02:21:22PM +0200, Uwe Hermann wrote: > > Is the problem the flash chip or the southbridge? > > Not sure, but I'll find out. OK, seems to be a mainboard issue: $ flashrom -wv foo.bin Calibrating delay loop... ok No LinuxBIOS table found. Found chipset "NVIDIA MCP55": Enabling flash write... OK. Pm49FL004 found at physical address: 0xfff80000 Flash part is Pm49FL004 (512 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 0007 at address: 0x00070000 Verifying flash - FAILED Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From peter at stuge.se Tue Aug 14 15:28:14 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 15:28:14 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: References: Message-ID: <20070814132814.14096.qmail@stuge.se> On Tue, Aug 14, 2007 at 06:37:24PM +0530, pratish ganguly wrote: > Hi > I am using flashrom to upgrade the BIOS on AMD Geode db800 > motherboard. I am getting the following error > > EEPROM/flash device not found. > > Please suggest me some pointers to solve the problem. Please see the ALIX thread. Everything there applies to db800 as well, except the possible need for a board_enable_db800 which is only dependant on the circuit design on the db800. //Peter From peter at stuge.se Tue Aug 14 15:34:11 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 15:34:11 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <46C1A762.4060803@saxnet.de> References: <46C1A762.4060803@saxnet.de> Message-ID: <20070814133411.15022.qmail@stuge.se> On Tue, Aug 14, 2007 at 03:00:18PM +0200, Thomas Buschhardt wrote: > I'm new to BIOS-flashing and have some questions and hopefully you > can help me out. I got a Galep5 programmer with a DIL32 to PLCC32 > Adapter and samples of some flash-memory chips SST 49LF004B > (33-4C-NHE). Good stuff. > These samples are from Gneral Software Inc. and Insyde Software. I > backup the original BIOS to files and delete the chip after that I > wrote my linuxbios.rom to the chip(s) and put it to the motherboard > (AMD LX DB800), but nothing happen. This could quite possibly be because the linuxbios.rom file just doesn't work for the board. (Have you seen that file work on another db800 board?) > After that I wrote the original BIOS back to the chip (compare > shown ok) and put these into the MB but nothing happen (again). This is on the other hand rather strange. > The MB is ok (I tested with other samples). > Now my question: Its possible these samples have some "protection" > against use with other BIOS (linuxbios :-) ) Not really. > or how can I find the error? Compare contents of the restored flash with one of the other samples. If different, try putting the new contents into the restored flash chip and see if it works. If not, you have a very strange situation indeed, where one flash chip works and another does not, when they both have the same contents. Are the flash chips the exact same model? Compare all the letters and numbers on them. Did you successfully boot the board using the restored chip before flashing it with LB? If you didn't try this, the contents may just not have been appropriate for the board. //Peter From darmawan.salihun at gmail.com Tue Aug 14 15:49:22 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 14 Aug 2007 20:49:22 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070814125606.8319.qmail@stuge.se> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> Message-ID: <46C1B2E2.10604@gmail.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 03:07:49PM +0700, Darmawan Salihun wrote: >> Moreover, direct port I/O was working flawlessly with the older >> flashrom that I port to windows back then. I think the "DPC" trick >> will guarantee the atomic operation and will give us the level of >> confidence to do the direct port I/O. > > I am not at all confident about that. > > Roman did make a good point about IRQL but that does not eliminate > the problem, we will still be changing hardware state underneath the > OS and that is ALWAYS a bad idea. > > Please look into: > > http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm > http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html > > for Windows 2000 and newer. > > > I do think we should try to support NT 4 as well, and there the > Hal API is good, so please don't throw the code away yet. No, I'm not. I put the code into my own local repository for future experimentation. Anyway, I've read both of the articles you mentioned. I will try looking into the issue much further tonight. I may missed something ;-). The problem is HalSetBusDataByOffset is not working as documented in MSDN :-(. --Darmawan From peter at stuge.se Tue Aug 14 15:59:46 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 15:59:46 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C1B2E2.10604@gmail.com> References: <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1B2E2.10604@gmail.com> Message-ID: <20070814135946.19210.qmail@stuge.se> On Tue, Aug 14, 2007 at 08:49:22PM +0700, Darmawan Salihun wrote: > > Please look into: > > > > http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm > > http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html > > > > for Windows 2000 and newer. > > > > > > I do think we should try to support NT 4 as well, and there the > > Hal API is good, so please don't throw the code away yet. > > No, I'm not. I put the code into my own local repository for future > experimentation. Excellent! :) Though not a high priority I think the typical NT 4 server should be treated to some LB fun as well. :) > Anyway, I've read both of the articles you mentioned. I will try > looking into the issue much further tonight. I may missed something > ;-). > > The problem is HalSetBusDataByOffset is not working as documented > in MSDN :-(. Both those pages show pretty complete examples of how the PnP Manager is used to do PCI config reads and writes, exactly because the HAL is deprecated. Please check out the code there, it looks like it could solve your problem. //Peter From pawn2be.wild at yahoo.de Tue Aug 14 16:07:28 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Tue, 14 Aug 2007 16:07:28 +0200 Subject: [LinuxBIOS] Hard drive passwords In-Reply-To: <20070814125826.8860.qmail@stuge.se> References: <20070813015637.28544.qmail@stuge.se> <20070814121228.GB21218@greenwood> <20070814125826.8860.qmail@stuge.se> Message-ID: <46C1B720.1030009@yahoo.de> there is also the issue, that unless BIOS disables the feature, a virus can lock up a modern hard drive for good at run time. this was reported on c't security some time ago. There were no known legacy BIOSes aware of this vulnerability at the time (~2005). --Q Peter Stuge schrieb: >>> Note that some laptop hard drives have password protection. LB does From peter at stuge.se Tue Aug 14 16:11:16 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 16:11:16 +0200 Subject: [LinuxBIOS] Hard drive passwords In-Reply-To: <46C1B720.1030009@yahoo.de> References: <20070813015637.28544.qmail@stuge.se> <20070814121228.GB21218@greenwood> <20070814125826.8860.qmail@stuge.se> <46C1B720.1030009@yahoo.de> Message-ID: <20070814141116.21730.qmail@stuge.se> On Tue, Aug 14, 2007 at 04:07:28PM +0200, Quux wrote: > there is also the issue, that unless BIOS disables the feature, a virus > can lock up a modern hard drive for good at run time. this was reported > on c't security some time ago. Hah. :p Well, not for good? It wouldn't be too difficult to make a brute force thingy that tests a few passwords then resets power, then continues. I don't believe the drive ever locks up completely, regardless of the number of tries. > There were no known legacy BIOSes aware of this vulnerability at > the time (~2005). --Q LB 1 - legacy 0 //Peter From joe at smittys.pointclark.net Tue Aug 14 18:06:25 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 14 Aug 2007 12:06:25 -0400 Subject: [LinuxBIOS] Setting up ethernet - help Message-ID: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> OK I am having a problem setting up my ethernet controller in src/mainboard Config.lb. Quoting from the i82830 Datasheet: Logically, the ICH3-M appears as two PCI devices within a single physical component also residing on PCI bus #0. One of the ICH4 devices residing on PCI Bus #0 is a PCI-to-PCI bridge. Logically, the primary side of the bridge resides on PCI bus #0 while the secondary side is the standard PCI expansion bus (PCI0). Also within the ICH3-M is another PCI Device, the LAN Controller, which resides on the standard PCI expansion bus (PCI0) down from the PCI-to-PCI bridge. lspci -n 00:1e.0 0604: 8086:244e (rev 82) 01:08.0 0200: 8086:103a (rev 82) lspci-tvv -[0000:00]-+-1e.0-[0000:01]----08.0 Intel Corporation 82801DB PRO/100 VE (CNR) Ethernet Controller lspci-v 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: ff700000-ff7fffff 01:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (CNR) Ethernet Controller (rev 82) Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at ff7ff000 (32-bit, non-prefetchable) [size=4K] I/O ports at dc00 [size=64] Capabilities: [dc] Power Management version 2 How the heck do I set this up in Config.lb? HELP?? Thanks - Joe From peter at stuge.se Tue Aug 14 18:06:57 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 18:06:57 +0200 Subject: [LinuxBIOS] Biostar K8T800-A7A In-Reply-To: <82ca492c0708130307n78c18120ob89aca22523ee14a@mail.gmail.com> References: <82ca492c0708130307n78c18120ob89aca22523ee14a@mail.gmail.com> Message-ID: <20070814160657.12010.qmail@stuge.se> On Mon, Aug 13, 2007 at 04:07:26AM -0600, Donovan Lavinder wrote: > I'm wondering if anybody are working on this particular model, > K8T800-A7A motherboard? Not that we know of. There is work being done on another VIA chipset, but not this particular board. > I would like to know, so I would like to have one flashed on my > motherboard. Also, what's the recommend steps to flash it onto my > motherboard while running Windows 2000? Darmawan Salihun is currently making flashrom work also on Windows based systems. //Peter From peter at stuge.se Tue Aug 14 18:16:24 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 18:16:24 +0200 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> Message-ID: <20070814161624.13673.qmail@stuge.se> On Tue, Aug 14, 2007 at 12:06:25PM -0400, Joseph Smith wrote: > lspci-tvv > -[0000:00]-+-1e.0-[0000:01]----08.0 Intel Corporation 82801DB PRO/100 > VE (CNR) Ethernet Controller > > How the heck do I set this up in Config.lb? HELP?? Looks like it's been done before: --8<-- src/mainboard/asus/mew-vm/Config.lb chip southbridge/intel/i82801xx # Southbridge device pci 1e.0 on # PCI Bridge #chip drivers/pci/onboard # device pci 1.0 on end # register "rom_address" = "0xfff80000" #end end .. end -->8-- //Peter From joe at smittys.pointclark.net Tue Aug 14 18:30:14 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 14 Aug 2007 12:30:14 -0400 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814161624.13673.qmail@stuge.se> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> Message-ID: <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> Quoting Peter Stuge : > On Tue, Aug 14, 2007 at 12:06:25PM -0400, Joseph Smith wrote: >> lspci-tvv >> -[0000:00]-+-1e.0-[0000:01]----08.0 Intel Corporation 82801DB PRO/100 >> VE (CNR) Ethernet Controller >> >> How the heck do I set this up in Config.lb? HELP?? > > Looks like it's been done before: > > --8<-- src/mainboard/asus/mew-vm/Config.lb > chip southbridge/intel/i82801xx # Southbridge > device pci 1e.0 on # PCI Bridge > #chip drivers/pci/onboard > # device pci 1.0 on end > # register "rom_address" = "0xfff80000" > #end > end > .. > end > -->8-- > > > //Peter > Does that mean I would have to cat in a ethernet rom? Also, wouldn't it be device pci 08.0 on end Thanks - Joe From peter at stuge.se Tue Aug 14 18:40:16 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 18:40:16 +0200 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> Message-ID: <20070814164016.18214.qmail@stuge.se> On Tue, Aug 14, 2007 at 12:30:14PM -0400, Joseph Smith wrote: > > On Tue, Aug 14, 2007 at 12:06:25PM -0400, Joseph Smith wrote: > >> lspci-tvv > >> -[0000:00]-+-1e.0-[0000:01]----08.0 Intel Corporation 82801DB PRO/100 > >> VE (CNR) Ethernet Controller > >> > >> How the heck do I set this up in Config.lb? HELP?? > > > > Looks like it's been done before: > > > > --8<-- src/mainboard/asus/mew-vm/Config.lb > > chip southbridge/intel/i82801xx # Southbridge > > device pci 1e.0 on # PCI Bridge > > #chip drivers/pci/onboard > > # device pci 1.0 on end > > # register "rom_address" = "0xfff80000" > > #end > > end > > .. > > end > > -->8-- > > Does that mean I would have to cat in a ethernet rom? Do you or the chip need one? Is there one in the factory BIOS or in a standalone flash chip or none at all? > Also, wouldn't it be device pci 08.0 on end Yep. I only looked for the PCI-PCI bridge. //Peter From peter at stuge.se Tue Aug 14 18:42:27 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 18:42:27 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070814132810.GA24494@greenwood> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> <20070814122122.GC21218@greenwood> <20070814132810.GA24494@greenwood> Message-ID: <20070814164227.18593.qmail@stuge.se> On Tue, Aug 14, 2007 at 03:28:10PM +0200, Uwe Hermann wrote: > On Tue, Aug 14, 2007 at 02:21:22PM +0200, Uwe Hermann wrote: > > > Is the problem the flash chip or the southbridge? > > > > Not sure, but I'll find out. > > OK, seems to be a mainboard issue: > > Found chipset "NVIDIA MCP55": Enabling flash write... OK. > Pm49FL004 found at physical address: 0xfff80000 All other problems have also been with the PMC parts IIRC. Do you have any other LPC flash chips? //Peter From joe at smittys.pointclark.net Tue Aug 14 18:54:04 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 14 Aug 2007 12:54:04 -0400 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814164016.18214.qmail@stuge.se> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> <20070814164016.18214.qmail@stuge.se> Message-ID: <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> Quoting Peter Stuge : > On Tue, Aug 14, 2007 at 12:30:14PM -0400, Joseph Smith wrote: >> > On Tue, Aug 14, 2007 at 12:06:25PM -0400, Joseph Smith wrote: >> >> lspci-tvv >> >> -[0000:00]-+-1e.0-[0000:01]----08.0 Intel Corporation 82801DB PRO/100 >> >> VE (CNR) Ethernet Controller >> >> >> >> How the heck do I set this up in Config.lb? HELP?? >> > >> > Looks like it's been done before: >> > >> > --8<-- src/mainboard/asus/mew-vm/Config.lb >> > chip southbridge/intel/i82801xx # Southbridge >> > device pci 1e.0 on # PCI Bridge >> > #chip drivers/pci/onboard >> > # device pci 1.0 on end >> > # register "rom_address" = "0xfff80000" >> > #end >> > end >> > .. >> > end >> > -->8-- >> >> Does that mean I would have to cat in a ethernet rom? > > Do you or the chip need one? Is there one in the factory BIOS or in a > standalone flash chip or none at all? > > >> Also, wouldn't it be device pci 08.0 on end > > Yep. I only looked for the PCI-PCI bridge. > > > //Peter > I don't need an ethernet rom. Etherboot would take care of that correct? But in the config above it is alocating 0xfff80000 for a PCI rom, correct? My VGA bios is already using 0xfff80000. Thanks - Joe From kononov at dls.net Tue Aug 14 19:14:22 2007 From: kononov at dls.net (Roman Kononov) Date: Tue, 14 Aug 2007 12:14:22 -0500 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070814125606.8319.qmail@stuge.se> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> Message-ID: <46C1E2EE.9000807@dls.net> On 08/14/2007 07:56 AM, Peter Stuge wrote: > Roman did make a good point about IRQL but that does not eliminate > the problem, we will still be changing hardware state underneath the > OS and that is ALWAYS a bad idea. The CF8/CFC sequence can preserve CF8 port value. What other hardware state would be changed? > http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm > http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html BTW, here is the "official" example: http://support.microsoft.com/kb/253232 Unfortunately, AFAIK, this approach does not work for cases like yours. It requires the "DeviceObject", which MUST be associated with a PARTICULAR PCI function. Q: In the above links, among HtsReadWriteConfig() and WritePCIConfigSpace() argument lists, which arguments are bus number and device number? A: They are inside PDEVICE_OBJECT, which structure is "opaque". Regarding how long DPC method takes. A scheduled DPC is launched as soon as the CPU's IRQL drops below DISPATCH_LEVEL. The CPU can be at DISPATCH_LEVEL (and higher) only running kernel code. This can last many time slices. This means that the DPC method might be quite expensive. Regards, Roman From marc.jones at amd.com Tue Aug 14 19:25:38 2007 From: marc.jones at amd.com (Marc Jones) Date: Tue, 14 Aug 2007 11:25:38 -0600 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070814132814.14096.qmail@stuge.se> References: <20070814132814.14096.qmail@stuge.se> Message-ID: <46C1E592.4080103@amd.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 06:37:24PM +0530, pratish ganguly wrote: >> Hi >> I am using flashrom to upgrade the BIOS on AMD Geode db800 >> motherboard. I am getting the following error >> >> EEPROM/flash device not found. >> >> Please suggest me some pointers to solve the problem. > > Please see the ALIX thread. Everything there applies to db800 as > well, except the possible need for a board_enable_db800 which is > only dependant on the circuit design on the db800. > > > //Peter > This page on over on OLPC twiki should probably be brought over to the LinuxBIOS twiki. http://wiki.laptop.org/go/Flashing_LinuxBIOS Is it worth adding rdmsr/wrmsr to flashrom? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From peter at stuge.se Tue Aug 14 19:27:05 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 19:27:05 +0200 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> <20070814164016.18214.qmail@stuge.se> <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> Message-ID: <20070814172705.26255.qmail@stuge.se> On Tue, Aug 14, 2007 at 12:54:04PM -0400, Joseph Smith wrote: > >> Does that mean I would have to cat in a ethernet rom? > > > > Do you or the chip need one? Is there one in the factory BIOS or > > in a standalone flash chip or none at all? > > I don't need an ethernet rom. Etherboot would take care of that > correct? For booting from network, yes. But maybe the hardware needs the ROM for initialization? Where is the MAC address stored? Note there doesn't seem to be any ROM even with the factory BIOS. > But in the config above it is alocating 0xfff80000 for a PCI > rom, correct? Yes. > My VGA bios is already using 0xfff80000. If you would need one more ROM just change that address to match what is in the flash chip. Add the size of the VGA BIOS and you'd have the address for the next ROM image. But seems you don't need one. //Peter From svn at openbios.org Tue Aug 14 20:36:12 2007 From: svn at openbios.org (LinuxBIOS) Date: Tue, 14 Aug 2007 18:36:12 -0000 Subject: [LinuxBIOS] #87: flashrom issues on m57sli-s4 In-Reply-To: <041.ecf9a38049d8bbbe15bbb6ff0a642599@openbios.org> References: <041.ecf9a38049d8bbbe15bbb6ff0a642599@openbios.org> Message-ID: <050.f92b36f81097a6ed224060409948e08b@openbios.org> #87: flashrom issues on m57sli-s4 -------------------------+-------------------------------------------------- Reporter: ward | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: there is no patch -------------------------+-------------------------------------------------- Changes (by ward): * component: code => flashrom -- Ticket URL: LinuxBIOS From uwe at hermann-uwe.de Tue Aug 14 20:52:44 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 14 Aug 2007 20:52:44 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070814164227.18593.qmail@stuge.se> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> <20070814122122.GC21218@greenwood> <20070814132810.GA24494@greenwood> <20070814164227.18593.qmail@stuge.se> Message-ID: <20070814185244.GA28288@greenwood> On Tue, Aug 14, 2007 at 06:42:27PM +0200, Peter Stuge wrote: > On Tue, Aug 14, 2007 at 03:28:10PM +0200, Uwe Hermann wrote: > > On Tue, Aug 14, 2007 at 02:21:22PM +0200, Uwe Hermann wrote: > > > > Is the problem the flash chip or the southbridge? > > > > > > Not sure, but I'll find out. > > > > OK, seems to be a mainboard issue: > > > > Found chipset "NVIDIA MCP55": Enabling flash write... OK. > > Pm49FL004 found at physical address: 0xfff80000 > > All other problems have also been with the PMC parts IIRC. > > Do you have any other LPC flash chips? I don't think the chip is the problem; I just tested another one which I know works fine in the ASUS A8NE-FM/S (however, it's a Pm49FL004 too). The writing fails with that chip. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From peter at stuge.se Tue Aug 14 21:22:27 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 21:22:27 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070814185244.GA28288@greenwood> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> <20070813004653.18174.qmail@stuge.se> <20070814122122.GC21218@greenwood> <20070814132810.GA24494@greenwood> <20070814164227.18593.qmail@stuge.se> <20070814185244.GA28288@greenwood> Message-ID: <20070814192227.12882.qmail@stuge.se> On Tue, Aug 14, 2007 at 08:52:44PM +0200, Uwe Hermann wrote: > > All other problems have also been with the PMC parts IIRC. > > > > Do you have any other LPC flash chips? > > I don't think the chip is the problem; Not the particular chip, but I would like to rule out the chip type. > I just tested another one which I know works fine in the ASUS > A8NE-FM/S (however, it's a Pm49FL004 too). That board has a CK804 southbridge though, right? > The writing fails with that chip. AFAIK all problems involve MCP55 and PMC flash, even if it's just the inactive chip in a BIOS savior and flashrom should write the other, active chip in a BIOS savior. Ward's problems are with MCP55+SST-in-BIOS-savior. As I recall Ward got SST chips working if they were put directly in the socket on the board. The PMC chips can do both LPC and FWH so they have their own state machine which is a bit different from those in a single-protocol chip. Not a lot, but maybe enough to cause trouble under some circumstances, which happens to collide with what flashrom does. Yes, it's just a suspicion. //Peter From peter at stuge.se Tue Aug 14 21:28:38 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 21:28:38 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C1E592.4080103@amd.com> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> Message-ID: <20070814192838.13977.qmail@stuge.se> On Tue, Aug 14, 2007 at 11:25:38AM -0600, Marc Jones wrote: > Is it worth adding rdmsr/wrmsr to flashrom? Is there a better option? Is it neccessary to always write all 64 bits of the MSR by the way? //Peter From peter at stuge.se Tue Aug 14 21:47:48 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 14 Aug 2007 21:47:48 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C1E2EE.9000807@dls.net> References: <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> Message-ID: <20070814194748.17110.qmail@stuge.se> On Tue, Aug 14, 2007 at 12:14:22PM -0500, Roman Kononov wrote: > On 08/14/2007 07:56 AM, Peter Stuge wrote: > > Roman did make a good point about IRQL but that does not eliminate > > the problem, we will still be changing hardware state underneath the > > OS and that is ALWAYS a bad idea. > > The CF8/CFC sequence can preserve CF8 port value. What other > hardware state would be changed? The bits that are changed in the device config space. > > http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm > > http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html > > BTW, here is the "official" example: > http://support.microsoft.com/kb/253232 > > Unfortunately, AFAIK, this approach does not work for cases like > yours. It requires the "DeviceObject", which MUST be associated > with a PARTICULAR PCI function. Right, I assumed that it would be possible to get that through some sequence of system calls that look at the PCI bus. > Q: In the above links, among HtsReadWriteConfig() and > WritePCIConfigSpace() argument lists, which arguments are bus > number and device number? > A: They are inside PDEVICE_OBJECT, which structure is "opaque". Yup. Are you saying it is simply not possible to access PCI config space of a device from a device driver unless the driver is in fact part of the driver stack associated with that device? I suppose Microsoft considers that a feature? It would certainly explain why there aren't already several applications for reprogramming flash on Windows. But, on the other hand, there are a few applications that _do_. So how do they do it? > This means that the DPC method might be quite expensive. If this is the only way to access PCI config space for unrelated devices then I guess it's the best we can do - unless we can make ourselves be part of the driver stack for the southbridge? Or maybe there is in fact a userspace API for PCI config access? I am by no means a Windows API or WDM expert, then I'd already written the code. :p That world is a pretty strange place. //Peter From jordan.crouse at amd.com Tue Aug 14 22:01:46 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Tue, 14 Aug 2007 14:01:46 -0600 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070814192838.13977.qmail@stuge.se> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> Message-ID: <20070814200146.GD30239@cosmic.amd.com> On 14/08/07 21:28 +0200, Peter Stuge wrote: > On Tue, Aug 14, 2007 at 11:25:38AM -0600, Marc Jones wrote: > > Is it worth adding rdmsr/wrmsr to flashrom? > > Is there a better option? Nope. You need MSR acess, and thats the only way to get it from userspace. > Is it neccessary to always write all 64 bits of the MSR by the way? Yes - at least this way, which uses just a straight wrmsr in the kernel. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From bari at onelabs.com Wed Aug 15 00:05:46 2007 From: bari at onelabs.com (bari) Date: Tue, 14 Aug 2007 17:05:46 -0500 Subject: [LinuxBIOS] Any VIA C7 Support? Message-ID: <46C2273A.10100@onelabs.com> Has anyone started on supporting the VIA C7 cpu's yet? -Bari From peter at stuge.se Wed Aug 15 00:08:11 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 00:08:11 +0200 Subject: [LinuxBIOS] Any VIA C7 Support? In-Reply-To: <46C2273A.10100@onelabs.com> References: <46C2273A.10100@onelabs.com> Message-ID: <20070814220811.9071.qmail@stuge.se> On Tue, Aug 14, 2007 at 05:05:46PM -0500, bari wrote: > Has anyone started on supporting the VIA C7 cpu's yet? I think that's what Corey has working, to a point at least. C7+DDR2+CN700 //Peter From kononov at dls.net Wed Aug 15 00:30:53 2007 From: kononov at dls.net (Roman Kononov) Date: Tue, 14 Aug 2007 17:30:53 -0500 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070814194748.17110.qmail@stuge.se> References: <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> Message-ID: <46C22D1D.1090102@dls.net> On 08/14/2007 02:47 PM, Peter Stuge wrote: >> The CF8/CFC sequence can preserve CF8 port value. What other >> hardware state would be changed? > > The bits that are changed in the device config space. I cannot imagine why the OS would care about a couple of configuration bits in the SB. > Yup. Are you saying it is simply not possible to access PCI config > space of a device from a device driver unless the driver is in fact > part of the driver stack associated with that device? Yes. > I suppose Microsoft considers that a feature? Yes. They don't want one driver to mess with other devices. > But, on the other hand, there are a few applications that _do_. > So how do they do it? Using undocumented features is not uncommon in Windows. > we can make > ourselves be part of the driver stack for the southbridge? It sounds too painful. > Or maybe there is in fact a userspace API for PCI config access? I doubt. It would be a huge security hole. > I am by no means a Windows API or WDM expert, then I'd already > written the code. :p That world is a pretty strange place. Lucky you... It is not a pleasure to write Windows code. Regards, Roman From corey.osgood at gmail.com Wed Aug 15 03:41:14 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 14 Aug 2007 21:41:14 -0400 Subject: [LinuxBIOS] Any VIA C7 Support? In-Reply-To: <20070814220811.9071.qmail@stuge.se> References: <46C2273A.10100@onelabs.com> <20070814220811.9071.qmail@stuge.se> Message-ID: <46C259BA.1000408@gmail.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 05:05:46PM -0500, bari wrote: > >> Has anyone started on supporting the VIA C7 cpu's yet? >> > > I think that's what Corey has working, to a point at least. > > C7+DDR2+CN700 > > > //Peter The C7 itself works fine with the via model_centaur code, just add the appropriate cpu ids. The C3 Nehemiah and later are actually C5Js, which are very similar to the C7. All of the above use the same init sequence. -Corey From corey.osgood at gmail.com Wed Aug 15 03:49:45 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 14 Aug 2007 21:49:45 -0400 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070814172705.26255.qmail@stuge.se> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> <20070814164016.18214.qmail@stuge.se> <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> <20070814172705.26255.qmail@stuge.se> Message-ID: <46C25BB9.9020906@gmail.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 12:54:04PM -0400, Joseph Smith wrote: > >>>> Does that mean I would have to cat in a ethernet rom? >>>> >>> Do you or the chip need one? Is there one in the factory BIOS or >>> in a standalone flash chip or none at all? >>> >> I don't need an ethernet rom. Etherboot would take care of that >> correct? >> > > For booting from network, yes. But maybe the hardware needs the ROM > for initialization? Where is the MAC address stored? Note there > doesn't seem to be any ROM even with the factory BIOS. > MAC address is stored in hardware. I honestly couldn't tell you why that code is there, but it shouldn't be, no rom is necessary. I'm guessing it was left over from my attempt at getting vga to run, but I'm not sure why I would have attached it to the ethernet (perhaps bad copy and paste?). Anyone wishing to remove it feel free, one of these days I'll wrap up that port, but no time for now. -Corey From corey.osgood at gmail.com Wed Aug 15 03:53:44 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Tue, 14 Aug 2007 21:53:44 -0400 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <20070814125002.7288.qmail@stuge.se> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> Message-ID: <46C25CA8.6000705@gmail.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 04:18:12AM -0400, Corey Osgood wrote: > >> I've tried roms from the original and latest jetway bios (that is >> from the original), and also one from a via epia-cn, all give the >> same result. Any help would be greatly appreciated. >> > > Please do dump say 1024 bytes at 0xc0000 before doing the BIOS init. > > Oh, and please try to get it working without vgabios.c if you can, > those files are just horrible. :\ > > > //Peter Alright, I'll give it a shot. I assume you mean after the bios is copied, but before it runs? -Corey From peter at stuge.se Wed Aug 15 04:03:26 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 04:03:26 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C25CA8.6000705@gmail.com> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> Message-ID: <20070815020326.15047.qmail@stuge.se> On Tue, Aug 14, 2007 at 09:53:44PM -0400, Corey Osgood wrote: > > Please do dump say 1024 bytes at 0xc0000 before doing the BIOS > > init. > > Alright, I'll give it a shot. I assume you mean after the bios is > copied, but before it runs? Yep. //Peter From joe at smittys.pointclark.net Wed Aug 15 08:34:19 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Wed, 15 Aug 2007 02:34:19 -0400 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <46C25BB9.9020906@gmail.com> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> <20070814164016.18214.qmail@stuge.se> <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> <20070814172705.26255.qmail@stuge.se> <46C25BB9.9020906@gmail.com> Message-ID: <20070815023419.9nburqjvsowww8k0@smittys.pointclark.net> Quoting Corey Osgood : > Peter Stuge wrote: >> On Tue, Aug 14, 2007 at 12:54:04PM -0400, Joseph Smith wrote: >> >>>>> Does that mean I would have to cat in a ethernet rom? >>>>> >>>> Do you or the chip need one? Is there one in the factory BIOS or >>>> in a standalone flash chip or none at all? >>>> >>> I don't need an ethernet rom. Etherboot would take care of that >>> correct? >>> >> >> For booting from network, yes. But maybe the hardware needs the ROM >> for initialization? Where is the MAC address stored? Note there >> doesn't seem to be any ROM even with the factory BIOS. >> > > MAC address is stored in hardware. Ok, so can I just do this with out specifing a PCI expansion rom address? device pci 1e.0 on # PCI Bridge chip drivers/pci/onboard device pci 08.0 on end # Intel PRO/100 VE (CNR) Ethernet Controller end end Thanks - Joe From ml at saxnet.de Wed Aug 15 08:50:49 2007 From: ml at saxnet.de (Thomas Buschhardt) Date: Wed, 15 Aug 2007 08:50:49 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <20070814133411.15022.qmail@stuge.se> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> Message-ID: <46C2A249.30502@saxnet.de> Hallo Peter, thanks for your answer > This could quite possibly be because the linuxbios.rom file just > doesn't work for the board. (Have you seen that file work on another > db800 board?) > OK its really possible the rom I build is broken. > Compare contents of the restored flash with one of the other samples. > If different, try putting the new contents into the restored flash > chip and see if it works. If not, you have a very strange situation > indeed, where one flash chip works and another does not, when they > both have the same contents. Are the flash chips the exact same > model? Compare all the letters and numbers on them. > Oh my god - I find the error - like you suggest, I compare the contents and it differ. It differ on all chips on all burnsessions. Hmm its only 2 options - the chips are damage or the programmer (Galep) Greetz Thomas From peter at stuge.se Wed Aug 15 09:44:12 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 09:44:12 +0200 Subject: [LinuxBIOS] Setting up ethernet - help In-Reply-To: <20070815023419.9nburqjvsowww8k0@smittys.pointclark.net> References: <20070814120625.7xj8ssq70g0g8owo@simittys.pointclark.net> <20070814161624.13673.qmail@stuge.se> <20070814123014.dv0t70am84ssgs0k@simittys.pointclark.net> <20070814164016.18214.qmail@stuge.se> <20070814125404.mf1nsi5pss84048g@www.smittys.pointclark.net> <20070814172705.26255.qmail@stuge.se> <46C25BB9.9020906@gmail.com> <20070815023419.9nburqjvsowww8k0@smittys.pointclark.net> Message-ID: <20070815074412.3844.qmail@stuge.se> On Wed, Aug 15, 2007 at 02:34:19AM -0400, Joseph Smith wrote: > > MAC address is stored in hardware. > > Ok, so can I just do this with out specifing a PCI expansion rom address? > > device pci 1e.0 on # PCI Bridge > chip drivers/pci/onboard > device pci 08.0 on end # Intel PRO/100 VE (CNR) Ethernet > Controller > end > end Looks good! //Peter From darmawan.salihun at gmail.com Wed Aug 15 10:21:29 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 15 Aug 2007 15:21:29 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C22D1D.1090102@dls.net> References: <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> <46C22D1D.1090102@dls.net> Message-ID: <46C2B789.6060107@gmail.com> Roman Kononov wrote: > On 08/14/2007 02:47 PM, Peter Stuge wrote: >>> The CF8/CFC sequence can preserve CF8 port value. What other >>> hardware state would be changed? >> The bits that are changed in the device config space. > > I cannot imagine why the OS would care about a couple of configuration bits > in the SB. > >> Yup. Are you saying it is simply not possible to access PCI config >> space of a device from a device driver unless the driver is in fact >> part of the driver stack associated with that device? > > Yes. Yeah, this is an already known issue from the beginning ;-). Technically, we don't have the PDO of the southbridge chip, therefore we cannot access it in anyway as documented by Micro$oft. Regards, Darmawan Salihun From peter at stuge.se Wed Aug 15 10:26:43 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 10:26:43 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C2B789.6060107@gmail.com> References: <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> <46C22D1D.1090102@dls.net> <46C2B789.6060107@gmail.com> Message-ID: <20070815082643.11270.qmail@stuge.se> On Wed, Aug 15, 2007 at 03:21:29PM +0700, Darmawan Salihun wrote: > >> Yup. Are you saying it is simply not possible to access PCI config > >> space of a device from a device driver unless the driver is in fact > >> part of the driver stack associated with that device? > > > > Yes. > > Yeah, this is an already known issue from the beginning ;-). > Technically, we don't have the PDO of the southbridge chip, > therefore we cannot access it in anyway as documented by Micro$oft. What is required to get into the southbridge driver stack? From darmawan.salihun at gmail.com Wed Aug 15 10:37:28 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 15 Aug 2007 15:37:28 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070815082643.11270.qmail@stuge.se> References: <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> <46C22D1D.1090102@dls.net> <46C2B789.6060107@gmail.com> <20070815082643.11270.qmail@stuge.se> Message-ID: <46C2BB48.6080207@gmail.com> Peter Stuge wrote: > On Wed, Aug 15, 2007 at 03:21:29PM +0700, Darmawan Salihun wrote: >>>> Yup. Are you saying it is simply not possible to access PCI config >>>> space of a device from a device driver unless the driver is in fact >>>> part of the driver stack associated with that device? >>> Yes. >> Yeah, this is an already known issue from the beginning ;-). >> Technically, we don't have the PDO of the southbridge chip, >> therefore we cannot access it in anyway as documented by Micro$oft. > > What is required to get into the southbridge driver stack? I'm not too sure. I think a "PCI bus filter driver", but that would be an overkill at the moment. The other problem is it's not well documented (maybe not documented at all :-/). I hardly found information about such a thing. Even, experts in Windows driver development says so. >>From the little reading I've done the last day or two it seems that > a driver would not have to do very much once in the stack. Is it > really not feasible? It would definately be the cleanest way. Yes, this is the cleanest way. However, we have to "attach" our driver entry point functions, including "AddDevice" function upon the first time the southbridge driver is installed. More like we make a driver for Intel, NVidia, AMD or Via chipset driver. The PnP manager will try to find the driver for the corresponding device the first time it's found after Windows installation and it seems once it has the driver we wouldn't be able to add our own "hook" into the driver stack. Unless we make the thing called "PCI bus filter driver" or other "Bus filter driver" as needed. But, the problem goes back to the beginning, it's not even documented. I think Microsoft has a reason to make it not documented. Regards, Darmawan From is at eseco.de Wed Aug 15 11:21:46 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 11:21:46 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070814200146.GD30239@cosmic.amd.com> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> Message-ID: <46C2C5AA.1020406@eseco.de> Jordan Crouse wrote: > On 14/08/07 21:28 +0200, Peter Stuge wrote: >> On Tue, Aug 14, 2007 at 11:25:38AM -0600, Marc Jones wrote: >>> Is it worth adding rdmsr/wrmsr to flashrom? >> Is there a better option? > > Nope. You need MSR acess, and thats the only way to get it from > userspace. > >> Is it neccessary to always write all 64 bits of the MSR by the way? > > Yes - at least this way, which uses just a straight wrmsr in the kernel. Okay, I hacked that in and it seems to work. My SST49LF040B flash chip is properly identified at 0xfff80000. How would you call the enable_flash function in chipset_enable? E.g. enable_flash_cs5536 or enable_flash_geodelx ? Ingmar From peter at stuge.se Wed Aug 15 11:35:33 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 11:35:33 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C2C5AA.1020406@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> Message-ID: <20070815093533.1450.qmail@stuge.se> On Wed, Aug 15, 2007 at 11:21:46AM +0200, Ingmar Schraub wrote: > >> Is it neccessary to always write all 64 bits of the MSR by the > >> way? > > > > Yes - at least this way, which uses just a straight wrmsr in the > > kernel. > > Okay, I hacked that in and it seems to work. My SST49LF040B flash > chip is properly identified at 0xfff80000. Great! > How would you call the enable_flash function in chipset_enable? > E.g. enable_flash_cs5536 or enable_flash_geodelx ? enable_flash_geodelx() yes. Please send a patch! Check out http://linuxbios.org/Development_Guidelines //Peter From peter at stuge.se Wed Aug 15 12:25:51 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 12:25:51 +0200 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C2BB48.6080207@gmail.com> References: <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> <46C22D1D.1090102@dls.net> <46C2B789.6060107@gmail.com> <20070815082643.11270.qmail@stuge.se> <46C2BB48.6080207@gmail.com> Message-ID: <20070815102551.10461.qmail@stuge.se> On Wed, Aug 15, 2007 at 03:37:28PM +0700, Darmawan Salihun wrote: > > What is required to get into the southbridge driver stack? > > I'm not too sure. I think a "PCI bus filter driver", but that > would be an overkill at the moment. Why? > The other problem is it's not well documented (maybe not documented > at all :-/). I hardly found information about such a thing. Even, > experts in Windows driver development says so. I found some: MSDN > Win32 and COM Development > Windows Driver Kit > Kernel-Mode Driver Architecture > Design Guide (check out Reference too) http://msdn2.microsoft.com/en-us/library/ms796245.aspx > > really not feasible? It would definately be the cleanest way. > > Yes, this is the cleanest way. However, we have to "attach" our > driver entry point functions, including "AddDevice" function upon > the first time the southbridge driver is installed. Well we don't have to be the _only_ driver. I don't expect that to work well. > More like we make a driver for Intel, NVidia, AMD or Via chipset > driver. I think separate drivers is OK but only one is of course ideal. > The PnP manager will try to find the driver for the corresponding > device the first time it's found after Windows installation and it > seems once it has the driver we wouldn't be able to add our own > "hook" into the driver stack. Unless we make the thing called "PCI > bus filter driver" or other "Bus filter driver" as needed. Right, this is what I thought seemed right. > But, the problem goes back to the beginning, it's not even > documented. There is talk about it. Google has a few bits of info too, as usual. One link is Doron Holan's blog: (Technical lead for WDF) http://blogs.msdn.com/doronh/archive/2006/09/18/761325.aspx (here talk about class filter drivers) And there is an example, look for "toaster", in the WDK/DDK. It was introduced in this old newsletter it seems: http://www.microsoft.com/whdc/resources/news/newsletters/MHN_090803.htm The WDK doesn't seem to be readily available without registration and possibly payment but there is a DDK for 2k<=SP4 XP<=SP1 and 2003<=SP1 immediately downloadable from: http://www.microsoft.com/whdc/DevTools/ddk/default.mspx ..which probably works just fine also for later versions. There's documentation to go with the DDK too: http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx There are also some interesting docs on the toaster: http://www.microsoft.com/whdc/driver/foundation/toastersamp.mspx http://download.microsoft.com/download/3/5/a/35a609bf-872a-4eb8-a0d6-a3e026f8485a/ToasterSamp.doc Google HTML: http://209.85.135.104/search?q=cache:wRLrFGamtKYJ:download.microsoft.com/download/3/5/a/35a609bf-872a-4eb8-a0d6-a3e026f8485a/ToasterSamp.doc+msdn+filter+driver+sample&hl=en&ct=clnk&cd=13 http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04006_WINHEC2004.ppt Google HTML: http://209.85.135.104/search?q=cache:H-hy11oPjsIJ:download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04006_WINHEC2004.ppt+msdn+filter+driver+sample&hl=en&ct=clnk&cd=14 The latter one is slides about driver distribution and installation. They have tools for that too: http://www.microsoft.com/whdc/driver/install/difxtools.mspx http://www.microsoft.com/whdc/driver/install/DIFxtls.mspx http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=difxtools Another good resource is: http://www.codeproject.com/system/driverdev4asp.asp here part 4 in a driver writing tutorial series that goes into healthy depth about technicalities, and provides code. Have a look. //Peter From peter at stuge.se Wed Aug 15 12:35:02 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 12:35:02 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <46C2A249.30502@saxnet.de> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> Message-ID: <20070815103502.11863.qmail@stuge.se> On Wed, Aug 15, 2007 at 08:50:49AM +0200, Thomas Buschhardt wrote: > > Compare contents of the restored flash with one of the other > > samples. > > Oh my god - I find the error - like you suggest, I compare the > contents and it differ. It differ on all chips on all burnsessions. It is quite likely that the different sample BIOS images from the vendors are different, even if for the same hardware. But if you erase the chip, write an image, and then verify fails - there is something wrong indeed. (Don't forget erase first!) > Hmm its only 2 options - the chips are damage or the programmer > (Galep) The GALEP 5 seems to be a really good piece of hardware so it seems unlikely to be the problem. Can you get a few other flash chips for further testing? //Peter From darmawan.salihun at gmail.com Wed Aug 15 12:41:14 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 15 Aug 2007 17:41:14 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <20070815102551.10461.qmail@stuge.se> References: <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <20070814194748.17110.qmail@stuge.se> <46C22D1D.1090102@dls.net> <46C2B789.6060107@gmail.com> <20070815082643.11270.qmail@stuge.se> <46C2BB48.6080207@gmail.com> <20070815102551.10461.qmail@stuge.se> Message-ID: <46C2D84A.3040305@gmail.com> Peter Stuge wrote: > On Wed, Aug 15, 2007 at 03:37:28PM +0700, Darmawan Salihun wrote: >>> What is required to get into the southbridge driver stack? >> I'm not too sure. I think a "PCI bus filter driver", but that >> would be an overkill at the moment. > > Why? First off, I need to make at least a "safe" working code this weekend, for GSoC compliance ;-). I have a "working" code at the moment with direct I/O but without much of a "protection mechanism" in the kernel. It's an obvious danger, so I would like to add the DPC mechanism for the time being. Of course, venturing through the bus filter driver has been planned for sometime now. So, don't worry ;-). > >> The other problem is it's not well documented (maybe not documented >> at all :-/). I hardly found information about such a thing. Even, >> experts in Windows driver development says so. > > I found some: > > MSDN > Win32 and COM Development > Windows Driver Kit > Kernel-Mode > Driver Architecture > Design Guide (check out Reference too) > http://msdn2.microsoft.com/en-us/library/ms796245.aspx OK. I'll read that. I might have come across that ;-). > >>> really not feasible? It would definately be the cleanest way. >> Yes, this is the cleanest way. However, we have to "attach" our >> driver entry point functions, including "AddDevice" function upon >> the first time the southbridge driver is installed. > > Well we don't have to be the _only_ driver. I don't expect that to > work well. > > >> More like we make a driver for Intel, NVidia, AMD or Via chipset >> driver. > > I think separate drivers is OK but only one is of course ideal. > > >> The PnP manager will try to find the driver for the corresponding >> device the first time it's found after Windows installation and it >> seems once it has the driver we wouldn't be able to add our own >> "hook" into the driver stack. Unless we make the thing called "PCI >> bus filter driver" or other "Bus filter driver" as needed. > > Right, this is what I thought seemed right. > > >> But, the problem goes back to the beginning, it's not even >> documented. > > There is talk about it. Google has a few bits of info too, as usual. > > One link is Doron Holan's blog: (Technical lead for WDF) > http://blogs.msdn.com/doronh/archive/2006/09/18/761325.aspx > (here talk about class filter drivers) OK. This one is on the list. I've been talking with Doron for a while in the OSR's mailing list for a while ;-). > > And there is an example, look for "toaster", in the WDK/DDK. > > It was introduced in this old newsletter it seems: > http://www.microsoft.com/whdc/resources/news/newsletters/MHN_090803.htm > > > The WDK doesn't seem to be readily available without registration and > possibly payment but there is a DDK for 2k<=SP4 XP<=SP1 and 2003<=SP1 > immediately downloadable from: > > http://www.microsoft.com/whdc/DevTools/ddk/default.mspx > > ..which probably works just fine also for later versions. Have tested it for about a month now and seems to be just fine building Win XP device driver ;-). > > There's documentation to go with the DDK too: > > http://www.microsoft.com/whdc/DevTools/WDK/WDKdocs.mspx Have got it too. > > There are also some interesting docs on the toaster: > > http://www.microsoft.com/whdc/driver/foundation/toastersamp.mspx > > http://download.microsoft.com/download/3/5/a/35a609bf-872a-4eb8-a0d6-a3e026f8485a/ToasterSamp.doc > Google HTML: http://209.85.135.104/search?q=cache:wRLrFGamtKYJ:download.microsoft.com/download/3/5/a/35a609bf-872a-4eb8-a0d6-a3e026f8485a/ToasterSamp.doc+msdn+filter+driver+sample&hl=en&ct=clnk&cd=13 > > http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04006_WINHEC2004.ppt > Google HTML: http://209.85.135.104/search?q=cache:H-hy11oPjsIJ:download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04006_WINHEC2004.ppt+msdn+filter+driver+sample&hl=en&ct=clnk&cd=14 > > The latter one is slides about driver distribution and installation. > They have tools for that too: > > http://www.microsoft.com/whdc/driver/install/difxtools.mspx > http://www.microsoft.com/whdc/driver/install/DIFxtls.mspx > http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=difxtools Thx for the links. > > Another good resource is: > > http://www.codeproject.com/system/driverdev4asp.asp > > here part 4 in a driver writing tutorial series that goes into > healthy depth about technicalities, and provides code. > > Have a look. Yeah, of course. Thanks for that. I've got two books in Windows driver development as well (Walter Oney's book and the other one about Win2K WDM driver development) Regards, --Darmawan From Richard.Wilson at senokian.com Wed Aug 15 12:49:57 2007 From: Richard.Wilson at senokian.com (Richard Wilson) Date: Wed, 15 Aug 2007 11:49:57 +0100 Subject: [LinuxBIOS] I have a push pin flash (Huzzah!) Now to get some more... Message-ID: <46C2DA55.1020102@senokian.com> Having consulted the list and concluded I was unlikely to find a Bios Saviour, I went at my chip with a push pin and some superglue. Success! Thanks to all who made suggestions. I have two important questions: I've found a UK ebay item of 6 SST 39SF020A chips, which appear to be the ones I want for my EPIA-MII 12000. Am I right, and could I go for a 4Meg chip if I wanted? Additionally, I have next to no coding ability, so I feel it falls to me to contribute in some other way. There are 6 currently available in the auction, and I feel I need at most 3. Are there any active developers who'd like a free 39F020A? I'd quite happily buy the lot and send the unneeded ones anywhere in Europe, if it'll do some good to the project. Heck I could probably stretch to the US if the postage isn't too hideous. Any takers? The auction ends in 5 days, but its a buy it now, so if I want them all I should probably get them sooner rather than later... -- Richard 'Dave' Wilson Systems Administrator Senokian Solutions Ltd. Business Innovation Centre, Binley Business Park, Coventry, United Kingdom CV3 2TX T: +44 (0)24 76 233 400 DDI: +44 (0)24 76 233 416 F: +44 (0)24 76 233 401 From ml at saxnet.de Wed Aug 15 13:54:59 2007 From: ml at saxnet.de (Thomas Buschhardt) Date: Wed, 15 Aug 2007 13:54:59 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <20070815103502.11863.qmail@stuge.se> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> <20070815103502.11863.qmail@stuge.se> Message-ID: <46C2E993.4030505@saxnet.de> Hallo Peter > > It is quite likely that the different sample BIOS images from the > vendors are different, even if for the same hardware. > Of course they differ, but if I read 1 chip 3 times and compare the bin's - they differ too :-( > The GALEP 5 seems to be a really good piece of hardware so it seems > unlikely to be the problem. > > Can you get a few other flash chips for further testing? > Today I telephone with the Galep producer and he said - some chip vendors use a "writeprotection technic" that u cant use the free samples to burn your own image on it. I order some new (clean ;-)) chips. I understand these method, because one of these vendor (www.insydesw.com) offer 50 chips for free - its quite a lot of money (1 chip is about 5.90 EUR). Cheers Thomas From stepan at coresystems.de Wed Aug 15 14:07:33 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 14:07:33 +0200 Subject: [LinuxBIOS] I have a push pin flash (Huzzah!) Now to get some more... In-Reply-To: <46C2DA55.1020102@senokian.com> References: <46C2DA55.1020102@senokian.com> Message-ID: <20070815120733.GA5297@coresystems.de> * Richard Wilson [070815 12:49]: > I've found a UK ebay item of 6 SST 39SF020A chips, which appear to be > the ones I want for my EPIA-MII 12000. Am I right, and could I go for a > 4Meg chip if I wanted? Just as a side node, 2M/4M usually means Mbit in this area. The 39SF020A thus has 2MBit: 256 KByte. If you can, get at least a 39SF040 (512KByte) or even a 39SF080 (1MByte) for the real fun. 2 Mbit is plenty for the Epia MII if you want to boot from IDE or CF using FILO (or soon Grub2 I assume) 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 stepan at coresystems.de Wed Aug 15 14:17:35 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 14:17:35 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <46C2E993.4030505@saxnet.de> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> <20070815103502.11863.qmail@stuge.se> <46C2E993.4030505@saxnet.de> Message-ID: <20070815121735.GB7585@coresystems.de> * Thomas Buschhardt [070815 13:54]: > Of course they differ, but if I read 1 chip 3 times and compare the > bin's - they differ too :-( Have you tried erasing the chip (a couple of times)? It sounds like the chip is no good. 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From rmh at aybabtu.com Wed Aug 15 14:18:06 2007 From: rmh at aybabtu.com (Robert Millan) Date: Wed, 15 Aug 2007 14:18:06 +0200 Subject: [LinuxBIOS] make dependencies and C includes Message-ID: <20070815121806.GA12788@aragorn> Hi! I've observed that C #include'd files such as raminit.c aren't represented in make dependencies, resulting in them not being recompiled after a modification. I'm not sure what would be the proper solution: - add the dependency manually in the corresponding Config.lb files? - migrate use of #include to separate compilation and standard linking? - modify util/newconfig/config.g to automatical scan C files and add the dependencies for #includes? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From stepan at coresystems.de Wed Aug 15 14:30:31 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 14:30:31 +0200 Subject: [LinuxBIOS] make dependencies and C includes In-Reply-To: <20070815121806.GA12788@aragorn> References: <20070815121806.GA12788@aragorn> Message-ID: <20070815123031.GA9927@coresystems.de> * Robert Millan [070815 14:18]: > - add the dependency manually in the corresponding Config.lb files? possible but nasty > - migrate use of #include to separate compilation and standard linking? not possible, unfortunately, because we're not using gcc for the raminit part but romcc. It has to be one big mess to work :-( > - modify util/newconfig/config.g to automatical scan C files and add > the dependencies for #includes? That would be neat. I wonder whether it might make more sense to put effort in v3 though, as v2 might just go away quicker that way. > I know my rights; I want my phone call! > What use is a phone call, if you are unable to speak? > (as seen on /.) That's a good one! 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 rminnich at gmail.com Wed Aug 15 14:47:47 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 15 Aug 2007 05:47:47 -0700 Subject: [LinuxBIOS] make dependencies and C includes In-Reply-To: <20070815121806.GA12788@aragorn> References: <20070815121806.GA12788@aragorn> Message-ID: <13426df10708150547i8a1965cvb622b99da60f0636@mail.gmail.com> On 8/15/07, Robert Millan wrote: > > Hi! > > I've observed that C #include'd files such as raminit.c aren't represented > in make dependencies, resulting in them not being recompiled after a > modification. > V3. We're trying as hard as we can to get the first ports out, at which point all life is better ... thanks ron From rmh at aybabtu.com Wed Aug 15 14:50:46 2007 From: rmh at aybabtu.com (Robert Millan) Date: Wed, 15 Aug 2007 14:50:46 +0200 Subject: [LinuxBIOS] make dependencies and C includes In-Reply-To: <20070815123031.GA9927@coresystems.de> References: <20070815121806.GA12788@aragorn> <20070815123031.GA9927@coresystems.de> Message-ID: <20070815125046.GJ16308@aragorn> On Wed, Aug 15, 2007 at 02:30:31PM +0200, Stefan Reinauer wrote: > > - migrate use of #include to separate compilation and standard linking? > > not possible, unfortunately, because we're not using gcc for the raminit > part but romcc. It has to be one big mess to work :-( I don't understand. You mean the same code is used by different compilers, or that romcc can't handle multi-object linking? Btw I thought that romcc was being deprecated in favour of cache-as-ram. > > - modify util/newconfig/config.g to automatical scan C files and add > > the dependencies for #includes? > > That would be neat. > > I wonder whether it might make more sense to put effort in v3 though, as > v2 might just go away quicker that way. Unfortunately I'm python illiterate. Does v3 use the same code? > > I know my rights; I want my phone call! > > What use is a phone call, if you are unable to speak? > > (as seen on /.) > > That's a good one! :-) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From rmh at aybabtu.com Wed Aug 15 15:00:05 2007 From: rmh at aybabtu.com (Robert Millan) Date: Wed, 15 Aug 2007 15:00:05 +0200 Subject: [LinuxBIOS] [PATCH] Initial support for the ASUS A8NE-FM Message-ID: <20070815130004.GA17303@aragorn> On my A8N5X, linuxbios gets quite far (it gets to vga initialisation, and then breaks - will write about that later). > Index: src/northbridge/amd/amdk8/raminit.c > =================================================================== > --- src/northbridge/amd/amdk8/raminit.c (Revision 2739) > +++ src/northbridge/amd/amdk8/raminit.c (Arbeitskopie) > @@ -620,7 +620,8 @@ > #warning "FIXME: Implement a better test for Opterons" > uint32_t nbcap; > nbcap = pci_read_config32(ctrl->f3, NORTHBRIDGE_CAP); > - return !!(nbcap & NBCAP_128Bit); > + //// return !!(nbcap & NBCAP_128Bit); > + return 0; > } > > static int is_registered(const struct mem_controller *ctrl) I had to take this part of your patch to fix Opteron miss-detection. Are you checking for the cpu itself? If this is so, I think CPUID would be much more reliable. Would you like a patch for that? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From rminnich at gmail.com Wed Aug 15 15:09:16 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 15 Aug 2007 06:09:16 -0700 Subject: [LinuxBIOS] make dependencies and C includes In-Reply-To: <20070815125046.GJ16308@aragorn> References: <20070815121806.GA12788@aragorn> <20070815123031.GA9927@coresystems.de> <20070815125046.GJ16308@aragorn> Message-ID: <13426df10708150609g48a2233dy328119ffca049890@mail.gmail.com> On 8/15/07, Robert Millan wrote: > I don't understand. You mean the same code is used by different compilers, or > that romcc can't handle multi-object linking? There is no mem, hence no stack, hence romcc is 100% inline. multi-object linking has no meaning in romcc. > > Btw I thought that romcc was being deprecated in favour of cache-as-ram. yes. > Unfortunately I'm python illiterate. Does v3 use the same code? V3 is Kconfig. NO NO NO NO NO Python in V3! Oh happy day! ron From rminnich at gmail.com Wed Aug 15 15:27:36 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 15 Aug 2007 06:27:36 -0700 Subject: [LinuxBIOS] Fwd: ACPI memo In-Reply-To: <46C0A236.2070601@atl.lmco.com> References: <46C0A236.2070601@atl.lmco.com> Message-ID: <13426df10708150627x19f0d5b8ydc74c4cc961fdd31@mail.gmail.com> You just have to love ACPI. Or any other binary standard, for that matter. In a simliar vein, I wonder if we'll find it almost impossible to run EFI drivers under non-EFI software ... ron ---------- Forwarded message ---------- From: Date: Aug 13, 2007 11:25 AM Subject: ACPI memo To: ron minnich Pretty amusing, if you haven't seen this before. :-) http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf From c-d.hailfinger.devel.2006 at gmx.net Mon Aug 13 05:04:45 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 13 Aug 2007 05:04:45 +0200 Subject: [LinuxBIOS] 64bit issues was: [PATCH] LBv3: fix printk format warnings In-Reply-To: <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> Message-ID: <46BFCA4D.90304@gmx.net> Please read through the whole mail. The first part is about printf issues, while the second part points out much more important problems with 64bit resources and stuff. Thanks. On 10.08.2007 18:31, ron minnich wrote: > Thanks very much for this. I have another patch pending which changes %Lx (L is unspecified for integers, happens to work) to %llx ("official" long long for integers). Quoting from the printf(3) man page: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The length modifier Here, `integer conversion' stands for d, i, o, u, x, or X conversion. hh A following integer conversion corresponds to a signed char or unsigned char argument, or a following n conversion corresponds to a pointer to a signed char argument. h A following integer conversion corresponds to a short int or unsigned short int argument, or a following n conversion corresponds to a pointer to a short int argument. l (ell) A following integer conversion corresponds to a long int or unsigned long int argument. ll (ell-ell). A following integer conversion corresponds to a long long int or unsigned long long int argument. L A following a, A, e, E, f, F, g, or G conversion corresponds to a long double argument. z A following integer conversion corresponds to a size_t or ssize_t argument. t A following integer conversion corresponds to a ptrdiff_t argument. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Conclusions: * "L" is for floats only. * "t" or "z" might be handy for resource sizes. * "h" and "hh" for u16 and u8 seem to be unknown to most coders (except in util/dtc) and gcc doesn't warn about them. Should investigate usefulness for us. > I have a suggestion. Nowadays, for things that are pointers, > even if they are not typed as such, I've taken to this style: > > > On 8/9/07, Carl-Daniel Hailfinger wrote: >> ./superio/winbond/w83627hf/superio.c:init_hwm() >> +printk(BIOS_SPEW, "base = 0x%04lx, reg = 0x%02x, value = 0x%02x\r\n", base, reg,value); > > vv vvvvvvv > printk(BIOS_SPEW, "base = %p, reg = 0x%02x, value = 0x%02x\r\n", (void *) base, reg,value); >> + printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev), rom_address); > > vv vvvvvvvv > printk(BIOS_DEBUG, "ROM address for %s = %p\n", dev_path(dev), (void *) rom_address); > Do I understand this correctly? (void *) conversion and usage of %p for things that are essentially pointers. > Why do this? It's actually more portable, even across plan 9 and > linux. It will probably work correctly in 64 bit mode. And, that > rom_address really *is* an address. I like it, but... in the first example it seems this was an error, the base is not an address, but some u16 value. Stefan? Can you tell us what the reason is? The second example is more correct, but we still face a problem: resource_t is u64 and as long as we don't use long mode, %p will expect 32bit values. However, almost everything being a resource_t (base, size, limit) is essentially a pointer of a pointerdiff. Now how do we handle that? And while we're at correct typing, shouldn't arch/x86/linuxbios_table.c use resource_t in most places where it uses u64? I have a lot of open questions: * How do we handle accesses to resources above 4 GB when we confine ourselves to 32bit code? * How do 32bit operating systems handle resources above 4 GB? Should we just avoid locating resources up there? Only do it if unavoidable? Consider a machine with 4 GB of RAM and a graphics card with 512 MB. That combination can be bought today. Now what will happen if video RAM grows to 4 GB? Can we boot such a machine in 32bit mode at all? Should we show a warning? Refuse to boot any non-64bit OS? * Should we have some preference setting which controls 64bit resource allocation? * Is there any point trying to handle 64bit resources on 32bit machines? * Do we have to compile 64bit code for 64bit machines? Regards, Carl-Daniel From is at eseco.de Wed Aug 15 16:16:39 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 16:16:39 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070815093533.1450.qmail@stuge.se> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> Message-ID: <46C30AC7.6020003@eseco.de> Peter Stuge wrote: > enable_flash_geodelx() yes. > > Please send a patch! Check out > http://linuxbios.org/Development_Guidelines Please have a look at the attached patch. I've tested it first with a bunch of printf lines in between the read/write steps and it looked good. The 'production' version comes without the printfs, but with some sanity testing which works fine here. cheers, Ingmar -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_geodelx.patch Type: text/x-patch Size: 1864 bytes Desc: not available URL: From stepan at coresystems.de Wed Aug 15 18:15:54 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 18:15:54 +0200 Subject: [LinuxBIOS] 64bit issues was: [PATCH] LBv3: fix printk format warnings In-Reply-To: <46BFCA4D.90304@gmx.net> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <46BFCA4D.90304@gmx.net> Message-ID: <46C326BA.3000603@coresystems.de> Carl-Daniel Hailfinger wrote: > I have another patch pending which changes %Lx (L is unspecified for > integers, happens to work) to %llx ("official" long long for integers). > > It doesn't "happen to work", it is implemented so that it works. %llx will not work if you don't change printk. I agree we should make it compatible to printf. > Conclusions: > * "L" is for floats only. > * "t" or "z" might be handy for resource sizes. > * "h" and "hh" for u16 and u8 seem to be unknown to most coders (except > in util/dtc) and gcc doesn't warn about them. Should investigate > usefulness for us. > > Then L really makes no sense. Then we want to drop it from the code completely to prevent people from using it with the wrong expectations (like I did, because I figured its meaning out from the code, not the man page of printf) >> printk(BIOS_DEBUG, "ROM address for %s = %p\n", dev_path(dev), (void *) rom_address); >> >> > > Do I understand this correctly? (void *) conversion and usage of %p for > things that are essentially pointers. > > What's unclear? >> Why do this? It's actually more portable, even across plan 9 and >> linux. It will probably work correctly in 64 bit mode. And, that >> rom_address really *is* an address. >> > > I like it, but... in the first example it seems this was an error, the > base is not an address, but some u16 value. > Stefan? Can you tell us what the reason is? > rom_address a 16bit value? Which part of the code? Sorry I lost you. Are you talking about IO accesses which have a 16bit address space? > The second example is more correct, but we still face a problem: > resource_t is u64 and as long as we don't use long mode, %p will expect > 32bit values. However, almost everything being a resource_t (base, size, > limit) is essentially a pointer of a pointerdiff. Now how do we handle that? > > Which second example? > And while we're at correct typing, shouldn't arch/x86/linuxbios_table.c > use resource_t in most places where it uses u64? > > Interesting idea. You might be correct. resource_t should be a u64 in fact. It might be something different due to alignment requirements of the pci structures > I have a lot of open questions: > * How do we handle accesses to resources above 4 GB when we confine > ourselves to 32bit code? > We don't confine ourselfes. There's PAE > * How do 32bit operating systems handle resources above 4 GB? Should we > just avoid locating resources up there? Only do it if unavoidable? > Consider a machine with 4 GB of RAM and a graphics card with 512 MB. > That combination can be bought today. Now what will happen if video RAM > grows to 4 GB? Can we boot such a machine in 32bit mode at all? Should > we show a warning? Refuse to boot any non-64bit OS? > 32bit OSes can not handle system resources above 4GB except with tricks (PAE). That is why 32bit OSes are dying out and are not being used anymore in environments where resources above 4GB happen. If you run a 32bit OS on a machine with 4G of RAM you simply can not be helped. Linux starts having severe performance problems in 32bit mode when you cross the 1G border. Which basically every machine does today, except lowend hobbyist stuff and embedded systems. > * Should we have some preference setting which controls 64bit resource > allocation? > We do have a CONFIG variable for that, and it packs resources into 32bit per default. This default will change at some point because a 3G PCI hole in 4G space makes only little sense. This is done on some machines so that _in theory_ you _could_ run a 32bit OS. > * Is there any point trying to handle 64bit resources on 32bit machines? > Not that I would know of. PCI resources can prefer to go to 64bit space, but on a 32bit machine that means you poke them out of visibility. > * Do we have to compile 64bit code for 64bit machines? > > No. Thanks to PAE we can access address space above 4G too. But in fact we want to go 64bit mode. The really broken thing with x86_64's long mode is that it does not work without paging enabled. That makes the effort to use it in the bios harder than the gain. For an OS and other high level applications like that things are different though. -- 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 stepan at coresystems.de Wed Aug 15 18:28:15 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 18:28:15 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C30AC7.6020003@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> <46C30AC7.6020003@eseco.de> Message-ID: <46C3299F.5060206@coresystems.de> Ingmar Schraub wrote: > Peter Stuge wrote: > >> enable_flash_geodelx() yes. >> >> Please send a patch! Check out >> http://linuxbios.org/Development_Guidelines >> > > Please have a look at the attached patch. > > I've tested it first with a bunch of printf lines in between the > read/write steps and it looked good. The 'production' version comes > without the printfs, but with some sanity testing which works fine here. Hm I wonder whether it might make sense to use asm("rdmsr") instead of /dev/... so that it will work on non-linux systems as well? Great work! -- 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 jordan.crouse at amd.com Wed Aug 15 16:30:51 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 15 Aug 2007 08:30:51 -0600 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C2C5AA.1020406@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> Message-ID: <20070815143051.GC6490@cosmic.amd.com> On 15/08/07 11:21 +0200, Ingmar Schraub wrote: > > Jordan Crouse wrote: > > On 14/08/07 21:28 +0200, Peter Stuge wrote: > >> On Tue, Aug 14, 2007 at 11:25:38AM -0600, Marc Jones wrote: > >>> Is it worth adding rdmsr/wrmsr to flashrom? > >> Is there a better option? > > > > Nope. You need MSR acess, and thats the only way to get it from > > userspace. > > > >> Is it neccessary to always write all 64 bits of the MSR by the way? > > > > Yes - at least this way, which uses just a straight wrmsr in the kernel. > > Okay, I hacked that in and it seems to work. My SST49LF040B flash chip > is properly identified at 0xfff80000. > > How would you call the enable_flash function in chipset_enable? E.g. > enable_flash_cs5536 or enable_flash_geodelx ? I vote for enabled_flash_cs5536. > Ingmar > > -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From is at eseco.de Wed Aug 15 16:36:15 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 16:36:15 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070815143051.GC6490@cosmic.amd.com> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815143051.GC6490@cosmic.amd.com> Message-ID: <46C30F5F.2080600@eseco.de> Jordan Crouse wrote: >> How would you call the enable_flash function in chipset_enable? E.g. >> enable_flash_cs5536 or enable_flash_geodelx ? > > I vote for enabled_flash_cs5536. hmmm, my very first version used enable_flash_cs5536. ;-) I changed it for the patch I submitted. Well, Peter and you should agree an something. At least it's easy to change ;-) regards, Ingmar From jordan.crouse at amd.com Wed Aug 15 16:43:39 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Wed, 15 Aug 2007 08:43:39 -0600 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C3299F.5060206@coresystems.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> <46C30AC7.6020003@eseco.de> <46C3299F.5060206@coresystems.de> Message-ID: <20070815144339.GG6490@cosmic.amd.com> On 15/08/07 18:28 +0200, Stefan Reinauer wrote: > Ingmar Schraub wrote: > > Peter Stuge wrote: > > > >> enable_flash_geodelx() yes. > >> > >> Please send a patch! Check out > >> http://linuxbios.org/Development_Guidelines > >> > > > > Please have a look at the attached patch. > > > > I've tested it first with a bunch of printf lines in between the > > read/write steps and it looked good. The 'production' version comes > > without the printfs, but with some sanity testing which works fine here. > > Hm I wonder whether it might make sense to use asm("rdmsr") instead of > /dev/... so that it will work on non-linux systems as well? the rdmsr instruction won't work in ring 3, unfortunately. There is a way to access the MSRs through a VSA virtual register, but I'm loath to mention it, because it makes me feel all icky. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From Richard.Wilson at senokian.com Wed Aug 15 16:45:15 2007 From: Richard.Wilson at senokian.com (Richard Wilson) Date: Wed, 15 Aug 2007 15:45:15 +0100 Subject: [LinuxBIOS] I have a push pin flash (Huzzah!) Now to get some more... In-Reply-To: <46C2F2B5.2030504@stockwith.co.uk> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> Message-ID: <46C3117B.9050005@senokian.com> Chris Lingard wrote: > Richard Wilson wrote: >> Having consulted the list and concluded I was unlikely to find a Bios >> Saviour, I went at my chip with a push pin and some superglue. Success! >> Thanks to all who made suggestions. I have two important questions: >> >> I've found a UK ebay item of 6 SST 39SF020A chips, which appear to be >> the ones I want for my EPIA-MII 12000. Am I right, and could I go for a >> 4Meg chip if I wanted? >> >> Additionally, I have next to no coding ability, so I feel it falls to me >> to contribute in some other way. There are 6 currently available in the >> auction, and I feel I need at most 3. Are there any active developers >> who'd like a free 39F020A? I'd quite happily buy the lot and send the >> unneeded ones anywhere in Europe, if it'll do some good to the project. >> Heck I could probably stretch to the US if the postage isn't too hideous. >> >> Any takers? The auction ends in 5 days, but its a buy it now, so if I >> want them all I should probably get them sooner rather than later... >> > > Saw your post on LinuxBios, I am about to start work on it too. > > I have already a Gigabyte M57SLI mother board, and have built the > machine and installed Linux. I am using it right now. > > I am a system programmer but have no knowledge of engineering at all > > I need to buy whatever you solder onto the motherboard, a guy at the > local computer shop can do the actual work. > > I can get the 120K resister, the three pieces of wire and a switch; > after that you may as well speak Ancient Greek to me. > > Can you fix me up with what I need to buy, I can pay, I do not need a > handout. Thanks > > Chris Lingard > I think there might be a bit of confusion here - I'm planning on buying some bios chips and putting push pin knobs on them to make them easier to swap around - I'm not making any custom hardware or the home-brew switcher others have mentioned. The ebay auction I'm looking at is at http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&rd=1&item=280143009151&ssPageName=STRK:MEWA:IT&ih=018 if you want to get some chips yourself. I wasn't suggesting anyone needed handouts, but I do know that there's a few developers on the list who are currently students, and I remember being a bit short of pennies when I was at university myself, not so long ago... Richard W From stepan at coresystems.de Wed Aug 15 16:53:20 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 16:53:20 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <20070815144339.GG6490@cosmic.amd.com> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> <46C30AC7.6020003@eseco.de> <46C3299F.5060206@coresystems.de> <20070815144339.GG6490@cosmic.amd.com> Message-ID: <20070815145320.GA14277@coresystems.de> * Jordan Crouse [070815 16:43]: > the rdmsr instruction won't work in ring 3, unfortunately. > There is a way to access the MSRs through a VSA virtual register, but I'm > loath to mention it, because it makes me feel all icky. oops. ioperm() is not enough? How are rdmsr/wrmsr done on opensolaris? 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 15 18:03:28 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 15 Aug 2007 18:03:28 +0200 Subject: [LinuxBIOS] where are we on the MSI K9N Neo-F? In-Reply-To: <20070812232912.6702.qmail@stuge.se> References: <20070812222526.GA8039@countzero.vandewege.net> <20070812232912.6702.qmail@stuge.se> Message-ID: <46C323D0.3060404@gmx.net> On 13.08.2007 01:29, Peter Stuge wrote: > On Sun, Aug 12, 2007 at 06:25:26PM -0400, Ward Vandewege wrote: > >> It's cheap and on the face of it should be fairly easy to port - >> MCP55 chipset, etc. There was some concern about the ehternet card? > > For LB purposes the NIC is not likely to cause problems, I think the > uncertainty was about a Linux driver for it. drivers/net/forcedeth.c > does support the relevant PCI IDs (PCI_DEVICE_ID_NVIDIA_NVENET_14/15, > 0x0372/0x0373) according to the FreeBSD nfe driver. If there are problems with forcedeth, I'd like to know about them as I'm one of the authors (although most of my work was in reverse engineering prior to Nvidia supporting the driver). >> I think I'll get this board or perhaps one of the Abit KN9 ones >> that are very similar to the Gigabyte M57SLI-S4. All have a PLCC >> socket which is a big plus. >> >> If anyone has been working on these boards give me a shout - I'd >> like to put some work into adding support for one of these. > > I don't know if Carl-Daniel got a response from the desktop BIOS > people at MSI, I got the impression we'd be able to get some help > from them if we needed it, but I suppose it would be easier for > them to answer specific questions. As you say: They were willing to answer specific questions, but I got sidetracked by university papers and unfortunately had no time for porting in the last months. Regards, Carl-Daniel From uwe at hermann-uwe.de Wed Aug 15 18:13:24 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Wed, 15 Aug 2007 18:13:24 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C30AC7.6020003@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> <46C30AC7.6020003@eseco.de> Message-ID: <20070815161324.GB17320@greenwood> Hi, On Wed, Aug 15, 2007 at 04:16:39PM +0200, Ingmar Schraub wrote: > > Please send a patch! Check out > > http://linuxbios.org/Development_Guidelines > > Please have a look at the attached patch. Please add a Signed-off-by line as per guidelines, otherwise we cannot commit the patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From is at eseco.de Wed Aug 15 19:30:35 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 19:30:35 +0200 Subject: [LinuxBIOS] flashrom geodelx patch Message-ID: <46C3383B.9040008@eseco.de> Add support for AMD Geode LX / CS5536 to the flashrom utility. Signed-off-by: Ingmar Schraub --- regards, Ingmar -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_geodelx.patch Type: text/x-patch Size: 1864 bytes Desc: not available URL: From rminnich at gmail.com Wed Aug 15 19:39:01 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 15 Aug 2007 10:39:01 -0700 Subject: [LinuxBIOS] flashrom geodelx patch In-Reply-To: <46C3383B.9040008@eseco.de> References: <46C3383B.9040008@eseco.de> Message-ID: <13426df10708151039r3a02f2ffmb57340d614d42f5a@mail.gmail.com> I think we ought to have a comment in here about what this does. It's a great patch, and very nice to have, but can you describe what is going on. thanks ron From tsylla at gmail.com Wed Aug 15 20:14:36 2007 From: tsylla at gmail.com (Tom Sylla) Date: Wed, 15 Aug 2007 14:14:36 -0400 Subject: [LinuxBIOS] flashrom geodelx patch In-Reply-To: <46C3383B.9040008@eseco.de> References: <46C3383B.9040008@eseco.de> Message-ID: <57947bf80708151114r63525548nfc0864ae2d3efaee@mail.gmail.com> This patch is not quite correct. The MSR being written is RCONF_DEFAULT_MSR (0x1808). That MSR includes SYSTOP (where RAM ends). That should be dynamic depending on the amount of RAM in the system, you can't really just smash in a fixed value. The correct thing to do is to read the MSR, clear WP of the ROMRP field, and write it back. Doing it this way would make it proper and much cleaner (and self-documented). (if anyone wonders what the fields mean, just read the LX databook) On 8/15/07, Ingmar Schraub wrote: > Add support for AMD Geode LX / CS5536 to the flashrom utility. > > Signed-off-by: Ingmar Schraub > > --- > > regards, > > Ingmar > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > > From is at eseco.de Wed Aug 15 20:20:55 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 20:20:55 +0200 Subject: [LinuxBIOS] flashrom geodelx patch In-Reply-To: <13426df10708151039r3a02f2ffmb57340d614d42f5a@mail.gmail.com> References: <46C3383B.9040008@eseco.de> <13426df10708151039r3a02f2ffmb57340d614d42f5a@mail.gmail.com> Message-ID: <46C34407.4090301@eseco.de> Most of it is already documented at http://wiki.laptop.org/go/Flashing_LinuxBIOS where I took the information from. The link came from Marc Jones and you provided there rdmsr/wrmsr. I got the chipset identifier from lspci from my Alix board and added it. I've tested it with my Alix board where I have a SST49LF040B flash chip. Well, maybe I've done something wrong... You can tell me. What did you/or other developers do when you added support for any other chipset? As I said before, I am completely new to LB... regards, Ingmar ron minnich wrote: > I think we ought to have a comment in here about what this does. It's > a great patch, and very nice to have, but can you describe what is > going on. > > thanks > ron From is at eseco.de Wed Aug 15 20:22:14 2007 From: is at eseco.de (Ingmar Schraub) Date: Wed, 15 Aug 2007 20:22:14 +0200 Subject: [LinuxBIOS] flashrom geodelx patch In-Reply-To: <57947bf80708151114r63525548nfc0864ae2d3efaee@mail.gmail.com> References: <46C3383B.9040008@eseco.de> <57947bf80708151114r63525548nfc0864ae2d3efaee@mail.gmail.com> Message-ID: <46C34456.50804@eseco.de> Okay, I fully agree with you. That means, the patch I sent, should not be applied until this has been corrected in a proper way!! Tom Sylla wrote: > This patch is not quite correct. > > The MSR being written is RCONF_DEFAULT_MSR (0x1808). That MSR includes > SYSTOP (where RAM ends). That should be dynamic depending on the > amount of RAM in the system, you can't really just smash in a fixed > value. The correct thing to do is to read the MSR, clear WP of the > ROMRP field, and write it back. Doing it this way would make it proper > and much cleaner (and self-documented). > > (if anyone wonders what the fields mean, just read the LX databook) > > On 8/15/07, Ingmar Schraub wrote: >> Add support for AMD Geode LX / CS5536 to the flashrom utility. >> >> Signed-off-by: Ingmar Schraub >> >> --- >> >> regards, >> >> Ingmar >> >> -- >> linuxbios mailing list >> linuxbios at linuxbios.org >> http://www.linuxbios.org/mailman/listinfo/linuxbios >> >> > From marc.jones at amd.com Wed Aug 15 21:07:15 2007 From: marc.jones at amd.com (Marc Jones) Date: Wed, 15 Aug 2007 13:07:15 -0600 Subject: [LinuxBIOS] flashrom geodelx patch In-Reply-To: <57947bf80708151114r63525548nfc0864ae2d3efaee@mail.gmail.com> References: <46C3383B.9040008@eseco.de> <57947bf80708151114r63525548nfc0864ae2d3efaee@mail.gmail.com> Message-ID: <46C34EE3.6080102@amd.com> Tom Sylla wrote: > This patch is not quite correct. > > The MSR being written is RCONF_DEFAULT_MSR (0x1808). That MSR includes > SYSTOP (where RAM ends). That should be dynamic depending on the > amount of RAM in the system, you can't really just smash in a fixed > value. The correct thing to do is to read the MSR, clear WP of the > ROMRP field, and write it back. Doing it this way would make it proper > and much cleaner (and self-documented). > > (if anyone wonders what the fields mean, just read the LX databook) > Thanks Tom! Couldn't put it better myself. :) Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From peter at stuge.se Wed Aug 15 22:32:55 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 22:32:55 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <46C2E993.4030505@saxnet.de> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> <20070815103502.11863.qmail@stuge.se> <46C2E993.4030505@saxnet.de> Message-ID: <20070815203256.14414.qmail@stuge.se> Hey, On Wed, Aug 15, 2007 at 01:54:59PM +0200, Thomas Buschhardt wrote: > > It is quite likely that the different sample BIOS images from the > > vendors are different, even if for the same hardware. > > Of course they differ, but if I read 1 chip 3 times and compare the > bin's - they differ too :-( Ouch. Do they differ a lot? Can you run xxd on them and then diff? Bit errors indeed start showing when the chip has been through (quite) a few erase/rewrite cycles. I had not heard about that write protection idea before. > > Can you get a few other flash chips for further testing? > > Today I telephone with the Galep producer and he said - some chip > vendors use a "writeprotection technic" that u cant use the free > samples to burn your own image on it. I order some new (clean ;-)) > chips. I understand these method, because one of these vendor > (www.insydesw.com) offer 50 chips for free - its quite a lot of > money (1 chip is about 5.90 EUR). If you are a company and have a budget for more than just a few chips you can usually get a decent deal for 30 chips (one tube) from the local component distributors. Price goes down a lot when quantity goes up, so I doubt Insyde is paying very much.. :) //Peter From peter at stuge.se Wed Aug 15 22:53:40 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 22:53:40 +0200 Subject: [LinuxBIOS] I have a push pin flash (Huzzah!) Now to get some more... In-Reply-To: <46C3117B.9050005@senokian.com> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> Message-ID: <20070815205340.17175.qmail@stuge.se> On Wed, Aug 15, 2007 at 03:45:15PM +0100, Richard Wilson wrote: > >> I've found a UK ebay item of 6 SST 39SF020A chips, which appear > >> to be the ones I want for my EPIA-MII 12000. Am I right, As long as it's in PLCC packaging they should work perfectly. > >> and could I go for a 4Meg chip if I wanted? Yes, the MII can do 4Mbit (512kb) flash too, that would be SST39SF040-70-4C-NHE. > >> Additionally, I have next to no coding ability, so I feel it > >> falls to me to contribute in some other way. > >> I'd quite happily buy the lot and send the unneeded ones > >> anywhere in Europe, if it'll do some good to the project. That's an awesome offer! :) Thanks a lot. I hope you get a taker! //Peter From marc.jones at amd.com Wed Aug 15 23:01:37 2007 From: marc.jones at amd.com (Marc Jones) Date: Wed, 15 Aug 2007 15:01:37 -0600 Subject: [LinuxBIOS] lpci_set_subsystem question Message-ID: <46C369B1.5000505@amd.com> I see a couple of different versions of lpci_set_subsystem function and I wonder why. For example: src\southbridge\broadcom\bcm5780\bcm5780_nic.c: static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) { pci_write_config32(dev, 0x40, ((device & 0xffff) << 16) | (vendor & 0xffff)); } src\southbridge\amd\amd8111\amd8111_ide.c: static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) { pci_write_config32(dev, 0x70, ((device & 0xffff) << 16) | (vendor & 0xffff)); } src\southbridge\broadcom\bcm5780\bcm5780_sb_pci_main.c: static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) { pci_write_config32(dev, 0x2c, ((device & 0xffff) << 16) | (vendor & 0xffff)); } Shouldn't the PCI config register always be 0x2c (subsystem ID register) like in the last example (bcm5780_sb_pci_main.c)? Should these functions even be there since there is a stock pci_dev_set_subsystem() that seems to be correct? Am I mis-understanding this function? Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From peter at stuge.se Wed Aug 15 23:07:01 2007 From: peter at stuge.se (Peter Stuge) Date: Wed, 15 Aug 2007 23:07:01 +0200 Subject: [LinuxBIOS] I have a push pin flash (Huzzah!) Now to get some more... In-Reply-To: <46C3117B.9050005@senokian.com> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> Message-ID: <20070815210701.18965.qmail@stuge.se> Hey Chris, On Wed, Aug 15, 2007 at 03:45:15PM +0100, Richard Wilson wrote: > Chris Lingard wrote: > > Saw your post on LinuxBios, I am about to start work on it too. That's great! :) > > I have already a Gigabyte M57SLI mother board, and have built the > > machine and installed Linux. I am using it right now. > > > > I am a system programmer but have no knowledge of engineering at > > all > > > > I need to buy whatever you solder onto the motherboard, a guy at > > the local computer shop can do the actual work. Perfect! > > I can get the 120K resister, the three pieces of wire and a > > switch; after that you may as well speak Ancient Greek to me. > > > > Can you fix me up with what I need to buy, Maybe we can help you find the components that you need. We should have thought about putting up article numbers for a few suppliers on the wiki page already. I don't know much about shopping for electronics in the UK - can anyone suggest good retail or mail order stores with online catalogues? I'll have a look at it and suggest some parts. > The ebay auction I'm looking at is at > http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&rd=1&item=280143009151&ssPageName=STRK:MEWA:IT&ih=018 > if you want to get some chips yourself. Note that these flash chips do NOT work for the M57SLI board. Chris, I'll get you a few part numbers for flash as well, eBay may be the best bet to find those since not all electronics stores have stock of flash memory. (Prices usually change too quickly.) > I do know that there's a few developers on the list who are > currently students, and I remember being a bit short of pennies > when I was at university myself, not so long ago... And it's a great help for development. We do need to think of some practical way to handle hardware donations, there has been a few offers recently, which is very nice. //Peter From rminnich at gmail.com Wed Aug 15 23:08:48 2007 From: rminnich at gmail.com (ron minnich) Date: Wed, 15 Aug 2007 14:08:48 -0700 Subject: [LinuxBIOS] lpci_set_subsystem question In-Reply-To: <46C369B1.5000505@amd.com> References: <46C369B1.5000505@amd.com> Message-ID: <13426df10708151408k676d2dccve33930c5c5be6632@mail.gmail.com> On 8/15/07, Marc Jones wrote: > > Shouldn't the PCI config register always be 0x2c (subsystem ID register) > like in the last example (bcm5780_sb_pci_main.c)? Should these functions > even be there since there is a stock pci_dev_set_subsystem() that seems > to be correct? IIRC it should be, but is not always. A lot of chips don't quite follow the spec, and this weird out-of-band setting of registers crops up. That's my take on it anyway. ron From stepan at coresystems.de Wed Aug 15 23:10:09 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 23:10:09 +0200 Subject: [LinuxBIOS] lpci_set_subsystem question In-Reply-To: <46C369B1.5000505@amd.com> References: <46C369B1.5000505@amd.com> Message-ID: <20070815211009.GA29915@coresystems.de> * Marc Jones [070815 23:01]: > Shouldn't the PCI config register always be 0x2c (subsystem ID register) > like in the last example (bcm5780_sb_pci_main.c)? Should these functions > even be there since there is a stock pci_dev_set_subsystem() that seems > to be correct? I think on some systems 2c is always read-only, while on others it is read/write or read-once. Those with read-only 2c have a writable register that mirrors the value to 2c. Not sure if that's the case here. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Wed Aug 15 23:13:20 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Wed, 15 Aug 2007 23:13:20 +0200 Subject: [LinuxBIOS] [PATCH] Initial support for the ASUS A8NE-FM In-Reply-To: <20070815130004.GA17303@aragorn> References: <20070815130004.GA17303@aragorn> Message-ID: <20070815211320.GA32376@coresystems.de> * Robert Millan [070815 15:00]: > I had to take this part of your patch to fix Opteron miss-detection. > > Are you checking for the cpu itself? If this is so, I think CPUID would > be much more reliable. Would you like a patch for that? Is CPUID reliable? (I guess it is, but that might make a pretty complex function) Please do send a patch. I think cpuid would be a good way to go. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From marc.jones at amd.com Wed Aug 15 23:13:32 2007 From: marc.jones at amd.com (Marc Jones) Date: Wed, 15 Aug 2007 15:13:32 -0600 Subject: [LinuxBIOS] lpci_set_subsystem question In-Reply-To: <20070815211009.GA29915@coresystems.de> References: <46C369B1.5000505@amd.com> <20070815211009.GA29915@coresystems.de> Message-ID: <46C36C7C.8060103@amd.com> Stefan Reinauer wrote: > * Marc Jones [070815 23:01]: >> Shouldn't the PCI config register always be 0x2c (subsystem ID register) >> like in the last example (bcm5780_sb_pci_main.c)? Should these functions >> even be there since there is a stock pci_dev_set_subsystem() that seems >> to be correct? > > I think on some systems 2c is always read-only, while on others it is > read/write or read-once. Those with read-only 2c have a writable > register that mirrors the value to 2c. > > Not sure if that's the case here. > > Ah, That could be it. I will see if I have some specs for those devices that look odd. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From segher at kernel.crashing.org Wed Aug 15 23:23:11 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Wed, 15 Aug 2007 23:23:11 +0200 Subject: [LinuxBIOS] lpci_set_subsystem question In-Reply-To: <13426df10708151408k676d2dccve33930c5c5be6632@mail.gmail.com> References: <46C369B1.5000505@amd.com> <13426df10708151408k676d2dccve33930c5c5be6632@mail.gmail.com> Message-ID: >> Shouldn't the PCI config register always be 0x2c (subsystem ID >> register) >> like in the last example (bcm5780_sb_pci_main.c)? Should these >> functions >> even be there since there is a stock pci_dev_set_subsystem() that >> seems >> to be correct? > > IIRC it should be, but is not always. A lot of chips don't quite > follow the spec, and this weird out-of-band setting of registers crops > up. That's my take on it anyway. The PCI spec only defines the "read" behaviour of the subsystem config registers as far as I know. Anything writing those regs is just as non-standard (or moreso!) as something using special regs is. Segher From peter at stuge.se Thu Aug 16 00:07:10 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Aug 2007 00:07:10 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C30F5F.2080600@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815143051.GC6490@cosmic.amd.com> <46C30F5F.2080600@eseco.de> Message-ID: <20070815220710.28566.qmail@stuge.se> On Wed, Aug 15, 2007 at 04:36:15PM +0200, Ingmar Schraub wrote: > Jordan Crouse wrote: > > I vote for enabled_flash_cs5536. > > Well, Peter and you should agree an something. I prefer geodelx because that's where the 1808 MSR seems to be - it's in the LX databook, and it tells the memory controller in the LX how to handle writes to the top of the address space. We may need a enable_flash_cs5536() as well, to fiddle with the 51400010-51400013 (maybe 0015) DIVIL MSRs for the flash controller in the 5536. 5536 has subtractive decode to LPC, so no decoding needs to be set up like for 5530. But maybe there is a write protect bit somewhere in the 5536 that needs to be flipped? I've looked through the data book briefly but didn't spot one. Jordan? //Peter From peter at stuge.se Thu Aug 16 00:22:24 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Aug 2007 00:22:24 +0200 Subject: [LinuxBIOS] EEPROM/flash device not found error In-Reply-To: <46C30AC7.6020003@eseco.de> References: <20070814132814.14096.qmail@stuge.se> <46C1E592.4080103@amd.com> <20070814192838.13977.qmail@stuge.se> <20070814200146.GD30239@cosmic.amd.com> <46C2C5AA.1020406@eseco.de> <20070815093533.1450.qmail@stuge.se> <46C30AC7.6020003@eseco.de> Message-ID: <20070815222224.30885.qmail@stuge.se> On Wed, Aug 15, 2007 at 04:16:39PM +0200, Ingmar Schraub wrote: > Please have a look at the attached patch. Thanks! > + unsigned char wrbuf[] = { 0x00, 0xbf, 0xf7, 0x10, 0x02, 0x80, 0xff, 0x22}; .. > + lseek64(fd_msr, (off64_t)addr, SEEK_SET); > + read(fd_msr, buf, 8); > + close(fd_msr); Do you know if it's neccessary to close and reopen? > + fd_msr = open("/dev/cpu/0/msr", O_WRONLY); > + lseek64(fd_msr, (off64_t)addr, SEEK_SET); > + write(fd_msr, wrbuf, 8); I thought about this. I don't think we should blindly overwrite the entire MSR. The only thing we really want to do is change the MSB of this MSR (ROMRP, ROM Region Properties) by clearing bit 2 and setting either bit 1 or bit 0. (0x22 on OLPC wiki sets bit 1 but bit 0 makes more sense to me, looking at the databook. Anyway, whatever works. :) > + if (memcmp(buf, wrbuf, 8)) > + return -1; Verify is good! Maybe print a success message with the current setting before returning too? //Peter From r.marek at assembler.cz Thu Aug 16 00:33:02 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 16 Aug 2007 00:33:02 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46BAA5A9.60501@assembler.cz> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> <46BA50B5.70805@assembler.cz> <46BAA5A9.60501@assembler.cz> Message-ID: <46C37F1E.5000908@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Just an update. The "memtester" which is doing the memtesting while in OS will fail on "solid test". Has anyone ever succeeded to run more than one dimm DDR unbuffered in single channel mode on K8? Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGw38e3J9wPJqZRNURAt/aAJ9SiG6HVFi78OiFWEn9j9x4X3R2jQCffVLT hbMqPqqwlc1HheKO1po/iyQ= =fJmY -----END PGP SIGNATURE----- From rmh at aybabtu.com Thu Aug 16 01:40:17 2007 From: rmh at aybabtu.com (Robert Millan) Date: Thu, 16 Aug 2007 01:40:17 +0200 Subject: [LinuxBIOS] [PATCH] Initial support for the ASUS A8NE-FM In-Reply-To: <20070815211320.GA32376@coresystems.de> References: <20070815130004.GA17303@aragorn> <20070815211320.GA32376@coresystems.de> Message-ID: <20070815234017.GA6214@aragorn> On Wed, Aug 15, 2007 at 11:13:20PM +0200, Stefan Reinauer wrote: > * Robert Millan [070815 15:00]: > > I had to take this part of your patch to fix Opteron miss-detection. > > > > Are you checking for the cpu itself? If this is so, I think CPUID would > > be much more reliable. Would you like a patch for that? > > Is CPUID reliable? (I guess it is, but that might make a pretty complex > function) > > Please do send a patch. I think cpuid would be a good way to go. CPUID is reliable I think, but I'm not sure what we need to test exactly: - Test for Dual Opteron as well? - Comments in the source code suggest that socket 939 Athlon64 also should match this check. This poses two problems: - Uwe's patch precisely disabled the check because it was breaking boot on his s939 athlon64 (and it also does in mine). However, I suspect this could be related to the memory access problem Rudolf just sent a mail about. - Some s939/athlon64 models cannot be distinguished properly with cpuid_eax(1) since the return value is shared with athlon64 fx or sempron. Does this indicate we need to match those? Or do we want to tell them appart in some other way? (processor name string should work for that, although strcmp'ing that has a feeling of is-not-quite-right over it) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From rmh at aybabtu.com Thu Aug 16 02:03:12 2007 From: rmh at aybabtu.com (Robert Millan) Date: Thu, 16 Aug 2007 02:03:12 +0200 Subject: [LinuxBIOS] VIA K8T890+VT8237 - update of the status In-Reply-To: <46C37F1E.5000908@assembler.cz> References: <46B8FDE5.5040808@assembler.cz> <46B91BC9.4040409@gmail.com> <46BA50B5.70805@assembler.cz> <46BAA5A9.60501@assembler.cz> <46C37F1E.5000908@assembler.cz> Message-ID: <20070816000312.GA8237@aragorn> On Thu, Aug 16, 2007 at 12:33:02AM +0200, Rudolf Marek wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > Just an update. The "memtester" which is doing the memtesting while in OS will > fail on "solid test". > > Has anyone ever succeeded to run more than one dimm DDR unbuffered in single > channel mode on K8? I get the same problem on my ASUS A8N5X (K8 northbridge). It can be reproduced with memtest86 too (in my case it fails after a few seconds). Also, sometimes Linux fails CRC check while decompressing itself. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From jsturges at speakeasy.net Thu Aug 16 05:02:29 2007 From: jsturges at speakeasy.net (Jonathan Sturges) Date: Wed, 15 Aug 2007 23:02:29 -0400 Subject: [LinuxBIOS] [PATCH] Reimplementation/fixing of CS5530/CS5530A southbridge code In-Reply-To: <20070606213436.GB14290@greenwood> References: <20070606213436.GB14290@greenwood> Message-ID: <46C3BE45.9080309@speakeasy.net> Thanks for the updated 5530 code! However, I'm having some difficulty enabling the IDE controllers when using this patch. As far as I can tell, configuration parsing doesn't appear to work for new ideX_enable flags. The 'register "ide0_enable" = "1"' configuration option seemed to have no effect on my 5530 system. Even though both IDE controllers were enabled in Config.lb, when I'd test the resulting image, IDE0 would be disabled and IDE1 enabled. In the end, to make it work, I changed: "if (conf->ide0_enable) {" to: "if ( 1 ) {" ...in cs5530_ide.c to get IDE0 enabled. This forces it to work. Any ideas what would cause this? By the way, I'm using the Eaglelion 5BCM target for the moment, as it's nearly identical to my system. thanks, Jonathan Uwe Hermann wrote: > See patch. > > This is also required to make the JUKI-511P code work AFAICT (won't > build otherwise). > > > Uwe. > > > ------------------------------------------------------------------------ > > This is a full rewrite of all the CS5530/CS5530A code. The previous code was > mostly undocumented, had a broken coding style, contained lots of dead > code and had several other problems, e.g. it enabled write access to the > ROM (why?), it unconditionally enabled primary/secondary IDE (which should > have a config option) and that even _twice_ (which is um... wrong). > > The new code > > - has 'ide0_enable' and 'ide1_enable' config options (which actually > work) to enable/disable the primary/secondary IDE interface in > Config.lb. > > - Does _not_ enable write access to the ROM (or is there some good > reason to do that? If so, it should at least have a config option). > > - Contains a bit more documentation. > > - Uses readable (and documented) #defines instead of hardcoded magic values. > > - aaand... it actually compiles ;-) Yep, that's right. The previous code > wouldn't even build, as it hadn't been fully ported from v1 (still used > v1 functions which are simply not available in v2). > From corey.osgood at gmail.com Thu Aug 16 06:05:23 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 16 Aug 2007 00:05:23 -0400 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <20070815020326.15047.qmail@stuge.se> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> <20070815020326.15047.qmail@stuge.se> Message-ID: <46C3CD03.7090606@gmail.com> Peter Stuge wrote: > On Tue, Aug 14, 2007 at 09:53:44PM -0400, Corey Osgood wrote: > >>> Please do dump say 1024 bytes at 0xc0000 before doing the BIOS >>> init. >>> >> Alright, I'll give it a shot. I assume you mean after the bios is >> copied, but before it runs? >> > > Yep. > > > //Peter > > Okay, did that, along with a ram_check of the entire region. ram_check failed, but the bios copy seems to have worked fine (???). So I figured out there was an error in auto.c, the pci_write_config8(ctrl->d0, 0x4f, 0x1) should have been before enable_shadow_ram(). I've fixed that, and the bios copy still works fine, x86emu still has an error at line 5100 fo ops.c, but vm86.c produces a different error now, posted below. Also, the screen now turns on and comes up completely green, only with vm86.c. Also, I've been looking at the msrs from linuxbios and the factory bios, the factory bios sets up a single msr to cover the entire 512mb range, then has another msr for the last 32mb (480-512mb), presumably the vga framebuffer area. A third msr covers 479-480, dunno why, and a fourth msr is off in deep space at the 4gb range, I assume this is acpi space. I'm wondering if I need to be simulating this, setting up an msr to cover the 480-512mb range, or if the vga bios handles this. Thanks, Corey PCI: 01:00.0 init Initiailizing VGA... INSTALL REAL-MODE IDT DO THE VGA BIOS found VGA: vid=1106, did=3344 rom base, size: fff80000 bus/devfn = 0x100 biosint: INT# 0x6 biosint: eax 0x5f0b ebx 0x10100 ecx 0x60 edx 0x110 biosint: ebp 0x29f74 esp 0xfbe edi 0x1 esi 0xb2d4 biosint: ip 0xf85e cs 0xf000 flags 0x13 biosint: Oops, exception 6 Stack contents: 0xf85e 0xf000 0x0013 0xd163 0xc000 0x0006 0x0342 0xd89b 0x0342 0x0060 0x0044 0xb2d4 0x9f74 0x0fe2 0x0100 0x0110 0x0060 0x0342 0xb18d 0x0044 0x03b4 0x9f74 0x0ff4 0x0200 0x03c2 0x0060 0x0000 0x014e 0x9f74 0x0040 0x0046 0x97e7 0x0000 biosint: Bailing out Enable VGA console biosint: INT# 0x6 biosint: eax 0x5f08 ebx 0x8001 ecx 0x1 edx 0x0 biosint: ebp 0x20fd0 esp 0xfa8 edi 0x1 esi 0x8f30 biosint: ip 0xf85e cs 0xf000 flags 0x213 biosint: Oops, exception 6 Stack contents: 0xf85e 0xf000 0x0213 0xd125 0xc000 0x0206 0x0000 0x8003 0x9824 0x898e 0x956d 0x898e 0x9dfb 0x898e 0xa60b 0x4f14 0x86ec 0x863a 0x8600 0x86a2 0x0000 0x0000 0x03b4 0x0000 0x9f90 0x0002 0x0ff0 0x0000 0x8003 0x0000 0x0000 0x0000 0x0001 0x0000 0x4f14 0x0000 0x0000 0x0000 0x87c9 0xc000 0x0006 0x966d 0x0000 0x0046 biosint: Bailing out Unexpected Exception: 6 @ 10:ffefbfff - Halting Code: 0 eflags: 00010006 eax: 0000ffff ebx: 000003b5 ecx: 04000000 edx: 5e000018 edi: 0000003d esi: 000003b4 ebp: 00029f7c esp: 00029f60 From corey.osgood at gmail.com Thu Aug 16 06:08:55 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Thu, 16 Aug 2007 00:08:55 -0400 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C3CD03.7090606@gmail.com> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> <20070815020326.15047.qmail@stuge.se> <46C3CD03.7090606@gmail.com> Message-ID: <46C3CDD7.6040608@gmail.com> Corey Osgood wrote: > Also, I've been looking at the msrs from linuxbios and the factory bios, > the factory bios sets up a single msr to cover the entire 512mb range, > then has another msr for the last 32mb (480-512mb), presumably the vga > framebuffer area. Should have mentioned this range is marked as UC, the others are marked as WB, IIRC. And I really meant mtrr, not msr, been reading too many of the geodelx posts I guess. -Corey From stepan at coresystems.de Thu Aug 16 09:43:59 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 16 Aug 2007 09:43:59 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C3CD03.7090606@gmail.com> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> <20070815020326.15047.qmail@stuge.se> <46C3CD03.7090606@gmail.com> Message-ID: <20070816074359.GA25992@coresystems.de> * Corey Osgood [070816 06:05]: > biosint: ip 0xf85e cs 0xf000 flags 0x13 Does it try to jump to 0xf000:0xf85e at some point? This seems to be a common "trick", it happened to their Epia ML5000 option rom as well: http://linuxbios.org/pipermail/linuxbios/2006-April/013899.html http://linuxbios.org/pipermail/linuxbios/2006-April/013907.html 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 r.marek at assembler.cz Thu Aug 16 09:50:08 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 16 Aug 2007 09:50:08 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C3CDD7.6040608@gmail.com> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> <20070815020326.15047.qmail@stuge.se> <46C3CD03.7090606@gmail.com> <46C3CDD7.6040608@gmail.com> Message-ID: <46C401B0.6060901@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Corey, I cant tell more than this code: To be distributed under GPL: //WARNING NEED to copy some registers from NB to SB (D0F3 -> D0F7) { device_t devFUNNB3 = dev_find_device(PCI_VENDOR_ID_VIA, 0x3238, 0); u8 regm, regm2; //shadow CTRL regm = pci_read_config8(devFUNNB3,0x88); writeback(dev, 0x57, regm); //shadow REGION 1 regm = pci_read_config8(devFUNNB3,0x80); writeback(dev, 0x61, regm); //shadow REGION 2 regm = pci_read_config8(devFUNNB3,0x81); writeback(dev, 0x62, regm); //shadow REGION 3 regm = pci_read_config8(devFUNNB3,0x86); writeback(dev, 0xe6, regm); regm = pci_read_config8(devFUNNB3,0x83); regm2 = pci_read_config8(dev,0x63); pci_write_config8(dev,0x63, (regm2 & 0xC0) | (regm & 0x3F)); } Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxAGv3J9wPJqZRNURAutyAKCSf9Yqp+RSfQkZk6sJOyCoifY3fACcCUzu Zsom6Bxouj3WbVHJ1SdzfvQ= =E/+Y -----END PGP SIGNATURE----- From stepan at coresystems.de Thu Aug 16 09:55:02 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 16 Aug 2007 09:55:02 +0200 Subject: [LinuxBIOS] Need help with the VGA bios In-Reply-To: <46C3CD03.7090606@gmail.com> References: <46C16544.6030900@gmail.com> <20070814125002.7288.qmail@stuge.se> <46C25CA8.6000705@gmail.com> <20070815020326.15047.qmail@stuge.se> <46C3CD03.7090606@gmail.com> Message-ID: <20070816075502.GB25992@coresystems.de> * Corey Osgood [070816 06:05]: > biosint: ip 0xf85e cs 0xf000 flags 0x13 LinuxBIOSv2/util/vgabios/helper_mem.c had some code that would set up parts of 0xf000:0xXXXX to look like a BIOS: > /* int 11 default location (Get Equipment Configuration) */ > MEM_WW(0x11 << 2, 0xf84d); > /* int 12 default location (Get Conventional Memory Size) */ > MEM_WW(0x12 << 2, 0xf841); > /* int 15 default location (I/O System Extensions) */ > MEM_WW(0x15 << 2, 0xf859); > /* int 1A default location (RTC, PCI and others) */ > MEM_WW(0x1a << 2, 0xff6e); > /* int 05 default location (Bound Exceeded) */ > MEM_WW(0x05 << 2, 0xff54); > /* int 08 default location (Double Fault) */ > MEM_WW(0x08 << 2, 0xfea5); > /* int 13 default location (Disk) */ > MEM_WW(0x13 << 2, 0xec59); > /* int 0E default location (Page Fault) */ > MEM_WW(0x0e << 2, 0xef57); > /* int 17 default location (Parallel Port) */ > MEM_WW(0x17 << 2, 0xefd2); > /* fdd table default location (int 1e) */ > MEM_WW(0x1e << 2, 0xefc7); Either this, or you could copy a bochs bios there? -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From bios at ryven.de Thu Aug 16 17:21:25 2007 From: bios at ryven.de (Markus) Date: Thu, 16 Aug 2007 15:21:25 +0000 Subject: [LinuxBIOS] littler image in bigger rom Message-ID: <20070816152125.0f97d511@PXE-Image> Hi Volks, I bought a 4 Mb Rom vor my Epia-v board. Flashrom can handel the chip but it isn't willig to programm the image of the old 2 Mb Chip in the 4 Mb Chip. Any idea's to solve this? Greeding Markus From stepan at coresystems.de Thu Aug 16 15:35:02 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 16 Aug 2007 15:35:02 +0200 Subject: [LinuxBIOS] littler image in bigger rom In-Reply-To: <20070816152125.0f97d511@PXE-Image> References: <20070816152125.0f97d511@PXE-Image> Message-ID: <46C45286.1090100@coresystems.de> Markus wrote: > Hi Volks, > I bought a 4 Mb Rom vor my Epia-v board. > Flashrom can handel the chip but it isn't willig to programm the image > of the old 2 Mb Chip in the 4 Mb Chip. > Any idea's to solve this? cat linuxbios.rom linuxbios.rom > linuxbios4M.rom 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 uwe at hermann-uwe.de Thu Aug 16 16:07:55 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 16 Aug 2007 16:07:55 +0200 Subject: [LinuxBIOS] [PATCH] Reimplementation/fixing of CS5530/CS5530A southbridge code In-Reply-To: <46C3BE45.9080309@speakeasy.net> References: <20070606213436.GB14290@greenwood> <46C3BE45.9080309@speakeasy.net> Message-ID: <20070816140755.GC13640@greenwood> On Wed, Aug 15, 2007 at 11:02:29PM -0400, Jonathan Sturges wrote: > Thanks for the updated 5530 code! > However, I'm having some difficulty enabling the IDE controllers when using > this patch. As far as I can tell, configuration parsing doesn't appear to > work for new ideX_enable flags. > > The 'register "ide0_enable" = "1"' configuration option seemed to have no > effect on my 5530 system. Even though both IDE controllers were enabled in > Config.lb, when I'd test the resulting image, IDE0 would be disabled and > IDE1 enabled. In the end, to make it work, I changed: > "if (conf->ide0_enable) {" > to: > "if ( 1 ) {" > ...in cs5530_ide.c to get IDE0 enabled. This forces it to work. The placement of the ide0_enable lines is important. I think they should _not_ be within the IDE section. Check src/mainboard/asi/mb_5blmp/Config.lb for an example which worked for me, and please report if that fixes the problem. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bios at ryven.de Thu Aug 16 18:11:36 2007 From: bios at ryven.de (Markus) Date: Thu, 16 Aug 2007 16:11:36 +0000 Subject: [LinuxBIOS] littler image in bigger rom In-Reply-To: <46C45286.1090100@coresystems.de> References: <20070816152125.0f97d511@PXE-Image> <46C45286.1090100@coresystems.de> Message-ID: <20070816161136.1f7393bc@PXE-Image> Am Thu, 16 Aug 2007 15:35:02 +0200 schrieb Stefan Reinauer : > Markus wrote: > > Hi Volks, > > I bought a 4 Mb Rom vor my Epia-v board. > > Flashrom can handel the chip but it isn't willig to programm the > > image of the old 2 Mb Chip in the 4 Mb Chip. > > Any idea's to solve this? > > cat linuxbios.rom linuxbios.rom > linuxbios4M.rom > > Stefan > Thanks it works. Markus From ryven at ryven.de Thu Aug 16 20:07:09 2007 From: ryven at ryven.de (Markus) Date: Thu, 16 Aug 2007 18:07:09 +0000 Subject: [LinuxBIOS] littler image in bigger rom In-Reply-To: <20070816161136.1f7393bc@PXE-Image> References: <20070816152125.0f97d511@PXE-Image> <46C45286.1090100@coresystems.de> <20070816161136.1f7393bc@PXE-Image> Message-ID: Am Thu, 16 Aug 2007 16:11:36 +0000 schrieb Markus : > Am Thu, 16 Aug 2007 15:35:02 +0200 > schrieb Stefan Reinauer : > > > Markus wrote: > > > Hi Volks, > > > I bought a 4 Mb Rom vor my Epia-v board. > > > Flashrom can handel the chip but it isn't willig to programm the > > > image of the old 2 Mb Chip in the 4 Mb Chip. > > > Any idea's to solve this? > > > > cat linuxbios.rom linuxbios.rom > linuxbios4M.rom > > > > Stefan > > > > Thanks it works. > > Markus > So I have tried: dd if=/dev/zero of=leer bs=1024 count=256 1) cat bios bios > bios-v4 work 2) cat bios leer > bios-v4 not working 3) cat leer bios > bios-v4 work in which order write Flashrom the image to flash? Markus From rminnich at gmail.com Thu Aug 16 18:18:23 2007 From: rminnich at gmail.com (ron minnich) Date: Thu, 16 Aug 2007 09:18:23 -0700 Subject: [LinuxBIOS] littler image in bigger rom In-Reply-To: References: <20070816152125.0f97d511@PXE-Image> <46C45286.1090100@coresystems.de> <20070816161136.1f7393bc@PXE-Image> Message-ID: <13426df10708160918h13faba11v39b55ddc02d4b6e9@mail.gmail.com> On 8/16/07, Markus wrote: > dd if=/dev/zero of=leer bs=1024 count=256 > 1) cat bios bios > bios-v4 work > 2) cat bios leer > bios-v4 not working > 3) cat leer bios > bios-v4 work > > in which order write Flashrom the image to flash? > The bios image comes last. ron From chris at stockwith.co.uk Thu Aug 16 18:21:27 2007 From: chris at stockwith.co.uk (Chris Lingard) Date: Thu, 16 Aug 2007 17:21:27 +0100 Subject: [LinuxBIOS] Getting the parts In-Reply-To: <20070815210701.18965.qmail@stuge.se> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> <20070815210701.18965.qmail@stuge.se> Message-ID: <46C47987.3040104@stockwith.co.uk> Peter Stuge wrote: > Hey Chris, > > On Wed, Aug 15, 2007 at 03:45:15PM +0100, Richard Wilson wrote: >>> I need to buy whatever you solder onto the motherboard, a guy at >>> the local computer shop can do the actual work. > > Perfect! > > Maybe we can help you find the components that you need. We should > have thought about putting up article numbers for a few suppliers > on the wiki page already. > > I don't know much about shopping for electronics in the UK - can > anyone suggest good retail or mail order stores with online > catalogues? I'll have a look at it and suggest some parts. > Note that these flash chips do NOT work for the M57SLI board. Chris, > I'll get you a few part numbers for flash as well, eBay may be the > best bet to find those since not all electronics stores have stock of > flash memory. (Prices usually change too quickly.) > And it's a great help for development. We do need to think of some > practical way to handle hardware donations, there has been a few > offers recently, which is very nice. > Thank you for the reply, I believe I need some SST 49LF040 or PM 49FL004 flash memory, and some sockets it will plug into. Will continue to search in the UK, But, if anyone has the above, or can buy some; please let me know and I will buy some too. I have got a RD1-PMC4 on the way. I have printed most of the descriptions out, so I can be ready Chris Lingard From r.marek at assembler.cz Thu Aug 16 18:34:55 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 16 Aug 2007 18:34:55 +0200 Subject: [LinuxBIOS] Getting the parts In-Reply-To: <46C47987.3040104@stockwith.co.uk> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> <20070815210701.18965.qmail@stuge.se> <46C47987.3040104@stockwith.co.uk> Message-ID: <46C47CAF.8080906@assembler.cz> > Thank you for the reply, I believe I need some SST 49LF040 or PM 49FL004 I bought some at http://bios-repair.co.uk/bios/eeprom.htm (shipped to Czech Rep for like 60p iirc;) Rudolf From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 16 19:31:38 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 16 Aug 2007 19:31:38 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> Message-ID: <46C489FA.6000807@gmx.net> On 05.08.2007 21:45, Ra?l S?nchez Siles wrote: > I'm sorry but I've been unable to get that info from the Dell flash > utility. When loaded it's no chance to get any info like that. The only > option I'm given is to reflash the BIOS again. > > I would be glad to test any other tool/method you propose to get the info. It seems that Dell has a BIOS update tool for Linux. Documentation is at http://linux.dell.com/libsmbios/main/dellBiosUpdate.html Maybe that can be used to find the necessary info. Besides that, it would be nice if someone could add generic Dell support to flashrom. Regards, Carl-Daniel From uwe at hermann-uwe.de Thu Aug 16 20:00:48 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 16 Aug 2007 20:00:48 +0200 Subject: [LinuxBIOS] Intel DRB HOWTO .. a 1st draft. In-Reply-To: <46BF13AC.4040107@gmx.de> References: <20070812134530.0872f4f7@absurd> <46BF13AC.4040107@gmx.de> Message-ID: <20070816180048.GD13640@greenwood> Hi, On Sun, Aug 12, 2007 at 04:05:32PM +0200, popkonserve wrote: > maybe this would be a good start for a decent source code documentation. at > least it should help understanding the code. Yep, great thanks! Assuming you wrote this from scratch (vs. copying from somewhere), please add this to your code so we can include it when committing... > * The modules can be single sided or double sided. Modules with chips on both > * sides are generally called double sided which may not be true. Double sided > * refers to the number of memory control signals used by the module to address > * its memory. Since the detection algorithm isn't able to actually see the > * module it doesn't matter if it has chips on both sides or not. The algorithm > * will just assume the module is double sided and maybe revise its descicion ^^^^^^^^^ decision > * Let's take another pair of those memory modules and install them in the two > * remaining SIMM sockets. There are now 4 single sided modules installed, 16MB > * each resulting in 64MB total. Figure 4 shows the acutal memory configuration. ^^^^^^ actual Cheers, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From rasasi78 at gmail.com Thu Aug 16 21:09:21 2007 From: rasasi78 at gmail.com (=?UTF-8?B?UmHDumwgU8OhbmNoZXogU2lsZXM=?=) Date: Thu, 16 Aug 2007 21:09:21 +0200 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <46C489FA.6000807@gmx.net> Message-ID: Carl-Daniel Hailfinger wrote: > On 05.08.2007 21:45, Ra?l S?nchez Siles wrote: >> I'm sorry but I've been unable to get that info from the Dell flash >> utility. When loaded it's no chance to get any info like that. The only >> option I'm given is to reflash the BIOS again. >> >> I would be glad to test any other tool/method you propose to get the >> info. > > It seems that Dell has a BIOS update tool for Linux. Documentation is at > http://linux.dell.com/libsmbios/main/dellBiosUpdate.html > > Maybe that can be used to find the necessary info. I had check out that as well, but the only valuable thing that could be done with that is BIOS flashing. Reading is not possible AFAIK. > > Besides that, it would be nice if someone could add generic Dell support > to flashrom. > I sign this, but without specs it will be very difficult. Contact me if you need me to do some testing. Undangerous experiments will have preference :P Thanks for the answer. From ward at gnu.org Thu Aug 16 21:26:39 2007 From: ward at gnu.org (Ward Vandewege) Date: Thu, 16 Aug 2007 15:26:39 -0400 Subject: [LinuxBIOS] ICH4 BIOS chip not recognised. In-Reply-To: References: <46B3D814.4010001@gmx.net> <20070804181125.GA16755@coresystems.de> <46C489FA.6000807@gmx.net> Message-ID: <20070816192639.GA24872@countzero.vandewege.net> On Thu, Aug 16, 2007 at 09:09:21PM +0200, Ra?l S?nchez Siles wrote: > > It seems that Dell has a BIOS update tool for Linux. Documentation is at > > http://linux.dell.com/libsmbios/main/dellBiosUpdate.html > > > > Maybe that can be used to find the necessary info. > > I had check out that as well, but the only valuable thing that could be done > with that is BIOS flashing. Reading is not possible AFAIK. As far as I know the way the Dell flashing tools work is that they upload the new bios image to ram, and set a flag (in cmos?) for the bios to reflash itself on the next boot from the ram image. So that doesn't really help us with regard to flashrom, I'm afraid. > > Besides that, it would be nice if someone could add generic Dell support > > to flashrom. +1 Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From joe at smittys.pointclark.net Thu Aug 16 23:42:25 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 16 Aug 2007 17:42:25 -0400 Subject: [LinuxBIOS] Getting the parts In-Reply-To: <46C47CAF.8080906@assembler.cz> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> <20070815210701.18965.qmail@stuge.se> <46C47987.3040104@stockwith.co.uk> <46C47CAF.8080906@assembler.cz> Message-ID: <20070816174225.eegjc47orkgkwock@www.smittys.pointclark.net> Quoting Rudolf Marek : >> Thank you for the reply, I believe I need some SST 49LF040 or PM 49FL004 > > I bought some at http://bios-repair.co.uk/bios/eeprom.htm (shipped > to Czech Rep > for like 60p iirc;) > > Rudolf > Have you tried Newark (http://www.newark.com). They have a huge inventory and will ship world wide. They sell alot of PC componants. This is where I get all of my stuff from including PLCC32 sockets when I need to socket a motherboard. Thanks - Joe From rmh at aybabtu.com Fri Aug 17 00:53:20 2007 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 17 Aug 2007 00:53:20 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X (K8/CK804/IT8712F) Message-ID: <20070816225320.GA8464@aragorn> Hi, After commenting this with Uwe on IRC, he said I should ask to the list to see if someone knows what's going on. I'm running LB with some patches (combined with fixes sent by Uwe and Rudolf), plus some PNP adjustments for the keyboard/game/midi ports on my ASUS A8N5X (K8/CK804/IT8712F), and keyboard is not working neither from FILO nor Linux. Find attached: - combined diff of the changes I have relative to svn - minicom capture log (using loglevel 11) - "lspci -nnv" and "lspnp -v" output Some hint would be appreciated. TIA! -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -------------- next part -------------- A non-text attachment was scrubbed... Name: combined.diff Type: text/x-diff Size: 7150 bytes Desc: not available URL: -------------- next part -------------- 00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3) Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:01.0 ISA bridge [0601]: nVidia Corporation CK804 ISA Bridge [10de:0050] (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus [0c05]: nVidia Corporation CK804 SMBus [10de:0052] (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: 66MHz, fast devsel, IRQ 5 I/O ports at e400 [size=32] I/O ports at 4c00 [size=64] I/O ports at 4c40 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005a] (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217 Memory at d2004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005b] (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225 Memory at feb00000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:04.0 Multimedia audio controller [0401]: nVidia Corporation CK804 AC'97 Audio Controller [10de:0059] (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:812a] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225 I/O ports at dc00 [size=256] I/O ports at e000 [size=256] Memory at d2003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at f000 [size=16] Capabilities: [44] Power Management version 2 00:07.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0054] (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 50 I/O ports at 09f0 [size=8] I/O ports at 0bf0 [size=4] I/O ports at 0970 [size=8] I/O ports at 0b70 [size=4] I/O ports at d800 [size=16] Memory at d2002000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:08.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0055] (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:815a] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217 I/O ports at 09e0 [size=8] I/O ports at 0be0 [size=4] I/O ports at 0960 [size=8] I/O ports at 0b60 [size=4] I/O ports at c400 [size=16] Memory at d2001000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:09.0 PCI bridge [0604]: nVidia Corporation CK804 PCI Bridge [10de:005c] (rev a2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=128 Memory behind bridge: d0000000-d1ffffff Prefetchable memory behind bridge: 68000000-680fffff 00:0a.0 Bridge [0680]: nVidia Corporation CK804 Ethernet Controller [10de:0057] (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard [1043:8141] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233 Memory at d2000000 (32-bit, non-prefetchable) [size=4K] I/O ports at b000 [size=8] Capabilities: [44] Power Management version 2 00:0b.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [40] Power Management version 2 Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Capabilities: [100] Virtual Channel 00:0c.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Capabilities: [40] Power Management version 2 Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Capabilities: [100] Virtual Channel 00:0d.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: [40] Power Management version 2 Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Capabilities: [100] Virtual Channel 00:0e.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: [40] Power Management version 2 Capabilities: [48] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+ Capabilities: [58] HyperTransport: MSI Mapping Capabilities: [80] Express Root Port (Slot+) IRQ 0 Capabilities: [100] Virtual Channel 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] Flags: fast devsel 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] Flags: fast devsel 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] Flags: fast devsel 05:06.0 VGA compatible controller [0300]: S3 Inc. 86c764/765 [Trio32/64/64V+] [5333:8811] (prog-if 00 [VGA]) Flags: medium devsel, IRQ 3 Memory at d1000000 (32-bit, non-prefetchable) [size=8M] [virtual] Expansion ROM at 68000000 [disabled] [size=64K] -------------- next part -------------- 00:00 PNP0a08 (unknown) state = active io 0xcf8-0xcff 00:01 PNP0c02 Motherboard resources state = active io 0x4000-0x407f io 0x4080-0x40ff io 0x4400-0x447f io 0x4480-0x44ff io 0x4800-0x487f io 0x4880-0x48ff 00:02 PNP0c02 Motherboard resources state = active io 0x10-0x1f io 0x22-0x3f io 0x44-0x5f io 0x62-0x63 io 0x65-0x6f io 0x74-0x7f io 0x91-0x93 io 0xa2-0xbf 00:03 PNP0200 AT DMA controller state = active io 0x0-0xf io 0x80-0x90 io 0x94-0x9f io 0xc0-0xdf dma 4 00:04 PNP0b00 AT real-time clock state = active io 0x70-0x73 irq 8 00:05 PNP0800 AT speaker state = active io 0x61-0x61 00:06 PNP0c04 Math coprocessor state = active io 0xf0-0xff irq 13 00:07 PNP0700 PC standard floppy disk controller state = active io 0x3f0-0x3f5 io 0x3f7-0x3f7 irq 6 dma 2 00:08 PNP0501 16550A-compatible serial port state = active io 0x3f8-0x3ff irq 4 00:09 PNP0401 ECP printer port state = active io 0x378-0x37f io 0x778-0x77b irq 7 dma 3 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) state = active io 0x60-0x60 io 0x64-0x64 irq 1 00:0b PNPb006 MPU401 compatible state = active io 0x330-0x331 irq 10 00:0c PNPb02f Joystick/Game port state = active io 0x201-0x201 00:0d PNP0c02 Motherboard resources state = active mem 0xe0000000-0xefffffff 00:0e PNP0c01 System board state = active mem 0xf0000-0xf3fff mem 0xf4000-0xf7fff mem 0xf8000-0xfbfff mem 0xfc000-0xfffff -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap.gz Type: application/octet-stream Size: 17904 bytes Desc: not available URL: From talbotx at comcast.net Fri Aug 17 01:05:12 2007 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 16 Aug 2007 16:05:12 -0700 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X (K8/CK804/IT8712F) In-Reply-To: <20070816225320.GA8464@aragorn> References: <20070816225320.GA8464@aragorn> Message-ID: <46C4D828.3090905@comcast.net> Let me just ask the very dumb question. Does the keyboard work with the stock BIOS? Have you tried the stock BIOS since you had this problem? Just a sanity check. -Adam Robert Millan wrote: > Hi, > > After commenting this with Uwe on IRC, he said I should ask to the list to > see if someone knows what's going on. > > I'm running LB with some patches (combined with fixes sent by Uwe and Rudolf), > plus some PNP adjustments for the keyboard/game/midi ports on my ASUS A8N5X > (K8/CK804/IT8712F), and keyboard is not working neither from FILO nor Linux. > > Find attached: > > - combined diff of the changes I have relative to svn > - minicom capture log (using loglevel 11) > - "lspci -nnv" and "lspnp -v" output > > Some hint would be appreciated. TIA! > > From rmh at aybabtu.com Fri Aug 17 01:06:45 2007 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 17 Aug 2007 01:06:45 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X (K8/CK804/IT8712F) In-Reply-To: <46C4D828.3090905@comcast.net> References: <20070816225320.GA8464@aragorn> <46C4D828.3090905@comcast.net> Message-ID: <20070816230645.GA9104@aragorn> On Thu, Aug 16, 2007 at 04:05:12PM -0700, Adam Talbot wrote: > Let me just ask the very dumb question. Does the keyboard work with the > stock BIOS? Have you tried the stock BIOS since you had this problem? > Just a sanity check. Yes :-) I switch LB and stock BIOS all the time, because from LB I don't get network, so I can't scp new images for re-flash. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 17 01:14:31 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 17 Aug 2007 01:14:31 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X (K8/CK804/IT8712F) In-Reply-To: <20070816225320.GA8464@aragorn> References: <20070816225320.GA8464@aragorn> Message-ID: <46C4DA57.4020906@gmx.net> On 17.08.2007 00:53, Robert Millan wrote: > Hi, > > After commenting this with Uwe on IRC, he said I should ask to the list to > see if someone knows what's going on. > > I'm running LB with some patches (combined with fixes sent by Uwe and Rudolf), > plus some PNP adjustments for the keyboard/game/midi ports on my ASUS A8N5X > (K8/CK804/IT8712F), and keyboard is not working neither from FILO nor Linux. Please also attach a dmesg (or minicom capture log) for Linux under the proprietary BIOS. Regards, Carl-Daniel From marc.jones at amd.com Fri Aug 17 01:32:07 2007 From: marc.jones at amd.com (Marc Jones) Date: Thu, 16 Aug 2007 17:32:07 -0600 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <20070816225320.GA8464@aragorn> References: <20070816225320.GA8464@aragorn> Message-ID: <46C4DE77.5090303@amd.com> Robert Millan wrote: > Hi, > > After commenting this with Uwe on IRC, he said I should ask to the list to > see if someone knows what's going on. > > I'm running LB with some patches (combined with fixes sent by Uwe and Rudolf), > plus some PNP adjustments for the keyboard/game/midi ports on my ASUS A8N5X > (K8/CK804/IT8712F), and keyboard is not working neither from FILO nor Linux. > > Find attached: > > - combined diff of the changes I have relative to svn > - minicom capture log (using loglevel 11) > - "lspci -nnv" and "lspnp -v" output > > Some hint would be appreciated. TIA! > > I assume you have a good reason, but why are you changing the it8712f pnp device numbers? I am not positive how this works, but I think changing 2e.0 to 2e.7 means that you are trying to program the it8712f logical device 7 with floppy settings. http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf IRQ routing/polarity/mask issues? Check mptable.c and irq_tables.c. You can check the keyboard controller input buffer to see if a keystroke is in there. Then you would know that interrupt isn't getting through. Do you have serial console working and does keyboard work there? That would tell you if interrupts are making it from the SIO. http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-8.html Hope this helps. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From rmh at aybabtu.com Fri Aug 17 01:44:51 2007 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 17 Aug 2007 01:44:51 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X (K8/CK804/IT8712F) In-Reply-To: <20070816225320.GA8464@aragorn> References: <20070816225320.GA8464@aragorn> Message-ID: <20070816234451.GA11423@aragorn> dmesg+init of each bios for comparison, as asked on IRC. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -------------- next part -------------- Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12) (waldi at debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Mon Mar 26 16:39:10 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 0000000060000000 (usable) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 00000010 DMI not present or invalid. ACPI: Unable to locate RSDP Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: ASUS Product ID: A8NE APIC at: 0xFEE00000 Processor #0 15:15 APIC version 16 I/O APIC #1 Version 17 at 0xFC900000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at 70000000 (gap: 60000000:a0000000) Detected 2211.388 MHz processor. Built 1 zonelists. Total pages: 229376 Kernel command line: root=/dev/hda1 ro console=ttyS0,115200 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 902100k/917504k available (1502k kernel code, 14824k reserved, 601k data, 256k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4428.89 BogoMIPS (lpj=8857799) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) Compat vDSO mapped to ffffe000. CPU: AMD Athlon(tm) 64 Processor 3500+ stepping 02 Checking 'hlt' instruction... OK. ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ..... (found pin 0) ...works. checking if image is initramfs... it is Freeing initrd memory: 4244k freed NET: Registered protocol family 16 EISA bus registered PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: PnP BIOS support was not detected. PCI: Probing PCI hardware PCI: Transparent bridge - 0000:00:09.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0b.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0c.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0d.0 PCI: Unable to handle 64-bit address space for bridge 0000:00:0e.0 PCI: Using IRQ router default [10de/005c] at 0000:00:09.0 PCI->APIC IRQ transform: 0000:00:01.1[A] -> IRQ 10 PCI->APIC IRQ transform: 0000:00:02.0[A] -> IRQ 153 PCI->APIC IRQ transform: 0000:00:02.1[B] -> IRQ 145 PCI->APIC IRQ transform: 0000:00:07.0[A] -> IRQ 169 PCI->APIC IRQ transform: 0000:00:08.0[A] -> IRQ 161 PCI->APIC IRQ transform: 0000:00:0a.0[A] -> IRQ 169 PCI BIOS passed nonexistent PCI bus 1! PCI: Cannot allocate resource region 5 of device 0000:00:01.1 PCI: Bridge: 0000:00:09.0 IO window: disabled. MEM window: fc000000-fc8fffff PREFETCH window: 70000000-700fffff PCI: Bridge: 0000:00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0d.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 7, 524288 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1187224235.884:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize PNP: No PS/2 controller found. Probing ports directly. i8042.c: Can't read CTR while initializing i8042. mice: PS/2 mouse device common for all mice EISA: Probing bus 0 at eisa.0 EISA: Cannot allocate resource for mainboard Cannot allocate resource for EISA slot 1 EISA: Detected 0 cards. TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 Using IPI Shortcut mode Freeing unused kernel memory: 256k freed Time: tsc clocksource has been installed. Loading, please wait... Begin: Loading essential drivers... ... Done. Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.18-4-486/kernel/drivers/acpi/fan.ko): No such device FATAL: Error inserting thermal (/lib/modules/2.6.18-4-486/kernel/drivers/acpi/thermal.ko): No such device usbcore: registered new driver usbfs usbcore: registered new driver hub Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ohci_hcd 0000:00:02.0: OHCI Host Controller ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:02.0: irq 153, io mem 0xfc901000 forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56. usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 10 ports detected ehci_hcd 0000:00:02.1: EHCI Host Controller ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:02.1: debug port 1 ehci_hcd 0000:00:02.1: irq 145, io mem 0xfc905000 ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0 NFORCE-CK804: chipset revision 162 NFORCE-CK804: not 100% native mode: will probe irqs later NFORCE-CK804: 0000:00:06.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:pio hda: ST34321A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 SCSI subsystem initialized forcedeth: using HIGHDMA eth0: forcedeth.c: subsystem: 010f1:2891 bound to 0000:00:0a.0 ata1: SATA max UDMA/133 cmd 0x1050 ctl 0x10A2 bmdma 0x1030 irq 169 ata2: SATA max UDMA/133 cmd 0x1060 ctl 0x10B2 bmdma 0x1038 irq 169 scsi0 : sata_nv ata1: SATA link down (SStatus 0 SControl 300) scsi1 : sata_nv ata2: SATA link down (SStatus 0 SControl 300) ata3: SATA max UDMA/133 cmd 0x1070 ctl 0x10C2 bmdma 0x1040 irq 161 ata4: SATA max UDMA/133 cmd 0x1080 ctl 0x10D2 bmdma 0x1048 irq 161 scsi2 : sata_nv ata3: SATA link down (SStatus 0 SControl 300) scsi3 : sata_nv ata4: SATA link down (SStatus 0 SControl 300) hda: max request size: 128KiB hda: 8404830 sectors (4303 MB) w/128KiB Cache, CHS=8894/15/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 > Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Running /scripts/local-premount ... kinit: name_to_dAttempting manual resume ev_t(/dev/hda5) = hda5(3,5) kinit: trying to resume from /dev/hda5 kinit: No resume image, doing normal boot... Done. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Begin: Running /scripts/local-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... Done. Mount failed for selinuxfs on /selinux: No such file or directory INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...input: PC Speaker as /class/input/input0 i2c_adapter i2c-0: nForce2 SMBus adapter at 0xc80 i2c_adapter i2c-1: nForce2 SMBus adapter at 0x1400 done. Activating swap...Adding 240932k swap on /dev/hda5. Priority:-1 extents:1 across:240932k done. Checking root file system...fsck 1.40-WIP (14-Nov-2006) /dev/hda1: clean, 17803/495008 files, 94979/989997 blocks (check after next mount) done. EXT3 FS on hda1, internal journal Setting the system clock.. Cleaning up ifupdown.... Loading kernel modules...loop: loaded (max 8 devices) done. Loading device-mapper supportdevice-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel at redhat.com . Checking file systems...fsck 1.40-WIP (14-Nov-2006) done. Setting kernel variables...done. Mounting local filesystems...done. Activating swapfile swap...done. Setting up networking.... Configuring network interfaces...Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ SIOCSIFADDR: No such device nforce: ERROR while getting interface flags: No such device nforce: ERROR while getting interface flags: No such device Bind socket to interface: No such device Failed to bring up nforce. done. Setting console screen modes and fonts. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting OpenBSD Secure Shell server: sshdNET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver . * Not starting internet superserver: no services enabled. Debian GNU/Linux 4.0 cesc ttyS0 cesc login: -------------- next part -------------- Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12) (waldi at debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Mon Mar 26 16:39:10 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000005fff0000 (usable) BIOS-e820: 000000005fff0000 - 000000005fff3000 (ACPI NVS) BIOS-e820: 000000005fff3000 - 0000000060000000 (ACPI data) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000f5650 DMI 2.3 present. ACPI: PM-Timer IO Port: 0x4008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:15 APIC version 16 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 68000000 (gap: 60000000:80000000) Detected 2211.355 MHz processor. Built 1 zonelists. Total pages: 229376 Kernel command line: root=/dev/hda1 ro console=ttyS0,115200 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 902096k/917504k available (1502k kernel code, 14828k reserved, 601k data, 256k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4425.34 BogoMIPS (lpj=8850694) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) Compat vDSO mapped to ffffe000. CPU: AMD Athlon(tm) 64 Processor 3500+ stepping 02 Checking 'hlt' instruction... OK. ACPI: Core revision 20060707 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1 checking if image is initramfs... it is Freeing initrd memory: 4244k freed NET: Registered protocol family 16 EISA bus registered ACPI: bus type pci registered PCI: Using MMCONFIG PCI: No mmconfig possible on 0:18 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Transparent bridge - 0000:00:09.0 ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled. ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled. ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled. ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled. ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 15 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:01: ioport range 0x4000-0x407f could not be reserved pnp: 00:01: ioport range 0x4080-0x40ff has been reserved pnp: 00:01: ioport range 0x4400-0x447f has been reserved pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved pnp: 00:01: ioport range 0x4800-0x487f has been reserved pnp: 00:01: ioport range 0x4880-0x48ff has been reserved PCI: Bridge: 0000:00:09.0 IO window: disabled. MEM window: d0000000-d1ffffff PREFETCH window: 68000000-680fffff PCI: Bridge: 0000:00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0d.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 7, 524288 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1187307859.176:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) PCI: Linking AER extended capability on 0000:00:0b.0 PCI: Linking AER extended capability on 0000:00:0c.0 PCI: Linking AER extended capability on 0000:00:0d.0 PCI: Linking AER extended capability on 0000:00:0e.0 pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 PNP: PS/2 controller doesn't have AUX irq; using default 12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice EISA: Probing bus 0 at eisa.0 Cannot allocate resource for EISA slot 4 EISA: Detected 0 cards. TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 Using IPI Shortcut mode ACPI: (supports S0 S1 S3 S4 S5<6>Time: tsc clocksource has been installed. ) Freeing unused kernel memory: 256k freed Loading, please wait... Begin: Loading essential drivers... ... Done. Begin: Running /scripts/init-premount ... ACPI: Fan [FAN] (on) ACPI: Getting cpuindex for acpiid 0x1 ACPI: Thermal Zone [THRM] (40 C) usbcore: registered new driver usbfs usbcore: registered new driver hub Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx input: AT Translated Set 2 keyboard as /class/input/input0 NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0 NFORCE-CK804: chipset revision 242 NFORCE-CK804: not 100% native mode: will probe irqs later NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56. hda: ST34321A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 SCSI subsystem initialized ACPI: PCI Interrupt Link [APCL] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 217 ehci_hcd 0000:00:02.1: EHCI Host Controller ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:02.1: debug port 1 ehci_hcd 0000:00:02.1: irq 217, io mem 0xfeb00000 ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 10 ports detected ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 225 ohci_hcd 0000:00:02.0: OHCI Host Controller ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:02.0: irq 225, io mem 0xd2004000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 10 ports detected ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21 ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 21 (level, low) -> IRQ 233 ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 233 ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 233 scsi0 : sata_nv ata1: SATA link down (SStatus 0 SControl 300) scsi1 : sata_nv ata2: SATA link down (SStatus 0 SControl 300) ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20 ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 20 (level, low) -> IRQ 50 ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 50 ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 50 scsi2 : sata_nv ata3: SATA link down (SStatus 0 SControl 300) scsi3 : sata_nv ata4: SATA link down (SStatus 0 SControl 300) ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 217 forcedeth: using HIGHDMA hda: max request size: 128KiB hda: 8404830 sectors (4303 MB) w/128KiB Cache, CHS=8894/15/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 > eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0 Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Running /scripts/local-premount ... kinit: name_to_dAttempting manual resume ev_t(/dev/hda5) = hda5(3,5) kinit: trying to resume from /dev/hda5 kinit: No resume image, doing normal boot... Done. EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. Begin: Running /scripts/local-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... Done. Mount failed for selinuxfs on /selinux: No such file or directory INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...Real Time Clock Driver v1.12ac Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 input: PC Speaker as /class/input/input1 i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00 i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40 parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 22 (level, low) -> IRQ 225 intel8x0_measure_ac97_clock: measured 54624 usecs intel8x0: clocking to 46960 Intel 810 + AC97 Audio, version 1.01, 17:02:08 Mar 26 2007 done. Activating swap...Adding 240932k swap on /dev/hda5. Priority:-1 extents:1 across:240932k done. Checking root file system...fsck 1.40-WIP (14-Nov-2006) /dev/hda1: clean, 32563/495008 files, 129886/989997 blocks done. EXT3 FS on hda1, internal journal Setting the system clock.. Cleaning up ifupdown.... Loading kernel modules...loop: loaded (max 8 devices) done. Loading device-mapper supportdevice-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel at redhat.com . Checking file systems...fsck 1.40-WIP (14-Nov-2006) done. Setting kernel variables...done. Mounting local filesystems...done. Activating swapfile swap...done. Setting up networking.... Configuring network interfaces...Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/nforce/00:13:d4:dc:14:fc Sending on LPF/nforce/00:13:d4:dc:14:fc Sending on Socket/fallback DHCPDISCOVER on nforce to 255.255.255.255 port 67 interval 8 DHCPOFFER from 192.168.0.1 DHCPREQUEST on nforce to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.9 -- renewal in 9424 seconds. NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver done. Setting console screen modes and fonts. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting OpenBSD Secure Shell server: sshd. Loading ACPI modules: battery ac processor button ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] fan thermal Starting Advanced Configuration and Power Interface daemon: acpid. * Not starting internet superserver: no services enabled. Debian GNU/Linux 4.0 cesc ttyS0 cesc login: From joe at smittys.pointclark.net Fri Aug 17 06:40:47 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Fri, 17 Aug 2007 00:40:47 -0400 Subject: [LinuxBIOS] smbus_write_byte??? Message-ID: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> Anyone know if there is a function to write to the smbus similar to the smbus_read_byte function? Execpt write not read of course, like smbus_write_byte? Thanks - Joe From corey.osgood at gmail.com Fri Aug 17 07:45:43 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 17 Aug 2007 01:45:43 -0400 Subject: [LinuxBIOS] smbus_write_byte??? In-Reply-To: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> Message-ID: <46C53607.9080003@gmail.com> Joseph Smith wrote: > Anyone know if there is a function to write to the smbus similar to > the smbus_read_byte function? Execpt write not read of course, like > smbus_write_byte? > > Thanks - Joe > > For i82801xx, it's already implemented, just totally untested. I have no idea who wrote it, and I make no claim of it actually working (although it very well could). Have a look at i82801xx_smbus.h, that's where all the smbus functions really live, you're looking for do_smbus_write_byte. It's commented out atm, my own decision since I was unsure of it with no real way to test. -Corey From rmh at aybabtu.com Fri Aug 17 13:49:10 2007 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 17 Aug 2007 13:49:10 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <46C4DE77.5090303@amd.com> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> Message-ID: <20070817114910.GA11469@aragorn> On Thu, Aug 16, 2007 at 05:32:07PM -0600, Marc Jones wrote: > > I assume you have a good reason, but why are you changing the it8712f > pnp device numbers? I am not positive how this works, but I think > changing 2e.0 to 2e.7 means that you are trying to program the it8712f > logical device 7 with floppy settings. > http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf The changes were mostly part of the patch Uwe sent me (for his slightly different board). I also changed keyboard (s/2e.5/2e.a/), midi (s/2e.8/2e.b/) and game port (s/2e.9/2e.c/) while trying to match with lspnp output: 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) 00:0b PNPb006 MPU401 compatible 00:0c PNPb02f Joystick/Game port Is this correct? > IRQ routing/polarity/mask issues? Check mptable.c and irq_tables.c. I see that they print these debug messages: Writing IRQ routing tables to 0xf0000...done. Wrote the mp table end at: 00000020 - 00000140 I'm not sure if I can make sense of this. Should I poke at the contents in these addresses? > You can check the keyboard controller input buffer to see if a keystroke > is in there. Then you would know that interrupt isn't getting through. How would I do that, with a userspace program using inb()/outb() ? > Do you have serial console working and does keyboard work there? That > would tell you if interrupts are making it from the SIO. Yes, that works. Thank you -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From j-engel at gmx.de Fri Aug 17 14:30:56 2007 From: j-engel at gmx.de (Johannes Engel) Date: Fri, 17 Aug 2007 14:30:56 +0200 Subject: [LinuxBIOS] DELL Latitude D820 flashrom info Message-ID: <46C59500.104@gmx.de> Hello! As Carl-Daniel suggested attached you find the info for a Dell Latitude D820 laptop. Greetings, Johannes -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmidecode URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: flashrom URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci URL: From angelini at ngames.com.br Fri Aug 17 18:01:55 2007 From: angelini at ngames.com.br (angelini) Date: Fri, 17 Aug 2007 13:01:55 -0300 Subject: [LinuxBIOS] help with bios to GEODE GX Message-ID: <000601c7e0e7$f005fd20$0c01a8c0@druid> Dear friends, I dont know if is possible or if works in this way, i need make a changes video ram memory sharing in my GEODE GX533 at 1W bios today they using 8mb of ram to video, and FIC told me that's GX533 is able to using at 64mb, but AMD don't provide BIOS changes to this. Please help me! If is possible! Angelini -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Fri Aug 17 18:50:43 2007 From: marc.jones at amd.com (Marc Jones) Date: Fri, 17 Aug 2007 10:50:43 -0600 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <20070817114910.GA11469@aragorn> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> <20070817114910.GA11469@aragorn> Message-ID: <46C5D1E3.8090904@amd.com> Robert Millan wrote: > On Thu, Aug 16, 2007 at 05:32:07PM -0600, Marc Jones wrote: >> I assume you have a good reason, but why are you changing the it8712f >> pnp device numbers? I am not positive how this works, but I think >> changing 2e.0 to 2e.7 means that you are trying to program the it8712f >> logical device 7 with floppy settings. >> http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf > > The changes were mostly part of the patch Uwe sent me (for his slightly > different board). I also changed keyboard (s/2e.5/2e.a/), midi (s/2e.8/2e.b/) > and game port (s/2e.9/2e.c/) while trying to match with lspnp output: > > 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) > 00:0b PNPb006 MPU401 compatible > 00:0c PNPb02f Joystick/Game port > > Is this correct? > I guess Uwe would need to answer this. I must not understand it correctly. >> IRQ routing/polarity/mask issues? Check mptable.c and irq_tables.c. > > I see that they print these debug messages: > > Writing IRQ routing tables to 0xf0000...done. > Wrote the mp table end at: 00000020 - 00000140 > > I'm not sure if I can make sense of this. Should I poke at the contents > in these addresses? > You can get more info here: http://linuxbios.org/Glossary#MPTable http://linuxbios.org/Glossary#PIRQ I don't recall where, but there are some guides on dumping the tables from the PCBIOS somewhere. >> You can check the keyboard controller input buffer to see if a keystroke >> is in there. Then you would know that interrupt isn't getting through. > > How would I do that, with a userspace program using inb()/outb() ? > Yes, // check if there is a keystroke that hasn't been serviced and see what it is. status = inb(0x64); if ((status & 0x1)) scancode = inb(0x60); if the KBC controller is being serviced it is unlikely that you will catch a character in the output buffer. If the KBC isn't initialized correctly you might not get a character either. >> Do you have serial console working and does keyboard work there? That >> would tell you if interrupts are making it from the SIO. > > Yes, that works. > > Thank you > Interesting that the SIO serial interrupt works and the the keyboard one doesn't. I am not sure what that means. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From robjoski at gmail.com Fri Aug 17 20:04:24 2007 From: robjoski at gmail.com (Robert Oscilowski) Date: Fri, 17 Aug 2007 14:04:24 -0400 Subject: [LinuxBIOS] Is my motherboard supported?... Message-ID: <279958380708171104t1961c9fck3d5acbf675da0e5@mail.gmail.com> Hi! I need to know if my motherboard is supported. I'm pretty sure most of its components are at least work-in-progress, but I'm not sure. Here is what I know about my system: CPU: Intel Pentium II 400Mhz -- I'm thinking about upgrading it soon... Northbridge: Intel 82443BX Southbridge: Intel 82371EB Super I/O: SMSC FDC37M707 Mainboard: Intel SE440BX-2 *Flash Chip: Intel... TSOC? It's a pity I can't send pictures; I need help identifying it! lspci output: 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 04) 00:0d.1 Input device controller: Creative Labs SB Live! Game Port (rev 01) 00:0e.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) 00:10.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 12) 01:00.0 VGA compatible controller: nVidia Corporation NV4 [RIVA TNT] (rev 04) Thanks! -- robjoski-1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.jones at amd.com Fri Aug 17 20:19:08 2007 From: marc.jones at amd.com (Marc Jones) Date: Fri, 17 Aug 2007 12:19:08 -0600 Subject: [LinuxBIOS] reset16 vs reset32 In-Reply-To: <46C4CEB6.3070608@amd.com> References: <46C4C94E.8010203@amd.com> <20070816221457.GA5012@coresystems.de> <46C4CEB6.3070608@amd.com> Message-ID: <46C5E69C.80106@amd.com> I am running into a build problem with a ROM that contains normal, fallback, and failover images. I get the following error. /usr/bin/ld: section .data [00000000fffbfff0 -> 00000000fffc07ff] overlaps section .reset [00000000fffbfff0 -> 00000000fffbffff] /usr/bin/ld: linuxbios: section .data lma 0xfffbfff0 overlaps previous sections Which means that the ldscript calculations is wrong (see attached ldscript.ld). What is the difference between reset16 and reset32? Why does reset32.lds do a calculation? Reset always needs to be at 0xFFFFFFF0. Thanks, Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldscript.ld URL: From chris at stockwith.co.uk Fri Aug 17 20:26:44 2007 From: chris at stockwith.co.uk (Chris Lingard) Date: Fri, 17 Aug 2007 19:26:44 +0100 Subject: [LinuxBIOS] Getting the parts In-Reply-To: <46C47CAF.8080906@assembler.cz> References: <46C2DA55.1020102@senokian.com> <46C2F2B5.2030504@stockwith.co.uk> <46C3117B.9050005@senokian.com> <20070815210701.18965.qmail@stuge.se> <46C47987.3040104@stockwith.co.uk> <46C47CAF.8080906@assembler.cz> Message-ID: <46C5E864.3070408@stockwith.co.uk> Rudolf Marek wrote: >> Thank you for the reply, I believe I need some SST 49LF040 or PM 49FL004 > > I bought some at http://bios-repair.co.uk/bios/eeprom.htm (shipped to Czech Rep > for like 60p iirc;) > > Rudolf > Thank you everybody, all parts have been ordered, and are on the way; and the software built. So I might get the soldering done next week. Chris Lingard From corey.osgood at gmail.com Fri Aug 17 20:32:41 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Fri, 17 Aug 2007 14:32:41 -0400 Subject: [LinuxBIOS] Is my motherboard supported?... In-Reply-To: <279958380708171104t1961c9fck3d5acbf675da0e5@mail.gmail.com> References: <279958380708171104t1961c9fck3d5acbf675da0e5@mail.gmail.com> Message-ID: <46C5E9C9.5060906@gmail.com> Robert Oscilowski wrote: > Hi! > > I need to know if my motherboard is supported. > I'm pretty sure most of its components are at least work-in-progress, > but I'm not sure. > Here is what I know about my system: > > CPU: Intel Pentium II 400Mhz -- I'm thinking about upgrading it soon... This board can only handle a 100MHz FSB, so keep that in mind. If you get a CPU with a 133MHz FSB, it will run at 100MHz, but you effectively get a 25% speed loss because of the north bridge. > Northbridge: Intel 82443BX WIP? Not sure if this ever got wrapped up, but it boots. > Southbridge: Intel 82371EB > Super I/O: SMSC FDC37M707 Not supported, yet. the fdc37m60x is supported though, should be an easy port. > Mainboard: Intel SE440BX-2 > *Flash Chip: Intel... TSOC? It's a pity I can't send pictures; I need > help identifying it! Yes, this is a TSOP flash chip, it should be located behind the top ISA slot, below the CMOS battery. You'll need to have that replaced with a TSOP socket to test linuxbios. -Corey From bari at onelabs.com Fri Aug 17 21:17:16 2007 From: bari at onelabs.com (bari) Date: Fri, 17 Aug 2007 14:17:16 -0500 Subject: [LinuxBIOS] VIA CX700 Support Message-ID: <46C5F43C.1080807@onelabs.com> Has anyone started on VIA CX700 support? http://www.via.com.tw/en/products/chipsets/c-series/cx700/ From stepan at coresystems.de Fri Aug 17 21:23:40 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Fri, 17 Aug 2007 21:23:40 +0200 Subject: [LinuxBIOS] reset16 vs reset32 In-Reply-To: <46C5E69C.80106@amd.com> References: <46C4C94E.8010203@amd.com> <20070816221457.GA5012@coresystems.de> <46C4CEB6.3070608@amd.com> <46C5E69C.80106@amd.com> Message-ID: <20070817192340.GA14779@coresystems.de> * Marc Jones [070817 20:19]: > I am running into a build problem with a ROM that contains normal, > fallback, and failover images. I get the following error. > > /usr/bin/ld: section .data [00000000fffbfff0 -> 00000000fffc07ff] overlaps > section .reset [00000000fffbfff0 -> 00000000fffbffff] > /usr/bin/ld: linuxbios: section .data lma 0xfffbfff0 overlaps previous > sections > Which means that the ldscript calculations is wrong (see attached > ldscript.ld). Those calculations are horrible. It usually just means your ROM_IMAGE_SIZE is too small though. > What is the difference between reset16 and reset32? Why does > reset32.lds do a calculation? Reset always needs to be at 0xFFFFFFF0. reset32 is the code running after the reset vector after switching to pmode. IIRC. I wiped that part from my brain after we got rid of that design flaw in v3. ;-) 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 17 22:28:34 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 17 Aug 2007 22:28:34 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <46C5D1E3.8090904@amd.com> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> <20070817114910.GA11469@aragorn> <46C5D1E3.8090904@amd.com> Message-ID: <46C604F2.6000101@gmx.net> On 17.08.2007 18:50, Marc Jones wrote: > > Robert Millan wrote: >> On Thu, Aug 16, 2007 at 05:32:07PM -0600, Marc Jones wrote: >>> I assume you have a good reason, but why are you changing the it8712f >>> pnp device numbers? I am not positive how this works, but I think >>> changing 2e.0 to 2e.7 means that you are trying to program the it8712f >>> logical device 7 with floppy settings. >>> http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf >> The changes were mostly part of the patch Uwe sent me (for his slightly >> different board). I also changed keyboard (s/2e.5/2e.a/), midi (s/2e.8/2e.b/) >> and game port (s/2e.9/2e.c/) while trying to match with lspnp output: >> >> 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) >> 00:0b PNPb006 MPU401 compatible >> 00:0c PNPb02f Joystick/Game port >> >> Is this correct? > > I guess Uwe would need to answer this. I must not understand it correctly. Exactly what superio model do you have? > Interesting that the SIO serial interrupt works and the the keyboard one > doesn't. I am not sure what that means. Yes, but serial loses continuous runs of characters. That might be a problem on the receiving side, though. Regards, Carl-Daniel From rmh at aybabtu.com Fri Aug 17 22:52:15 2007 From: rmh at aybabtu.com (Robert Millan) Date: Fri, 17 Aug 2007 22:52:15 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <46C604F2.6000101@gmx.net> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> <20070817114910.GA11469@aragorn> <46C5D1E3.8090904@amd.com> <46C604F2.6000101@gmx.net> Message-ID: <20070817205215.GA29350@aragorn> On Fri, Aug 17, 2007 at 10:28:34PM +0200, Carl-Daniel Hailfinger wrote: > On 17.08.2007 18:50, Marc Jones wrote: > > > > Robert Millan wrote: > >> On Thu, Aug 16, 2007 at 05:32:07PM -0600, Marc Jones wrote: > >>> I assume you have a good reason, but why are you changing the it8712f > >>> pnp device numbers? I am not positive how this works, but I think > >>> changing 2e.0 to 2e.7 means that you are trying to program the it8712f > >>> logical device 7 with floppy settings. > >>> http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf > >> The changes were mostly part of the patch Uwe sent me (for his slightly > >> different board). I also changed keyboard (s/2e.5/2e.a/), midi (s/2e.8/2e.b/) > >> and game port (s/2e.9/2e.c/) while trying to match with lspnp output: > >> > >> 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) > >> 00:0b PNPb006 MPU401 compatible > >> 00:0c PNPb02f Joystick/Game port > >> > >> Is this correct? > > > > I guess Uwe would need to answer this. I must not understand it correctly. > > Exactly what superio model do you have? IT8712F-A. Uwe has a different one, I think. Perhaps I should start with the Config.lb pnp setup from pristine svn and adapt that to my pnp layout instead of using his patched version ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 17 23:22:43 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 17 Aug 2007 23:22:43 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <20070817205215.GA29350@aragorn> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> <20070817114910.GA11469@aragorn> <46C5D1E3.8090904@amd.com> <46C604F2.6000101@gmx.net> <20070817205215.GA29350@aragorn> Message-ID: <46C611A3.5020302@gmx.net> On 17.08.2007 22:52, Robert Millan wrote: > On Fri, Aug 17, 2007 at 10:28:34PM +0200, Carl-Daniel Hailfinger wrote: >> On 17.08.2007 18:50, Marc Jones wrote: >>> Robert Millan wrote: >>>> On Thu, Aug 16, 2007 at 05:32:07PM -0600, Marc Jones wrote: >>>>> I assume you have a good reason, but why are you changing the it8712f >>>>> pnp device numbers? I am not positive how this works, but I think >>>>> changing 2e.0 to 2e.7 means that you are trying to program the it8712f >>>>> logical device 7 with floppy settings. >>>>> http://www.tranzistoare.ro/datasheets/1150/495234_DS.pdf >>>> The changes were mostly part of the patch Uwe sent me (for his slightly >>>> different board). I also changed keyboard (s/2e.5/2e.a/), midi (s/2e.8/2e.b/) >>>> and game port (s/2e.9/2e.c/) while trying to match with lspnp output: >>>> >>>> 00:0a PNP0303 IBM enhanced keyboard (101/102-key, PS/2 mouse support) >>>> 00:0b PNPb006 MPU401 compatible >>>> 00:0c PNPb02f Joystick/Game port >>>> >>>> Is this correct? >>> I guess Uwe would need to answer this. I must not understand it correctly. >> Exactly what superio model do you have? > > IT8712F-A. Uwe has a different one, I think. Perhaps I should start with the > Config.lb pnp setup from pristine svn and adapt that to my pnp layout instead > of using his patched version ? Start from a Config.lb which uses exactly the superio you have. If that is not possible, read the datasheet of your superio and modify your Config.lb so that it matches the datasheet. Please be also aware that the IT8712F has a "keyboard controller with 2 kb programmable ROM" which might need special handling. If you have problems downloading the datasheet from ITE (the download may stall) tell me and I'll send it to you privately. Regards, Carl-Daniel From robjoski at gmail.com Sat Aug 18 00:41:53 2007 From: robjoski at gmail.com (Robert Oscilowski) Date: Fri, 17 Aug 2007 18:41:53 -0400 Subject: [LinuxBIOS] Is my motherboard supported?... In-Reply-To: <46C5E9C9.5060906@gmail.com> References: <279958380708171104t1961c9fck3d5acbf675da0e5@mail.gmail.com> <46C5E9C9.5060906@gmail.com> Message-ID: <279958380708171541p6f87791fpf6af3a8083d173a2@mail.gmail.com> Corey, Thanks for the quick reply! Unfortunately, I'm not so quick... So... what is a TSOP socket? > You'll need to have that replaced with a > TSOP socket to test linuxbios. How would I go about doing that? What else has to be done before I can run it? With all due respect, R.J.O aka "robjoski-1" -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawn2be.wild at yahoo.de Sat Aug 18 01:00:55 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Sat, 18 Aug 2007 01:00:55 +0200 Subject: [LinuxBIOS] VIA CX700 Support In-Reply-To: <46C5F43C.1080807@onelabs.com> References: <46C5F43C.1080807@onelabs.com> Message-ID: <46C628A7.9060704@yahoo.de> bari schrieb: > Has anyone started on VIA CX700 support? > http://www.via.com.tw/en/products/chipsets/c-series/cx700/ this is unlikely, unless mentioned in wiki ! this answer applies to various questions concerning particular hardware - but we do not wish to appear rude in any way ! there is a list of supported southbridges, Super I/O chips and flash memory types which are supported. if you have zero hits with your mainboard, probably you are facing a learning curve ;-) ... --Q From c-d.hailfinger.devel.2006 at gmx.net Sat Aug 18 01:24:37 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 18 Aug 2007 01:24:37 +0200 Subject: [LinuxBIOS] VIA CX700 Support In-Reply-To: <46C628A7.9060704@yahoo.de> References: <46C5F43C.1080807@onelabs.com> <46C628A7.9060704@yahoo.de> Message-ID: <46C62E35.3000106@gmx.net> On 18.08.2007 01:00, Quux wrote: > bari schrieb: >> Has anyone started on VIA CX700 support? >> http://www.via.com.tw/en/products/chipsets/c-series/cx700/ > this is unlikely, unless mentioned in wiki ! I think Corey Osgood was working on that. Regards, Carl-Daniel From marekpenther at gmail.com Sat Aug 18 01:43:24 2007 From: marekpenther at gmail.com (Marek Artur Penther) Date: Sat, 18 Aug 2007 01:43:24 +0200 Subject: [LinuxBIOS] One very important device to support Message-ID: <46C6329C.6000708@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Podpis 004.PNG Type: image/png Size: 11090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: marekpenther.vcf Type: text/x-vcard Size: 213 bytes Desc: not available URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Aug 18 04:49:49 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 18 Aug 2007 04:49:49 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C6329C.6000708@gmail.com> References: <46C6329C.6000708@gmail.com> Message-ID: <46C65E4D.6040404@gmx.net> On 18.08.2007 01:43, Marek Artur Penther wrote: > I think there, about support for every clock chip (like l9248). I think this > will help to overclock and/or underclock and/or for (most important) properly > set speed of CPU and FSB and PCI and AGP. If you have any trouble in find > datasheets about clock chips I know few web sites where anyone can download > datasheets for free. Do you offer to write some code? Back in 2005, we had some code to over-/underclock hypertransport links. That code has been dropped, though. Even if some new code for overclocking will be written, there is still the question whether we want such code in LinuxBIOS. Usually people blame the stuff which gives them the ability to shoot themselves in the foot. I don't want people blaming LinuxBIOS because it allowed them to overclock their machines until the hardware failed. Regards, Carl-Daniel From darmawan.salihun at gmail.com Sat Aug 18 04:55:02 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Sat, 18 Aug 2007 09:55:02 +0700 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65E4D.6040404@gmx.net> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> Message-ID: <46C65F86.1080201@gmail.com> Carl-Daniel Hailfinger wrote: > On 18.08.2007 01:43, Marek Artur Penther wrote: >> I think there, about support for every clock chip (like l9248). I think this >> will help to overclock and/or underclock and/or for (most important) properly >> set speed of CPU and FSB and PCI and AGP. If you have any trouble in find >> datasheets about clock chips I know few web sites where anyone can download >> datasheets for free. > > Do you offer to write some code? Back in 2005, we had some code to > over-/underclock hypertransport links. That code has been dropped, though. > > Even if some new code for overclocking will be written, there is still > the question whether we want such code in LinuxBIOS. Usually people > blame the stuff which gives them the ability to shoot themselves in the > foot. I don't want people blaming LinuxBIOS because it allowed them to > overclock their machines until the hardware failed. Yeah, agree with that ;-). It shouldn't be given to the unknowns. But, what about an "overclocking/underclocking branch" for LinuxBIOS? I mean maybe someone interested to maintain such a branch of LinuxBIOS? Only, a naive idea though ;-). Regards, Darmawan From c-d.hailfinger.devel.2006 at gmx.net Sat Aug 18 05:36:20 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 18 Aug 2007 05:36:20 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65F86.1080201@gmail.com> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> Message-ID: <46C66934.2040408@gmx.net> On 18.08.2007 04:55, Darmawan Salihun wrote: > Carl-Daniel Hailfinger wrote: >> On 18.08.2007 01:43, Marek Artur Penther wrote: >>> I think there, about support for every clock chip (like l9248). I think this >>> will help to overclock and/or underclock and/or for (most important) properly >>> set speed of CPU and FSB and PCI and AGP. If you have any trouble in find >>> datasheets about clock chips I know few web sites where anyone can download >>> datasheets for free. >> Do you offer to write some code? Back in 2005, we had some code to >> over-/underclock hypertransport links. That code has been dropped, though. >> >> Even if some new code for overclocking will be written, there is still >> the question whether we want such code in LinuxBIOS. Usually people >> blame the stuff which gives them the ability to shoot themselves in the >> foot. I don't want people blaming LinuxBIOS because it allowed them to >> overclock their machines until the hardware failed. > Yeah, agree with that ;-). It shouldn't be given to the unknowns. > > But, what about an "overclocking/underclocking branch" for LinuxBIOS? > I mean maybe someone interested to maintain such a branch of LinuxBIOS? > Only, a naive idea though ;-). Please call the branch/fork UnreliableBIOS :-P Regards, Carl-Daniel From corey.osgood at gmail.com Sat Aug 18 06:57:31 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 18 Aug 2007 00:57:31 -0400 Subject: [LinuxBIOS] VIA CX700 Support In-Reply-To: <46C62E35.3000106@gmx.net> References: <46C5F43C.1080807@onelabs.com> <46C628A7.9060704@yahoo.de> <46C62E35.3000106@gmx.net> Message-ID: <46C67C3B.60207@gmail.com> Carl-Daniel Hailfinger wrote: > On 18.08.2007 01:00, Quux wrote: > >> bari schrieb: >> >>> Has anyone started on VIA CX700 support? >>> http://www.via.com.tw/en/products/chipsets/c-series/cx700/ >>> >> this is unlikely, unless mentioned in wiki ! >> > > I think Corey Osgood was working on that. > > Regards, > Carl-Daniel No. I'm working on CN700, CX700 is essentially (but not exactly!!!) the CN700 + VT8237 in one chip. I have some info on the CX700, but no board to work on, hence I can't make it work. If someone were to give me a board, that might be different ;) Afaik, one of the biggest differences is that it includes a different video device than the CN700, but I can't confirm that. There's also some differences in the north-south bridge linkup, etc. -Corey From corey.osgood at gmail.com Sat Aug 18 07:14:54 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 18 Aug 2007 01:14:54 -0400 Subject: [LinuxBIOS] Is my motherboard supported?... In-Reply-To: <279958380708171541p6f87791fpf6af3a8083d173a2@mail.gmail.com> References: <279958380708171104t1961c9fck3d5acbf675da0e5@mail.gmail.com> <46C5E9C9.5060906@gmail.com> <279958380708171541p6f87791fpf6af3a8083d173a2@mail.gmail.com> Message-ID: <46C6804E.50404@gmail.com> Robert Oscilowski wrote: > > Corey, > > Thanks for the quick reply! > Unfortunately, I'm not so quick... > So... what is a TSOP socket? > > > You'll need to have that replaced with a > > TSOP socket to test linuxbios. > > How would I go about doing that? > What else has to be done before I can run it? > > With all due respect, > > R.J.O aka "robjoski-1" I think it was either Carl-Daniel or Peter that linked to this recently: http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/index.html IIRC, that flash chip is 48 pin. The onboard flash chip would have to be desodiered and replaced with a socket like this one. You'd also have to purchase at least one, if not more, additional flash chips to flash linuxbios on to. This way, if anything goes wrong, you have the factory bios to fall back onto. Personally, I'd recommend getting a different motherboard over a socket. You can probably pick up another 440bx based board with a socketed PLCC or DIP bios off ebay for around the same price as this socket (~$20). PLCC and DIP bios chips can be purchase from distributors like mouser.com and avnet.com in the US. You'll find mention of BIOS Savior RD1s in the wiki, but these are no longer manufactured and are growing nearly impossible to find, I know frozencpu.com still has a few. Or you can go for a pentium 3 based board and continue work on the i810 port I've started (complete except vga and fully dynamic sdram detection), or grab one of the already-support motherboards listed in the Supported Motherboards page of the wiki. Just my 2 cents. -Corey From joe at smittys.pointclark.net Sat Aug 18 08:02:26 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 18 Aug 2007 02:02:26 -0400 Subject: [LinuxBIOS] row_offset Message-ID: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> Corey, I am a little confused about the significance of the row_offset in the i82810 raminit.c. 1. What do you mean by row? Each row of DRAM technologies (Side) or each row of DIMM (Socket)?? Two different things. /* Set the row offset, in KBytes (should this be * Kbits?). Note that this offset is the start of the * next row. */ row_offset = (dimm_size * 4 * 1024); 2. If this the start of the next row should it be row_offset +1 Kilobyte?? 3. Lastly, is row_offset from function spd_set_dram_size supposed show up in sdram_enable?? Wouldn?t we need a: return row_offset; At the end of spd_set_dram_size?? For me it just shows as 0? Thanks - Joe From corey.osgood at gmail.com Sat Aug 18 10:03:59 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 18 Aug 2007 04:03:59 -0400 Subject: [LinuxBIOS] row_offset In-Reply-To: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> References: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> Message-ID: <46C6A7EF.8030602@gmail.com> Joseph Smith wrote: > Corey, > I am a little confused about the significance of the row_offset in the > i82810 raminit.c. > > 1. What do you mean by row? Each row of DRAM technologies (Side) or > each row of DIMM (Socket)?? Two different things. > > /* Set the row offset, in KBytes (should this be > * Kbits?). Note that this offset is the start of the > * next row. > */ > row_offset = (dimm_size * 4 * 1024); I'm not entirely sure. I think I asked on the mailing list at one point, but never really got a definite answer. I honestly never got around to testing dual sided function at all, I couldn't find any known-good sticks around here, just one very flaky one. > 2. If this the start of the next row should it be row_offset +1 > Kilobyte?? Perhaps I'm a bit too tired, but I don't think so. IIRC, if you have 64mb of ram, ie 65536k, the last address is at 65535 because addressing starts at 0. The next address, at 65536, would be address 0 of the next row. But I could easily be wrong. And I think that if you screw up the addressing, you also screw up the mode register set, so gotta get it right ;) > > 3. Lastly, is row_offset from function spd_set_dram_size supposed show > up in sdram_enable?? Wouldn?t we need a: > > return row_offset; > > At the end of spd_set_dram_size?? I don't think so, but again I could be wrong. row_offset is declared in sdram_enable then passed along to spd_set_dram_size, which should then be able to modify it. This is one of those "lack of coding experience" situations, where I simply don't know. I really should have checked it, but the cn700 docs were dumped in my lap and it was time to get back to that. I suppose the easiest way to check if this is working correctly or not would be to set row_offset to some arbitrary number at the end of spd_set_dram_size, then dump it to the console after exiting, ie in sdram_enable. > For me it just shows as 0? > > > Thanks - Joe > Not exactly sure what you mean. Are you dumping it inside spd_set_dram_size or after? -Corey From popkonserve at gmx.de Sat Aug 18 11:13:23 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 18 Aug 2007 11:13:23 +0200 Subject: [LinuxBIOS] row_offset In-Reply-To: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> References: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> Message-ID: <46C6B833.6010105@gmx.de> > Corey, > I am a little confused about the significance of the row_offset in the > i82810 raminit.c. > > 1. What do you mean by row? Each row of DRAM technologies (Side) or > each row of DIMM (Socket)?? Two different things. "GMCH supports 4 physical rows of system memory in 2 DIMMs. The width of a row is 64 bits. The DRAM Row Population Register defines the population of each Side of each DIMM." - from Intel? 82810/82810-DC100 (GMCH) a row in the intel datasheets is always one side of a memory module. one side means: there are single-sided dimms and double sided dimms. you have to configure each side of the memory module in order to make it work correctly. please take a look at my previous post: "Intel DRB HOWTO .. a 1st draft.". i tried to explain how those registers work..on the Intel 430FX. they work the same on every other (intel) chipset, too. > /* Set the row offset, in KBytes (should this be > * Kbits?). Note that this offset is the start of the > * next row. > */ > row_offset = (dimm_size * 4 * 1024); > > 2. If this the start of the next row should it be row_offset +1 Kilobyte?? As Corey already stated: a memory region starts at 0 and ends at regionsize-1. the next memory region starts at regionsize then. example: 1MB = 1*1024*1024 = 1048576 (decimal) = 100000h. the 1MB region would start at 0 and end at 100000h-1 = 0FFFFFh. take a look at the intel datasheet mentioned above, there is a memory map at page 72. just if someone was wondering: i can provide a sniplet of code that calculates the start address of the current region from the contents of the Intel row offset register for the previous row. btw. converting between kilobytes and kilobits is just a simple left shift by 3 digits. i'll restart working on more memory init functions in mid september. my implementation will work without reading any spd data and detect the size of a memory module just by reading/writing data. when i'm done with the socket 7 chipsets, i'll continue with the slot1/s370 ones..hope it won't take too long. From stepan at coresystems.de Sat Aug 18 11:21:22 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 18 Aug 2007 11:21:22 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65E4D.6040404@gmx.net> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> Message-ID: <20070818092122.GA16698@coresystems.de> * Carl-Daniel Hailfinger [070818 04:49]: > Even if some new code for overclocking will be written, there is still > the question whether we want such code in LinuxBIOS. Usually people > blame the stuff which gives them the ability to shoot themselves in the > foot. I don't want people blaming LinuxBIOS because it allowed them to > overclock their machines until the hardware failed. One thing I am concerned is that adding all the hooks for overclocking snafus the algorithms we implemented to do things in a "optimal but not overclocking" way. If people come up with patches that allow overclocking without making the code hard to understand and follow, I would vote for it to go into the tree. The value of overclocking is very questionable in times where hardware is so fast and cheap and has so little scope left for gains. This was way different back when you could overclock a 68000 from 8 to 28 MHz and just add passive cooling. Or wire your 68882 from 25 to 50MHz. Nowadays you sit for quite some hours before you get a half ways stable setup which gives you a speed gain of 10%. If some master overclocker can prove me wrong, please do :-) 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 stepan at coresystems.de Sat Aug 18 11:22:41 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 18 Aug 2007 11:22:41 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65F86.1080201@gmail.com> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> Message-ID: <20070818092240.GB16698@coresystems.de> * Darmawan Salihun [070818 04:55]: > But, what about an "overclocking/underclocking branch" for LinuxBIOS? > I mean maybe someone interested to maintain such a branch of LinuxBIOS? > Only, a naive idea though ;-). I think that is a nice idea. Any takers? -- 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 peter at stuge.se Sat Aug 18 11:42:36 2007 From: peter at stuge.se (Peter Stuge) Date: Sat, 18 Aug 2007 11:42:36 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65F86.1080201@gmail.com> <20070818092122.GA16698@coresystems.de> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> Message-ID: <20070818094236.18698.qmail@stuge.se> On Sat, Aug 18, 2007 at 11:21:22AM +0200, Stefan Reinauer wrote: > The value of overclocking is very questionable It has huge educational value, which is why I think it's important that LB can do it. ..or maybe not.. On Sat, Aug 18, 2007 at 09:55:02AM +0700, Darmawan Salihun wrote: > Yeah, agree with that ;-). It shouldn't be given to the unknowns. I disagree. Let user shoot self in foot. Maybe politely warn though. > But, what about an "overclocking/underclocking branch" for > LinuxBIOS? My idea is that these tweaks are contained in a separate piece of software. Maybe lbmenu. There's a certain point in letting LB stay LB and just do a very safe, always known-working setup. Then add fancy schmancy on top of that. This is also important because we may like to have fallback use different performance profiles. Easily done with tweaks in a payload. //Peter From marekpenther at gmail.com Sat Aug 18 11:57:12 2007 From: marekpenther at gmail.com (Marek Artur Penther) Date: Sat, 18 Aug 2007 11:57:12 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <20070818092122.GA16698@coresystems.de> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> Message-ID: <46C6C278.2070106@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Podpis 004.PNG Type: image/png Size: 11090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: marekpenther.vcf Type: text/x-vcard Size: 223 bytes Desc: not available URL: From popkonserve at gmx.de Sat Aug 18 12:19:14 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 18 Aug 2007 12:19:14 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <20070818094236.18698.qmail@stuge.se> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> Message-ID: <46C6C7A2.3090901@gmx.de> is setting memory timings considered overclocking, too? for all memory modules before sdram the user should be able to alter those settings because those modules do not have spd. the clock chips sit on top of the smbus and it should be simple to program them to whatever the user thinks he needs (and the chip supports). there are so many options that may (positivly) influence performance on chipsets in general. i don't see the point why LB should hide them. to be honest that is why i started developing for LB in the first place. there are so many ugly bios implementations for older boards that make chipset and mainboard unusably slow (have a look at pcchips boards). i will include performance options in all my drivers. if they are not user adjustable i would have to enforce them. i don't think that telling the user to read the source code and uncomment some performance options is a real solution. who wants/can to read the source code anyway? i agree that all those options should be in an 'expert' menu and a warning should be shown on entering it, but that's all. every single option should be there. i think that we as the programmers should know best but the user should still be able to know better. since we have the datasheets and the programming skills to adjust (almost) anything on the supported chipsets we should share it. this is not a risk, it is a feature! if anyone really needs links to performance gains beyond the 10% mark i'll post some on the mailing list. From stepan at coresystems.de Sat Aug 18 12:15:57 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 18 Aug 2007 12:15:57 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <20070818094236.18698.qmail@stuge.se> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> Message-ID: <20070818101556.GA29339@coresystems.de> * Peter Stuge [070818 11:42]: > > But, what about an "overclocking/underclocking branch" for > > LinuxBIOS? > > My idea is that these tweaks are contained in a separate piece of > software. Maybe lbmenu. There's a certain point in letting LB stay LB > and just do a very safe, always known-working setup. Then add fancy > schmancy on top of that. The main code needs to support the fact that it's values are overwritten at some point. For example, HT speed only gets active when you do a reset (or LDTSTOP). Imagine lbmenu overclocks the HT bus and does a reset. LinuxBIOS will see the reset and see that it would run he HT bus with different values. It'll change the values and.... do a reset. > This is also important because we may like to have fallback use > different performance profiles. Easily done with tweaks in a payload. This means lbmenu would get another task: Setting the HW up according to its settings. This requires a lot of HW knowledge per board within lbmenu. I like the idea of capsulating this functionality. I am not sure whether lbmenu is the right place for the magic. (definitely for the visualization!) 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 stepan at coresystems.de Sat Aug 18 12:52:05 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Sat, 18 Aug 2007 12:52:05 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C6C7A2.3090901@gmx.de> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> <46C6C7A2.3090901@gmx.de> Message-ID: <20070818105205.GA30614@coresystems.de> * popkonserve [070818 12:19]: > user adjustable i would have to enforce them. i don't think that telling > the user to read the source code and uncomment some performance options > is a real solution. who wants/can to read the source code anyway? Basically those people who understand what those options are for. I doubt anyone who knows that is unable to read a config file. The question is: Why would you set your system up in a non-optimal way in the first place. If a setting is possible, stable and performance-improving, lets always set it. If not, it is no good? > since we have the datasheets and the programming skills to adjust > (almost) anything on the supported chipsets we should share it. this is > not a risk, it is a feature! if anyone really needs links to performance > gains beyond the 10% mark i'll post some on the mailing list. I do agree here. Please do post those links, if possible. 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 popkonserve at gmx.de Sat Aug 18 14:29:27 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 18 Aug 2007 14:29:27 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <20070818105205.GA30614@coresystems.de> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> <46C6C7A2.3090901@gmx.de> <20070818105205.GA30614@coresystems.de> Message-ID: <46C6E627.8070805@gmx.de> >>user adjustable i would have to enforce them. i don't think that telling >>the user to read the source code and uncomment some performance options >>is a real solution. who wants/can to read the source code anyway? > > Basically those people who understand what those options are for. I > doubt anyone who knows that is unable to read a config file. people knowing chipset options are not necessarily programmers. a menu like the current bios implementations offer would be nice to have. > The question is: Why would you set your system up in a non-optimal way > in the first place. because there are chipset options that shouldn't be set according to the manufacturer but they do have in fact an impact on performance. the best example are ALi chipsets: if you leave everything unconfigured the chipset will be dead slow. if you set everything to optimal performance some (pci) devices could run into problems. the user should have at least the options to flip some bits if something isn't working correctly. > If a setting is possible, stable and performance-improving, lets always > set it. If not, it is no good? agree! i wish the chipset manufacturers would have written those information in their chipset documentation. that would make things so much easier. i guess the main reason why they made those options adjustable is the fact that there is so much different hardware out there that cling to different (more or less officical) specifications. that makes it almost impossible to find the optimal setting for every possible combination. > I do agree here. Please do post those links, if possible. celeron 600 at 1008 (by cranking up the fsb from 66 to 112MHz): http://www.thetechzone.com/reviews/cpu/oc_warehouse1000/page3.shtml ram interleaving on VIA chipsets: http://www.georgebreese.com/net/software/readmes/venabler_v015_readme.htm http://www.overclockers.com/tips105/index03.asp register tweaking the Intel BX chipset: http://www.overclockers.com/tips607/index03.asp register tweaking a PcChips mainboard with SIS chipset: http://m571.com/m571/tweek.htm power saving (not performance, but still useful): http://members.jcom.home.ne.jp/jacobi/linux/softwares.html#athcool enable UDMA on a PcChips mainboard: http://www.rainbow-software.org/hardware/m726tune.html and there are so many more..i didn't find anything on PCI performance benchmarks but some tweaks modify pci performance registers, too. i should definately do some tests on a pcchips board regarding pci performance.. Holger From joe at smittys.pointclark.net Sat Aug 18 18:04:58 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 18 Aug 2007 12:04:58 -0400 Subject: [LinuxBIOS] row_offset In-Reply-To: <46C6B833.6010105@gmx.de> References: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> <46C6B833.6010105@gmx.de> Message-ID: <20070818120458.8ygiolkrvkg0w8c0@www.smittys.pointclark.net> Quoting popkonserve : >> I am a little confused about the significance of the row_offset in >> the i82810 raminit.c. >> > > please take a look at my previous post: "Intel DRB > HOWTO .. a 1st draft.". i tried to explain how those registers work..on > the Intel 430FX. they work the same on every other (intel) chipset, too. > Don't worry Holger, I understand perfectly how the DRB registers work on the i828** chipsets I am just a little confused on how the whole row_offset thing plays into it. I am already able to setup ALL FOUR DRB registers with out it. So, I am questioning if I really need to use it at all. I noticed the i440bx does not use it..... Thanks - Joe From andi.mundt at web.de Sat Aug 18 18:25:06 2007 From: andi.mundt at web.de (Andreas B. Mundt) Date: Sat, 18 Aug 2007 18:25:06 +0200 Subject: [LinuxBIOS] GA-M57SLI-S4 and ACPI Message-ID: <20070818162506.GA5513@flashgordon> Hello everybody, it has been pointed out on the list, that an implementation of ACPI for the GA-M57SLI-S4 needs to be done in a "cleanroom" to avoid legal issues. Is it possible to move the ACPI functionality from the BIOS to the linux kernel? By extracting the DSDT from the vendor BIOS and preparing a kernel with: CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/linux-source-2.6.21/dsdt.hex" the user could run linuxbios but the vendor's DSDT as a workaround for the time being. What modifications are necessary in linuxbios to allow for this? Or do the same legal issues aply? Thanks, Andi From joe at smittys.pointclark.net Sat Aug 18 18:37:26 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 18 Aug 2007 12:37:26 -0400 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <46C53607.9080003@gmail.com> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> Message-ID: <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> Quoting Corey Osgood : > Joseph Smith wrote: >> Anyone know if there is a function to write to the smbus similar to >> the smbus_read_byte function? Execpt write not read of course, like >> smbus_write_byte? >> >> Thanks - Joe >> >> > > For i82801xx, it's already implemented, just totally untested. I have no > idea who wrote it, and I make no claim of it actually working (although > it very well could). Have a look at i82801xx_smbus.h, that's where all > the smbus functions really live, you're looking for do_smbus_write_byte. > It's commented out atm, my own decision since I was unsure of it with no > real way to test. > > -Corey > > Hmm, Looks like in i82801xx_early_smbus.c (which is what I need for auto.c) there is smbus_write_byte, and smbus_write_block. The function is defined in i82801xx_smbus.h. I really need to get this going. Because my onboard memory has no SPD I need to write to smbus 0x51 to trick the system into thinking there is SPD there. Any suggestions on what is wrong with it?? Thanks - Joe From popkonserve at gmx.de Sat Aug 18 18:43:31 2007 From: popkonserve at gmx.de (popkonserve) Date: Sat, 18 Aug 2007 18:43:31 +0200 Subject: [LinuxBIOS] row_offset In-Reply-To: <20070818120458.8ygiolkrvkg0w8c0@www.smittys.pointclark.net> References: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> <46C6B833.6010105@gmx.de> <20070818120458.8ygiolkrvkg0w8c0@www.smittys.pointclark.net> Message-ID: <46C721B3.7090908@gmx.de> Hi Joseph, if you get the size of the modules from the SPD you can ignore all offset addressing stuff as long as you don't need to write anything to a specific module row. SPD is a nice thing as it tells you everything you need to set up the northbridge memory controller :) if you would want to write to a special module row you could use code like this to calculate the starting address: 1. assume the DRB stores the size of the memory module row in 4MB granularity. 2. calculate starting address: if (previous_DRB == 0) {starting_address = 0;} else {starting_address = (1<<22)<<(previous_DRB - 1);} 4MB ^^^^^ ^^^^^^^^^^^^^^ no. of additional 4MB portions the last address of the previous memory row would btw. be: last_address_of_prev_row = starting_address - 1; i didn't take a look at the code for the i82810 yet, so i'm unaware why and how the row_offset is used. Holger From yinghailu at gmail.com Sat Aug 18 20:47:04 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 18 Aug 2007 11:47:04 -0700 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> Message-ID: <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> just provide one fake spd array... YH From yinghailu at gmail.com Sat Aug 18 20:48:07 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 18 Aug 2007 11:48:07 -0700 Subject: [LinuxBIOS] GA-M57SLI-S4 and ACPI In-Reply-To: <20070818162506.GA5513@flashgordon> References: <20070818162506.GA5513@flashgordon> Message-ID: <2ea3fae10708181148p736501acub865c38cffdfca8e@mail.gmail.com> On 8/18/07, Andreas B. Mundt wrote: > Hello everybody, > > it has been pointed out on the list, that an implementation of ACPI for the > GA-M57SLI-S4 needs to be done in a "cleanroom" to avoid legal issues. > > Is it possible to move the ACPI functionality from the BIOS to the linux > kernel? By extracting the DSDT from the vendor BIOS and preparing a kernel > with: > > CONFIG_ACPI_CUSTOM_DSDT=y > CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/linux-source-2.6.21/dsdt.hex" > > the user could run linuxbios but the vendor's DSDT as a workaround for the > time being. > > What modifications are necessary in linuxbios to allow for this? you may still need to update dsdt.dsl, because some io range is different.... YH From corey.osgood at gmail.com Sat Aug 18 20:53:55 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Sat, 18 Aug 2007 14:53:55 -0400 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> Message-ID: <46C74043.2010108@gmail.com> yhlu wrote: > just provide one fake spd array... > > YH My thoughts exactly. You can't write to the smbus because there's no device on the smbus at that location to receive those writes. -Corey From pawn2be.wild at yahoo.de Sat Aug 18 21:21:10 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Sat, 18 Aug 2007 21:21:10 +0200 Subject: [LinuxBIOS] PS2 keyboard not working on ASUS A8N5X ( K8/CK804/IT8712F) In-Reply-To: <46C611A3.5020302@gmx.net> References: <20070816225320.GA8464@aragorn> <46C4DE77.5090303@amd.com> <20070817114910.GA11469@aragorn> <46C5D1E3.8090904@amd.com> <46C604F2.6000101@gmx.net> <20070817205215.GA29350@aragorn> <46C611A3.5020302@gmx.net> Message-ID: <46C746A6.30706@yahoo.de> Carl-Daniel Hailfinger schrieb: > If you have problems downloading the datasheet from ITE (the download > may stall) tell me and I'll send it to you privately. the ITE datasheet looks quite informative. Is it all you get / need to do the job ? my ebay seller of the A8N-E keeps me waiting for a week now, though I got all other components handy ! I hope to boot LB any day now ! --Q From joe at smittys.pointclark.net Sat Aug 18 23:46:56 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Sat, 18 Aug 2007 17:46:56 -0400 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <46C74043.2010108@gmail.com> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> <46C74043.2010108@gmail.com> Message-ID: <20070818174656.npc45tm0owwc4w0c@www.smittys.pointclark.net> Quoting Corey Osgood : > yhlu wrote: >> just provide one fake spd array... >> >> YH > > My thoughts exactly. You can't write to the smbus because there's no > device on the smbus at that location to receive those writes. > > -Corey > > How would I provide a fake spd array? Here is the situation. My board has the onboard memory without a SPD, I could just hardcode this into the northbridge raminit.c. But I don't want to do that so people that may want to use the northbridge src for other boards won't have to deal with it. So right now I have auto.c call a function that runs in between sdram_set_spd_registers and sdram_enable, like this: sdram_set_spd_registers(memctrl); onboard_sdram_set_registers(memctrl); sdram_enable(0, memctrl); This function, onboard_sdram_set_registers manually sets up the regsters. Anyways I would also like to get the smbus_write_byte write going to setup my tv-out registers on my tv-out chip? Thanks - Joe From segher at kernel.crashing.org Sun Aug 19 01:00:33 2007 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sun, 19 Aug 2007 01:00:33 +0200 Subject: [LinuxBIOS] row_offset In-Reply-To: <46C6B833.6010105@gmx.de> References: <20070818020226.9rwppviqq04sos88@www.smittys.pointclark.net> <46C6B833.6010105@gmx.de> Message-ID: <29c0fd503921c0e583cb7c754d0f4116@kernel.crashing.org> >> I am a little confused about the significance of the row_offset in the >> i82810 raminit.c. >> >> 1. What do you mean by row? Each row of DRAM technologies (Side) or >> each row of DIMM (Socket)?? Two different things. > > "GMCH supports 4 physical rows of system memory in 2 DIMMs. The width > of > a row is 64 bits. The DRAM Row Population Register defines the > population of each Side of each DIMM." - from Intel? 82810/82810-DC100 > (GMCH) > > a row in the intel datasheets is always one side of a memory module. More common (and way less confusing) terms for "physical row" are "rank" and "chip select" (the latter isn't fully technically correct of course, a rank is what a chip select connects to -- but people use the term anyway and it is obvious what they mean). Maybe this clears up things a bit -- if the opposite, please ignore :-) Segher From svn at openbios.org Sun Aug 19 01:31:09 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 19 Aug 2007 01:31:09 +0200 Subject: [LinuxBIOS] r467 - in LinuxBIOSv3: arch/x86/geodelx mainboard/adl/msm800sev mainboard/artecgroup/dbe61 mainboard/emulation/qemu-x86 northbridge/amd/geodelx Message-ID: Author: stepan Date: 2007-08-19 01:31:09 +0200 (Sun, 19 Aug 2007) New Revision: 467 Modified: LinuxBIOSv3/arch/x86/geodelx/geodelx.c LinuxBIOSv3/mainboard/adl/msm800sev/initram.c LinuxBIOSv3/mainboard/adl/msm800sev/stage1.c LinuxBIOSv3/mainboard/artecgroup/dbe61/stage1.c LinuxBIOSv3/mainboard/emulation/qemu-x86/stage1.c LinuxBIOSv3/northbridge/amd/geodelx/geodelx.c LinuxBIOSv3/northbridge/amd/geodelx/geodelxinit.c Log: small trivial patch to fix return types, printk warnings Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/geodelx/geodelx.c =================================================================== --- LinuxBIOSv3/arch/x86/geodelx/geodelx.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/arch/x86/geodelx/geodelx.c 2007-08-18 23:31:09 UTC (rev 467) @@ -152,9 +152,8 @@ msr_glcp_sys_pll = rdmsr(GLCP_SYS_RSTPLL); - printk(BIOS_DEBUG, - "_MSR GLCP_SYS_RSTPLL (%08x) value is: %08x:%08x\n", - msr_glcp_sys_pll.hi, msr_glcp_sys_pll.lo); + printk(BIOS_DEBUG, "_MSR GLCP_SYS_RSTPLL (%08x) value is: %08x:%08x\n", + GLCP_SYS_RSTPLL, msr_glcp_sys_pll.hi, msr_glcp_sys_pll.lo); post_code(POST_PLL_INIT); if (!(msr_glcp_sys_pll.lo & (1 << RSTPLL_LOWER_SWFLAGS_SHIFT))) { Modified: LinuxBIOSv3/mainboard/adl/msm800sev/initram.c =================================================================== --- LinuxBIOSv3/mainboard/adl/msm800sev/initram.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/mainboard/adl/msm800sev/initram.c 2007-08-18 23:31:09 UTC (rev 467) @@ -59,4 +59,6 @@ printk(BIOS_SPEW, "Before wbinvd\n"); __asm__("wbinvd\n"); printk(BIOS_SPEW, "After wbinvd\n"); + + return 0; } Modified: LinuxBIOSv3/mainboard/adl/msm800sev/stage1.c =================================================================== --- LinuxBIOSv3/mainboard/adl/msm800sev/stage1.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/mainboard/adl/msm800sev/stage1.c 2007-08-18 23:31:09 UTC (rev 467) @@ -35,7 +35,7 @@ #define SERIAL_DEV 0x30 -int hardware_stage1(void) +void hardware_stage1(void) { void w83627hf_enable_serial(u8 dev, u8 serial, u16 iobase); post_code(POST_START_OF_MAIN); Modified: LinuxBIOSv3/mainboard/artecgroup/dbe61/stage1.c =================================================================== --- LinuxBIOSv3/mainboard/artecgroup/dbe61/stage1.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/mainboard/artecgroup/dbe61/stage1.c 2007-08-18 23:31:09 UTC (rev 467) @@ -48,7 +48,7 @@ wrmsr(dbe61_msr[i].reg, dbe61_msr[i].msr); } -int hardware_stage1(void) +void hardware_stage1(void) { post_code(POST_START_OF_MAIN); Modified: LinuxBIOSv3/mainboard/emulation/qemu-x86/stage1.c =================================================================== --- LinuxBIOSv3/mainboard/emulation/qemu-x86/stage1.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/mainboard/emulation/qemu-x86/stage1.c 2007-08-18 23:31:09 UTC (rev 467) @@ -18,11 +18,13 @@ */ /* no printk allowed until hardware is ready; hardware is ready */ + /** * start up hardware needed for stage1 */ void hardware_stage1(void) { + /* Nothing to do for Qemu */ } void disable_car(void) { Modified: LinuxBIOSv3/northbridge/amd/geodelx/geodelx.c =================================================================== --- LinuxBIOSv3/northbridge/amd/geodelx/geodelx.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/northbridge/amd/geodelx/geodelx.c 2007-08-18 23:31:09 UTC (rev 467) @@ -248,9 +248,7 @@ for (link = 0; link < dev->links; link++) { bus = &dev->link[link]; if (bus->children) { - printk(BIOS_DEBUG, - "my_dev_set_resources: phase4_assign_resources %d\n", - bus); + printk(BIOS_DEBUG, "my_dev_set_resources: phase4_assign_resources %p\n", bus); phase4_assign_resources(bus); } } Modified: LinuxBIOSv3/northbridge/amd/geodelx/geodelxinit.c =================================================================== --- LinuxBIOSv3/northbridge/amd/geodelx/geodelxinit.c 2007-08-11 18:38:24 UTC (rev 466) +++ LinuxBIOSv3/northbridge/amd/geodelx/geodelxinit.c 2007-08-18 23:31:09 UTC (rev 467) @@ -123,7 +123,7 @@ msr.lo = gl->lo; msr.hi = gl->hi; wrmsr(gl->desc_name, msr); - printk(BIOS_SPEW, "%s: MSR 0x%08x, val 0x%08x:0x%08x\n", + printk(BIOS_SPEW, "%s: MSR 0x%08lx, val 0x%08x:0x%08x\n", __FUNCTION__, gl->desc_name, msr.hi, msr.lo); } @@ -175,7 +175,7 @@ msr.lo = sizebytes; wrmsr(gl->desc_name, msr); - printk(BIOS_DEBUG, "%s: MSR 0x%08x, val 0x%08x:0x%08x\n", __FUNCTION__, + printk(BIOS_DEBUG, "%s: MSR 0x%08lx, val 0x%08x:0x%08x\n", __FUNCTION__, gl->desc_name, msr.hi, msr.lo); } @@ -206,7 +206,7 @@ msr.lo |= ((~(SMM_SIZE * 1024) + 1) >> 12) & 0xfffff; wrmsr(gl->desc_name, msr); - printk(BIOS_DEBUG, "%s: MSR 0x%08x, val 0x%08x:0x%08x\n", __FUNCTION__, + printk(BIOS_DEBUG, "%s: MSR 0x%08lx, val 0x%08x:0x%08x\n", __FUNCTION__, gl->desc_name, msr.hi, msr.lo); } @@ -228,7 +228,7 @@ msr.lo |= ((~(SMM_SIZE * 1024) + 1) >> 12) & 0xfffff; wrmsr(gl->desc_name, msr); - printk(BIOS_DEBUG, "%s: MSR 0x%08x, val 0x%08x:0x%08x\n", __FUNCTION__, + printk(BIOS_DEBUG, "%s: MSR 0x%08lx, val 0x%08x:0x%08x\n", __FUNCTION__, gl->desc_name, msr.hi, msr.lo); } From marekpenther at gmail.com Sun Aug 19 02:43:15 2007 From: marekpenther at gmail.com (Marek Artur Penther) Date: Sun, 19 Aug 2007 02:43:15 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C65E4D.6040404@gmx.net> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> Message-ID: <46C79223.3070008@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Podpis 004.PNG Type: image/png Size: 11090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: marekpenther.vcf Type: text/x-vcard Size: 213 bytes Desc: not available URL: From yinghailu at gmail.com Sun Aug 19 02:45:31 2007 From: yinghailu at gmail.com (yhlu) Date: Sat, 18 Aug 2007 17:45:31 -0700 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <20070818174656.npc45tm0owwc4w0c@www.smittys.pointclark.net> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> <46C74043.2010108@gmail.com> <20070818174656.npc45tm0owwc4w0c@www.smittys.pointclark.net> Message-ID: <2ea3fae10708181745t4c3f3d12h3b17381bb95e0f76@mail.gmail.com> On 8/18/07, Joseph Smith wrote: > How would I provide a fake spd array? Here is the situation. My board > has the onboard memory without a SPD, I could just hardcode this into > the northbridge raminit.c. But I don't want to do that so people that > may want to use the northbridge src for other boards won't have to > deal with it. So right now I have auto.c call a function that runs in > between sdram_set_spd_registers and sdram_enable, like this: > > sdram_set_spd_registers(memctrl); > onboard_sdram_set_registers(memctrl); > sdram_enable(0, memctrl); > > This function, onboard_sdram_set_registers manually sets up the regsters. > > Anyways I would also like to get the smbus_write_byte write going to > setup my tv-out registers on my tv-out chip? rename these function to different name _*. and add functions that will handle SPD address with handling the array. and other address still call _*. YH From peter at stuge.se Sun Aug 19 05:24:09 2007 From: peter at stuge.se (Peter Stuge) Date: Sun, 19 Aug 2007 05:24:09 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <46C6E627.8070805@gmx.de> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> <46C6C7A2.3090901@gmx.de> <20070818105205.GA30614@coresystems.de> <46C6E627.8070805@gmx.de> Message-ID: <20070819032409.26974.qmail@stuge.se> On Sat, Aug 18, 2007 at 02:29:27PM +0200, popkonserve wrote: > a menu like the current bios implementations offer would be nice > to have. I disagree. I want something much better. Me and Uwe share this idea about a (tree?) view of the complete system, where the user is free to change every single adjustable setting. Yes, it needs some work. //Peter From popkonserve at gmx.de Sun Aug 19 09:56:39 2007 From: popkonserve at gmx.de (popkonserve) Date: Sun, 19 Aug 2007 09:56:39 +0200 Subject: [LinuxBIOS] One very important device to support In-Reply-To: <20070819032409.26974.qmail@stuge.se> References: <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <46C65F86.1080201@gmail.com> <46C6329C.6000708@gmail.com> <46C65E4D.6040404@gmx.net> <20070818092122.GA16698@coresystems.de> <20070818094236.18698.qmail@stuge.se> <46C6C7A2.3090901@gmx.de> <20070818105205.GA30614@coresystems.de> <46C6E627.8070805@gmx.de> <20070819032409.26974.qmail@stuge.se> Message-ID: <46C7F7B7.70309@gmx.de> Peter Stuge wrote: > I disagree. I want something much better. Me and Uwe share this idea > about a (tree?) view of the complete system, where the user is free > to change every single adjustable setting. That's the kind of menu i thought of :) but changing every adjustable setting could mean overclocking or should we say running the hardware out of specs (which specs exactly?). anyway i think this is the way to go. full control for the user. From svn at openbios.org Sun Aug 19 19:21:20 2007 From: svn at openbios.org (svn at openbios.org) Date: Sun, 19 Aug 2007 19:21:20 +0200 Subject: [LinuxBIOS] r468 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-19 19:21:20 +0200 (Sun, 19 Aug 2007) New Revision: 468 Modified: LinuxBIOSv3/util/lar/Makefile LinuxBIOSv3/util/lar/lar.h Log: Add a top level target to the LAR makefile so it can be built by itself in the LBv3 tree. Also remove any reference to the build system so that LAr can be constructed in an un-configured tree. Signed-off-by: Jordan Crouse Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/Makefile =================================================================== --- LinuxBIOSv3/util/lar/Makefile 2007-08-18 23:31:09 UTC (rev 467) +++ LinuxBIOSv3/util/lar/Makefile 2007-08-19 17:21:20 UTC (rev 468) @@ -47,6 +47,8 @@ $(Q)$(HOSTCC) $(HOSTCFLAGS) -c $< -o $@ +lar: $(obj)/util/lar/lar + # ----------------------------------------------------------------------------- # Stuff below this line is for debugging purposes only. Modified: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h 2007-08-18 23:31:09 UTC (rev 467) +++ LinuxBIOSv3/util/lar/lar.h 2007-08-19 17:21:20 UTC (rev 468) @@ -49,7 +49,6 @@ */ #include -#include "../../build/config.h" #define MAGIC "LARCHIVE" #define MAX_PATHLEN 1024 From uwe at hermann-uwe.de Sun Aug 19 20:14:55 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Sun, 19 Aug 2007 20:14:55 +0200 Subject: [LinuxBIOS] [PATCH][v3] Support for multiple LinuxBIOS payloads Message-ID: <20070819181455.GA19802@greenwood> Hi, here's a first (draft) implementation for having multiple LinuxBIOS payloads in one image, which will be executed one after the other. This is part of my G?oC project work; it's needed for lbmenu, the LinuxBIOS runtime config tool. More details in the patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: v3_multiple_payloads.patch Type: text/x-diff Size: 6939 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From augusto.pedroza at gmail.com Sun Aug 19 20:42:14 2007 From: augusto.pedroza at gmail.com (Augusto Pedroza) Date: Sun, 19 Aug 2007 15:42:14 -0300 Subject: [LinuxBIOS] LinuxBIOS - Booting Windows XP Message-ID: I have created two diff's, the first one is for linuxBIOSv2 (xpboot.diff) the second is for LinuxBIOSv3, it adds ADLO to v3. details: http://www.linuxbios.org/Booting_Windows_using_LinuxBIOS Feel free to test it and give some feedback!! We hope Vista comes soon. Regards, -- Augusto Pedroza -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: xpboot.diff Type: application/octet-stream Size: 1545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ADLO_xp_v3.diff Type: application/octet-stream Size: 351632 bytes Desc: not available URL: From svn at openbios.org Mon Aug 20 00:58:42 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 00:58:42 +0200 Subject: [LinuxBIOS] r469 - in LinuxBIOSv3/util: lar nrv2b Message-ID: Author: stepan Date: 2007-08-20 00:58:42 +0200 (Mon, 20 Aug 2007) New Revision: 469 Modified: LinuxBIOSv3/util/lar/Makefile LinuxBIOSv3/util/lar/lar.h LinuxBIOSv3/util/nrv2b/nrv2b.c Log: Always compile in all compression algorithms. This is required for building in an unconfigured tree and to continue with Jordans patches. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/Makefile =================================================================== --- LinuxBIOSv3/util/lar/Makefile 2007-08-19 17:21:20 UTC (rev 468) +++ LinuxBIOSv3/util/lar/Makefile 2007-08-19 22:58:42 UTC (rev 469) @@ -1,7 +1,7 @@ ## ## lar - LinuxBIOS archiver ## -## Copyright (C) 2006 coresystems GmbH +## Copyright (C) 2006-2007 coresystems GmbH ## (Written by Stefan Reinauer for coresystems GmbH) ## ## This program is free software; you can redistribute it and/or modify @@ -22,15 +22,11 @@ LARDIR := lardir -ifeq ($(CONFIG_COMPRESSION_LZMA),y) COMPRESSOR := $(LZMA_OBJ) $(obj)/util/lzma/lzma-compress.o LARDIR += lzmadir -endif -ifeq ($(CONFIG_COMPRESSION_NRV2B),y) COMPRESSOR += $(obj)/util/nrv2b/nrv2b-compress.o LARDIR += nrv2bdir -endif LAROBJ_ABS := $(patsubst %,$(obj)/util/lar/%,$(LAROBJ)) Modified: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h 2007-08-19 17:21:20 UTC (rev 468) +++ LinuxBIOSv3/util/lar/lar.h 2007-08-19 22:58:42 UTC (rev 469) @@ -78,29 +78,13 @@ void compress_impossible(char *in, u32 in_len, char *out, u32 *out_len); void do_no_compress(char *in, u32 in_len, char *out, u32 *out_len); -#ifdef CONFIG_COMPRESSION_LZMA void do_lzma_compress(char *in, u32 in_len, char *out, u32 *out_len); -#else -#define do_lzma_compress compress_impossible -#endif -#ifdef CONFIG_COMPRESSION_NRV2B void do_nrv2b_compress(char *in, u32 in_len, char *out, u32 *out_len); -#else -#define do_nrv2b_compress compress_impossible -#endif void uncompress_impossible(char *, char *, u32); void do_no_uncompress(char *, char *, u32); -#ifdef CONFIG_COMPRESSION_LZMA void do_lzma_uncompress(char *, char *, u32); -#else -#define do_lzma_uncompress uncompress_impossible -#endif -#ifdef CONFIG_COMPRESSION_NRV2B void do_nrv2b_uncompress(char *, char *, u32); -#else -#define do_nrv2b_uncompress uncompress_impossible -#endif static compress_func compress_functions[] = { do_no_compress, Modified: LinuxBIOSv3/util/nrv2b/nrv2b.c =================================================================== --- LinuxBIOSv3/util/nrv2b/nrv2b.c 2007-08-19 17:21:20 UTC (rev 468) +++ LinuxBIOSv3/util/nrv2b/nrv2b.c 2007-08-19 22:58:42 UTC (rev 469) @@ -1304,7 +1304,7 @@ #endif #ifdef COMPACT -void do_nrv2b_compress(char* in, unsigned long in_len, char* out, unsigned long* out_len) { +void do_nrv2b_compress(uint8_t *in, unsigned long in_len, uint8_t *out, unsigned long *out_len) { *out_len = in_len + (in_len/8) + 256; out = malloc(*out_len); ucl_nrv2b_99_compress(in, in_len, out, out_len, 0 ); @@ -1346,7 +1346,7 @@ #endif #ifdef COMPACT -void do_nrv2b_uncompress(char* dst, char* src, unsigned long len) { +void do_nrv2b_uncompress(uint8_t *dst, uint8_t *src, unsigned long len) { unsigned long ilen = 0, olen = 0, last_m_off = 1; uint32_t bb = 0; unsigned bc = 0; From svn at openbios.org Mon Aug 20 01:31:58 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 01:31:58 +0200 Subject: [LinuxBIOS] r470 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 01:31:58 +0200 (Mon, 20 Aug 2007) New Revision: 470 Removed: LinuxBIOSv3/util/lar/create.c LinuxBIOSv3/util/lar/extract.c LinuxBIOSv3/util/lar/list.c Modified: LinuxBIOSv3/util/lar/Makefile LinuxBIOSv3/util/lar/lar.c LinuxBIOSv3/util/lar/lar.h LinuxBIOSv3/util/lar/lib.c LinuxBIOSv3/util/lar/lib.h Log: In preparation for adding new LAR functionality - this patch consolidates creating and accessing the LAR into new code utilizing mmap which facilitates moving about within the archive. This code also turns the bootblock path name as a constant value. It also requires that the user specify a size when the LAR is created. This patch was missing do_no_uncompress() which was fixed before commit. This part should be reviewed. Signed-off-by: Jordan crouse Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/Makefile =================================================================== --- LinuxBIOSv3/util/lar/Makefile 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/Makefile 2007-08-19 23:31:58 UTC (rev 470) @@ -18,7 +18,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA ## -LAROBJ := lar.o create.o extract.o list.o lib.o bootblock.o +LAROBJ := lar.o stream.o lib.o LARDIR := lardir Deleted: LinuxBIOSv3/util/lar/create.c =================================================================== --- LinuxBIOSv3/util/lar/create.c 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/create.c 2007-08-19 23:31:58 UTC (rev 470) @@ -1,278 +0,0 @@ -/* - * lar - LinuxBIOS archiver - * - * Copyright (C) 2006-2007 coresystems GmbH - * (Written by Stefan Reinauer for coresystems GmbH) - * Copyright (C) 2007 Patrick Georgi - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "lib.h" -#include "lar.h" - -extern enum compalgo algo; - -void compress_impossible(char *in, u32 in_len, char *out, u32 *out_len) -{ - fprintf(stderr, - "The selected compression algorithm wasn't compiled in.\n"); - exit(1); -} - -void do_no_compress(char *in, u32 in_len, char *out, u32 *out_len) -{ - memcpy(out, in, in_len); - out_len[0] = in_len; -} - -int create_lar(const char *archivename, struct file *files) -{ - int i, ret; - int diff = 0; - int bb_header_len = 0; - FILE *archive, *source; - char *tempmem; - char *filebuf, *filetarget; - char *pathname; - u32 *walk; - u32 csum; - int pathlen, entrylen, filelen; - u32 compfilelen; - long currentsize = 0; - struct lar_header *header; - struct stat statbuf; - enum compalgo thisalgo; - - if (!files) { - fprintf(stderr, "No files for archive %s\n", archivename); - exit(1); - } - - if (verbose()) - printf("Opening %s\n", archivename); - - archive = fopen(archivename, "w"); - if (!archive) { - fprintf(stderr, "Could not open archive %s for writing\n", - archivename); - exit(1); - } - - while (files) { - char *name = files->name; - - thisalgo = algo; - - if (strstr(name, "nocompress:") == name) { - name += 11; - thisalgo = none; - } - - /* skip ./ if available */ - if (name[0] == '.' && name[1] == '/') - name += 2; - - if (verbose()) - printf(" Adding %s to archive\n", name); - - ret = stat(name, &statbuf); - if (ret) { - fprintf(stderr, "No such file %s\n", name); - exit(1); - } - filelen = statbuf.st_size; - - tempmem = malloc(sizeof(struct lar_header) + MAX_PATHLEN - + filelen + 16); - if (!tempmem) { - fprintf(stderr, "Out of memory.\n"); - return (1); - } - memset(tempmem, 0, sizeof(struct lar_header) + MAX_PATHLEN - + filelen + 16); - - header = (struct lar_header *)tempmem; - pathname = tempmem + sizeof(struct lar_header); - pathlen = snprintf(pathname, MAX_PATHLEN - 1, name) + 1; - pathlen = (pathlen + 15) & 0xfffffff0; /* Align to 16 bytes. */ - - /* Read file into memory. */ - filebuf = malloc(filelen); - filetarget = pathname + pathlen; - source = fopen(name, "r"); - if (!source) { - fprintf(stderr, "No such file %s\n", name); - exit(1); - } - fread(filebuf, filelen, 1, source); - fclose(source); - compress_functions[thisalgo](filebuf, filelen, filetarget, - &compfilelen); - if ((compfilelen >= filelen) && (thisalgo != none)) { - thisalgo = none; - compress_functions[thisalgo](filebuf, filelen, - filetarget, &compfilelen); - } - free(filebuf); - - /* Create correct header. */ - memcpy(header, MAGIC, 8); - header->compression = htonl(thisalgo); - header->reallen = htonl(filelen); - header->len = htonl(compfilelen); - header->offset = htonl(sizeof(struct lar_header) + pathlen); - - /* Calculate checksum. */ - csum = 0; - for (walk = (u32 *) tempmem; - walk < (u32 *) (tempmem + compfilelen + - sizeof(struct lar_header) + pathlen); - walk++) { - csum += ntohl(*walk); - } - header->checksum = htonl(csum); - - /* Write out entry to archive. */ - entrylen = (compfilelen + pathlen + sizeof(struct lar_header) + - 15) & 0xfffffff0; - - fwrite(tempmem, entrylen, 1, archive); - - free(tempmem); - - /* size counter */ - currentsize += entrylen; - - files = files->next; - } - - /* Calculate difference, if a size has been specified. - * If diff is below zero, the size has been exceeded. - * If diff is above zero, it specifies the number of - * padding bytes required for the image. - * Otherwise diff stays 0 and no action is taken below. - */ - if (get_larsize()) - diff = get_larsize() - currentsize; - - /* If there's a bootblock loaded, some space is required - * _after_ the padding. - * Calculate this size here, but write the bootblock later. - */ - - if (bootblock_len) { - if (verbose()) - printf("Detected bootblock of %d bytes\n", - bootblock_len); - - bb_header_len = sizeof(struct lar_header) + - ((strlen(basename(get_bootblock())) + 15) & 0xfffffff0); - - bb_header_len = (bb_header_len + 15) & 0xfffffff0; - - if (verbose()) - printf("Required bootblock header of %d bytes\n", - bb_header_len); - - diff -= bootblock_len; - diff -= bb_header_len; - } - - /* The image became too big. Print an error message and exit, - * deleting the file. So nobody used an invalid image by accident. - * - * Don't delete the image in "Out of memory" situations. If memory - * is _that_ tight that a few bytes don't fit anymore, everything - * else will fail as well, so just print an error and exit the - * program as soon as possible. - */ - - if (diff < 0) { - fprintf(stderr, - "Error: LAR archive exceeded size (%ld > %ld)\n", - currentsize, get_larsize()); - - /* Open files can not be deleted. */ - fclose(archive); - /* File is too big, delete it. */ - unlink(archivename); - return -1; - } - - /* Pad the image. */ - - if (diff > 0) { - char *padding; - /* generate padding (0xff is flash friendly) */ - padding = malloc(diff); - if (!padding) { - fprintf(stderr, "Out of memory.\n"); - exit(1); - } - memset(padding, 0xff, diff); - fwrite(padding, diff, 1, archive); - free(padding); - } - - if (bootblock_len) { - char *bootblock_header; - struct lar_header *bb; - - bootblock_header = malloc(bb_header_len); - if (!bootblock_header) { - fprintf(stderr, "Out of memory.\n"); - exit(1); - } - - memset(bootblock_header, 0, bb_header_len); - - /* construct header */ - bb = (struct lar_header *)bootblock_header; - memcpy(bb->magic, MAGIC, 8); - bb->reallen = htonl(bootblock_len); - bb->len = htonl(bootblock_len); - bb->offset = htonl(bb_header_len); - - /* TODO checksum */ - - /* Write filename. we calculated the buffer size, - * so no overflow danger here. - */ - strcpy(bootblock_header + sizeof(struct lar_header), - basename(get_bootblock())); - - fwrite(bootblock_header, bb_header_len, 1, archive); - fwrite(bootblock_code, bootblock_len, 1, archive); - } - - fclose(archive); - - if (verbose()) - printf("done.\n"); - - return 0; -} Deleted: LinuxBIOSv3/util/lar/extract.c =================================================================== --- LinuxBIOSv3/util/lar/extract.c 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/extract.c 2007-08-19 23:31:58 UTC (rev 470) @@ -1,155 +0,0 @@ -/* - * lar - LinuxBIOS archiver - * - * Copyright (C) 2006-2007 coresystems GmbH - * (Written by Stefan Reinauer for coresystems GmbH) - * Copyright (C) 2007 Patrick Georgi - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "lib.h" -#include "lar.h" - -void uncompress_impossible(char *dst, char *src, u32 len) -{ - fprintf(stderr, - "Cannot uncompress data (algorithm not compiled in).\n"); - exit(1); -} - -void do_no_uncompress(char *dst, char *src, u32 len) -{ - memcpy(dst, src, len); -} - -int extract_lar(const char *archivename, struct file *files) -{ - int archivefile; - char *inmap; - char *walk; - char *fullname, *pathname, *pos; - struct lar_header *header; - struct stat statbuf; - int archivelen; - int do_extract; - int i; - - if (stat(archivename, &statbuf) != 0) { - printf("Error opening %s: %s\n", archivename, strerror(errno)); - exit(1); - } - - if (verbose()) - printf("Opening %s\n", archivename); - - archivefile = open(archivename, O_RDONLY); - if (archivefile == -1) { - printf("Error while opening %s: %s\n", - archivename, strerror(errno)); - exit(1); - } - archivelen = statbuf.st_size; - - inmap = mmap(NULL, statbuf.st_size, PROT_READ, - MAP_SHARED, archivefile, 0); - - for (walk = inmap; walk < inmap + statbuf.st_size; walk += 16) { - FILE *file_to_extract; - - if (strcmp(walk, MAGIC) != 0) - continue; - - header = (struct lar_header *)walk; - fullname = walk + sizeof(struct lar_header); - - /* FIXME: check checksum. */ - - do_extract = 1; - if (files) { - struct file *fwalk = files; - do_extract = 0; - while (fwalk) { - if (strcmp(fullname, fwalk->name) == 0) { - do_extract = 1; - break; - } - fwalk = fwalk->next; - } - } - - /* Don't extract this one, skip it. */ - if (!do_extract) - continue; - - if (verbose()) - printf(" Extracting file %s\n", - walk + sizeof(struct lar_header)); - - /* Create the directory if it does not exist. */ - pathname = strdup(fullname); - if (!pathname) { - fprintf(stderr, "Out of memory.\n"); - exit(1); - } - - pos = strrchr(pathname, '/'); - if (pos) { - pos[1] = 0; - /* printf("Pathname %s\n",pathname); */ - mkdirp_below(".", pathname, 0755); - } - free(pathname); - - file_to_extract = fopen(fullname, "w"); - if (!file_to_extract) { - fprintf(stderr, "error creating file %s.\n", fullname); - exit(1); - } - - if (ntohl(header->compression) == none) { - fwrite(walk + ntohl(header->offset), - ntohl(header->len), 1, file_to_extract); - } else { - char *buf = malloc(ntohl(header->reallen)); - uncompress_functions[ntohl(header->compression)](buf, - walk + ntohl(header->offset), ntohl(header->len)); - fwrite(buf, ntohl(header->reallen), 1, file_to_extract); - free(buf); - } - fclose(file_to_extract); - - walk += (ntohl(header->offset) + ntohl(header->len) - - 1) & 0xfffffff0; - } - - munmap(inmap, statbuf.st_size); - close(archivefile); - - if (verbose()) - printf("done.\n"); - - return 0; -} Modified: LinuxBIOSv3/util/lar/lar.c =================================================================== --- LinuxBIOSv3/util/lar/lar.c 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/lar.c 2007-08-19 23:31:58 UTC (rev 470) @@ -62,6 +62,64 @@ return bootblock; } +int create_lar(const char *archivename, struct file *files) +{ + struct lar *lar = lar_new_archive(archivename, larsize); + + if (lar == NULL) { + fprintf(stderr, "Unable to create %s as a LAR archive.\n", + archivename); + exit(1); + } + + for( ; files; files = files->next) { + if (lar_add_file(lar, files->name)) { + fprintf(stderr, "Error adding %s to the LAR.\n", files->name); + lar_close_archive(lar); + exit(1); + } + } + + if (lar_add_bootblock(lar, bootblock)) { + fprintf(stderr, "Error adding the bootblock to the LAR.\n"); + lar_close_archive(lar); + exit(1); + } + + lar_close_archive(lar); + return 0; +} + +int list_lar(const char *archivename, struct file *files) +{ + struct lar *lar = lar_open_archive(archivename); + + if (lar == NULL) { + fprintf(stderr, "Unable to open LAR archive %s\n", archivename); + exit(1); + } + + lar_list_files(lar, files); + lar_close_archive(lar); + return 0; +} + +int extract_lar(const char *archivename, struct file *files) +{ + int ret; + + struct lar *lar = lar_open_archive(archivename); + + if (lar == NULL) { + fprintf(stderr, "Unable to open LAR archive %s\n", archivename); + exit(1); + } + + ret = lar_extract_files(lar, files); + lar_close_archive(lar); + return ret; +} + int main(int argc, char *argv[]) { int opt; @@ -173,16 +231,9 @@ /* adding a bootblock only makes sense when creating a lar */ if (!larsize) { - printf("Warning: When specifying a bootblock " - "you should also set an archive size.\n"); + printf("When creating a LAR archive, you must specify an archive size.\n"); + exit(1); } - - /* load the bootblock */ - if (larmode == CREATE) { - load_bootblock(bootblock); - fixup_bootblock(); - } - } if (optind < argc) { Modified: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/lar.h 2007-08-19 23:31:58 UTC (rev 470) @@ -54,7 +54,11 @@ #define MAX_PATHLEN 1024 #define BOOTBLOCK_SIZE 16384 +#define BOOTBLOCK_NAME "bootblock" +#define BOOTBLOCK_NAME_LEN 16 + typedef uint32_t u32; +typedef uint8_t u8; struct lar_header { char magic[8]; @@ -71,6 +75,16 @@ u32 compression; }; +/**\struct + * A structure containing information about a currently open and mapped + * LAR archive + */ +struct lar { + int fd; /**< The file descriptor of the open archive */ + u8 *map; /**< A pointer to the mmap()ed file */ + u32 size; /**< Size of the mmaped file */ +}; + enum compalgo { none = 0, lzma = 1, nrv2b = 2 }; typedef void (*compress_func) (char *, u32, char *, u32 *); Modified: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3/util/lar/lib.c 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/lib.c 2007-08-19 23:31:58 UTC (rev 470) @@ -29,6 +29,7 @@ #include #include +#include "lar.h" #include "lib.h" #define MAX_PATH 1024 @@ -36,6 +37,46 @@ static struct file *files = NULL; /** + * The default "compress impossible" hook to call when no other compression + * is used + */ +void compress_impossible(char *in, u32 in_len, char *out, u32 *out_len) +{ + fprintf(stderr, + "The selected compression algorithm wasn't compiled in.\n"); + exit(1); +} + +/** + * The default "compress" hook to call when no other compression is used + */ +void do_no_compress(char *in, u32 in_len, char *out, u32 *out_len) +{ + memcpy(out, in, in_len); + out_len[0] = in_len; +} + +/** + * The default "uncompress" hook to call when no other compression is used + */ + +void do_no_uncompress(char *dst, char *src, u32 len) +{ + memcpy(dst, src, len); +} + +/** + * The default "uncompress" hook to call when no other compression is used + */ +void uncompress_impossible(char *dst, char *src, u32 len) +{ + fprintf(stderr, + "Cannot uncompress data (algorithm not compiled in).\n"); + exit(1); +} + + +/** * Create a new directory including any missing parent directories. * * NOTE: This function does not do complete path resolution as described in @@ -114,6 +155,12 @@ return ret; } + +int mkdirp(const char *dirpath, mode_t mode) +{ + return mkdirp_below(".", dirpath, mode); +} + static int handle_directory(const char *name) { int n; Modified: LinuxBIOSv3/util/lar/lib.h =================================================================== --- LinuxBIOSv3/util/lar/lib.h 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/lib.h 2007-08-19 23:31:58 UTC (rev 470) @@ -49,6 +49,16 @@ struct file *get_files(void); void free_files(void); +/* Prototypes for the LAR I/O functions */ +struct lar * lar_new_archive(const char *archive, unsigned int size); +struct lar * lar_open_archive(const char *archive); +void lar_close_archive(struct lar *lar); + +void lar_list_files(struct lar *lar, struct file *files); +int lar_add_file(struct lar *lar, const char *name); +int lar_add_bootblock(struct lar *lar, const char *bootblock); +int lar_extract_files(struct lar *lar, struct file *files); + /* prototypes for extract.c functions */ int extract_lar(const char *archivename, struct file *files); Deleted: LinuxBIOSv3/util/lar/list.c =================================================================== --- LinuxBIOSv3/util/lar/list.c 2007-08-19 22:58:42 UTC (rev 469) +++ LinuxBIOSv3/util/lar/list.c 2007-08-19 23:31:58 UTC (rev 470) @@ -1,121 +0,0 @@ -/* - * lar - LinuxBIOS archiver - * - * Copyright (C) 2006-2007 coresystems GmbH - * (Written by Stefan Reinauer for coresystems GmbH) - * Copyright (C) 2007 Patrick Georgi - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "lib.h" -#include "lar.h" - -int list_lar(const char *archivename, struct file *files) -{ - int archivefile; - char *inmap; - char *walk; - char *fullname; - struct lar_header *header; - struct stat statbuf; - int archivelen; - int do_extract; - int i; - - if (stat(archivename, &statbuf) != 0) { - fprintf(stderr, "Error opening %s: %s\n", - archivename, strerror(errno)); - exit(1); - } - - if (verbose()) - printf("Opening %s\n", archivename); - - archivefile = open(archivename, O_RDONLY); - if (archivefile == -1) { - printf("Error while opening %s: %s\n", - archivename, strerror(errno)); - exit(1); - } - archivelen = statbuf.st_size; - - inmap = mmap(NULL, statbuf.st_size, PROT_READ, - MAP_SHARED, archivefile, 0); - - for (walk = inmap; walk < inmap + statbuf.st_size; walk += 16) { - if (strcmp(walk, MAGIC) != 0) - continue; - - header = (struct lar_header *)walk; - fullname = walk + sizeof(struct lar_header); - - do_extract = 1; - if (files) { - struct file *fwalk = files; - do_extract = 0; - while (fwalk) { - if (strcmp(fullname, fwalk->name) == 0) { - do_extract = 1; - break; - } - fwalk = fwalk->next; - } - } - - /* Don't extract this one, skip it. */ - if (!do_extract) { - continue; - } - - printf(" %s ", walk + sizeof(struct lar_header)); - - if (ntohl(header->compression) == none) { - printf("(%d bytes @0x%lx)\n", - ntohl(header->len), - (unsigned long)(walk - inmap) + - ntohl(header->offset)); - } else { - printf("(%d bytes, %s compressed to %d bytes " - "@0x%lx)\n", - ntohl(header->reallen), - algo_name[ntohl(header->compression)], - ntohl(header->len), - (unsigned long)(walk - inmap) + - ntohl(header->offset)); - } - - walk += (ntohl(header->len) + ntohl(header->offset) - - 1) & 0xfffffff0; - } - - munmap(inmap, statbuf.st_size); - close(archivefile); - - if (verbose()) - printf("done.\n"); - - return 0; -} From svn at openbios.org Mon Aug 20 01:33:41 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 01:33:41 +0200 Subject: [LinuxBIOS] r471 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 01:33:41 +0200 (Mon, 20 Aug 2007) New Revision: 471 Modified: LinuxBIOSv3/util/lar/lib.c Log: Add another field to the filename specified for create and add operations to specify the intended pathname for the blob. Signed-off-by: Jordan Crouse Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3/util/lar/lib.c 2007-08-19 23:31:58 UTC (rev 470) +++ LinuxBIOSv3/util/lar/lib.c 2007-08-19 23:33:41 UTC (rev 471) @@ -210,16 +210,29 @@ { struct stat filestat; int ret = -1; - const char *realname; + char *realname; + char *c; - realname = name; if (strstr(name, "nocompress:") == name) { - realname = name + 11; + name += 11; } + realname = strdup(name); + + if (realname == NULL) { + fprintf(stderr, "Out of memory.\n"); + exit(1); + } + + c = strchr(realname, ':'); + + if (c != NULL) + *c = '\0'; + /* printf("... add_files %s\n", name); */ if (stat(realname, &filestat) == -1) { fprintf(stderr, "Error getting file attributes of %s\n", name); + free(realname); return -1; } @@ -264,6 +277,7 @@ ret = 0; } + free(realname); return ret; } From svn at openbios.org Mon Aug 20 01:37:34 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 01:37:34 +0200 Subject: [LinuxBIOS] r472 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 01:37:34 +0200 (Mon, 20 Aug 2007) New Revision: 472 Added: LinuxBIOSv3/util/lar/stream.c Log: missing svn add for r470. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Added: LinuxBIOSv3/util/lar/stream.c =================================================================== --- LinuxBIOSv3/util/lar/stream.c (rev 0) +++ LinuxBIOSv3/util/lar/stream.c 2007-08-19 23:37:34 UTC (rev 472) @@ -0,0 +1,677 @@ +/* + * lar - LinuxBIOS archiver + * + * This includes code from previous versions of the LAR utility, + * including create.c, list.c, extract.c and bootblock.c + * + * Copyright (C) 2006-2007 coresystems GmbH + * (Written by Stefan Reinauer for coresystems GmbH) + * Copyright (C) 2007 Patrick Georgi + * Copyright (C) 2007 Advanced Micro Devices, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "lib.h" +#include "lar.h" + +/** + * \def err(fmt,args...) + * Abstract outputing error strings to avoid repetition + */ +#define err(fmt,args...) fprintf(stderr, fmt, ##args) + +extern enum compalgo algo; + +/** + * Given a size, return the offset of the bootblock (including the + * header) + * @param size Size of the LAR archive + * @return The offset of the bootblock header + */ +static inline u32 get_bootblock_offset(u32 size) +{ + return size - (BOOTBLOCK_SIZE + sizeof(struct lar_header) + + BOOTBLOCK_NAME_LEN); +} + +/** + * Return the expected offset of the next LAR header after the given one + * @param header The current LAR header + * @return The offset of the next possible LAR header + */ +static inline u32 get_next_offset(struct lar_header *header) { + return ((ntohl(header->len) + ntohl(header->offset) - 1) & 0xFFFFFFF0) + + 16; +} + +/** + * Read the size of the LAR archive from the size embedded in the bootblock + * @param lar The LAR archive to read from + * @return The size as read from the bootblock header + */ +static int lar_read_size(struct lar *lar) +{ + u32 *ptr = (u32 *) (lar->map + (lar->size - 12)); + return ptr[0]; +} + +/** + * Add the LAR archive size to the bootblock, and clean up some other params + * in what we're loosely calling the "bootblockh header" + * @param ptr Pointer to the start of the bootblock + * @param size The size value to write to the bootblock header + */ +static void annotate_bootblock(u8 *ptr, u32 size) +{ + int i; + u32 *p; + + memset(ptr + (BOOTBLOCK_SIZE - 13), 0, 13); + p = (u32 *) (ptr + BOOTBLOCK_SIZE - 12); + p[0] = size; +} + +/** + * Add a bootblock file to the LAR - the bootblock must be of a consistant + * size, and always gets put in a special location in the LAR + * @param lar The LAR archive to write to + * @param bootblock The name of the bootblock file to insert + * @return 0 on success, or -1 on failure + */ +int lar_add_bootblock(struct lar *lar, const char *bootblock) +{ + u8 *offset; + struct lar_header *header; + int ret; + + offset = lar->map + get_bootblock_offset(lar->size); + header = (struct lar_header *) offset; + + memcpy(header->magic, MAGIC, 8); + header->reallen = htonl(BOOTBLOCK_SIZE); + header->len = htonl(BOOTBLOCK_SIZE); + header->offset = htonl(sizeof(struct lar_header) + BOOTBLOCK_NAME_LEN); + + offset += sizeof(struct lar_header); + strcpy((char *) offset, BOOTBLOCK_NAME); + + offset += BOOTBLOCK_NAME_LEN; + + /* If a file waas specified, then load it, and read it directly + * into place */ + + if (bootblock != NULL) { + struct stat s; + int fd = open(bootblock, O_RDONLY); + + if (fd == -1) { + err("Unable to read bootblock file %s\n", bootblock); + return -1; + } + + ret = fstat(fd, &s); + + if (ret == -1) { + err("Unable to stat %s\n", bootblock); + close(fd); + return -1; + } + + if (s.st_size != BOOTBLOCK_SIZE) { + err("Bootblock %s does not appear to be a bootblock.\n", + bootblock); + close(fd); + return -1; + } + + ret = read(fd, offset, BOOTBLOCK_SIZE); + close(fd); + + if (ret != BOOTBLOCK_SIZE) { + err("Unable to read all the bytes in the bootblock file.\n"); + return -1; + } + } + + annotate_bootblock(offset, lar->size); + return 0; +} + +/** + * mmap() the LAR archive + * @param lar The LAR archive information to map + * @param u32 size Size of the mapped region + * @return 0 on success, or -1 on failure + */ +static int _map_lar(struct lar *lar, u32 size) +{ + if (lar == NULL) + return -1; + + lar->map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, + lar->fd, 0); + + lar->size = size; + + if (lar->map == MAP_FAILED) + return -1; + + return 0; +} + +/** + * Close the LAR archive and free all structures + * @param lar The LAR archive to close + */ +void lar_close_archive(struct lar *lar) +{ + if (lar == NULL) + return; + + if (lar->map != MAP_FAILED) + munmap(lar->map, lar->size); + + if (lar->fd >= 0) + close(lar->fd); + + free(lar); +} + +/** + * Create a new LAR archive - the archive must not exist on disk. + * @param archive The filename of the new archive + * @param size The intended size of the new archive + * @return A LAR archive structure for the new archive + */ +struct lar * lar_new_archive(const char *archive, u32 size) +{ + struct lar *lar; + int i; + + if (!access(archive, F_OK)) { + err("Archive file %s already exists\n", archive); + return NULL; + } + + lar = calloc(sizeof(*lar), 1); + + if (lar == NULL) { + err("Unable to allocate memory.\n"); + return NULL; + } + + lar->fd = open(archive, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); + + if (lar->fd == -1) { + err("Couldn't open the archive %s\n", archive); + + free(lar); + return NULL; + } + + /* Expand the file to the correct size */ + + if (lseek(lar->fd, size - 1, SEEK_SET) == -1) { + err("Unable to write the archive %s\n", archive); + goto err; + } + + if (write(lar->fd, "", 1) != 1) { + err("Unable to write the file %s\n", archive); + goto err; + } + + if (_map_lar(lar, size)) { + err("Unable to map the archive %s\n", archive); + goto err; + } + + /* Fill the whole thing with flash friendly 0xFFs */ + memset(lar->map, 0xFF, lar->size); + + /* Make a dummy bootblock */ + + if (lar_add_bootblock(lar, NULL)) { + err("Couldn't add a bootblock to %s\n", archive); + goto err; + } + + return lar; + err: + lar_close_archive(lar); + + /* Don't leave a halfbaked LAR laying around */ + + unlink(archive); + return NULL; +} + +/** + * Open an existing LAR archive + * @param The archive filename to open + * @return A LAR archive structure for the opened archive + */ +struct lar * lar_open_archive(const char *archive) +{ + struct lar *lar; + int ret; + u32 romlen; + struct stat s; + + lar = calloc(sizeof(*lar), 1); + + if (lar == NULL) { + err("Unable to allocate memory.\n"); + return NULL; + } + + lar->fd = open(archive, O_RDWR); + + ret = fstat(lar->fd, &s); + + if (ret == -1) { + err("Unable to stat %s\n", archive); + goto err; + } + + if (_map_lar(lar, s.st_size)) { + err("Unable to map the archive %s\n", archive); + goto err; + } + + /* Sanity check - make sure the bootblock header is the same length + * as the LAR archive + */ + + romlen = lar_read_size(lar); + + if (romlen != s.st_size) { + err("Size mismatch - the header says %d but the file is %d bytes long.\n", + romlen, (int) s.st_size); + goto err; + } + + return lar; + + err: + lar_close_archive(lar); + return NULL; +} + +/** + * Return the offset of the first chunk of empty space in the LAR + * @param lar the LAR archive structure + * @return The offset of the first chunk of empty space + */ +static int lar_empty_offset(struct lar *lar) +{ + u32 offset = 0; + struct lar_header *header; + + while (offset < get_bootblock_offset(lar->size)) { + header = (struct lar_header *) (lar->map + offset); + + /* We interpet the absence of the magic as empty space */ + + if (memcmp(header->magic, MAGIC, 8)) + break; + + offset += get_next_offset(header); + } + + if (offset >= get_bootblock_offset(lar->size)) + return -1; + + return offset; +} + +/** + * Return a 1 if filename is in the list of files - if files is NULL, then + * act as if all files are in the list + * @param files A list of files to check + * @param filename The filename to check against the list + * @return 1 if the file is in the list or if the list is NULL, 0 otherwise + */ +static int file_in_list(struct file *files, char *filename) +{ + struct file *p; + + if (files == NULL) + return 1; + + for(p = files ; p; p = p->next) { + if (!strcmp(p->name, filename)) + return 1; + } + + return 0; +} + +/** + * List the files in a LAR archive + * @param lar The LAR archive to list + * @param files A list of files to display- if this is NULL, then the default + * is to list all files + */ +void lar_list_files(struct lar *lar, struct file *files) +{ + u8 *ptr = lar->map; + char *filename; + + struct lar_header *header; + struct file *fp; + + while (ptr < (lar->map + get_bootblock_offset(lar->size))) { + header = (struct lar_header *) ptr; + + /* We interpet the absence of the magic as empty space */ + + if (strncmp(header->magic, MAGIC, 8)) + break; + + filename = (char *) (ptr + sizeof(struct lar_header)); + + if (file_in_list(files, filename)) { + printf(" %s ", filename); + + if (ntohl(header->compression) == none) { + printf("(%d bytes @0x%lx)\n", + ntohl(header->len), + (unsigned long)(ptr - lar->map) + + ntohl(header->offset)); + } else { + printf("(%d bytes, %s compressed to %d bytes " + "@0x%lx)\n", + ntohl(header->reallen), + algo_name[ntohl(header->compression)], + ntohl(header->len), + (unsigned long)(ptr - lar->map) + + ntohl(header->offset)); + } + } + + ptr += get_next_offset(header); + } + + /* Show the bootblock */ + + if (file_in_list(files, BOOTBLOCK_NAME)) { + header = (struct lar_header *) + (lar->map + get_bootblock_offset(lar->size)); + + printf(" bootblock (%d bytes @0x%x)\n", + ntohl(header->len), + get_bootblock_offset(lar->size) + + ntohl(header->offset)); + } +} + +/** + * Write a buffer to a file - this is used to write blobs from a LAR archive + * @param filename The file to write + * @param buffer The source buffer + * @param len The length of the buffer + * @return 0 on success , or -1 on failure + */ +static int _write_file(char *filename, u8 *buffer, u32 len) +{ + char *path = strdup(filename); + int fd, ret; + + if (path == NULL) { + err("Out of memory.\n"); + return -1; + } + + mkdirp((const char *) dirname(path), 0755); + free(path); + + fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644); + + if (fd == -1) { + err("Error creating file %s\n", filename); + return -1; + } + + ret = write(fd, buffer, len); + + if (ret != len) + err("Error writingthe file %s\n", filename); + + close(fd); + return (ret == len) ? 0 : -1; +} + +/** + * Extract files from a LAR archive. If files is not NULL, then only + * extract the filenames listed within + * @param lar The LAR archive to extract from + * @param files A list of files to extract. If NULL then all files are + * extracted + * @return 0 on success, or -1 on failure + */ +int lar_extract_files(struct lar *lar, struct file *files) +{ + u8 *ptr = lar->map; + char *filename; + struct lar_header *header; + int ret = 0; + + while (ptr < (lar->map + get_bootblock_offset(lar->size))) { + + header = (struct lar_header *) ptr; + + if (strncmp(header->magic, MAGIC, 8)) + break; + + filename = (char *) (ptr + sizeof(struct lar_header)); + + if (file_in_list(files, filename)) { + + if (ntohl(header->compression) == none) { + ret = _write_file(filename, + (u8 *) (ptr + ntohl(header->offset)), + (u32) ntohl(header->len)); + } + else { + char *buf = + malloc(ntohl(header->reallen)); + + if (buf == NULL) { + err("Out of memory.\n"); + return -1; + } + + uncompress_functions[ntohl(header->compression)]( + (char*) buf, + (char *) ptr + ntohl(header->offset), + ntohl(header->len)); + + ret = _write_file(filename, (u8 *) buf, + ntohl(header->reallen)); + + free(buf); + } + + if (ret == -1) + return -1; + } + + ptr += get_next_offset(header); + } + + if (file_in_list(files, BOOTBLOCK_NAME)) { + header = (struct lar_header *) + (lar->map + get_bootblock_offset(lar->size)); + + ret = _write_file((char *) BOOTBLOCK_NAME, + lar->map + (get_bootblock_offset(lar->size) + ntohl(header->offset)), + BOOTBLOCK_SIZE); + } + + return ret; +} + +/** + * Add a new file to the LAR archive + * @param lar The LAR archive to write into + * @param name The name of the file to add + * @return 0 on success, or -1 on failure + */ +int lar_add_file(struct lar *lar, const char *name) +{ + char *filename, *ptr, *temp; + char *pathname; + + enum compalgo thisalgo; + struct lar_header *header; + u32 offset; + int ret, fd, hlen; + u32 complen; + int pathlen; + struct stat s; + u32 *walk, csum; + + /* Find the beginning of the available space in the LAR */ + offset = lar_empty_offset(lar); + + thisalgo = algo; + + filename = (char *) name; + + if (!strncmp(name, "nocompress:",11)) { + filename += 11; + thisalgo = none; + } + + if (filename[0] == '.' && filename[1] == '/') + filename += 2; + + pathname = strchr(filename, ':'); + + if (pathname != NULL) { + *pathname = '\0'; + pathname++; + + if (!strlen(pathname)) { + err("Invalid pathname specified.\n"); + return -1; + } + } + else + pathname = filename; + + /* Open the file */ + fd = open(filename, O_RDONLY); + + if (fd == -1) { + err("Unable to open %s\n", filename); + return -1; + } + + if (fstat(fd, &s)) { + err("Unable to stat the file %s\n", filename); + close(fd); + return -1; + } + + /* Allocate a temporary buffer to compress into - this is unavoidable, + because we need to make sure that the compressed data will fit in + the LAR, and we won't know the size of the compressed data until + we actually compress it */ + + temp = calloc(s.st_size, 1); + + if (temp == NULL) { + err("Out of memory.\n"); + return -1; + } + + ptr = mmap(0, s.st_size, PROT_READ, MAP_SHARED, fd, 0); + + if (ptr == MAP_FAILED) { + err("Unable to map %s\n", filename); + close(fd); + free(temp); + return -1; + } + + + /* Do the compression step */ + compress_functions[thisalgo](ptr, s.st_size, temp, &complen); + + if (complen >= s.st_size && (thisalgo != none)) { + thisalgo = none; + compress_functions[thisalgo](ptr, s.st_size, temp, &complen); + } + + munmap(ptr, s.st_size); + close(fd); + + pathlen = strlen(pathname) + 1 > MAX_PATHLEN ? MAX_PATHLEN : strlen(pathname) + 1; + + /* Figure out how big our header will be */ + hlen = sizeof(struct lar_header) + pathlen; + hlen = (hlen + 15) & 0xFFFFFFF0; + + if (offset + hlen + complen >= get_bootblock_offset(lar->size)) { + err("Not enough room in the LAR to add the file.\n"); + free(temp); + return -1; + } + + /* Lets do this thing */ + + /* Zero out the header area */ + memset(lar->map + offset, 0, hlen); + + header = (struct lar_header *) (lar->map + offset); + + memcpy(header, MAGIC, 8); + header->compression = htonl(thisalgo); + header->reallen = htonl(s.st_size); + header->len = htonl(complen); + header->offset = htonl(hlen); + + /* Copy the path name */ + strncpy((char *) (lar->map + offset + sizeof(struct lar_header)), + pathname, pathlen - 1); + + /* Copy in the data */ + memcpy(lar->map + (offset + hlen), temp, complen); + + /* Figure out the checksum */ + + csum = 0; + for (walk = (u32 *) (lar->map + offset); + walk < (u32 *) (temp + complen + hlen); + walk++) { + csum += ntohl(*walk); + } + header->checksum = htonl(csum); + + free(temp); + return 0; +} From stepan at coresystems.de Mon Aug 20 01:49:01 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 20 Aug 2007 01:49:01 +0200 Subject: [LinuxBIOS] r471 - LinuxBIOSv3/util/lar Message-ID: <46C8D6ED.5050804@coresystems.de> Sorry for not testing this patch before committing it. It breaks the compression exception code. Without patch: stepan at linux:~/svn/LinuxBIOSv3> build/util/lar/lar -l build/linuxbios.rom normal/option_table (932 bytes @0x40) normal/stage2 (37404 bytes, lzma compressed to 15530 bytes @0x420) normal/initram (2221 bytes @0x4100) bootblock (16384 bytes @0x3c000) With patch: stepan at linux:~/svn/LinuxBIOSv3> build/util/lar/lar -l build/linuxbios.rom normal/option_table (932 bytes, lzma compressed to 352 bytes @0x40) normal/stage2 (37404 bytes, lzma compressed to 15526 bytes @0x1d0) normal/initram (2221 bytes, lzma compressed to 1593 bytes @0x3eb0) bootblock (16384 bytes @0x3c000) svn at openbios.org wrote: > Author: stepan > Date: 2007-08-20 01:33:41 +0200 (Mon, 20 Aug 2007) > New Revision: 471 > > Modified: > LinuxBIOSv3/util/lar/lib.c > Log: > Add another field to the filename specified for create and add > operations to specify the intended pathname for the blob. > > Signed-off-by: Jordan Crouse > Acked-by: Stefan Reinauer > > > > Modified: LinuxBIOSv3/util/lar/lib.c > =================================================================== > --- LinuxBIOSv3/util/lar/lib.c 2007-08-19 23:31:58 UTC (rev 470) > +++ LinuxBIOSv3/util/lar/lib.c 2007-08-19 23:33:41 UTC (rev 471) > @@ -210,16 +210,29 @@ > { > struct stat filestat; > int ret = -1; > - const char *realname; > + char *realname; > + char *c; > > - realname = name; > if (strstr(name, "nocompress:") == name) { > - realname = name + 11; > + name += 11; > } > > + realname = strdup(name); > + > + if (realname == NULL) { > + fprintf(stderr, "Out of memory.\n"); > + exit(1); > + } > + > + c = strchr(realname, ':'); > + > + if (c != NULL) > + *c = '\0'; > + > /* printf("... add_files %s\n", name); */ > if (stat(realname, &filestat) == -1) { > fprintf(stderr, "Error getting file attributes of %s\n", name); > + free(realname); > return -1; > } > > @@ -264,6 +277,7 @@ > ret = 0; > } > > + free(realname); > return ret; > } > > > > -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From svn at openbios.org Mon Aug 20 01:53:16 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 01:53:16 +0200 Subject: [LinuxBIOS] r473 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 01:53:16 +0200 (Mon, 20 Aug 2007) New Revision: 473 Modified: LinuxBIOSv3/util/lar/lar.c LinuxBIOSv3/util/lar/lib.h Log: Provide the ability to add arbitrary files to an existing LAR. Also fleshed out the "usage" screen. Signed-off-by: Jordan Crouse Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lar.c =================================================================== --- LinuxBIOSv3/util/lar/lar.c 2007-08-19 23:37:34 UTC (rev 472) +++ LinuxBIOSv3/util/lar/lar.c 2007-08-19 23:53:16 UTC (rev 473) @@ -44,7 +44,33 @@ static void usage(char *name) { printf("\nLAR - the LinuxBIOS Archiver " VERSION "\n" COPYRIGHT "\n\n" - "Usage: %s [-cxl] archive.lar [[[file1] file2] ...]\n\n", name); + "Usage: %s [-cxal] archive.lar [[[file1] file2] ...]\n\n", name); + printf("Examples:\n"); + printf(" lar -c -s 32768 -b bootblock myrom.lar foo nocompress:bar\n"); + printf(" lar -a myrom.lar foo blob:baz\n"); + printf(" lar -l myrom.lar\n\n"); + + printf("File names:\n"); + printf(" Names specified in the create or add modes are formatted as\n"); + printf(" follows: [flags]:[filename]:[pathname].\n"); + printf(" * Flags are modifiers for the file. Valid flags:\n"); + printf(" nocompress\tDon't compress the file in the LAR\n"); + printf(" * Filename is the name of the file on disk. If no pathname\n"); + printf(" is specified, then the filename will also be the path name\n"); + printf(" used in the LAR.\n"); + printf(" * Pathname is the name to use in the LAR header.\n\n"); + + printf("Create options:\n"); + printf(" -s [size]\tSpecify the size of the archive (in bytes)\n"); + printf(" -b [bootblock]\tSpecify the bootblock blob\n"); + printf(" -C [lzma|nrv2b]\tSpecify the compression method to use\n\n"); + + printf("General options\n"); + printf(" -v\tEnable verbose mode\n"); + printf(" -V\tShow the version\n"); + printf(" -h\tShow this help\n"); + printf("\n"); + } int verbose(void) @@ -90,6 +116,27 @@ return 0; } +int add_lar(const char *archivename, struct file *files) +{ + struct lar *lar = lar_open_archive(archivename); + + if (lar == NULL) { + fprintf(stderr, "Unable to open LAR archive %s\n", archivename); + exit(1); + } + + for( ; files; files = files->next) { + if (lar_add_file(lar, files->name)) { + fprintf(stderr, "Error adding %s to the LAR.\n", files->name); + lar_close_archive(lar); + exit(1); + } + } + + lar_close_archive(lar); + return 0; +} + int list_lar(const char *archivename, struct file *files) { struct lar *lar = lar_open_archive(archivename); @@ -130,6 +177,7 @@ char *archivename = NULL; static struct option long_options[] = { + {"add", 0, 0, 'a'}, {"create", 0, 0, 'c'}, {"compress-algo", 1, 0, 'C'}, {"extract", 0, 0, 'x'}, @@ -147,9 +195,12 @@ exit(1); } - while ((opt = getopt_long(argc, argv, "cC:xls:b:vVh?", + while ((opt = getopt_long(argc, argv, "acC:xls:b:vVh?", long_options, &option_index)) != EOF) { switch (opt) { + case 'a': + larmode = ADD; + break; case 'c': larmode = CREATE; break; @@ -258,6 +309,9 @@ } switch (larmode) { + case ADD: + add_lar(archivename, get_files()); + break; case EXTRACT: extract_lar(archivename, get_files()); break; Modified: LinuxBIOSv3/util/lar/lib.h =================================================================== --- LinuxBIOSv3/util/lar/lib.h 2007-08-19 23:37:34 UTC (rev 472) +++ LinuxBIOSv3/util/lar/lib.h 2007-08-19 23:53:16 UTC (rev 473) @@ -30,6 +30,7 @@ enum { NONE, + ADD, CREATE, LIST, EXTRACT From stepan at coresystems.de Mon Aug 20 02:01:23 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 20 Aug 2007 02:01:23 +0200 Subject: [LinuxBIOS] [patch 3/5] Allow user to specify pathnames for create and add In-Reply-To: <20070723161036.508583000@cosmic.amd.com> References: <20070723160602.511777000@cosmic.amd.com> <20070723161036.508583000@cosmic.amd.com> Message-ID: <46C8D9D3.5070807@coresystems.de> jordan.crouse at amd.com wrote: > Add another field to the filename specified for create and add operations > to specify the intended pathname for the blob. > > Signed-off-by: Jordan Crouse This patch breaks the produced image. Please provide a fix. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From stepan at coresystems.de Mon Aug 20 02:08:02 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 20 Aug 2007 02:08:02 +0200 Subject: [LinuxBIOS] [patch 5/5] Allow human friendly suffixes for the size option In-Reply-To: <20070723161037.964196000@cosmic.amd.com> References: <20070723160602.511777000@cosmic.amd.com> <20070723161037.964196000@cosmic.amd.com> Message-ID: <46C8DB62.7020206@coresystems.de> jordan.crouse at amd.com wrote: > Enable 'k' and 'm' suffixes to modify the size in a human friendly > way - s 32k is much easier on the brain then -s 32768. > > Signed-off-by: Jordan Crouse This patch breaks the old behavior of being able to specify the number of bytes without a unit. I'll commit it with a fix. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From svn at openbios.org Mon Aug 20 02:08:18 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 02:08:18 +0200 Subject: [LinuxBIOS] r474 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 02:08:18 +0200 (Mon, 20 Aug 2007) New Revision: 474 Modified: LinuxBIOSv3/util/lar/lar.c Log: Add another field to the filename specified for create and add operations to specify the intended pathname for the blob. Signed-off-by: Jordan Crouse Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lar.c =================================================================== --- LinuxBIOSv3/util/lar/lar.c 2007-08-19 23:53:16 UTC (rev 473) +++ LinuxBIOSv3/util/lar/lar.c 2007-08-20 00:08:18 UTC (rev 474) @@ -46,7 +46,7 @@ printf("\nLAR - the LinuxBIOS Archiver " VERSION "\n" COPYRIGHT "\n\n" "Usage: %s [-cxal] archive.lar [[[file1] file2] ...]\n\n", name); printf("Examples:\n"); - printf(" lar -c -s 32768 -b bootblock myrom.lar foo nocompress:bar\n"); + printf(" lar -c -s 32k -b bootblock myrom.lar foo nocompress:bar\n"); printf(" lar -a myrom.lar foo blob:baz\n"); printf(" lar -l myrom.lar\n\n"); @@ -61,7 +61,9 @@ printf(" * Pathname is the name to use in the LAR header.\n\n"); printf("Create options:\n"); - printf(" -s [size]\tSpecify the size of the archive (in bytes)\n"); + printf(" -s [size] \tSpecify the size of the archive.\n"); + printf(" \tUse a 'k' suffix to multiply the size by 1024 or\n"); + printf(" \ta 'm' suffix to multiple the size by 1024*1024.\n"); printf(" -b [bootblock]\tSpecify the bootblock blob\n"); printf(" -C [lzma|nrv2b]\tSpecify the compression method to use\n\n"); @@ -73,6 +75,29 @@ } +/* Add a human touch to the LAR size by allowing suffixes: + * XX[KkMm] where k = XX * 1024 and m or M = xx * 1024 * 1024 + */ + +static void parse_larsize(char *str) +{ + char *p = NULL; + unsigned int size = strtoul(str, &p, 0); + + if (p != NULL) { + if (*p == 'k' || *p == 'K') + size *= 1024; + else if (*p == 'm' || *p == 'M') + size *= (1024 * 1024); + else if (*p) { + fprintf(stderr, "Unknown LAR size suffix '%c'\n", *p); + exit(1); + } + } + + larsize = size; +} + int verbose(void) { return isverbose; @@ -219,7 +244,7 @@ larmode = EXTRACT; break; case 's': - larsize = strtol(optarg, (char **)NULL, 10); + parse_larsize(optarg); break; case 'b': bootblock = strdup(optarg); From svn at openbios.org Mon Aug 20 02:36:20 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 02:36:20 +0200 Subject: [LinuxBIOS] r475 - LinuxBIOSv3/arch/x86 Message-ID: Author: stepan Date: 2007-08-20 02:36:20 +0200 (Mon, 20 Aug 2007) New Revision: 475 Modified: LinuxBIOSv3/arch/x86/Makefile Log: fix building LinuxBIOS with new lar. lar fails now if the target file already exists. Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/arch/x86/Makefile =================================================================== --- LinuxBIOSv3/arch/x86/Makefile 2007-08-20 00:08:18 UTC (rev 474) +++ LinuxBIOSv3/arch/x86/Makefile 2007-08-20 00:36:20 UTC (rev 475) @@ -77,6 +77,7 @@ fi endif $(Q)printf " LAR $(subst $(shell pwd)/,,$(@))\n" + $(Q)rm -f $(obj)/linuxbios.rom $(Q)cd $(obj)/lar.tmp && ../util/lar/lar $(COMPRESSFLAG) -c \ ../linuxbios.rom \ $(LARFILES) \ From stepan at coresystems.de Mon Aug 20 02:36:55 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 20 Aug 2007 02:36:55 +0200 Subject: [LinuxBIOS] [patch 2/5] New LAR access functions In-Reply-To: <20070723161035.445067000@cosmic.amd.com> References: <20070723160602.511777000@cosmic.amd.com> <20070723161035.445067000@cosmic.amd.com> Message-ID: <46C8E227.7040602@coresystems.de> jordan.crouse at amd.com wrote: > In preparation for adding new LAR functionality - this patch consolidates > creating and accessing the LAR into new code utilizing mmap which > facilitates moving about within the archive. > > This code also turns the bootblock path name as a constant value. > It also requires that the user specify a size when the LAR is > created. > > Signed-off-by: Jordan crouse This code checks whether the target file already exists and fails if this is the case. I am not sure whether this is an intended behavior. When running "make" two times in a row, the second make fails now: > Archive file ../linuxbios.rom already exists Unable to create > ../linuxbios.rom as a LAR archive. make: *** > [/home/stepan/svn/LinuxBIOSv3/build/linuxbios.rom] Error 1 I fixed this in the Makefile for now by deleting the output file before creating it. -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From svn at openbios.org Mon Aug 20 02:48:06 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 02:48:06 +0200 Subject: [LinuxBIOS] r476 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 02:48:06 +0200 (Mon, 20 Aug 2007) New Revision: 476 Modified: LinuxBIOSv3/util/lar/lib.c LinuxBIOSv3/util/lar/stream.c Log: fix mkdirp_below calls like I think Peter intended them Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3/util/lar/lib.c 2007-08-20 00:36:20 UTC (rev 475) +++ LinuxBIOSv3/util/lar/lib.c 2007-08-20 00:48:06 UTC (rev 476) @@ -155,12 +155,6 @@ return ret; } - -int mkdirp(const char *dirpath, mode_t mode) -{ - return mkdirp_below(".", dirpath, mode); -} - static int handle_directory(const char *name) { int n; Modified: LinuxBIOSv3/util/lar/stream.c =================================================================== --- LinuxBIOSv3/util/lar/stream.c 2007-08-20 00:36:20 UTC (rev 475) +++ LinuxBIOSv3/util/lar/stream.c 2007-08-20 00:48:06 UTC (rev 476) @@ -445,7 +445,7 @@ return -1; } - mkdirp((const char *) dirname(path), 0755); + mkdirp_below(".", (const char *) dirname(path), 0755); free(path); fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644); From joe at smittys.pointclark.net Mon Aug 20 08:27:55 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Mon, 20 Aug 2007 02:27:55 -0400 Subject: [LinuxBIOS] Problems with Intel vga working Message-ID: <20070820022755.lvgcz2sx7okk0skk@www.smittys.pointclark.net> Hello, I have followed the vga support documentaion to a "T" but I don't get any vga output when I boot, only serial. I have tried several different ersions of the vga rom with no luck. Has anyone else had any success with integrated vga on an Intel board? Is there anyway to debug this to find out what is happening? Here is my lspci -v: 00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 04) (prog-if 00 [VGA]) Flags: bus master, fast devsel, latency 0, IRQ 7 Memory at f0000000 (32-bit, prefetchable) [size=128M] Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] Flags: bus master, fast devsel, latency 0 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at ff980000 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 Here is what my Conif.lb looks like: device pci 2.0 on # VGA compatible controller: Intel Corporation 82830 CGC chip drivers/pci/onboard device pci 2.1 on end # Display controller: Intel Corporation 82830 CGC register "rom_address" = "0xfff80000" end end Thanks - Joe From rmh at aybabtu.com Mon Aug 20 09:47:08 2007 From: rmh at aybabtu.com (Robert Millan) Date: Mon, 20 Aug 2007 09:47:08 +0200 Subject: [LinuxBIOS] Fwd: ACPI memo In-Reply-To: <13426df10708150627x19f0d5b8ydc74c4cc961fdd31@mail.gmail.com> References: <46C0A236.2070601@atl.lmco.com> <13426df10708150627x19f0d5b8ydc74c4cc961fdd31@mail.gmail.com> Message-ID: <20070820074708.GA6987@aragorn> On Wed, Aug 15, 2007 at 06:27:36AM -0700, ron minnich wrote: > You just have to love ACPI. Or any other binary standard, for that matter. Amazing. Well, except we're pretty used to this kind of mob-style tactics :-) > In a simliar vein, I wonder if we'll find it almost impossible to run > EFI drivers under non-EFI software ... But who wants to run EFI drivers anyway? If I had EFI, the first thing I would want is getting rid of it. > ---------- Forwarded message ---------- > From: > Date: Aug 13, 2007 11:25 AM > Subject: ACPI memo > To: ron minnich > > > Pretty amusing, if you haven't seen this before. :-) > > http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From darmawan.salihun at gmail.com Mon Aug 20 11:59:12 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Mon, 20 Aug 2007 16:59:12 +0700 Subject: [LinuxBIOS] GSoC -- Winflashrom Last Status Message-ID: <46893e740708200259u145b943avaab14e54e1874095@mail.gmail.com> Hi all, The latest code from winflashrom is attached (overall code in tar.gz format) and the diff. Anyway, sorry about the diff because it's reversed, I can't get TortoiseCVS to make it not reversed. I don't know why the diff is always reversed like that. I'll be moving to command line SVN very soon to alleviate the problem. Anyway, I might be uploading an updated code in the next few hours. This is only for GSoC "compliance". The current version has no DPC support what so ever :(. I'll submit the one with DPC in the next few hours. This is merely to make sure that there is a working code submitted prior to GSoC "pencils down" time limit. Note that this version has an improved support for Winbond W39V040FA flashchip. The original support in flashrom is *not* working because it's not setting the Block Locking Register (BLR) prior to flashing. I'll add the patch to the Linux version in the next few days (I need to test it in my machine before hand even if winflashrom shows it's working flawlessly). The excerpt as follows: ---------------------------------------------------- enum { BLOCKING_REGS_PHY_RANGE = 0x80000, BLOCKING_REGS_PHY_BASE = 0xFFB80000, }; static volatile char * unprotect_39v040fa(void) { unsigned char i, byte_val; volatile char * block_regs_base; block_regs_base = (volatile char*) map_physical_addr_range( BLOCKING_REGS_PHY_BASE, BLOCKING_REGS_PHY_RANGE); if (block_regs_base == NULL) { perror("Error: Unable to map Winbond w39v040fa" "blocking registers!\n"); return NULL; } // // Unprotect the BIOS chip address range // for( i = 0; i < 8 ; i++ ) { byte_val = *(block_regs_base + 2 + i*0x10000); myusec_delay(10); byte_val &= 0xF8; // Enable full access to the chip *(block_regs_base + 2 + i*0x10000) = byte_val; myusec_delay(10); } return block_regs_base; } static void protect_39v040fa(volatile char * reg_base) { // // Protect the BIOS chip address range // unsigned char i, byte_val; volatile char * block_regs_base = reg_base; for( i = 0; i < 8 ; i++ ) { byte_val = *(block_regs_base + 2 + i*0x10000); myusec_delay(10); byte_val |= 1; // Prohibited to write in the block // where set *(block_regs_base + 2 + i*0x10000) = byte_val; myusec_delay(10); } unmap_physical_addr_range((void*) reg_base, BLOCKING_REGS_PHY_RANGE); } int write_39v040fa(struct flashchip *flash, uint8_t *buf) { int i; int total_size = flash->total_size * 1024; int page_size = flash->page_size; volatile uint8_t *bios = flash->virtual_memory; volatile char * reg_base; reg_base = unprotect_39v040fa(); erase_chip_jedec(flash); printf("Programming Page: "); for (i = 0; i < total_size / page_size; i++) { /* write to the sector */ printf("%04d at address: 0x%08x", i, i * page_size); write_sector_jedec(bios, buf + i * page_size, bios + i * page_size, page_size); printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); fflush(stdout); } printf("\n"); if(NULL != reg_base) { protect_39v040fa(reg_base); } return (0); } --------------------------------------------------------------- That's all for now. Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- A non-text attachment was scrubbed... Name: winflashrom.tar.gz Type: application/x-gzip Size: 121570 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: winflashrom.diff Type: application/octet-stream Size: 48438 bytes Desc: not available URL: From peter at stuge.se Mon Aug 20 13:34:43 2007 From: peter at stuge.se (Peter Stuge) Date: Mon, 20 Aug 2007 13:34:43 +0200 Subject: [LinuxBIOS] Problems with Intel vga working In-Reply-To: <20070820022755.lvgcz2sx7okk0skk@www.smittys.pointclark.net> References: <20070820022755.lvgcz2sx7okk0skk@www.smittys.pointclark.net> Message-ID: <20070820113443.21555.qmail@stuge.se> On Mon, Aug 20, 2007 at 02:27:55AM -0400, Joseph Smith wrote: > Is there anyway to debug this to find out what is happening? Is there any indication of what the problem is in the boot messages? Have you tried using both vm86 and x86emu? //Peter From jordan.crouse at amd.com Mon Aug 20 16:19:21 2007 From: jordan.crouse at amd.com (Jordan Crouse) Date: Mon, 20 Aug 2007 08:19:21 -0600 Subject: [LinuxBIOS] Allow user to specify pathnames for create and add In-Reply-To: <46C8D9D3.5070807@coresystems.de> References: <20070723160602.511777000@cosmic.amd.com> <20070723161036.508583000@cosmic.amd.com> <46C8D9D3.5070807@coresystems.de> Message-ID: <20070820141921.GC2170@cosmic.amd.com> On 20/08/07 02:01 +0200, Stefan Reinauer wrote: > jordan.crouse at amd.com wrote: > > Add another field to the filename specified for create and add operations > > to specify the intended pathname for the blob. > > > > Signed-off-by: Jordan Crouse > This patch breaks the produced image. Please provide a fix. Not sure what you mean - but this code has suffered from too much bit rot, so I'm going to withdraw all of them. Better luck next time, I guess. :) Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. From stepan at coresystems.de Mon Aug 20 16:40:30 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Mon, 20 Aug 2007 16:40:30 +0200 Subject: [LinuxBIOS] Allow user to specify pathnames for create and add In-Reply-To: <20070820141921.GC2170@cosmic.amd.com> References: <20070723160602.511777000@cosmic.amd.com> <20070723161036.508583000@cosmic.amd.com> <46C8D9D3.5070807@coresystems.de> <20070820141921.GC2170@cosmic.amd.com> Message-ID: <20070820144030.GA9019@coresystems.de> Dear Jordan, * Jordan Crouse [070820 16:19]: > On 20/08/07 02:01 +0200, Stefan Reinauer wrote: > > jordan.crouse at amd.com wrote: > > > Add another field to the filename specified for create and add operations > > > to specify the intended pathname for the blob. > > > > > > Signed-off-by: Jordan Crouse > > This patch breaks the produced image. Please provide a fix. > > Not sure what you mean - but this code has suffered from too much bit rot, > so I'm going to withdraw all of them. Better luck next time, I guess. :) No, it seems it's not a problem of bit rot, that code has not been touched in the repository between the time you made the changes and the time it got checked in. It just seems to be a corner case that is not fully working yet with the new code base. I narrowed the problem down to the util/lar/lib.c part of the patch which causes all modules to be compressed, even those with a nocompress: tag. It's too late for a withdraw now since your fine piece of work is already in the v3 repository since yesterday night ;-) Please don't ask me to remove it again. I believe this is a significant step forward on our road to v3. I want to apologize for the long delay since you provided the code - The final version of the patches have been sitting in my inbox and on my todo list since July 23rd. Time has been a very tight resource for me, just like for many other core LinuxBIOS developers lately. We're trying as good as we can to change that. Let's try to get things going again so we don't lose the momentum we had in Ottawa! Best wishes, 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 darmawan.salihun at gmail.com Mon Aug 20 17:05:21 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Mon, 20 Aug 2007 22:05:21 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C1E2EE.9000807@dls.net> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> Message-ID: <46C9ADB1.2080602@gmail.com> Roman Kononov wrote: > On 08/14/2007 07:56 AM, Peter Stuge wrote: >> Roman did make a good point about IRQL but that does not eliminate >> the problem, we will still be changing hardware state underneath the >> OS and that is ALWAYS a bad idea. > > The CF8/CFC sequence can preserve CF8 port value. What other hardware state > would be changed? > >> http://www.hollistech.com/Resources/Misc%20articles/getbusdata.htm >> http://www.freelists.org/archives/wdmaudiodev/03-2004/msg00010.html > > BTW, here is the "official" example: > http://support.microsoft.com/kb/253232 > > Unfortunately, AFAIK, this approach does not work for cases like yours. It > requires the "DeviceObject", which MUST be associated with a PARTICULAR PCI > function. > > Q: In the above links, among HtsReadWriteConfig() and WritePCIConfigSpace() > argument lists, which arguments are bus number and device number? > A: They are inside PDEVICE_OBJECT, which structure is "opaque". > > Regarding how long DPC method takes. A scheduled DPC is launched as soon as > the CPU's IRQL drops below DISPATCH_LEVEL. The CPU can be at DISPATCH_LEVEL > (and higher) only running kernel code. This can last many time slices. This > means that the DPC method might be quite expensive. According to the official documentation, DPC is running at IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because only one DPC object of one "type" can exist in the system at one instance. This means we need to provide different DPC object "type" for different processor in multiprocessor environment to ensure "atomic" execution of the I/O code which seems to be an overkill and make the system too much loaded. I found this when trying to code the "DPC approach" in my latest device driver. Perhaps, using a kernel mode spinlock is a better approach. To ensure an atomic execution of the I/O operation. Seems to be the DPC approach is not the right solution for this type of problem. I'm still working on this problem right now. Regards, Darmawan Salihun From marc.jones at amd.com Mon Aug 20 18:29:38 2007 From: marc.jones at amd.com (Marc Jones) Date: Mon, 20 Aug 2007 10:29:38 -0600 Subject: [LinuxBIOS] smbus_write_byte In-Reply-To: <20070818174656.npc45tm0owwc4w0c@www.smittys.pointclark.net> References: <20070817004047.hq32sq7qooskooog@www.smittys.pointclark.net> <46C53607.9080003@gmail.com> <20070818123726.r2ur57snsc48sksk@www.smittys.pointclark.net> <2ea3fae10708181147p7a0431c0i155ba57b132d6c5a@mail.gmail.com> <46C74043.2010108@gmail.com> <20070818174656.npc45tm0owwc4w0c@www.smittys.pointclark.net> Message-ID: <46C9C172.9050909@amd.com> Joseph Smith wrote: > Quoting Corey Osgood : > >> yhlu wrote: >>> just provide one fake spd array... >>> >>> YH >> My thoughts exactly. You can't write to the smbus because there's no >> device on the smbus at that location to receive those writes. >> >> -Corey >> >> > How would I provide a fake spd array? Here is the situation. My board > has the onboard memory without a SPD, I could just hardcode this into > the northbridge raminit.c. But I don't want to do that so people that > may want to use the northbridge src for other boards won't have to > deal with it. So right now I have auto.c call a function that runs in > between sdram_set_spd_registers and sdram_enable, like this: > > sdram_set_spd_registers(memctrl); > onboard_sdram_set_registers(memctrl); > sdram_enable(0, memctrl); > > This function, onboard_sdram_set_registers manually sets up the regsters. > > Anyways I would also like to get the smbus_write_byte write going to > setup my tv-out registers on my tv-out chip? > > Thanks - Joe > Joe, There is an example of an spd array in mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You will have to generate the correct SPD values for your memory. Is the normal smbus_write_byte not working? Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From patrick at georgi-clan.de Mon Aug 20 18:34:54 2007 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 20 Aug 2007 18:34:54 +0200 Subject: [LinuxBIOS] Allow user to specify pathnames for create and add References: <20070723160602.511777000@cosmic.amd.com> <20070723161036.508583000@cosmic.amd.com> <46C8D9D3.5070807@coresystems.de> <20070820141921.GC2170@cosmic.amd.com> <20070820144030.GA9019@coresystems.de> Message-ID: Stefan Reinauer wrote: > fully working yet with the new code base. I narrowed the problem down to > the util/lar/lib.c part of the patch which causes all modules to be > compressed, even those with a nocompress: tag. the attached patch should fix it.. Regards, Patrick Georgi -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-20070820-1-linuxbios-fix-lar-nocompress Type: text/x-diff Size: 774 bytes Desc: not available URL: From kononov at dls.net Mon Aug 20 19:01:27 2007 From: kononov at dls.net (Roman Kononov) Date: Mon, 20 Aug 2007 12:01:27 -0500 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C9ADB1.2080602@gmail.com> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <46C9ADB1.2080602@gmail.com> Message-ID: <46C9C8E7.2070106@dls.net> On 08/20/2007 10:05 AM, Darmawan Salihun wrote: > According to the official documentation, DPC is running at > IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because > only one DPC object of one "type" can exist in the system at one > instance. What do you mean by "type"? If you have N CPUs: Initialization: KeInitializeDpc() initializes N DPC objects, each object has the same "DeferredRoutine". KeSetTargetProcessorDpc() ties each DPC object with a CPU. PCI Configuration Sequence: IRQL is raised to DISPATCH_LEVEL. KeGetCurrentProcessorNumber() tells which CPU it is. KeInsertQueueDpc() schedules the N-1 DPCs to run. All but this CPU are scheduled. Spin waiting for the DeferredRoutines to enter phase A. IRQL is raised to HIGH_LEVEL. The DeferredRoutins are flagged to enter phase B. Spin waiting for the DeferredRoutines to enter phase B. Do the 3f8/3fc business. The DeferredRoutins are flagged to finish. Restore the IRQL. DeferredRoutine: Indicate that the phase is phase A. Spin waiting for being flagged to enter phase B. Raise IRQL to HICH_LEVEL. Indicate that the phase is phase B. Spin waiting for being flagged to finish. Restore the IRQL. This means we need to provide different DPC object "type" for > different processor in multiprocessor environment to ensure "atomic" > execution of the I/O code which seems to be an overkill and make the > system too much loaded. What is "too much"? I found this when trying to code the "DPC > approach" in my latest device driver. Perhaps, using a kernel mode > spinlock is a better approach. To ensure an atomic execution of the I/O > operation. A spin lock does not help. A CPU, which has acquired a spin lock, does not prevent another CPU to mess with the cf8/cfc registers. You need to lock all other CPUs. Seems to be the DPC approach is not the right solution for > this type of problem. You are the man, you make the decision. Regards, Roman From svn at openbios.org Mon Aug 20 19:55:32 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 19:55:32 +0200 Subject: [LinuxBIOS] r477 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 19:55:32 +0200 (Mon, 20 Aug 2007) New Revision: 477 Modified: LinuxBIOSv3/util/lar/lib.c Log: Fixes nocompress:-handling in lar Signed-off-by: Patrick Georgi Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3/util/lar/lib.c 2007-08-20 00:48:06 UTC (rev 476) +++ LinuxBIOSv3/util/lar/lib.c 2007-08-20 17:55:32 UTC (rev 477) @@ -208,21 +208,17 @@ char *c; if (strstr(name, "nocompress:") == name) { - name += 11; + free(realname); + realname = strdup(name + 11); + } else { + realname = strdup(name); } - realname = strdup(name); - if (realname == NULL) { fprintf(stderr, "Out of memory.\n"); exit(1); } - c = strchr(realname, ':'); - - if (c != NULL) - *c = '\0'; - /* printf("... add_files %s\n", name); */ if (stat(realname, &filestat) == -1) { fprintf(stderr, "Error getting file attributes of %s\n", name); From svn at openbios.org Mon Aug 20 20:00:45 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 20 Aug 2007 18:00:45 -0000 Subject: [LinuxBIOS] #84: grub2 can boot linux from IDE disk In-Reply-To: <044.b70ec6a25142eed67ff6f8f078bde54f@openbios.org> References: <044.b70ec6a25142eed67ff6f8f078bde54f@openbios.org> Message-ID: <053.75b476de336afc2d69c511d9c54e9733@openbios.org> #84: grub2 can boot linux from IDE disk ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Changes (by oxygene): * status: new => closed * patchstatus: there is no patch => patch needs review * resolution: => fixed Comment: contained in lbgrub2 patch, using code from openbios (unclear licensing, gpl2 vs. gpl3!) see http://openbios.org/~oxygene/patch-20070820-2-lbgrub2-genesis-patch and http://openbios.org/~oxygene/lbgrub2-20070820-1.tar.bz2 -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Aug 20 20:04:04 2007 From: svn at openbios.org (LinuxBIOS) Date: Mon, 20 Aug 2007 18:04:04 -0000 Subject: [LinuxBIOS] #79: grub2 loads and executes as payload of the Qemu target In-Reply-To: <044.a6b58101ab47e4cd7f414f91b1c794be@openbios.org> References: <044.a6b58101ab47e4cd7f414f91b1c794be@openbios.org> Message-ID: <053.366cd6857bbdef3a9549df8b059acd50@openbios.org> #79: grub2 loads and executes as payload of the Qemu target ----------------------------+----------------------------------------------- Reporter: oxygene | Owner: oxygene Type: enhancement | Status: closed Priority: major | Milestone: Port GRUB2 to LinuxBIOS Component: code | Version: v3 Resolution: fixed | Keywords: Dependencies: | Patchstatus: patch needs review ----------------------------+----------------------------------------------- Changes (by oxygene): * status: assigned => closed * patchstatus: patch needs work => patch needs review * resolution: => fixed Comment: see http://openbios.org/~oxygene/patch-20070820-2-lbgrub2-genesis-patch and http://openbios.org/~oxygene/lbgrub2-20070820-1.tar.bz2 -- Ticket URL: LinuxBIOS From svn at openbios.org Mon Aug 20 20:21:53 2007 From: svn at openbios.org (svn at openbios.org) Date: Mon, 20 Aug 2007 20:21:53 +0200 Subject: [LinuxBIOS] r478 - LinuxBIOSv3/util/lar Message-ID: Author: stepan Date: 2007-08-20 20:21:52 +0200 (Mon, 20 Aug 2007) New Revision: 478 Modified: LinuxBIOSv3/util/lar/lib.c Log: small typo Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: LinuxBIOSv3/util/lar/lib.c =================================================================== --- LinuxBIOSv3/util/lar/lib.c 2007-08-20 17:55:32 UTC (rev 477) +++ LinuxBIOSv3/util/lar/lib.c 2007-08-20 18:21:52 UTC (rev 478) @@ -208,7 +208,6 @@ char *c; if (strstr(name, "nocompress:") == name) { - free(realname); realname = strdup(name + 11); } else { realname = strdup(name); From patrick at georgi-clan.de Mon Aug 20 20:29:16 2007 From: patrick at georgi-clan.de (Patrick Georgi) Date: Mon, 20 Aug 2007 20:29:16 +0200 Subject: [LinuxBIOS] [PATCH][RFC] PCBIOS legacy tables Message-ID: Hi, there are several legacy tables that PCBIOS writes, eg. about the io-ports of the various serial ports. We probably need a place for them to be generated, as some clients might rely on the presence of these tables. Grub2 definitely needs the serial port's ioport written at 0x400 (which the attached patch does) to support serial console, but I'm not sure if that's a good place to collect such configuration or where to put it instead. So please consider this patch an attempt to start a discussion... :-) Regards, Patrick Georgi -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-20070820-3-legacy-serial-table Type: text/x-diff Size: 930 bytes Desc: not available URL: From joe at smittys.pointclark.net Mon Aug 20 21:09:58 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Mon, 20 Aug 2007 15:09:58 -0400 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte Message-ID: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> Quoting Marc Jones : > > > Joseph Smith wrote: >> Quoting Corey Osgood : >> >>> yhlu wrote: >>>> just provide one fake spd array... >>>> >>>> YH >>> My thoughts exactly. You can't write to the smbus because there's no >>> device on the smbus at that location to receive those writes. >>> >>> -Corey >>> >>> >> How would I provide a fake spd array? Here is the situation. My >> board has the onboard memory without a SPD, I could just hardcode >> this into the northbridge raminit.c. But I don't want to do that >> so people that may want to use the northbridge src for other >> boards won't have to deal with it. So right now I have auto.c call >> a function that runs in between sdram_set_spd_registers and >> sdram_enable, like this: >> >> sdram_set_spd_registers(memctrl); >> onboard_sdram_set_registers(memctrl); >> sdram_enable(0, memctrl); >> >> This function, onboard_sdram_set_registers manually sets up the regsters. >> >> Anyways I would also like to get the smbus_write_byte write going >> to setup my tv-out registers on my tv-out chip? >> >> Thanks - Joe >> > > Joe, > There is an example of an spd array in > mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You > will have to generate the correct SPD values for your memory. > > Is the normal smbus_write_byte not working? > > Marc > > Thanks everyone for your help. No, the smbus_write_byte is commented out and has a big FIXME. I assume the code just never got finished?? static void smbus_write_byte(unsigned device, unsigned address, unsigned char val) { if (smbus_wait_until_ready(SMBUS_IO_BASE) < 0) { return; } print_debug("Unimplemented smbus_write_byte() called.\r\n"); #if 0 /* setup transaction */ /* disable interrupts */ outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)), SMBUS_IO_BASE + SMBGCTL); /* set the device I'm talking too */ outw(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBHSTADDR); outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); /* set up for a byte data write */ /* FIXME */ outw((inw(SMBUS_IO_BASE + SMBGCTL) & ~7) | (0x1), SMBUS_IO_BASE + SMBGCTL); /* clear any lingering errors, so the transaction will run */ /* Do I need to write the bits to a 1 to clear an error? */ outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS); /* clear the data word...*/ outw(val, SMBUS_IO_BASE + SMBHSTDAT); /* start the command */ outw((inw(SMBUS_IO_BASE + SMBGCTL) | (1 << 3)), SMBUS_IO_BASE + SMBGCTL); /* poll for transaction completion */ smbus_wait_until_done(SMBUS_IO_BASE); #endif return; } Thanks - Joe From corey.osgood at gmail.com Mon Aug 20 22:32:37 2007 From: corey.osgood at gmail.com (Corey Osgood) Date: Mon, 20 Aug 2007 16:32:37 -0400 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> References: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> Message-ID: <46C9FA65.4060200@gmail.com> Joseph Smith wrote: > Quoting Marc Jones : > >> >> >> Joseph Smith wrote: >>> Quoting Corey Osgood : >>> >>>> yhlu wrote: >>>>> just provide one fake spd array... >>>>> >>>>> YH >>>> My thoughts exactly. You can't write to the smbus because there's no >>>> device on the smbus at that location to receive those writes. >>>> >>>> -Corey >>>> >>>> >>> How would I provide a fake spd array? Here is the situation. My >>> board has the onboard memory without a SPD, I could just hardcode >>> this into the northbridge raminit.c. But I don't want to do that >>> so people that may want to use the northbridge src for other >>> boards won't have to deal with it. So right now I have auto.c call >>> a function that runs in between sdram_set_spd_registers and >>> sdram_enable, like this: >>> >>> sdram_set_spd_registers(memctrl); >>> onboard_sdram_set_registers(memctrl); >>> sdram_enable(0, memctrl); >>> >>> This function, onboard_sdram_set_registers manually sets up the >>> regsters. >>> >>> Anyways I would also like to get the smbus_write_byte write going >>> to setup my tv-out registers on my tv-out chip? >>> >>> Thanks - Joe >>> >> >> Joe, >> There is an example of an spd array in >> mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You >> will have to generate the correct SPD values for your memory. >> >> Is the normal smbus_write_byte not working? >> >> Marc >> >> > Thanks everyone for your help. No, the smbus_write_byte is commented > out and has a big FIXME. I assume the code just never got finished?? Hmm, smbus_write_byte is commented in the original code (intel/i82801db/i82801db_early_smbus.c), but smbus_write_block is not, so it should work with the comments removed. Does that help at all? -Corey > > static void smbus_write_byte(unsigned device, unsigned address, > unsigned char val) > { > if (smbus_wait_until_ready(SMBUS_IO_BASE) < 0) { > return; > } > > print_debug("Unimplemented smbus_write_byte() called.\r\n"); > > #if 0 > /* setup transaction */ > /* disable interrupts */ > outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)), > SMBUS_IO_BASE + SMBGCTL); > /* set the device I'm talking too */ > outw(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBHSTADDR); > outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); > /* set up for a byte data write */ /* FIXME */ > outw((inw(SMBUS_IO_BASE + SMBGCTL) & ~7) | (0x1), SMBUS_IO_BASE + > SMBGCTL); > /* clear any lingering errors, so the transaction will run */ > /* Do I need to write the bits to a 1 to clear an error? */ > outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS); > > /* clear the data word...*/ > outw(val, SMBUS_IO_BASE + SMBHSTDAT); > > /* start the command */ > outw((inw(SMBUS_IO_BASE + SMBGCTL) | (1 << 3)), SMBUS_IO_BASE + > SMBGCTL); > > /* poll for transaction completion */ > smbus_wait_until_done(SMBUS_IO_BASE); > #endif > return; > } > > Thanks - Joe > > From c-d.hailfinger.devel.2006 at gmx.net Mon Aug 20 22:50:16 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Mon, 20 Aug 2007 22:50:16 +0200 Subject: [LinuxBIOS] 64bit issues was: [PATCH] LBv3: fix printk format warnings In-Reply-To: <46C326BA.3000603@coresystems.de> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <46BFCA4D.90304@gmx.net> <46C326BA.3000603@coresystems.de> Message-ID: <46C9FE88.7000303@gmx.net> On 15.08.2007 18:15, Stefan Reinauer wrote: > Carl-Daniel Hailfinger wrote: >> I have another patch pending which changes %Lx (L is unspecified for >> integers, happens to work) to %llx ("official" long long for integers). >> >> > It doesn't "happen to work", it is implemented so that it works. %llx > will not work if you don't change printk. Quoting from v3/lib/vtxprintf.c: if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L') { qualifier = *fmt; ++fmt; if (*fmt == 'l') { qualifier = 'L'; ++fmt; } %llx already works. > I agree we should make it compatible to printf. OK, I'll send followup patches. >> Conclusions: >> * "L" is for floats only. >> * "t" or "z" might be handy for resource sizes. >> * "h" and "hh" for u16 and u8 seem to be unknown to most coders (except >> in util/dtc) and gcc doesn't warn about them. Should investigate >> usefulness for us. > > Then L really makes no sense. Then we want to drop it from the code > completely to prevent people from using it with the wrong expectations > (like I did, because I figured its meaning out from the code, not the > man page of printf) Will send patches. >>> printk(BIOS_DEBUG, "ROM address for %s = %p\n", dev_path(dev), (void *) rom_address); >>> >>> >> Do I understand this correctly? (void *) conversion and usage of %p for >> things that are essentially pointers. > > What's unclear? Nothing. I was just trying to make sure I had understood Ron correctly. >>> Why do this? It's actually more portable, even across plan 9 and >>> linux. It will probably work correctly in 64 bit mode. And, that >>> rom_address really *is* an address. >>> >> I like it, but... in the first example it seems this was an error, the >> base is not an address, but some u16 value. >> Stefan? Can you tell us what the reason is? >> > rom_address a 16bit value? Which part of the code? Sorry I lost you. > > Are you talking about IO accesses which have a 16bit address space? I was talking about ./superio/winbond/w83627hf/superio.c:init_hwm() where Ron assumed that base was a pointer, however init_hwm defines it as u16. Which is somewhat interesting because w83627hf_init() calls init_hwm(res0->base + HWM_INDEX_PORT) where res0->base is resource_t aka u64. That means we have an implicit truncation from u64 to u16. Is that intentional? >> The second example is more correct, but we still face a problem: >> resource_t is u64 and as long as we don't use long mode, %p will expect >> 32bit values. However, almost everything being a resource_t (base, size, >> limit) is essentially a pointer of a pointerdiff. Now how do we handle that? > > Which second example? Reading that text again, it seems I was totally unclear. ./device/pci_rom.c:pci_rom_probe(): printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev), rom_address); I was wondering whether rom_address (which is essentially a pointer) should be resource_t. Also, how should we printk anything that's resource_t? Everything with type resource_t is essentially a pointer. %p won't work unless we compile for 64bit. Maybe introduce %P or some other ugly hack. >> And while we're at correct typing, shouldn't arch/x86/linuxbios_table.c >> use resource_t in most places where it uses u64? >> >> > Interesting idea. You might be correct. resource_t should be a u64 in > fact. It might be something different due to alignment requirements of > the pci structures It is typedef'ed to u64, so there aren't any differences. But when we use resource_t instead of u64, we still have the freedom to define it to u32 for some architectures. >> I have a lot of open questions: >> * How do we handle accesses to resources above 4 GB when we confine >> ourselves to 32bit code? >> > We don't confine ourselfes. There's PAE Which we don't want to handle in LB. >> * How do 32bit operating systems handle resources above 4 GB? Should we >> just avoid locating resources up there? Only do it if unavoidable? >> Consider a machine with 4 GB of RAM and a graphics card with 512 MB. >> That combination can be bought today. Now what will happen if video RAM >> grows to 4 GB? Can we boot such a machine in 32bit mode at all? Should >> we show a warning? Refuse to boot any non-64bit OS? > > 32bit OSes can not handle system resources above 4GB except with tricks > (PAE). That is why 32bit OSes are dying out and are not being used > anymore in environments where resources above 4GB happen. The interesting question is whether we can set up resources in a way that allows 32bit OSes to boot, e.g. by "moving" RAM to above 4G and making it inaccessible that way. > If you run a 32bit OS on a machine with 4G of RAM you simply can not be > helped. Linux starts having severe performance problems in 32bit mode > when you cross the 1G border. Which basically every machine does today, > except lowend hobbyist stuff and embedded systems. Yes, but we should allow it to boot if this is technically possible. >> * Should we have some preference setting which controls 64bit resource >> allocation? > > We do have a CONFIG variable for that, and it packs resources into 32bit > per default. This default will change at some point because a 3G PCI > hole in 4G space makes only little sense. This is done on some machines > so that _in theory_ you _could_ run a 32bit OS. There is not such CONFIG variable in v3. >> * Is there any point trying to handle 64bit resources on 32bit machines? >> > Not that I would know of. PCI resources can prefer to go to 64bit space, > but on a 32bit machine that means you poke them out of visibility. OK. >> * Do we have to compile 64bit code for 64bit machines? >> >> > No. Thanks to PAE we can access address space above 4G too. But in fact Ugly. > we want to go 64bit mode. > The really broken thing with x86_64's long mode is that it does not work > without paging enabled. That makes the effort to use it in the bios > harder than the gain. Seems we are caught between a rock and a hard place. PAE is ugly, long mode is difficult. > For an OS and other high level applications like that things are > different though. Yes. Regards, Carl-Daniel From peter at stuge.se Tue Aug 21 02:44:56 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Aug 2007 02:44:56 +0200 Subject: [LinuxBIOS] [PATCH][RFC] PCBIOS legacy tables In-Reply-To: References: Message-ID: <20070821004456.18368.qmail@stuge.se> On Mon, Aug 20, 2007 at 08:29:16PM +0200, Patrick Georgi wrote: > + *(u32*)(0x400)=TTYSx_BASE; It's actually an u16 per port. I don't like where this is going. I don't want LB to be BIOS-compatible, I think that would be a regression. What happened with the lbtable and the device tree? //Peter From joe at smittys.pointclark.net Tue Aug 21 03:07:58 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Mon, 20 Aug 2007 21:07:58 -0400 Subject: [LinuxBIOS] Problems with Intel vga working In-Reply-To: <20070820113443.21555.qmail@stuge.se> References: <20070820022755.lvgcz2sx7okk0skk@www.smittys.pointclark.net> <20070820113443.21555.qmail@stuge.se> Message-ID: <20070820210758.2qh3j9tfqwwg4wgc@www.smittys.pointclark.net> Quoting Peter Stuge : > On Mon, Aug 20, 2007 at 02:27:55AM -0400, Joseph Smith wrote: >> Is there anyway to debug this to find out what is happening? > > Is there any indication of what the problem is in the boot messages? > > Have you tried using both vm86 and x86emu? > > > //Peter > No, I have the debugging level on 9 and it boots just fine, no errors but only on console. I have not used vm86 or x86emu, I am using a live system, does that make a diference? Thanks - Joe Thanks - Joe From angelini at ngames.com.br Tue Aug 21 03:10:02 2007 From: angelini at ngames.com.br (angelini) Date: Mon, 20 Aug 2007 22:10:02 -0300 Subject: [LinuxBIOS] GEODE GX2 BIOS CHANGES In-Reply-To: <20070821004456.18368.qmail@stuge.se> References: <20070821004456.18368.qmail@stuge.se> Message-ID: <000001c7e390$01929d50$0c01a8c0@druid> Dear friends, I have one GEODE GX533 at 1W mother thats i need some help to change memory sharing with on board video card. Please is possible do this ? Today in bios share 8mb with video card, and we need share 64mb or 32 mb of ram memory, I try per many times talk with AMD, and no success :( . Angelini From Marc.Jones at amd.com Tue Aug 21 07:19:13 2007 From: Marc.Jones at amd.com (Marc Jones) Date: Mon, 20 Aug 2007 23:19:13 -0600 Subject: [LinuxBIOS] GEODE GX2 BIOS CHANGES In-Reply-To: <000001c7e390$01929d50$0c01a8c0@druid> References: <20070821004456.18368.qmail@stuge.se> <000001c7e390$01929d50$0c01a8c0@druid> Message-ID: <46CA75D1.8020701@AMD.com> angelini wrote: > Dear friends, > > I have one GEODE GX533 at 1W mother thats i need some help to change > memory sharing with on board video card. > > Please is possible do this ? > Today in bios share 8mb with video card, and we need share 64mb or 32 mb of > ram memory, I try per many times talk with AMD, and no success :( . > > Angelini > > > What BIOS are you using? It should be a BIOS setting. Please be more descriptive about your failure. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From stepan at coresystems.de Tue Aug 21 10:10:51 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 21 Aug 2007 10:10:51 +0200 Subject: [LinuxBIOS] [PATCH][RFC] PCBIOS legacy tables In-Reply-To: <20070821004456.18368.qmail@stuge.se> References: <20070821004456.18368.qmail@stuge.se> Message-ID: <20070821081050.GA7663@coresystems.de> * Peter Stuge [070821 02:44]: > On Mon, Aug 20, 2007 at 08:29:16PM +0200, Patrick Georgi wrote: > > + *(u32*)(0x400)=TTYSx_BASE; > > It's actually an u16 per port. Hah. you gotta love little endian :-) > I don't like where this is going. > I agree that this needs to be done a little more generic, and we want to capsulate it in a seperate function. > I don't want LB to be BIOS-compatible, I think that would be a > regression. This is not BIOS compatibility. It is broken OS compatibility. In the specific grub2 case we could possibly fix this in the grub code though, term/i386/pc/serial.c: serial_hw_get_port (const unsigned short unit) might indeed read the lbtable rather than 0x400 in case it is running on LinuxBIOS. 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From joe at smittys.pointclark.net Tue Aug 21 10:34:19 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 21 Aug 2007 04:34:19 -0400 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> References: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> Message-ID: <20070821043419.352fg7540goko0cw@www.smittys.pointclark.net> >> Joe, >> There is an example of an spd array in >> mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You >> will have to generate the correct SPD values for your memory. >> >> >> Marc Cool!! So let me get this straight. The function spd_read_byte() in cache_as_ram_auto.c is re-defining the spd_read_byte() function from src/southbridge/amd/cs5536/cs5536_early_smbus.c correct? And it is saying that if the device is DIMM0 (0xA0) to read from the array? So what if it is DIMM1 (0xA2)? Does it use the normal spd_read_byte() from cs5536_early_smbus.c? Thanks - Joe From darmawan.salihun at gmail.com Tue Aug 21 11:32:28 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 21 Aug 2007 16:32:28 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <20070515101126.GA29326@skynet.be> References: <20070515101126.GA29326@skynet.be> Message-ID: <46CAB12C.7050102@gmail.com> Hi all, This patch fixes the support for Winbond W39V040FA. I've tested the patch and it successfully read and write the binary (with verification) to the flash chip. The previous code is able to read but cannot write into the chip because the block locking registers (BLR) are not set accordingly. Regards, Darmawan Salihun -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_fix_support_for_w39v040fa.diff Type: text/x-patch Size: 4809 bytes Desc: not available URL: From darmawan.salihun at gmail.com Tue Aug 21 11:33:04 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 21 Aug 2007 16:33:04 +0700 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46C9C8E7.2070106@dls.net> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <46C9ADB1.2080602@gmail.com> <46C9C8E7.2070106@dls.net> Message-ID: <46CAB150.80008@gmail.com> Roman Kononov wrote: > On 08/20/2007 10:05 AM, Darmawan Salihun wrote: >> According to the official documentation, DPC is running at >> IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because >> only one DPC object of one "type" can exist in the system at one >> instance. > > What do you mean by "type"? DPC objects that has the same "Deferred Routine" > If you have N CPUs: > > Initialization: > KeInitializeDpc() initializes N DPC objects, each object has the same > "DeferredRoutine". > KeSetTargetProcessorDpc() ties each DPC object with a CPU. > I might have made a wrong assumption previously. I thought that a DPC object that has the same "Deferred Routine" won't be queued twice in the system's DPC queue. Nonetheless, this might not be the case for multiprocessor machine because every processor has its own DPC queue which implies that DPC objects with the same "Deferred Routine" can be queued in different processor's DPC queue without anyone of them being rejected. In single processor machine, a DPC object with the same "Deferred Routine" cannot be queued twice because the second request to queue the DPC will be rejected by the kernel. > PCI Configuration Sequence: > IRQL is raised to DISPATCH_LEVEL. > KeGetCurrentProcessorNumber() tells which CPU it is. > KeInsertQueueDpc() schedules the N-1 DPCs to run. All but this CPU are > scheduled. > Spin waiting for the DeferredRoutines to enter phase A. > IRQL is raised to HIGH_LEVEL. > The DeferredRoutins are flagged to enter phase B. > Spin waiting for the DeferredRoutines to enter phase B. > Do the 3f8/3fc business. OK, this is parallel port, right? Mine would be CF8/CFC > The DeferredRoutins are flagged to finish. > Restore the IRQL. > > DeferredRoutine: > Indicate that the phase is phase A. > Spin waiting for being flagged to enter phase B. > Raise IRQL to HICH_LEVEL. > Indicate that the phase is phase B. > Spin waiting for being flagged to finish. > Restore the IRQL. > > This means we need to provide different DPC object "type" for >> different processor in multiprocessor environment to ensure "atomic" >> execution of the I/O code which seems to be an overkill and make the >> system too much loaded. > > What is "too much"? I implied that every DPC objects are being allocated from the kernel non-paged pool memory which can degrade system performance if we are overusing it. But, this might not be the case. > I found this when trying to code the "DPC >> approach" in my latest device driver. Perhaps, using a kernel mode >> spinlock is a better approach. To ensure an atomic execution of the I/O >> operation. > > A spin lock does not help. A CPU, which has acquired a spin lock, does > not prevent another CPU to mess with the cf8/cfc registers. You need to > lock all other CPUs. Yes, locking all of the CPU in a spinlock is what I'm thinking about. But, there possibly other alternative. > Seems to be the DPC approach is not the right solution for >> this type of problem. > > You are the man, you make the decision. > OK, thanks. Regards, Darmawan Salihun From peter at stuge.se Tue Aug 21 14:31:24 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Aug 2007 14:31:24 +0200 Subject: [LinuxBIOS] Problems with Intel vga working In-Reply-To: <20070820210758.2qh3j9tfqwwg4wgc@www.smittys.pointclark.net> References: <20070820022755.lvgcz2sx7okk0skk@www.smittys.pointclark.net> <20070820113443.21555.qmail@stuge.se> <20070820210758.2qh3j9tfqwwg4wgc@www.smittys.pointclark.net> Message-ID: <20070821123124.10175.qmail@stuge.se> On Mon, Aug 20, 2007 at 09:07:58PM -0400, Joseph Smith wrote: > > On Mon, Aug 20, 2007 at 02:27:55AM -0400, Joseph Smith wrote: > >> Is there anyway to debug this to find out what is happening? > > > > Is there any indication of what the problem is in the boot messages? > > No, I have the debugging level on 9 and it boots just fine, no > errors but only on console. Could you send the full messages to the list? > > Have you tried using both vm86 and x86emu? > > I have not used vm86 or x86emu, I am using a live system, does that > make a diference? The VGA BIOS is always executed by LB using either x86emu or vm86, never directly on hardware. Which one works best differs from one VGA BIOS to another, so it's always a good idea to try both. I'm not sure exactly how you switch. You may have to copy a bit of code around. //Peter From peter at stuge.se Tue Aug 21 14:37:31 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Aug 2007 14:37:31 +0200 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46CAB12C.7050102@gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> Message-ID: <20070821123731.11263.qmail@stuge.se> On Tue, Aug 21, 2007 at 04:32:28PM +0700, Darmawan Salihun wrote: > This patch fixes the support for Winbond W39V040FA. Great! Please add the chip as supported to all relevant documentation files and add your sign-off according to the development guidelines on the wiki, so we can commit. Thanks! //Peter From ward at gnu.org Tue Aug 21 14:51:16 2007 From: ward at gnu.org (Ward Vandewege) Date: Tue, 21 Aug 2007 08:51:16 -0400 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46CAB12C.7050102@gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> Message-ID: <20070821125116.GA6811@countzero.vandewege.net> On Tue, Aug 21, 2007 at 04:32:28PM +0700, Darmawan Salihun wrote: > + * w39v040fa.c: driver for Winbond W39V040FAx flash models. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The FSF has not been at this address for a *very* long time. The current address is 51 Franklin St, 5th floor, Boston, MA 02110, USA. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From darmawan.salihun at gmail.com Tue Aug 21 15:09:23 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 21 Aug 2007 20:09:23 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46893e740708210608p5e64baf0h481f84d31fc9077e@mail.gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821125116.GA6811@countzero.vandewege.net> <46893e740708210608p5e64baf0h481f84d31fc9077e@mail.gmail.com> Message-ID: <46893e740708210609tf3ec274q9361accbf8a7732f@mail.gmail.com> ---------- Forwarded message ---------- From: Darmawan Salihun Date: Aug 21, 2007 8:08 PM Subject: Re: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA To: Ward Vandewege On 8/21/07, Ward Vandewege wrote: > > On Tue, Aug 21, 2007 at 04:32:28PM +0700, Darmawan Salihun wrote: > > + * w39v040fa.c: driver for Winbond W39V040FAx flash models. > > + * > > + * This program is free software; you can redistribute it and/or > modify > > + * it under the terms of the GNU General Public License as published > by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > > The FSF has not been at this address for a *very* long time. The current > address is 51 Franklin St, 5th floor, Boston, MA 02110, USA. > > Thanks, > Ward. > > -- > Ward Vandewege > Free Software Foundation - Senior System Administrator > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > OK, I'll do that. Thanks for the pointers ;-). Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -- Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From darmawan.salihun at gmail.com Tue Aug 21 16:07:13 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Tue, 21 Aug 2007 21:07:13 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <20070821123731.11263.qmail@stuge.se> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> Message-ID: <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> Hi, All things set. See patch. Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_fix_support_for_w39v040fa.diff Type: application/octet-stream Size: 5197 bytes Desc: not available URL: From stepan at coresystems.de Tue Aug 21 17:01:32 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 21 Aug 2007 17:01:32 +0200 Subject: [LinuxBIOS] 64bit issues was: [PATCH] LBv3: fix printk format warnings In-Reply-To: <46C9FE88.7000303@gmx.net> References: <46BB9EC0.8080806@gmx.net> <13426df10708100931u401d8836ib99e72d4b814c51a@mail.gmail.com> <46BFCA4D.90304@gmx.net> <46C326BA.3000603@coresystems.de> <46C9FE88.7000303@gmx.net> Message-ID: <20070821150132.GA32020@coresystems.de> * Carl-Daniel Hailfinger [070820 22:50]: > I was talking about ./superio/winbond/w83627hf/superio.c:init_hwm() > where Ron assumed that base was a pointer, however init_hwm defines it > as u16. Which is somewhat interesting because w83627hf_init() calls > init_hwm(res0->base + HWM_INDEX_PORT) where res0->base is resource_t aka > u64. That means we have an implicit truncation from u64 to u16. Is that > intentional? Hm this looks like a shortcoming of our device model. The superio base address is 0x2e or 0x4e > ./device/pci_rom.c:pci_rom_probe(): > printk(BIOS_DEBUG, "ROM address for %s = %lx\n", dev_path(dev), > rom_address); > > I was wondering whether rom_address (which is essentially a pointer) > should be resource_t. In the current PCI standard the rom address is always a 32bit value. In theory ROMs might be mapped above 4G in future standards. It's nothing we need to handle too soon though in that scope. (ie. when that happens we are probably not going to have x86 pcbios option roms anymore) > Also, how should we printk anything that's resource_t? Everything with > type resource_t is essentially a pointer. %p won't work unless we > compile for 64bit. Maybe introduce %P or some other ugly hack. Hm. probably %P is a good idea. or %lp to stay consistent? > > We don't confine ourselfes. There's PAE > > Which we don't want to handle in LB. We already do. > > 32bit OSes can not handle system resources above 4GB except with tricks > > (PAE). That is why 32bit OSes are dying out and are not being used > > anymore in environments where resources above 4GB happen. > > The interesting question is whether we can set up resources in a way > that allows 32bit OSes to boot, e.g. by "moving" RAM to above 4G and > making it inaccessible that way. That's what happens in the default configuration if you dont set CONFIG_PCI_64BIT_PREF_MEM to 1. > > If you run a 32bit OS on a machine with 4G of RAM you simply can not be > > helped. Linux starts having severe performance problems in 32bit mode > > when you cross the 1G border. Which basically every machine does today, > > except lowend hobbyist stuff and embedded systems. > > Yes, but we should allow it to boot if this is technically possible. It is allowed and possible. > > we want to go 64bit mode. > > The really broken thing with x86_64's long mode is that it does not work > > without paging enabled. That makes the effort to use it in the bios > > harder than the gain. > > Seems we are caught between a rock and a hard place. PAE is ugly, long > mode is difficult. Not only difficult, it is impossible for most of our code. For long mode you need paging. For paging you need page tables. These need to be in RAM. RAM is not initialized yet. It might not be a problem when switching to long mode before entering stage2. That would disallow our calls into stage0/1 functions that we currently do. Might be a low price to pay. Then there's the next question: What do we do with OSes and payloads that have no 64bit entry point? Go back to 32bit mode? 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 kononov at dls.net Tue Aug 21 17:21:16 2007 From: kononov at dls.net (Roman Kononov) Date: Tue, 21 Aug 2007 10:21:16 -0500 Subject: [LinuxBIOS] Winflashrom -- Current Status In-Reply-To: <46CAB150.80008@gmail.com> References: <20070713105219.GA30746@coresystems.de> <46A57BEB.7080205@gmail.com> <20070725091224.GA16393@coresystems.de> <20070727172637.GA30602@coresystems.de> <46ADE4C0.4060809@gmail.com> <46ADF604.5070005@dls.net> <46BC1CFA.4060308@gmail.com> <20070810101624.25036.qmail@stuge.se> <46BC6A5A.6080609@dls.net> <46C162D5.7020302@gmail.com> <20070814125606.8319.qmail@stuge.se> <46C1E2EE.9000807@dls.net> <46C9ADB1.2080602@gmail.com> <46C9C8E7.2070106@dls.net> <46CAB150.80008@gmail.com> Message-ID: <46CB02EC.3010104@dls.net> Darmawan Salihun wrote: > I might have made a wrong assumption previously. I thought that a DPC > object that has the same "Deferred Routine" won't be queued twice in the > system's DPC queue. Nonetheless, this might not be the case for > multiprocessor machine because every processor has its own DPC queue > which implies that DPC objects with the same "Deferred Routine" can be > queued in different processor's DPC queue without anyone of them being > rejected. In single processor machine, a DPC object with the same > "Deferred Routine" cannot be queued twice because the second request to > queue the DPC will be rejected by the kernel. I think that you can initialize multiple DPC objects with the same routine and enqueue them all. It is a single DPC object which cannot be enqueued many times. Regards, Roman From marc.jones at amd.com Tue Aug 21 17:48:06 2007 From: marc.jones at amd.com (Marc Jones) Date: Tue, 21 Aug 2007 09:48:06 -0600 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <20070821043419.352fg7540goko0cw@www.smittys.pointclark.net> References: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> <20070821043419.352fg7540goko0cw@www.smittys.pointclark.net> Message-ID: <46CB0936.4000900@amd.com> Joseph Smith wrote: >>> Joe, >>> There is an example of an spd array in >>> mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You >>> will have to generate the correct SPD values for your memory. >>> >>> >>> Marc > > Cool!! So let me get this straight. The function spd_read_byte() in > cache_as_ram_auto.c is re-defining the spd_read_byte() function from > src/southbridge/amd/cs5536/cs5536_early_smbus.c correct? > And it is saying that if the device is DIMM0 (0xA0) to read from the array? > So what if it is DIMM1 (0xA2)? Does it use the normal spd_read_byte() > from cs5536_early_smbus.c? > > Thanks - Joe > No, If it is 0xA2 it returns 0xFF as if the spd is not there. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From darmawan.salihun at gmail.com Tue Aug 21 19:24:38 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 22 Aug 2007 00:24:38 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> Message-ID: <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> Hi, I forgot to include the my copyright for the added file previously. Fixed. See patch Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_fix_w39v040fa_support.diff Type: application/octet-stream Size: 5273 bytes Desc: not available URL: From stepan at coresystems.de Tue Aug 21 20:05:59 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Tue, 21 Aug 2007 20:05:59 +0200 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> Message-ID: <46CB2987.8020403@coresystems.de> Darmawan Salihun wrote: > Hi, > I forgot to include the my copyright for the added file previously. > Fixed. See patch > > > Regards, > > Darmawan Salihun > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- Is there a reason you use your own mmap instead of using the already mmapped area in flashrom.c:int map_flash_registers(struct flashchip *flash) ? -- 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/ Registergericht: Amtsgericht Freiburg ? HRB 7656 Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866 From joe at smittys.pointclark.net Tue Aug 21 20:27:22 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Tue, 21 Aug 2007 14:27:22 -0400 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <46CB0936.4000900@amd.com> References: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> <20070821043419.352fg7540goko0cw@www.smittys.pointclark.net> <46CB0936.4000900@amd.com> Message-ID: <20070821142722.wj62kwjjy84ooc0w@www.smittys.pointclark.net> Quoting Marc Jones : > > > Joseph Smith wrote: >>>> Joe, >>>> There is an example of an spd array in >>>> mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You >>>> will have to generate the correct SPD values for your memory. >>>> >>>> >>>> Marc >> >> Cool!! So let me get this straight. The function spd_read_byte() in >> cache_as_ram_auto.c is re-defining the spd_read_byte() function >> from src/southbridge/amd/cs5536/cs5536_early_smbus.c correct? >> And it is saying that if the device is DIMM0 (0xA0) to read from the array? >> So what if it is DIMM1 (0xA2)? Does it use the normal >> spd_read_byte() from cs5536_early_smbus.c? >> >> Thanks - Joe >> > No, If it is 0xA2 it returns 0xFF as if the spd is not there. > Marc > Oh, then I would have to switch it up a bit. This should work ok right? --------------------- static int spd_read_byte(unsigned device, unsigned address) { int i; if (device == 0x50){ return do_smbus_read_byte(device, address); } else if (device == 0x51){ for (i=0; i < (sizeof spd_table/sizeof spd_table[0]); i++){ if (spd_table[i].address == address){ return spd_table[i].data; } } } else { return 0xFF; /* returns 0xFF on any failures */ } } --------------------- Thanks - Joe From marc.jones at amd.com Tue Aug 21 21:08:27 2007 From: marc.jones at amd.com (Marc Jones) Date: Tue, 21 Aug 2007 13:08:27 -0600 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <20070821142722.wj62kwjjy84ooc0w@www.smittys.pointclark.net> References: <20070820150958.cew6vbg3s4wkk8c0@www.smittys.pointclark.net> <20070821043419.352fg7540goko0cw@www.smittys.pointclark.net> <46CB0936.4000900@amd.com> <20070821142722.wj62kwjjy84ooc0w@www.smittys.pointclark.net> Message-ID: <46CB382B.4090402@amd.com> Joseph Smith wrote: > Quoting Marc Jones : > >> >> >> Joseph Smith wrote: >>>>> Joe, >>>>> There is an example of an spd array in >>>>> mainboard/artecgroup/dbe61/cache_as_ram_auto.c spd_read_byte(). You >>>>> will have to generate the correct SPD values for your memory. >>>>> >>>>> >>>>> Marc >>> >>> Cool!! So let me get this straight. The function spd_read_byte() in >>> cache_as_ram_auto.c is re-defining the spd_read_byte() function >>> from src/southbridge/amd/cs5536/cs5536_early_smbus.c correct? >>> And it is saying that if the device is DIMM0 (0xA0) to read from the >>> array? >>> So what if it is DIMM1 (0xA2)? Does it use the normal >>> spd_read_byte() from cs5536_early_smbus.c? >>> >>> Thanks - Joe >>> >> No, If it is 0xA2 it returns 0xFF as if the spd is not there. >> Marc >> > Oh, then I would have to switch it up a bit. This should work ok right? > --------------------- > static int spd_read_byte(unsigned device, unsigned address) > { > int i; > > if (device == 0x50){ > return do_smbus_read_byte(device, address); > } else if (device == 0x51){ > for (i=0; i < (sizeof spd_table/sizeof spd_table[0]); i++){ > if (spd_table[i].address == address){ > return spd_table[i].data; > } > } > } else { > return 0xFF; /* returns 0xFF on any failures */ > } > } > --------------------- > > Thanks - Joe > > That looks like it should do what you want. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:Marc.Jones at amd.com http://www.amd.com/embeddedprocessors From myles at pel.cs.byu.edu Tue Aug 21 21:18:13 2007 From: myles at pel.cs.byu.edu (Myles Watson) Date: Tue, 21 Aug 2007 13:18:13 -0600 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte Message-ID: <00cc01c7e428$04e99470$4d22040a@chimp> > > Oh, then I would have to switch it up a bit. This should work ok right? > > --------------------- > > static int spd_read_byte(unsigned device, unsigned address) > > { > > int i; > > > > if (device == 0x50){ > > return do_smbus_read_byte(device, address); > > } else if (device == 0x51){ > > for (i=0; i < (sizeof spd_table/sizeof spd_table[0]); i++){ > > if (spd_table[i].address == address){ > > return spd_table[i].data; > > } > > } return 0xFF; /* This line returns 0xFF when address not found */ > > } else { > > return 0xFF; /* returns 0xFF on any failures */ > > } > > } I think it's a good idea to have a return in every control path. Myles From uwe at hermann-uwe.de Tue Aug 21 21:19:40 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Tue, 21 Aug 2007 21:19:40 +0200 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> Message-ID: <20070821191940.GA24806@greenwood> On Wed, Aug 22, 2007 at 12:24:38AM +0700, Darmawan Salihun wrote: > I forgot to include the my copyright for the added file previously. > Fixed. See patch Does this lock/unlock also apply to other Winbond chips? The rest of the code looks pretty much the same as for other chips, maybe it lock/unlock functions can be merged into one of the ?xisting files? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nico.inc at gmail.com Tue Aug 21 21:30:35 2007 From: nico.inc at gmail.com (nico) Date: Tue, 21 Aug 2007 21:30:35 +0200 Subject: [LinuxBIOS] AM2 socket based Tyan motherboards Message-ID: Hi everyone, I'm completely fed up with the crappy BIOS and I'm considering buying a whole new desktop computer. Do you know if linuxbios will have a full support for the new "Tomcat n3400B" from Tyan (I know that the Opteron based mobos have a good support) ? thanks a lot, nico -- |_|0|_| |_|_|0| Nicolas HUOT |0|0|0| From peter at stuge.se Tue Aug 21 23:23:39 2007 From: peter at stuge.se (Peter Stuge) Date: Tue, 21 Aug 2007 23:23:39 +0200 Subject: [LinuxBIOS] AM2 socket based Tyan motherboards In-Reply-To: References: Message-ID: <20070821212339.25286.qmail@stuge.se> Hi Nico, On Tue, Aug 21, 2007 at 09:30:35PM +0200, nico wrote: > Do you know if linuxbios will have a full support for the new > "Tomcat n3400B" from Tyan It doesn't right now, and I noone has mentioned it before AFAIK. Maybe you are interested in porting LB to it? > (I know that the Opteron based mobos have a good support) ? There's all the other stuff on the mobo too that needs good support. Not all southbridges work equally well for one. Do you know what, exactly, is on that board? lspci -v would be good. //Peter From nico.inc at gmail.com Wed Aug 22 01:20:55 2007 From: nico.inc at gmail.com (nico) Date: Wed, 22 Aug 2007 01:20:55 +0200 Subject: [LinuxBIOS] AM2 socket based Tyan motherboards In-Reply-To: <20070821212339.25286.qmail@stuge.se> References: <20070821212339.25286.qmail@stuge.se> Message-ID: I was about to go for the S2925A2NRF. there is a NVIDIA nForce Professional 3400 chipset in it where are we regarding to that chipset support ? It should be supported by the mcp55 generic arch if my understanding of the nvidia product line is correct... (sorry I had no time to look deeply into the source code...) I was looking for a winter project.... helping out with the port to this mobo might do the job :) I had no exposure to the linux bios project before, but I played with u-boot (embedded bootloader project) lately, it will be helpfull I hope. I'll start with my old ASUS A7V8X-MX SE and see what linuxbios can do with it... nico On 8/21/07, Peter Stuge wrote: > Hi Nico, > > On Tue, Aug 21, 2007 at 09:30:35PM +0200, nico wrote: > > Do you know if linuxbios will have a full support for the new > > "Tomcat n3400B" from Tyan > > It doesn't right now, and I noone has mentioned it before AFAIK. > Maybe you are interested in porting LB to it? > > > > (I know that the Opteron based mobos have a good support) ? > > There's all the other stuff on the mobo too that needs good support. > Not all southbridges work equally well for one. Do you know what, > exactly, is on that board? lspci -v would be good. > > > //Peter > > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios > -- |_|0|_| |_|_|0| Nicolas HUOT |0|0|0| From darmawan.salihun at gmail.com Wed Aug 22 03:21:30 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 22 Aug 2007 08:21:30 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46CB2987.8020403@coresystems.de> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> <46CB2987.8020403@coresystems.de> Message-ID: <46893e740708211821x18894727w5099806089b31120@mail.gmail.com> On 8/22/07, Stefan Reinauer wrote: > > Is there a reason you use your own mmap instead of using the already > mmapped area in flashrom.c:int map_flash_registers(struct flashchip > *flash) > ? > Yes, the BLRs are located in areas not covered by mmap in int map_flash_registers(struct flashchip *flash). Anyway, there's a possibility that I misunderstood map_flash_registers() though. I'm going to recheck it tonight. Last time I check it, the BLRs areas are not covered. Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From darmawan.salihun at gmail.com Wed Aug 22 03:26:01 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Wed, 22 Aug 2007 08:26:01 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <20070821191940.GA24806@greenwood> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> <20070821191940.GA24806@greenwood> Message-ID: <46893e740708211826n23e269cev1580ff60f079ef04@mail.gmail.com> On 8/22/07, Uwe Hermann wrote: > > On Wed, Aug 22, 2007 at 12:24:38AM +0700, Darmawan Salihun wrote: > > I forgot to include the my copyright for the added file previously. > > Fixed. See patch > > Does this lock/unlock also apply to other Winbond chips? The rest of the > code looks pretty much the same as for other chips, maybe it lock/unlock > functions can be merged into one of the ?xisting files? > > This chip is an Firmware Hub (FWH) chip. I don't see the code applies to other Winbond chip that's not an FWH. As for merging the lock/unlock function, I will need to read other winbond chip to see if there's a possibility for that. Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at georgi-clan.de Wed Aug 22 14:57:15 2007 From: patrick at georgi-clan.de (Patrick Georgi) Date: Wed, 22 Aug 2007 14:57:15 +0200 Subject: [LinuxBIOS] [PATCH][v3] small lar fix Message-ID: Hi, the checksum creation in lar starts somewhere in the lar image, and ends at the end of a temporary buffer, which doesn't look right to me (and segfaults if between those two there's an unmapped region, as happened here) Attached patch should fix that, but I'd like to have someone look over it to make sure it checksums the right area. Regards, Patrick Georgi -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-20070822-1-lbv3-lar-iteration-fix Type: text/x-diff Size: 666 bytes Desc: not available URL: From lemenkov at gmail.com Wed Aug 22 15:43:35 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 22 Aug 2007 17:43:35 +0400 Subject: [LinuxBIOS] a little amount of statisics of mainboards used by linux users. Message-ID: Hello All! Maybe somebody already knows about smolt project? http://smolt.fedoraproject.org/ https://hosted.fedoraproject.org/projects/smolt/ It's Fedora Project's aim to provide automatic statistics gathering of hardware on which Linux is installed. Thus far its installed by default on Fedora-family of Linux distros and nothing prevents other distros from including this handy tool (its already been tested in SuSE). From c-d.hailfinger.devel.2006 at gmx.net Wed Aug 22 19:14:09 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Wed, 22 Aug 2007 19:14:09 +0200 Subject: [LinuxBIOS] [PATCH] [notready] my current v3 diff Message-ID: <46CC6EE1.7060808@gmx.net> Hi, attached (because of whitespace issues, same content as quoted text inline) is my current diff to upstream sources. Some cosmetic stuff, some comments to self, maybe even downright senseless changes. A short review would be appreciated so I can send real patches. Regards, Carl-Daniel > Index: include/device/device.h > =================================================================== > --- include/device/device.h (Revision 476) > +++ include/device/device.h (Arbeitskopie) > @@ -202,7 +202,7 @@ > struct resource resource[MAX_RESOURCES]; > unsigned int resources; > > - /* link are (down sream) buses attached to the device, usually a leaf > + /* link are (downstream) buses attached to the device, usually a leaf > * device with no children have 0 buses attached and a bridge has 1 bus > */ > struct bus link[MAX_LINKS]; > Index: mainboard/adl/msm800sev/stage1.c > =================================================================== > --- mainboard/adl/msm800sev/stage1.c (Revision 476) > +++ mainboard/adl/msm800sev/stage1.c (Arbeitskopie) > @@ -33,7 +33,9 @@ > #include > #include > > +/* This is wrong! SERIAL_DEV can't be >=0x10 because it's a PNP device number */ > #define SERIAL_DEV 0x30 > +#define SERIAL_IOBASE 0x3f8 > > void hardware_stage1(void) > { > @@ -49,6 +51,6 @@ > * for cs5536 > */ > cs5536_disable_internal_uart(); > - w83627hf_enable_serial(0x2e, 0x30, 0x3f8); > + w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); > printk(BIOS_DEBUG, "Done %s\n", __FUNCTION__); > } > Index: device/device.c > =================================================================== > --- device/device.c (Revision 476) > +++ device/device.c (Arbeitskopie) > @@ -260,8 +260,10 @@ > for (curdev = bus->children; curdev; curdev = curdev->sibling) { > unsigned int links; > int i; > - printk(BIOS_SPEW, "%s: %s(%s) have_resources %d enabled %d\n", > + printk(BIOS_SPEW, > + "%s: %s(%s) dtsname %s have_resources %d enabled %d\n", > __func__, bus->dev->dtsname, dev_path(bus->dev), > + curdev->dtsname, > curdev->have_resources, curdev->enabled); > if (curdev->have_resources) { > continue; > @@ -402,7 +404,11 @@ > min_align = 0; > base = bridge->base; > > - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); > + printk(BIOS_SPEW, > + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d\n", > + dev_path(bus->dev), > + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", > + base, bridge->size, bridge->align, bridge->gran); > > /* We want different minimum alignments for different kinds of > * resources. These minimums are not device type specific but > @@ -485,7 +491,7 @@ > base += size; > > printk(BIOS_SPEW, > - "%s %02lx * [0x%08Lx - 0x%08Lx] %s\n", > + "%s %02lx * [0x%08llx - 0x%08llx] %s\n", > dev_path(dev), > resource->index, > resource->base, > @@ -503,7 +509,11 @@ > */ > bridge->size = align_up(base, bridge->gran) - bridge->base; > > - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d done\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); > + printk(BIOS_SPEW, > + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d done\n", > + dev_path(bus->dev), > + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", > + base, bridge->size, bridge->align, bridge->gran); > } > > #if defined(CONFIG_PCI_OPTION_ROM_RUN) && CONFIG_PCI_OPTION_ROM_RUN == 1 > Index: device/pnp_device.c > =================================================================== > --- device/pnp_device.c (Revision 476) > +++ device/pnp_device.c (Arbeitskopie) > @@ -87,7 +87,7 @@ > { > if (!(resource->flags & IORESOURCE_ASSIGNED)) { > printk(BIOS_ERR, > - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", > + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", > dev_path(dev), resource->index, resource_type(resource), > resource->size); > return; > Index: device/pci_device.c > =================================================================== > --- device/pci_device.c (Revision 476) > +++ device/pci_device.c (Arbeitskopie) > @@ -252,10 +252,10 @@ > printk(BIOS_DEBUG, "%s %02x ->", > dev_path(dev), resource->index); > printk(BIOS_DEBUG, > - " value: 0x%08Lx zeroes: 0x%08Lx ones: 0x%08Lx attr: %08lx\n", > + " value: 0x%08llx zeroes: 0x%08llx ones: 0x%08llx attr: %08lx\n", > value, zeroes, ones, attr); > printk(BIOS_DEBUG, > - "%s %02x -> size: 0x%08Lx max: 0x%08Lx %s\n ", > + "%s %02x -> size: 0x%08llx max: 0x%08llx %s\n ", > dev_path(dev), resource->index, resource->size, > resource->limit, resource_type(resource)); > } > @@ -456,7 +456,7 @@ > /* Make certain the resource has actually been set. */ > if (!(resource->flags & IORESOURCE_ASSIGNED)) { > printk(BIOS_ERR, > - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", > + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", > dev_path(dev), resource->index, resource_type(resource), > resource->size); > return; > @@ -863,7 +863,7 @@ > (*list)->path.type); > continue; > } > - printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%x\n", > + printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%02x\n", > __func__, (*list)->dtsname, (*list)->path.u.pci.devfn); > if ((*list)->path.u.pci.devfn == devfn) { > /* Unlink from the list. */ > Index: device/device_util.c > =================================================================== > --- device/device_util.c (Revision 476) > +++ device/device_util.c (Arbeitskopie) > @@ -229,7 +229,7 @@ > memcpy(buffer, "Root Device", 12); > break; > case DEVICE_ID_PCI: > - sprintf(buffer, "PCI: %02x:%02x", id->u.pci.vendor, > + sprintf(buffer, "PCI: %04x:%04x", id->u.pci.vendor, > id->u.pci.device); > break; > case DEVICE_ID_PNP: > @@ -243,7 +243,7 @@ > id->u.apic.device); > break; > case DEVICE_ID_PCI_DOMAIN: > - sprintf(buffer, "PCI_DOMAIN: %02x:%02x", > + sprintf(buffer, "PCI_DOMAIN: %04x:%04x", > id->u.pci_domain.vendor, > id->u.pci_domain.device); > break; > @@ -602,7 +602,7 @@ > #endif > } > printk(BIOS_DEBUG, > - "%s %02lx <- [0x%010Lx - 0x%010Lx] %s%s%s\n", > + "%s %02lx <- [0x%010llx - 0x%010llx] %s%s%s\n", > dev_path(dev), > resource->index, > base, end, buf, resource_type(resource), comment); > @@ -656,7 +656,7 @@ > for (i = 0; i < curdev->resources; i++) { > struct resource *resource = &curdev->resource[i]; > printk(BIOS_SPEW, > - "%s: dev %s, resource %d, flags %lx base 0x%Lx size 0x%Lx\n", > + "%s: dev %s, resource %d, flags %lx base 0x%llx size 0x%llx\n", > __func__, curdev->dtsname, i, resource->flags, > resource->base, resource->size); > /* If it isn't the right kind of resource ignore it. */ > Index: lib/stage2.c > =================================================================== > --- lib/stage2.c (Revision 476) > +++ lib/stage2.c (Arbeitskopie) > @@ -31,8 +31,9 @@ > /** > * Main function of the DRAM part of LinuxBIOS. > * > - * LinuxBIOS is divided into pre-DRAM part and DRAM part. The phases before > - * this part are phase 0 and phase 1. This part contains phases x through y. > + * LinuxBIOS is divided into pre-DRAM part and DRAM part. The stages before > + * this part are stage 0 and stage 1. This part contains stage 2, which > + * consists of phases 1 through 6. > * > * Device Enumeration: in the dev_enumerate() phase. > * > @@ -53,6 +54,7 @@ > > post_code(0x20); > > + /* TODO: Explain why we use printk here although it is impossible */ > printk(BIOS_NOTICE, console_test); > > dev_init(); > Index: lib/elfboot.c > =================================================================== > --- lib/elfboot.c (Revision 476) > +++ lib/elfboot.c (Arbeitskopie) > @@ -61,7 +61,7 @@ > } > if (i == mem_entries) { > printk(BIOS_ERR, "No matching RAM area found for range:\n"); > - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx)\n", start, end); > + printk(BIOS_ERR, " [0x%016llx, 0x%016llx)\n", start, end); > printk(BIOS_ERR, "RAM areas\n"); > for(i = 0; i < mem_entries; i++) { > u64 mstart, mend; > @@ -69,7 +69,7 @@ > mtype = mem->map[i].type; > mstart = unpack_lb64(mem->map[i].start); > mend = mstart + unpack_lb64(mem->map[i].size); > - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx) %s\n", > + printk(BIOS_ERR, " [0x%016llx, 0x%016llx) %s\n", > mstart, mend, (mtype == LB_MEM_RAM)?"RAM":"Reserved"); > > } > Index: northbridge/intel/i440bxemulation/i440bx.c > =================================================================== > --- northbridge/intel/i440bxemulation/i440bx.c (Revision 476) > +++ northbridge/intel/i440bxemulation/i440bx.c (Arbeitskopie) > @@ -79,7 +79,7 @@ > resource->size = ((resource_t) sizek) << 10; > resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE | > IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; > - printk(BIOS_DEBUG, "%s: add ram resoource %Ld bytes\n", __func__, > + printk(BIOS_DEBUG, "%s: add ram resource %lld bytes\n", __func__, > resource->size); > } > > Index: arch/x86/linuxbios_table.c > =================================================================== > --- arch/x86/linuxbios_table.c (Revision 476) > +++ arch/x86/linuxbios_table.c (Arbeitskopie) > @@ -177,7 +177,7 @@ > { > int entries; > > - printk(BIOS_DEBUG, "%s: start 0x%Lx size 0x%Lx\n", > + printk(BIOS_DEBUG, "%s: start 0x%llx size 0x%llx\n", > __func__, start, size); > > entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); > Index: arch/x86/pci_ops_mmconf.c > =================================================================== > --- arch/x86/pci_ops_mmconf.c (Revision 476) > +++ arch/x86/pci_ops_mmconf.c (Arbeitskopie) > @@ -18,32 +18,32 @@ > > #include > > -static uint8_t pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) > +static u8 pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) > { > return (read8x(PCI_MMIO_ADDR(bus, devfn, where))); > } > > -static uint16_t pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) > +static u16 pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) > { > return (read16x(PCI_MMIO_ADDR(bus, devfn, where))); > } > > -static uint32_t pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) > +static u32 pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) > { > return (read32x(PCI_MMIO_ADDR(bus, devfn, where))); > } > > -static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, uint8_t value) > +static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, u8 value) > { > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > } > > -static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, uint16_t value) > +static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, u16 value) > { > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > } > > -static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, uint32_t value) > +static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, u32 value) > { > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > } -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios3_RFC_various01.diff URL: From uwe at hermann-uwe.de Thu Aug 23 00:33:17 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 00:33:17 +0200 Subject: [LinuxBIOS] [PATCH] [notready] my current v3 diff In-Reply-To: <46CC6EE1.7060808@gmx.net> References: <46CC6EE1.7060808@gmx.net> Message-ID: <20070822223317.GA17816@greenwood> On Wed, Aug 22, 2007 at 07:14:09PM +0200, Carl-Daniel Hailfinger wrote: > > Index: include/device/device.h > > =================================================================== > > --- include/device/device.h (Revision 476) > > +++ include/device/device.h (Arbeitskopie) > > @@ -202,7 +202,7 @@ > > struct resource resource[MAX_RESOURCES]; > > unsigned int resources; > > > > - /* link are (down sream) buses attached to the device, usually a leaf > > + /* link are (downstream) buses attached to the device, usually a leaf ACK. > > * device with no children have 0 buses attached and a bridge has 1 bus > > */ > > struct bus link[MAX_LINKS]; > > Index: mainboard/adl/msm800sev/stage1.c > > =================================================================== > > --- mainboard/adl/msm800sev/stage1.c (Revision 476) > > +++ mainboard/adl/msm800sev/stage1.c (Arbeitskopie) > > @@ -33,7 +33,9 @@ > > #include > > #include > > > > +/* This is wrong! SERIAL_DEV can't be >=0x10 because it's a PNP device number */ > > #define SERIAL_DEV 0x30 > > +#define SERIAL_IOBASE 0x3f8 This is probably the wrong location for this information anyway. This is hardware property and should thus be in the dts, IMHO. This includes the 0x2e, the 0x30 (I think), and the 0x3f8. > > > > void hardware_stage1(void) > > { > > @@ -49,6 +51,6 @@ > > * for cs5536 > > */ > > cs5536_disable_internal_uart(); > > - w83627hf_enable_serial(0x2e, 0x30, 0x3f8); > > + w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); > > printk(BIOS_DEBUG, "Done %s\n", __FUNCTION__); > > } > > Index: device/device.c > > =================================================================== > > --- device/device.c (Revision 476) > > +++ device/device.c (Arbeitskopie) > > @@ -260,8 +260,10 @@ > > for (curdev = bus->children; curdev; curdev = curdev->sibling) { > > unsigned int links; > > int i; > > - printk(BIOS_SPEW, "%s: %s(%s) have_resources %d enabled %d\n", > > + printk(BIOS_SPEW, > > + "%s: %s(%s) dtsname %s have_resources %d enabled %d\n", > > __func__, bus->dev->dtsname, dev_path(bus->dev), > > + curdev->dtsname, > > curdev->have_resources, curdev->enabled); > > if (curdev->have_resources) { > > continue; > > @@ -402,7 +404,11 @@ > > min_align = 0; > > base = bridge->base; > > > > - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); > > + printk(BIOS_SPEW, > > + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d\n", > > + dev_path(bus->dev), > > + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", > > + base, bridge->size, bridge->align, bridge->gran); > > > > /* We want different minimum alignments for different kinds of > > * resources. These minimums are not device type specific but > > @@ -485,7 +491,7 @@ > > base += size; > > > > printk(BIOS_SPEW, > > - "%s %02lx * [0x%08Lx - 0x%08Lx] %s\n", > > + "%s %02lx * [0x%08llx - 0x%08llx] %s\n", Yep, I guess so. If this works (didn't follow the last printk-fixes thread too closely), then please make one patch for all of these and related printk-fixes. > > dev_path(dev), > > resource->index, > > resource->base, > > @@ -503,7 +509,11 @@ > > */ > > bridge->size = align_up(base, bridge->gran) - bridge->base; > > > > - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d done\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); > > + printk(BIOS_SPEW, > > + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d done\n", > > + dev_path(bus->dev), > > + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", > > + base, bridge->size, bridge->align, bridge->gran); > > } > > > > #if defined(CONFIG_PCI_OPTION_ROM_RUN) && CONFIG_PCI_OPTION_ROM_RUN == 1 > > Index: device/pnp_device.c > > =================================================================== > > --- device/pnp_device.c (Revision 476) > > +++ device/pnp_device.c (Arbeitskopie) > > @@ -87,7 +87,7 @@ > > { > > if (!(resource->flags & IORESOURCE_ASSIGNED)) { > > printk(BIOS_ERR, > > - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", > > + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", > > dev_path(dev), resource->index, resource_type(resource), > > resource->size); > > return; > > Index: device/pci_device.c > > =================================================================== > > --- device/pci_device.c (Revision 476) > > +++ device/pci_device.c (Arbeitskopie) > > @@ -252,10 +252,10 @@ > > printk(BIOS_DEBUG, "%s %02x ->", > > dev_path(dev), resource->index); > > printk(BIOS_DEBUG, > > - " value: 0x%08Lx zeroes: 0x%08Lx ones: 0x%08Lx attr: %08lx\n", > > + " value: 0x%08llx zeroes: 0x%08llx ones: 0x%08llx attr: %08lx\n", Are we sure %ll will never produce more than 8 digits? On all architectures? > > value, zeroes, ones, attr); > > printk(BIOS_DEBUG, > > - "%s %02x -> size: 0x%08Lx max: 0x%08Lx %s\n ", > > + "%s %02x -> size: 0x%08llx max: 0x%08llx %s\n ", > > dev_path(dev), resource->index, resource->size, > > resource->limit, resource_type(resource)); > > } > > @@ -456,7 +456,7 @@ > > /* Make certain the resource has actually been set. */ > > if (!(resource->flags & IORESOURCE_ASSIGNED)) { > > printk(BIOS_ERR, > > - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", > > + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", > > dev_path(dev), resource->index, resource_type(resource), > > resource->size); > > return; > > @@ -863,7 +863,7 @@ > > (*list)->path.type); > > continue; > > } > > - printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%x\n", > > + printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%02x\n", ACK, same for all other %x -> %02x (etc.) changes. > > __func__, (*list)->dtsname, (*list)->path.u.pci.devfn); > > if ((*list)->path.u.pci.devfn == devfn) { > > /* Unlink from the list. */ > > Index: device/device_util.c > > =================================================================== > > --- device/device_util.c (Revision 476) > > +++ device/device_util.c (Arbeitskopie) > > @@ -229,7 +229,7 @@ > > memcpy(buffer, "Root Device", 12); > > break; > > case DEVICE_ID_PCI: > > - sprintf(buffer, "PCI: %02x:%02x", id->u.pci.vendor, > > + sprintf(buffer, "PCI: %04x:%04x", id->u.pci.vendor, > > id->u.pci.device); > > break; > > case DEVICE_ID_PNP: > > @@ -243,7 +243,7 @@ > > id->u.apic.device); > > break; > > case DEVICE_ID_PCI_DOMAIN: > > - sprintf(buffer, "PCI_DOMAIN: %02x:%02x", > > + sprintf(buffer, "PCI_DOMAIN: %04x:%04x", > > id->u.pci_domain.vendor, > > id->u.pci_domain.device); > > break; > > @@ -602,7 +602,7 @@ > > #endif > > } > > printk(BIOS_DEBUG, > > - "%s %02lx <- [0x%010Lx - 0x%010Lx] %s%s%s\n", > > + "%s %02lx <- [0x%010llx - 0x%010llx] %s%s%s\n", > > dev_path(dev), > > resource->index, > > base, end, buf, resource_type(resource), comment); > > @@ -656,7 +656,7 @@ > > for (i = 0; i < curdev->resources; i++) { > > struct resource *resource = &curdev->resource[i]; > > printk(BIOS_SPEW, > > - "%s: dev %s, resource %d, flags %lx base 0x%Lx size 0x%Lx\n", > > + "%s: dev %s, resource %d, flags %lx base 0x%llx size 0x%llx\n", > > __func__, curdev->dtsname, i, resource->flags, > > resource->base, resource->size); > > /* If it isn't the right kind of resource ignore it. */ > > Index: lib/stage2.c > > =================================================================== > > --- lib/stage2.c (Revision 476) > > +++ lib/stage2.c (Arbeitskopie) > > @@ -31,8 +31,9 @@ > > /** > > * Main function of the DRAM part of LinuxBIOS. > > * > > - * LinuxBIOS is divided into pre-DRAM part and DRAM part. The phases before > > - * this part are phase 0 and phase 1. This part contains phases x through y. > > + * LinuxBIOS is divided into pre-DRAM part and DRAM part. The stages before > > + * this part are stage 0 and stage 1. This part contains stage 2, which > > + * consists of phases 1 through 6. Looks correct, but using "stages" _and_ "phases" will confuse the hell out of everyone. I vote for only using stage 0-2, just drop the phases terminology completely. Or maybe something like "which consists of multiple steps"? > > * > > * Device Enumeration: in the dev_enumerate() phase. > > * > > @@ -53,6 +54,7 @@ > > > > post_code(0x20); > > > > + /* TODO: Explain why we use printk here although it is impossible */ > > printk(BIOS_NOTICE, console_test); Hm, good point. It works in QEMU, but that's not a good indicator in this case. > > > > dev_init(); > > Index: lib/elfboot.c > > =================================================================== > > --- lib/elfboot.c (Revision 476) > > +++ lib/elfboot.c (Arbeitskopie) > > @@ -61,7 +61,7 @@ > > } > > if (i == mem_entries) { > > printk(BIOS_ERR, "No matching RAM area found for range:\n"); > > - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx)\n", start, end); > > + printk(BIOS_ERR, " [0x%016llx, 0x%016llx)\n", start, end); > > printk(BIOS_ERR, "RAM areas\n"); > > for(i = 0; i < mem_entries; i++) { > > u64 mstart, mend; > > @@ -69,7 +69,7 @@ > > mtype = mem->map[i].type; > > mstart = unpack_lb64(mem->map[i].start); > > mend = mstart + unpack_lb64(mem->map[i].size); > > - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx) %s\n", > > + printk(BIOS_ERR, " [0x%016llx, 0x%016llx) %s\n", > > mstart, mend, (mtype == LB_MEM_RAM)?"RAM":"Reserved"); > > > > } > > Index: northbridge/intel/i440bxemulation/i440bx.c > > =================================================================== > > --- northbridge/intel/i440bxemulation/i440bx.c (Revision 476) > > +++ northbridge/intel/i440bxemulation/i440bx.c (Arbeitskopie) > > @@ -79,7 +79,7 @@ > > resource->size = ((resource_t) sizek) << 10; > > resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE | > > IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; > > - printk(BIOS_DEBUG, "%s: add ram resoource %Ld bytes\n", __func__, > > + printk(BIOS_DEBUG, "%s: add ram resource %lld bytes\n", __func__, > > resource->size); > > } > > > > Index: arch/x86/linuxbios_table.c > > =================================================================== > > --- arch/x86/linuxbios_table.c (Revision 476) > > +++ arch/x86/linuxbios_table.c (Arbeitskopie) > > @@ -177,7 +177,7 @@ > > { > > int entries; > > > > - printk(BIOS_DEBUG, "%s: start 0x%Lx size 0x%Lx\n", > > + printk(BIOS_DEBUG, "%s: start 0x%llx size 0x%llx\n", > > __func__, start, size); > > > > entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); > > Index: arch/x86/pci_ops_mmconf.c > > =================================================================== > > --- arch/x86/pci_ops_mmconf.c (Revision 476) > > +++ arch/x86/pci_ops_mmconf.c (Arbeitskopie) > > @@ -18,32 +18,32 @@ > > > > #include > > > > -static uint8_t pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) > > +static u8 pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) ACK (same for the other occurences). > > { > > return (read8x(PCI_MMIO_ADDR(bus, devfn, where))); > > } > > > > -static uint16_t pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) > > +static u16 pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) > > { > > return (read16x(PCI_MMIO_ADDR(bus, devfn, where))); > > } > > > > -static uint32_t pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) > > +static u32 pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) > > { > > return (read32x(PCI_MMIO_ADDR(bus, devfn, where))); > > } > > > > -static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, uint8_t value) > > +static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, u8 value) > > { > > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > > } > > > > -static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, uint16_t value) > > +static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, u16 value) > > { > > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > > } > > > > -static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, uint32_t value) > > +static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, u32 value) > > { > > write8x(PCI_MMIO_ADDR(bus, devfn, where), value); > > } Please repost all of this as two or three separate patches, each fixing a single issue repository-wide. I think we can apply this soon. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From darmawan.salihun at gmail.com Thu Aug 23 08:28:04 2007 From: darmawan.salihun at gmail.com (Darmawan Salihun) Date: Thu, 23 Aug 2007 13:28:04 +0700 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46CB2987.8020403@coresystems.de> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> <46CB2987.8020403@coresystems.de> Message-ID: <46893e740708222328w5ee86dfal96d4c349f1ba7575@mail.gmail.com> On 8/22/07, Stefan Reinauer wrote: > > Darmawan Salihun wrote: > > Hi, > > I forgot to include the my copyright for the added file previously. > > Fixed. See patch > > > > > > Regards, > > > > Darmawan Salihun > > -------------------------------------------------------------------- > > -= Human knowledge belongs to the world =- > Is there a reason you use your own mmap instead of using the already > mmapped area in flashrom.c:int map_flash_registers(struct flashchip > *flash) > ? > > Having analyzed map_flash_registers(), I'm sure I can use that function. I'm going to test it tonight. However, it seems to be the patch will stay as different file because among all of the flashchip support files, there's no one of them that can provide the register unprotect routine(s). Regards, Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =- -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at smittys.pointclark.net Thu Aug 23 09:45:50 2007 From: joe at smittys.pointclark.net (Joseph Smith) Date: Thu, 23 Aug 2007 03:45:50 -0400 Subject: [LinuxBIOS] Fwd: Re: smbus_write_byte In-Reply-To: <00cc01c7e428$04e99470$4d22040a@chimp> References: <00cc01c7e428$04e99470$4d22040a@chimp> Message-ID: <20070823034550.z7ctvg4mzcc0coso@www.smittys.pointclark.net> Quoting Myles Watson : > > >> > static int spd_read_byte(unsigned device, unsigned address) >> > { >> > int i; >> > >> > if (device == 0x50){ >> > return do_smbus_read_byte(device, address); >> > } else if (device == 0x51){ >> > for (i=0; i < (sizeof spd_table/sizeof spd_table[0]); i++){ >> > if (spd_table[i].address == address){ >> > return spd_table[i].data; >> > } >> > } > return 0xFF; /* This line returns 0xFF when address not found */ >> > } else { >> > return 0xFF; /* returns 0xFF on any failures */ >> > } >> > } > Hmm, This isn't working. In raminit.c the spd_read_byte() uses ctrl->channel0[i] not device (0x51). Example: smbus_read_byte(ctrl->channel0[i], 2) I will have to investigate what this tranlates to. Does anyone know off the top of their head what ctrl->channel0[i] translates to? Thanks - Joe From uwe at hermann-uwe.de Thu Aug 23 09:47:54 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 09:47:54 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Move code into C files Message-ID: <20070823074753.GA15343@greenwood> This is the first in a row of many cleanup patches for flashrom. Step 1: Move all code into *.c files, not *.h files. I don't see a reason to have them in header files. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_move_code_to_c_files.patch Type: text/x-diff Size: 11348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From stepan at coresystems.de Thu Aug 23 10:22:13 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 23 Aug 2007 10:22:13 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Move code into C files In-Reply-To: <20070823074753.GA15343@greenwood> References: <20070823074753.GA15343@greenwood> Message-ID: <20070823082213.GA18194@coresystems.de> * Uwe Hermann [070823 09:47]: > This is the first in a row of many cleanup patches for flashrom. > > Step 1: Move all code into *.c files, not *.h files. I don't see a > reason to have them in header files. I like this a lot! > Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer -- 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 peter at stuge.se Thu Aug 23 10:29:04 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 23 Aug 2007 10:29:04 +0200 Subject: [LinuxBIOS] [patch] flashrom: Fix support for Winbond W39V040FA In-Reply-To: <46893e740708222328w5ee86dfal96d4c349f1ba7575@mail.gmail.com> References: <20070515101126.GA29326@skynet.be> <46CAB12C.7050102@gmail.com> <20070821123731.11263.qmail@stuge.se> <46893e740708210707v5bf4129bk6fd24aa7adfa38b8@mail.gmail.com> <46893e740708211024tf17c8e6t423272c473d0d582@mail.gmail.com> <46CB2987.8020403@coresystems.de> <46893e740708222328w5ee86dfal96d4c349f1ba7575@mail.gmail.com> Message-ID: <20070823082904.1674.qmail@stuge.se> On Thu, Aug 23, 2007 at 01:28:04PM +0700, Darmawan Salihun wrote: > However, it seems to be the patch will stay as different file > because among all of the flashchip support files, there's no > one of them that can provide the register unprotect routine(s). The idea is to keep code duplication to a minimum where possible, so if W39V are quite similar to another already-supported chip except for these registers it may be a good idea to just add the neccessary register stuff to that chip code instead. (But only called for W39V, of course.) //Peter From peter at stuge.se Thu Aug 23 10:35:21 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 23 Aug 2007 10:35:21 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Move code into C files In-Reply-To: <20070823074753.GA15343@greenwood> References: <20070823074753.GA15343@greenwood> Message-ID: <20070823083521.2585.qmail@stuge.se> On Thu, Aug 23, 2007 at 09:47:54AM +0200, Uwe Hermann wrote: > Step 1: Move all code into *.c files, not *.h files. I don't see a > reason to have them in header files. Good stuff - but what about the inline? Might be nice to keep that for some functions that are called frequently while programming? //Peter From svn at openbios.org Thu Aug 23 12:20:40 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 23 Aug 2007 12:20:40 +0200 Subject: [LinuxBIOS] r2745 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-08-23 12:20:40 +0200 (Thu, 23 Aug 2007) New Revision: 2745 Modified: trunk/util/flashrom/82802ab.c trunk/util/flashrom/82802ab.h trunk/util/flashrom/jedec.c trunk/util/flashrom/jedec.h trunk/util/flashrom/m29f400bt.c trunk/util/flashrom/m29f400bt.h trunk/util/flashrom/sharplhf00l04.c trunk/util/flashrom/sharplhf00l04.h Log: Move code into *.c files, there's no reason to have it in header files. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/util/flashrom/82802ab.c =================================================================== --- trunk/util/flashrom/82802ab.c 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/82802ab.c 2007-08-23 10:20:40 UTC (rev 2745) @@ -30,6 +30,46 @@ #include "82802ab.h" #include "debug.h" +void toggle_ready_82802ab(volatile uint8_t *dst) +{ + unsigned int i = 0; + uint8_t tmp1, tmp2; + + tmp1 = *dst & 0x40; + + while (i++ < 0xFFFFFF) { + tmp2 = *dst & 0x40; + if (tmp1 == tmp2) { + break; + } + tmp1 = tmp2; + } +} + +void data_polling_82802ab(volatile uint8_t *dst, uint8_t data) +{ + unsigned int i = 0; + uint8_t tmp; + + data &= 0x80; + + while (i++ < 0xFFFFFF) { + tmp = *dst & 0x80; + if (tmp == data) { + break; + } + } +} + +void protect_82802ab(volatile uint8_t *bios) +{ + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; + *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; + *(volatile uint8_t *)(bios + 0x5555) = 0xA0; + + usleep(200); +} + // I need that Berkeley bit-map printer void print_82802ab_status(uint8_t status) { Modified: trunk/util/flashrom/82802ab.h =================================================================== --- trunk/util/flashrom/82802ab.h 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/82802ab.h 2007-08-23 10:20:40 UTC (rev 2745) @@ -5,45 +5,4 @@ extern int erase_82802ab(struct flashchip *flash); extern int write_82802ab(struct flashchip *flash, uint8_t *buf); -extern __inline__ void toggle_ready_82802ab(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; - - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -extern __inline__ void data_polling_82802ab(volatile uint8_t *dst, - uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -extern __inline__ void protect_82802ab(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0xA0; - - usleep(200); -} - #endif /* !__82802AB_H__ */ Modified: trunk/util/flashrom/jedec.c =================================================================== --- trunk/util/flashrom/jedec.c 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/jedec.c 2007-08-23 10:20:40 UTC (rev 2745) @@ -33,6 +33,58 @@ #define MAX_REFLASH_TRIES 0x10 +void toggle_ready_jedec(volatile uint8_t *dst) +{ + unsigned int i = 0; + uint8_t tmp1, tmp2; + + tmp1 = *dst & 0x40; + + while (i++ < 0xFFFFFFF) { + tmp2 = *dst & 0x40; + if (tmp1 == tmp2) { + break; + } + tmp1 = tmp2; + } +} + +void data_polling_jedec(volatile uint8_t *dst, uint8_t data) +{ + unsigned int i = 0; + uint8_t tmp; + + data &= 0x80; + + while (i++ < 0xFFFFFFF) { + tmp = *dst & 0x80; + if (tmp == data) { + break; + } + } +} + +void unprotect_jedec(volatile uint8_t *bios) +{ + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; + *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; + *(volatile uint8_t *)(bios + 0x5555) = 0x80; + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; + *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; + *(volatile uint8_t *)(bios + 0x5555) = 0x20; + + usleep(200); +} + +void protect_jedec(volatile uint8_t *bios) +{ + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; + *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; + *(volatile uint8_t *)(bios + 0x5555) = 0xA0; + + usleep(200); +} + int probe_jedec(struct flashchip *flash) { volatile uint8_t *bios = flash->virtual_memory; Modified: trunk/util/flashrom/jedec.h =================================================================== --- trunk/util/flashrom/jedec.h 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/jedec.h 2007-08-23 10:20:40 UTC (rev 2745) @@ -1,8 +1,12 @@ #ifndef __JEDEC_H__ #define __JEDEC_H__ 1 + +extern void toggle_ready_jedec(volatile uint8_t *dst); +extern void data_polling_jedec(volatile uint8_t *dst, uint8_t data); +extern void unprotect_jedec(volatile uint8_t *bios); +extern void protect_jedec(volatile uint8_t *bios); int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst); - extern int probe_jedec(struct flashchip *flash); extern int erase_chip_jedec(struct flashchip *flash); extern int write_jedec(struct flashchip *flash, uint8_t *buf); @@ -11,56 +15,4 @@ extern int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst, unsigned int page_size); -extern __inline__ void toggle_ready_jedec(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; - - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -extern __inline__ void data_polling_jedec(volatile uint8_t *dst, uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -extern __inline__ void unprotect_jedec(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0x80; - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0x20; - - usleep(200); -} - -extern __inline__ void protect_jedec(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0xA0; - - usleep(200); -} - #endif /* !__JEDEC_H__ */ Modified: trunk/util/flashrom/m29f400bt.c =================================================================== --- trunk/util/flashrom/m29f400bt.c 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/m29f400bt.c 2007-08-23 10:20:40 UTC (rev 2745) @@ -27,6 +27,69 @@ #include "m29f400bt.h" #include "debug.h" +void toggle_ready_m29f400bt(volatile uint8_t *dst) +{ + unsigned int i = 0; + uint8_t tmp1, tmp2; + + tmp1 = *dst & 0x40; + + while (i++ < 0xFFFFFF) { + tmp2 = *dst & 0x40; + if (tmp1 == tmp2) { + break; + } + tmp1 = tmp2; + } +} + +void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data) +{ + unsigned int i = 0; + uint8_t tmp; + + data &= 0x80; + + while (i++ < 0xFFFFFF) { + tmp = *dst & 0x80; + if (tmp == data) { + break; + } + } +} + +void protect_m29f400bt(volatile uint8_t *bios) +{ + *(volatile uint8_t *)(bios + 0xAAA) = 0xAA; + *(volatile uint8_t *)(bios + 0x555) = 0x55; + *(volatile uint8_t *)(bios + 0xAAA) = 0xA0; + + usleep(200); +} + +void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, int page_size) +{ + int i; + + for (i = 0; i < page_size; i++) { + *(volatile uint8_t *)(bios + 0xAAA) = 0xAA; + *(volatile uint8_t *)(bios + 0x555) = 0x55; + *(volatile uint8_t *)(bios + 0xAAA) = 0xA0; + + /* transfer data from source to destination */ + *dst = *src; + //*(volatile char *) (bios) = 0xF0; + //usleep(5); + toggle_ready_m29f400bt(dst); + printf + ("Value in the flash at address %p = %#x, want %#x\n", + (uint8_t *) (dst - bios), *dst, *src); + dst++; + src++; + } +} + int probe_m29f400bt(struct flashchip *flash) { volatile uint8_t *bios = flash->virtual_memory; Modified: trunk/util/flashrom/m29f400bt.h =================================================================== --- trunk/util/flashrom/m29f400bt.h 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/m29f400bt.h 2007-08-23 10:20:40 UTC (rev 2745) @@ -10,71 +10,10 @@ extern int write_m29f400bt(struct flashchip *flash, uint8_t *buf); extern int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf); -extern __inline__ void toggle_ready_m29f400bt(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; +extern void toggle_ready_m29f400bt(volatile uint8_t *dst); +extern void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data); +extern void protect_m29f400bt(volatile uint8_t *bios); +extern void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, int page_size); - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -extern __inline__ void data_polling_m29f400bt(volatile uint8_t *dst, - uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -extern __inline__ void protect_m29f400bt(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0xAAA) = 0xAA; - *(volatile uint8_t *)(bios + 0x555) = 0x55; - *(volatile uint8_t *)(bios + 0xAAA) = 0xA0; - - usleep(200); -} - -extern __inline__ void write_page_m29f400bt(volatile uint8_t *bios, - uint8_t *src, - volatile uint8_t *dst, - int page_size) -{ - int i; - - for (i = 0; i < page_size; i++) { - *(volatile uint8_t *)(bios + 0xAAA) = 0xAA; - *(volatile uint8_t *)(bios + 0x555) = 0x55; - *(volatile uint8_t *)(bios + 0xAAA) = 0xA0; - - /* transfer data from source to destination */ - *dst = *src; - //*(volatile char *) (bios) = 0xF0; - //usleep(5); - toggle_ready_m29f400bt(dst); - printf - ("Value in the flash at address %p = %#x, want %#x\n", - (uint8_t *) (dst - bios), *dst, *src); - dst++; - src++; - } - -} - #endif /* !__M29F400BT_H__ */ Modified: trunk/util/flashrom/sharplhf00l04.c =================================================================== --- trunk/util/flashrom/sharplhf00l04.c 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/sharplhf00l04.c 2007-08-23 10:20:40 UTC (rev 2745) @@ -29,6 +29,46 @@ #include "sharplhf00l04.h" #include "debug.h" +void toggle_ready_lhf00l04(volatile uint8_t *dst) +{ + unsigned int i = 0; + uint8_t tmp1, tmp2; + + tmp1 = *dst & 0x40; + + while (i++ < 0xFFFFFF) { + tmp2 = *dst & 0x40; + if (tmp1 == tmp2) { + break; + } + tmp1 = tmp2; + } +} + +void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data) +{ + unsigned int i = 0; + uint8_t tmp; + + data &= 0x80; + + while (i++ < 0xFFFFFF) { + tmp = *dst & 0x80; + if (tmp == data) { + break; + } + } +} + +void protect_lhf00l04(volatile uint8_t *bios) +{ + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; + *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; + *(volatile uint8_t *)(bios + 0x5555) = 0xA0; + + usleep(200); +} + // I need that Berkeley bit-map printer void print_lhf00l04_status(uint8_t status) { Modified: trunk/util/flashrom/sharplhf00l04.h =================================================================== --- trunk/util/flashrom/sharplhf00l04.h 2007-08-13 04:10:32 UTC (rev 2744) +++ trunk/util/flashrom/sharplhf00l04.h 2007-08-23 10:20:40 UTC (rev 2745) @@ -4,45 +4,8 @@ extern int probe_lhf00l04(struct flashchip *flash); extern int erase_lhf00l04(struct flashchip *flash); extern int write_lhf00l04(struct flashchip *flash, uint8_t *buf); -extern __inline__ void toggle_ready_lhf00l04(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; +extern void toggle_ready_lhf00l04(volatile uint8_t *dst); +extern void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data); +extern void protect_lhf00l04(volatile uint8_t *bios); - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -extern __inline__ void data_polling_lhf00l04(volatile uint8_t *dst, - uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -extern __inline__ void protect_lhf00l04(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0xA0; - - usleep(200); -} - #endif /* !__SHARPLHF00L04_H__ */ From uwe at hermann-uwe.de Thu Aug 23 12:42:26 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 12:42:26 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Move code into C files In-Reply-To: <20070823082213.GA18194@coresystems.de> References: <20070823074753.GA15343@greenwood> <20070823082213.GA18194@coresystems.de> Message-ID: <20070823104226.GB15343@greenwood> On Thu, Aug 23, 2007 at 10:22:13AM +0200, Stefan Reinauer wrote: > > Signed-off-by: Uwe Hermann > Acked-by: Stefan Reinauer Thanks, r2745. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Aug 23 12:47:57 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 12:47:57 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Move code into C files In-Reply-To: <20070823083521.2585.qmail@stuge.se> References: <20070823074753.GA15343@greenwood> <20070823083521.2585.qmail@stuge.se> Message-ID: <20070823104757.GC15343@greenwood> On Thu, Aug 23, 2007 at 10:35:21AM +0200, Peter Stuge wrote: > On Thu, Aug 23, 2007 at 09:47:54AM +0200, Uwe Hermann wrote: > > Step 1: Move all code into *.c files, not *.h files. I don't see a > > reason to have them in header files. > > Good stuff - but what about the inline? Might be nice to keep that > for some functions that are called frequently while programming? Hm, good question. In general I think the inline is not really needed. Do you think this might be important for the time-critical parts in flashrom? Could be, but I doubt this code is _that_ time-critical. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Aug 23 12:49:04 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 12:49:04 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop useless header files Message-ID: <20070823104904.GD15343@greenwood> See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_drop_useless_headers.patch Type: text/x-diff Size: 19790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From info at coresystems.de Thu Aug 23 13:07:24 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 23 Aug 2007 13:07:24 +0200 Subject: [LinuxBIOS] r2745 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2745 to the LinuxBIOS source repository and caused the following changes: Change Log: Move code into *.c files, there's no reason to have it in header files. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2745&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From stepan at coresystems.de Thu Aug 23 13:16:14 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 23 Aug 2007 13:16:14 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop useless header files In-Reply-To: <20070823104904.GD15343@greenwood> References: <20070823104904.GD15343@greenwood> Message-ID: <20070823111614.GA3171@coresystems.de> * Uwe Hermann [070823 12:49]: > Drop a bunch of useless header files, merge them into flash.h. > > Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer 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 ml at saxnet.de Thu Aug 23 14:21:31 2007 From: ml at saxnet.de (Thomas Buschhardt) Date: Thu, 23 Aug 2007 14:21:31 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <20070815203256.14414.qmail@stuge.se> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> <20070815103502.11863.qmail@stuge.se> <46C2E993.4030505@saxnet.de> <20070815203256.14414.qmail@stuge.se> Message-ID: <46CD7BCB.8050508@saxnet.de> Hallo Peter, in the short: the timing of the read/write-process was wrong and the galep-producer change his software ;-) its so easy sometimes .... ...no protection Thomas Peter Stuge schrieb: > Hey, > > On Wed, Aug 15, 2007 at 01:54:59PM +0200, Thomas Buschhardt wrote: > >>> It is quite likely that the different sample BIOS images from the >>> vendors are different, even if for the same hardware. >>> >> Of course they differ, but if I read 1 chip 3 times and compare the >> bin's - they differ too :-( >> > > Ouch. Do they differ a lot? Can you run xxd on them and then diff? > > Bit errors indeed start showing when the chip has been through > (quite) a few erase/rewrite cycles. I had not heard about that > write protection idea before. > > > >>> Can you get a few other flash chips for further testing? >>> >> Today I telephone with the Galep producer and he said - some chip >> vendors use a "writeprotection technic" that u cant use the free >> samples to burn your own image on it. I order some new (clean ;-)) >> chips. I understand these method, because one of these vendor >> (www.insydesw.com) offer 50 chips for free - its quite a lot of >> money (1 chip is about 5.90 EUR). >> > > If you are a company and have a budget for more than just a few chips > you can usually get a decent deal for 30 chips (one tube) from the > local component distributors. > > Price goes down a lot when quantity goes up, so I doubt Insyde is > paying very much.. :) > > > //Peter > > From svn at openbios.org Thu Aug 23 15:34:59 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 23 Aug 2007 15:34:59 +0200 Subject: [LinuxBIOS] r2746 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-08-23 15:34:59 +0200 (Thu, 23 Aug 2007) New Revision: 2746 Removed: trunk/util/flashrom/82802ab.h trunk/util/flashrom/am29f040b.h trunk/util/flashrom/debug.h trunk/util/flashrom/jedec.h trunk/util/flashrom/layout.h trunk/util/flashrom/lbtable.h trunk/util/flashrom/m29f400bt.h trunk/util/flashrom/mx29f002.h trunk/util/flashrom/pm49fl004.h trunk/util/flashrom/sharplhf00l04.h trunk/util/flashrom/sst28sf040.h trunk/util/flashrom/sst39sf020.h trunk/util/flashrom/sst49lf040.h trunk/util/flashrom/sst49lfxxxc.h trunk/util/flashrom/sst_fwhub.h trunk/util/flashrom/w49f002u.h Modified: trunk/util/flashrom/82802ab.c trunk/util/flashrom/am29f040b.c trunk/util/flashrom/board_enable.c trunk/util/flashrom/chipset_enable.c trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/flashrom.c trunk/util/flashrom/jedec.c trunk/util/flashrom/layout.c trunk/util/flashrom/lbtable.c trunk/util/flashrom/m29f400bt.c trunk/util/flashrom/msys_doc.c trunk/util/flashrom/mx29f002.c trunk/util/flashrom/pm49fl004.c trunk/util/flashrom/sharplhf00l04.c trunk/util/flashrom/sst28sf040.c trunk/util/flashrom/sst39sf020.c trunk/util/flashrom/sst49lf040.c trunk/util/flashrom/sst49lfxxxc.c trunk/util/flashrom/sst_fwhub.c trunk/util/flashrom/udelay.c trunk/util/flashrom/w49f002u.c Log: Drop a bunch of useless header files, merge them into flash.h. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/util/flashrom/82802ab.c =================================================================== --- trunk/util/flashrom/82802ab.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/82802ab.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -25,10 +25,7 @@ #include #include - #include "flash.h" -#include "82802ab.h" -#include "debug.h" void toggle_ready_82802ab(volatile uint8_t *dst) { Deleted: trunk/util/flashrom/82802ab.h =================================================================== --- trunk/util/flashrom/82802ab.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/82802ab.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __82802AB_H__ -#define __82802AB_H__ 1 - -extern int probe_82802ab(struct flashchip *flash); -extern int erase_82802ab(struct flashchip *flash); -extern int write_82802ab(struct flashchip *flash, uint8_t *buf); - -#endif /* !__82802AB_H__ */ Modified: trunk/util/flashrom/am29f040b.c =================================================================== --- trunk/util/flashrom/am29f040b.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/am29f040b.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -25,8 +25,6 @@ #include #include #include "flash.h" -#include "jedec.h" -#include "debug.h" static __inline__ int erase_sector_29f040b(volatile uint8_t *bios, unsigned long address) Deleted: trunk/util/flashrom/am29f040b.h =================================================================== --- trunk/util/flashrom/am29f040b.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/am29f040b.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __AM29F040B_H__ -#define __AM29F040B_H__ 1 - -extern int probe_29f040b(struct flashchip *flash); -extern int erase_29f040b(struct flashchip *flash); -extern int write_29f040b(struct flashchip *flash, uint8_t *buf); - -#endif /* !__AM29F040B_H__ */ Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/board_enable.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -19,9 +19,7 @@ #include #include #include - #include "flash.h" -#include "debug.h" /* * Helper functions for many Winbond superIOs of the w836xx range. Modified: trunk/util/flashrom/chipset_enable.c =================================================================== --- trunk/util/flashrom/chipset_enable.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/chipset_enable.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -14,9 +14,7 @@ #include #include #include - #include "flash.h" -#include "debug.h" static int enable_flash_ali_m1533(struct pci_dev *dev, char *name) { Deleted: trunk/util/flashrom/debug.h =================================================================== --- trunk/util/flashrom/debug.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/debug.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,10 +0,0 @@ -#ifndef __DEBUG_H__ -#define __DEBUG_H__ 1 - -//#define printf_debug(x...) printf(x) - -extern int verbose; - -#define printf_debug(x...) { if(verbose) printf(x); } - -#endif Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/flash.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -27,9 +27,9 @@ #if defined(__GLIBC__) #include #endif - #include #include +#include struct flashchip { char *name; @@ -164,6 +164,103 @@ extern int fd_mem; -int map_flash_registers(struct flashchip *flash); /* flashrom.c */ +/* debug.c */ +extern int verbose; +#define printf_debug(x...) { if (verbose) printf(x); } +/* flashrom.c */ +int map_flash_registers(struct flashchip *flash); + +/* layout.c */ +int show_id(uint8_t *bios, int size); +int read_romlayout(char *name); +int find_romentry(char *name); +int handle_romentries(uint8_t *buffer, uint8_t *content); + +/* lbtable.c */ +int linuxbios_init(void); +extern char *lb_part, *lb_vendor; + +/* 82802ab.c */ +extern int probe_82802ab(struct flashchip *flash); +extern int erase_82802ab(struct flashchip *flash); +extern int write_82802ab(struct flashchip *flash, uint8_t *buf); + +/* am29f040b.c */ +extern int probe_29f040b(struct flashchip *flash); +extern int erase_29f040b(struct flashchip *flash); +extern int write_29f040b(struct flashchip *flash, uint8_t *buf); + +/* jedec.c */ +extern void toggle_ready_jedec(volatile uint8_t *dst); +extern void data_polling_jedec(volatile uint8_t *dst, uint8_t data); +extern void unprotect_jedec(volatile uint8_t *bios); +extern void protect_jedec(volatile uint8_t *bios); +int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst); +extern int probe_jedec(struct flashchip *flash); +extern int erase_chip_jedec(struct flashchip *flash); +extern int write_jedec(struct flashchip *flash, uint8_t *buf); +extern int erase_sector_jedec(volatile uint8_t *bios, unsigned int page); +extern int erase_block_jedec(volatile uint8_t *bios, unsigned int page); +extern int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, unsigned int page_size); + +/* m29f400bt.c */ +extern int probe_m29f400bt(struct flashchip *flash); +extern int erase_m29f400bt(struct flashchip *flash); +extern int block_erase_m29f400bt(volatile uint8_t *bios, + volatile uint8_t *dst); +extern int write_m29f400bt(struct flashchip *flash, uint8_t *buf); +extern int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf); +extern void toggle_ready_m29f400bt(volatile uint8_t *dst); +extern void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data); +extern void protect_m29f400bt(volatile uint8_t *bios); +extern void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, + volatile uint8_t *dst, int page_size); + +/* mx29f002.c */ +extern int probe_29f002(struct flashchip *flash); +extern int erase_29f002(struct flashchip *flash); +extern int write_29f002(struct flashchip *flash, uint8_t *buf); + +/* pm49fl004.c */ +extern int probe_49fl004(struct flashchip *flash); +extern int erase_49fl004(struct flashchip *flash); +extern int write_49fl004(struct flashchip *flash, uint8_t *buf); + +/* sharplhf00l04.c */ +extern int probe_lhf00l04(struct flashchip *flash); +extern int erase_lhf00l04(struct flashchip *flash); +extern int write_lhf00l04(struct flashchip *flash, uint8_t *buf); +extern void toggle_ready_lhf00l04(volatile uint8_t *dst); +extern void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data); +extern void protect_lhf00l04(volatile uint8_t *bios); + +/* sst28sf040.c */ +extern int probe_28sf040(struct flashchip *flash); +extern int erase_28sf040(struct flashchip *flash); +extern int write_28sf040(struct flashchip *flash, uint8_t *buf); + +/* sst39sf020.c */ +extern int probe_39sf020(struct flashchip *flash); +extern int write_39sf020(struct flashchip *flash, uint8_t *buf); + +/* sst49lf040.c */ +extern int erase_49lf040(struct flashchip *flash); +extern int write_49lf040(struct flashchip *flash, uint8_t *buf); + +/* sst49lfxxxc.c */ +extern int probe_49lfxxxc(struct flashchip *flash); +extern int erase_49lfxxxc(struct flashchip *flash); +extern int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); + +/* sst_fwhub.c */ +extern int probe_sst_fwhub(struct flashchip *flash); +extern int erase_sst_fwhub(struct flashchip *flash); +extern int write_sst_fwhub(struct flashchip *flash, uint8_t *buf); + +/* w49f002u.c */ +extern int write_49f002(struct flashchip *flash, uint8_t *buf); + #endif /* !__FLASH_H__ */ Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/flashchips.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -22,22 +22,9 @@ */ #include "flash.h" -#include "jedec.h" -#include "m29f400bt.h" -#include "82802ab.h" #ifndef DISABLE_DOC #include "msys_doc.h" #endif -#include "am29f040b.h" -#include "sst28sf040.h" -#include "sst49lfxxxc.h" -#include "w49f002u.h" -#include "sst39sf020.h" -#include "sst49lf040.h" -#include "pm49fl004.h" -#include "mx29f002.h" -#include "sharplhf00l04.h" -#include "sst_fwhub.h" struct flashchip flashchips[] = { {"Am29F040B", AMD_ID, AM_29F040B, 512, 64 * 1024, Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/flashrom.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -36,7 +36,6 @@ #include #include #include - /* for iopl */ #if defined (__sun) && (defined(__i386) || defined(__amd64)) #include @@ -44,11 +43,7 @@ #include #include #endif - #include "flash.h" -#include "lbtable.h" -#include "layout.h" -#include "debug.h" char *chip_to_probe = NULL; struct pci_access *pacc; /* For board and chipset_enable */ Modified: trunk/util/flashrom/jedec.c =================================================================== --- trunk/util/flashrom/jedec.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/jedec.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -28,8 +28,6 @@ #include #include #include "flash.h" -#include "jedec.h" -#include "debug.h" #define MAX_REFLASH_TRIES 0x10 Deleted: trunk/util/flashrom/jedec.h =================================================================== --- trunk/util/flashrom/jedec.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/jedec.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,18 +0,0 @@ -#ifndef __JEDEC_H__ -#define __JEDEC_H__ 1 - -extern void toggle_ready_jedec(volatile uint8_t *dst); -extern void data_polling_jedec(volatile uint8_t *dst, uint8_t data); -extern void unprotect_jedec(volatile uint8_t *bios); -extern void protect_jedec(volatile uint8_t *bios); -int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, - volatile uint8_t *dst); -extern int probe_jedec(struct flashchip *flash); -extern int erase_chip_jedec(struct flashchip *flash); -extern int write_jedec(struct flashchip *flash, uint8_t *buf); -extern int erase_sector_jedec(volatile uint8_t *bios, unsigned int page); -extern int erase_block_jedec(volatile uint8_t *bios, unsigned int page); -extern int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, - volatile uint8_t *dst, unsigned int page_size); - -#endif /* !__JEDEC_H__ */ Modified: trunk/util/flashrom/layout.c =================================================================== --- trunk/util/flashrom/layout.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/layout.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -2,9 +2,7 @@ #include #include #include -#include "layout.h" -#include "lbtable.h" -#include "debug.h" +#include "flash.h" char *mainboard_vendor = NULL; char *mainboard_part = NULL; Deleted: trunk/util/flashrom/layout.h =================================================================== --- trunk/util/flashrom/layout.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/layout.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,9 +0,0 @@ -#ifndef __LAYOUT_H__ -#define __LAYOUT_H__ 1 - -int show_id(uint8_t *bios, int size); -int read_romlayout(char *name); -int find_romentry(char *name); -int handle_romentries(uint8_t *buffer, uint8_t *content); - -#endif /* !__LAYOUT_H__ */ Modified: trunk/util/flashrom/lbtable.c =================================================================== --- trunk/util/flashrom/lbtable.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/lbtable.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -32,7 +32,6 @@ #include #include "flash.h" #include "linuxbios_tables.h" -#include "debug.h" char *lb_part = NULL, *lb_vendor = NULL; Deleted: trunk/util/flashrom/lbtable.h =================================================================== --- trunk/util/flashrom/lbtable.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/lbtable.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __LBTABLE_H__ -#define __LBTABLE_H__ 1 - -int linuxbios_init(void); - -extern char *lb_part, *lb_vendor; - -#endif Modified: trunk/util/flashrom/m29f400bt.c =================================================================== --- trunk/util/flashrom/m29f400bt.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/m29f400bt.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -24,8 +24,6 @@ */ #include "flash.h" -#include "m29f400bt.h" -#include "debug.h" void toggle_ready_m29f400bt(volatile uint8_t *dst) { Deleted: trunk/util/flashrom/m29f400bt.h =================================================================== --- trunk/util/flashrom/m29f400bt.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/m29f400bt.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,19 +0,0 @@ -#ifndef __M29F400BT_H__ -#define __M29F400BT_H__ 1 - -#include - -extern int probe_m29f400bt(struct flashchip *flash); -extern int erase_m29f400bt(struct flashchip *flash); -extern int block_erase_m29f400bt(volatile uint8_t *bios, - volatile uint8_t *dst); -extern int write_m29f400bt(struct flashchip *flash, uint8_t *buf); -extern int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf); - -extern void toggle_ready_m29f400bt(volatile uint8_t *dst); -extern void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data); -extern void protect_m29f400bt(volatile uint8_t *bios); -extern void write_page_m29f400bt(volatile uint8_t *bios, uint8_t *src, - volatile uint8_t *dst, int page_size); - -#endif /* !__M29F400BT_H__ */ Modified: trunk/util/flashrom/msys_doc.c =================================================================== --- trunk/util/flashrom/msys_doc.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/msys_doc.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -23,7 +23,6 @@ #include #include "flash.h" #include "msys_doc.h" -#include "debug.h" static int doc_wait(volatile uint8_t *bios, int timeout); static uint8_t doc_read_chipid(volatile uint8_t *bios); Modified: trunk/util/flashrom/mx29f002.c =================================================================== --- trunk/util/flashrom/mx29f002.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/mx29f002.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -27,9 +27,6 @@ #include #include #include "flash.h" -#include "jedec.h" -#include "mx29f002.h" -#include "debug.h" int probe_29f002(struct flashchip *flash) { Deleted: trunk/util/flashrom/mx29f002.h =================================================================== --- trunk/util/flashrom/mx29f002.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/mx29f002.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __MX29F002_H__ -#define __MX29F002_H__ 1 - -extern int probe_29f002(struct flashchip *flash); -extern int erase_29f002(struct flashchip *flash); -extern int write_29f002(struct flashchip *flash, uint8_t *buf); - -#endif /* !__MX29F002_H__ */ Modified: trunk/util/flashrom/pm49fl004.c =================================================================== --- trunk/util/flashrom/pm49fl004.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/pm49fl004.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -24,8 +24,6 @@ #include #include "flash.h" -#include "jedec.h" -#include "pm49fl004.h" extern int exclude_start_page, exclude_end_page; Deleted: trunk/util/flashrom/pm49fl004.h =================================================================== --- trunk/util/flashrom/pm49fl004.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/pm49fl004.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __PM49FL004_H__ -#define __PM49FL004_H__ 1 - -extern int probe_49fl004(struct flashchip *flash); -extern int erase_49fl004(struct flashchip *flash); -extern int write_49fl004(struct flashchip *flash, uint8_t *buf); - -#endif Modified: trunk/util/flashrom/sharplhf00l04.c =================================================================== --- trunk/util/flashrom/sharplhf00l04.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sharplhf00l04.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -24,10 +24,7 @@ #include #include - #include "flash.h" -#include "sharplhf00l04.h" -#include "debug.h" void toggle_ready_lhf00l04(volatile uint8_t *dst) { Deleted: trunk/util/flashrom/sharplhf00l04.h =================================================================== --- trunk/util/flashrom/sharplhf00l04.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sharplhf00l04.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,11 +0,0 @@ -#ifndef __SHARPLHF00L04_H__ -#define __SHARPLHF00L04_H__ 1 - -extern int probe_lhf00l04(struct flashchip *flash); -extern int erase_lhf00l04(struct flashchip *flash); -extern int write_lhf00l04(struct flashchip *flash, uint8_t *buf); -extern void toggle_ready_lhf00l04(volatile uint8_t *dst); -extern void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data); -extern void protect_lhf00l04(volatile uint8_t *bios); - -#endif /* !__SHARPLHF00L04_H__ */ Modified: trunk/util/flashrom/sst28sf040.c =================================================================== --- trunk/util/flashrom/sst28sf040.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst28sf040.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -28,8 +28,6 @@ #include #include #include "flash.h" -#include "jedec.h" -#include "debug.h" #define AUTO_PG_ERASE1 0x20 #define AUTO_PG_ERASE2 0xD0 Deleted: trunk/util/flashrom/sst28sf040.h =================================================================== --- trunk/util/flashrom/sst28sf040.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst28sf040.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __SST28SF040_H__ -#define __SST28SF040_H__ - -extern int probe_28sf040(struct flashchip *flash); -extern int erase_28sf040(struct flashchip *flash); -extern int write_28sf040(struct flashchip *flash, uint8_t *buf); - -#endif /* !__SST28SF040_H__ */ Modified: trunk/util/flashrom/sst39sf020.c =================================================================== --- trunk/util/flashrom/sst39sf020.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst39sf020.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -29,8 +29,6 @@ #include #include #include "flash.h" -#include "jedec.h" -#include "sst39sf020.h" #define AUTO_PG_ERASE1 0x20 #define AUTO_PG_ERASE2 0xD0 Deleted: trunk/util/flashrom/sst39sf020.h =================================================================== --- trunk/util/flashrom/sst39sf020.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst39sf020.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,7 +0,0 @@ -#ifndef __SST39SF020_H__ -#define __SST39SF020_H__ 1 - -extern int probe_39sf020(struct flashchip *flash); -extern int write_39sf020(struct flashchip *flash, uint8_t *buf); - -#endif /* !__SST39SF020_H__ */ Modified: trunk/util/flashrom/sst49lf040.c =================================================================== --- trunk/util/flashrom/sst49lf040.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst49lf040.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -26,8 +26,6 @@ */ #include #include "flash.h" -#include "jedec.h" -#include "sst49lf040.h" int erase_49lf040(struct flashchip *flash) { Deleted: trunk/util/flashrom/sst49lf040.h =================================================================== --- trunk/util/flashrom/sst49lf040.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst49lf040.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,7 +0,0 @@ -#ifndef __SST49LF040_H__ -#define __SST49LF040_H__ 1 - -extern int erase_49lf040(struct flashchip *flash); -extern int write_49lf040(struct flashchip *flash, uint8_t *buf); - -#endif /* !__SST49LF040_H__ */ Modified: trunk/util/flashrom/sst49lfxxxc.c =================================================================== --- trunk/util/flashrom/sst49lfxxxc.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst49lfxxxc.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -32,10 +32,7 @@ #include #include #include - #include "flash.h" -#include "jedec.h" -#include "debug.h" #define SECTOR_ERASE 0x30 #define BLOCK_ERASE 0x20 Deleted: trunk/util/flashrom/sst49lfxxxc.h =================================================================== --- trunk/util/flashrom/sst49lfxxxc.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst49lfxxxc.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __SST49LFXXXC_H__ -#define __SST49LFXXXC_H__ - -extern int probe_49lfxxxc(struct flashchip *flash); -extern int erase_49lfxxxc(struct flashchip *flash); -extern int write_49lfxxxc(struct flashchip *flash, uint8_t *buf); - -#endif /* !__SST49LFXXXC_H__ */ Modified: trunk/util/flashrom/sst_fwhub.c =================================================================== --- trunk/util/flashrom/sst_fwhub.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst_fwhub.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -21,10 +21,7 @@ */ #include - #include "flash.h" -#include "jedec.h" -#include "sst_fwhub.h" // I need that Berkeley bit-map printer void print_sst_fwhub_status(uint8_t status) Deleted: trunk/util/flashrom/sst_fwhub.h =================================================================== --- trunk/util/flashrom/sst_fwhub.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/sst_fwhub.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,8 +0,0 @@ -#ifndef __SST_FWHUB_H__ -#define __SST_FWHUB_H__ 1 - -extern int probe_sst_fwhub(struct flashchip *flash); -extern int erase_sst_fwhub(struct flashchip *flash); -extern int write_sst_fwhub(struct flashchip *flash, uint8_t *buf); - -#endif /* !__SST_FWHUB_H__ */ Modified: trunk/util/flashrom/udelay.c =================================================================== --- trunk/util/flashrom/udelay.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/udelay.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,6 +1,6 @@ #include #include -#include "debug.h" +#include "flash.h" // count to a billion. Time it. If it's < 1 sec, count to 10B, etc. unsigned long micro = 1; Modified: trunk/util/flashrom/w49f002u.c =================================================================== --- trunk/util/flashrom/w49f002u.c 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/w49f002u.c 2007-08-23 13:34:59 UTC (rev 2746) @@ -28,8 +28,6 @@ #include #include "flash.h" -#include "jedec.h" -#include "w49f002u.h" int write_49f002(struct flashchip *flash, uint8_t *buf) { Deleted: trunk/util/flashrom/w49f002u.h =================================================================== --- trunk/util/flashrom/w49f002u.h 2007-08-23 10:20:40 UTC (rev 2745) +++ trunk/util/flashrom/w49f002u.h 2007-08-23 13:34:59 UTC (rev 2746) @@ -1,6 +0,0 @@ -#ifndef __W49F002U_H__ -#define __W49F002U_H__ 1 - -extern int write_49f002(struct flashchip *flash, uint8_t *buf); - -#endif /* !__W49F002U_H__ */ From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 23 03:32:09 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 23 Aug 2007 03:32:09 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support Message-ID: <46CCE399.6070608@gmx.net> This adds probing for almost all recent (since 1999) ITE Super I/O chips to probe_superio. Not much of the configuration is dumped, however I did verify against all ITE datasheets (including those not available any more) that the probing was non-destructive. More information can be extracted easily, however this needs loads of datasheet surfing. Signed-off-by: Carl-Daniel Hailfinger --- util/probe_superio/probe_superio.c (Revision 2744) +++ util/probe_superio/probe_superio.c (Arbeitskopie) @@ -3,6 +3,7 @@ * * Copyright (C) 2006 Ronald Minnich * Copyright (C) 2006 coresystems GmbH + * Copyright (C) 2007 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -32,11 +33,16 @@ * if we need this. */ -unsigned char regval(unsigned short port, unsigned short reg) { +unsigned char regval(unsigned short port, unsigned char reg) { outb(reg, port); return inb(port+1); } +void regwrite(unsigned short port, unsigned char reg, unsigned char val) { + outb(reg, port); + outb(val, port+1); +} + void dump_ns8374(unsigned short port) { printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", @@ -46,15 +52,13 @@ /* check COM1. This is all we care about at present. */ printf("COM 1 is Globally %s\n", regval(port,0x26)&8 ? "disabled" : "enabled"); /* select com1 */ - outb(0x7, port); - outb(3, port+1); + regwrite(port, 0x07, 0x03); printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); /* select gpio */ - outb(0x7, port); - outb(7, port+1); + regwrite(port, 0x07, 0x07); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), @@ -85,38 +89,33 @@ printf("2b=%02x\n", regval(port, 0x2b)); /* select UART 1 */ - outb(0x07, port); - outb(0x01, port+1); + regwrite(port, 0x07, 0x01); printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, regval(port, 0xf0)&0x10 ? "RS485":"RS232"); /* select UART 2 */ - outb(0x07, port); - outb(0x02, port+1); + regwrite(port, 0x07, 0x02); printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, regval(port, 0xf0)&0x10 ? "RS485":"RS232"); /* select Parport */ - outb(0x07, port); - outb(0x03, port+1); + regwrite(port, 0x07, 0x03); printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("PARPORT base=%02x%02x, irq=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); /* select hw monitor */ - outb(0x07, port); - outb(0x04, port+1); + regwrite(port, 0x07, 0x04); printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("HW monitor base=%02x%02x, irq=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); /* select gpio */ - outb(0x07, port); - outb(0x06, port+1); + regwrite(port, 0x07, 0x05); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), @@ -130,7 +129,20 @@ } +void +dump_ite(unsigned short port) +{ + int i; + printf ("ITE chip\n"); + for (i=0x20; i<=0x2c; i++) + printf("index %02x=%02x\n", i, regval(port, i)); + + /* select UART 1 */ + regwrite(port, 0x07, 0x01); + printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); +} + void probe_idregs_simple(unsigned short port){ unsigned char id; @@ -167,9 +179,10 @@ void probe_idregs_fintek(unsigned short port){ - unsigned int vid, did; + unsigned int vid, did, success; // Enable configuration sequence (Fintek uses this for example) + // Older ITE chips have the same enable sequence outb(0x87, port); outb(0x87, port); @@ -185,13 +198,10 @@ } did = inb(port+1); - outb(0x21, port); - did = did|(inb(port+1)<<8); + did = did|(regval(port, 0x21)<<8); - outb(0x23, port); - vid = inb(port+1); - outb(0x24, port); - vid = vid|(inb(port+1)<<8); + vid = regval(port, 0x23); + vid = vid|(regval(port, 0x24)<<8); printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); @@ -199,23 +209,104 @@ return; // printf("%s\n", familyid[id]); + switch(did) { + case 0x1087: // reversed for ITE8710 + success = 1; + dump_ite(port); + // disable configuration + regwrite(port, 0x02, 0x02); + break; + default: + break; + } switch(vid) { case 0x3419: + success = 1; dump_fintek(port, did); break; default: - printf("no dump for 0x%04x/0x%04x\n", vid, did); break; } + if (!success) + printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); - // disable configuration + // disable configuration (for Fintek, doesn't hurt ITE) outb(0xaa, port); } void +probe_idregs_ite(unsigned short port){ + unsigned int id, chipver; + + // Enable configuration sequence (ITE uses this for newer IT87[012]x) + // IT871[01] uses 0x87, 0x87 -> fintek detection should handle it + // IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa + // IT86xx series uses different ports + // IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes + // IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes + outb(0x87, port); + outb(0x01, port); + outb(0x55, port); + if (port == 0x2e) + outb(0x55, port); + else + outb(0xAA, port); + + outb(0x20, port); + if (inb(port) != 0x20) { + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port+1)); + return; + } + + // Read Chip ID Byte 1, we already issued the write to port + id = inb(port+1); + id <<= 8; + + // Read Chip ID Byte 2 + id |= regval(port, 0x21); + + // Read Chip Version, only bit 3..0 for all IT87xx + chipver = regval(port, 0x22) & 0x0f; + + /* ID Mapping Table + unknown -> IT8711 (no datasheet) + unknown -> IT8722 (no datasheet) + 0x8702 -> IT8702 + 0x8705 -> IT8700 or IT8705 + 0x8710 -> IT8710 + 0x8712 -> IT8712 + 0x8716 -> IT8716 or IT8726 (identical except CPU voltage control) + 0x8718 -> IT8718 + */ + printf("ITE? SuperIO found at 0x%02x: id=0x%04x, chipver=0x%01x\n", + port, id, chipver); + + switch(id) { + case 0x8702: + case 0x8705: + case 0x8710: //pointless, IT8710 has different enable sequence + case 0x8712: + case 0x8716: + case 0x8718: + dump_ite(port); + break; + default: + printf("no dump for id 0x%04x\n", id); + break; + } + // disable configuration + regwrite(port, 0x02, 0x02); +} + +void probe_superio(unsigned short port) { probe_idregs_simple(port); probe_idregs_fintek(port); + probe_idregs_ite(port); } int From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 23 15:47:24 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 23 Aug 2007 15:47:24 +0200 Subject: [LinuxBIOS] [PATCH] [notready] my current v3 diff In-Reply-To: <20070822223317.GA17816@greenwood> References: <46CC6EE1.7060808@gmx.net> <20070822223317.GA17816@greenwood> Message-ID: <46CD8FEC.2040007@gmx.net> On 23.08.2007 00:33, Uwe Hermann wrote: > On Wed, Aug 22, 2007 at 07:14:09PM +0200, Carl-Daniel Hailfinger wrote: >>> Index: include/device/device.h >>> =================================================================== >>> --- include/device/device.h (Revision 476) >>> +++ include/device/device.h (Arbeitskopie) >>> @@ -202,7 +202,7 @@ >>> struct resource resource[MAX_RESOURCES]; >>> unsigned int resources; >>> >>> - /* link are (down sream) buses attached to the device, usually a leaf >>> + /* link are (downstream) buses attached to the device, usually a leaf > > ACK. > > >>> * device with no children have 0 buses attached and a bridge has 1 bus >>> */ >>> struct bus link[MAX_LINKS]; >>> Index: mainboard/adl/msm800sev/stage1.c >>> =================================================================== >>> --- mainboard/adl/msm800sev/stage1.c (Revision 476) >>> +++ mainboard/adl/msm800sev/stage1.c (Arbeitskopie) >>> @@ -33,7 +33,9 @@ >>> #include >>> #include >>> >>> +/* This is wrong! SERIAL_DEV can't be >=0x10 because it's a PNP device number */ >>> #define SERIAL_DEV 0x30 >>> +#define SERIAL_IOBASE 0x3f8 > > This is probably the wrong location for this information anyway. This is > hardware property and should thus be in the dts, IMHO. > This includes the 0x2e, the 0x30 (I think), and the 0x3f8. Is the dts already used in stage 1? Otherwise I would just get some of the values from the w83627hf.h >>> >>> void hardware_stage1(void) >>> { >>> @@ -49,6 +51,6 @@ >>> * for cs5536 >>> */ >>> cs5536_disable_internal_uart(); >>> - w83627hf_enable_serial(0x2e, 0x30, 0x3f8); >>> + w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE); >>> printk(BIOS_DEBUG, "Done %s\n", __FUNCTION__); >>> } >>> Index: device/device.c >>> =================================================================== >>> --- device/device.c (Revision 476) >>> +++ device/device.c (Arbeitskopie) >>> @@ -260,8 +260,10 @@ >>> for (curdev = bus->children; curdev; curdev = curdev->sibling) { >>> unsigned int links; >>> int i; >>> - printk(BIOS_SPEW, "%s: %s(%s) have_resources %d enabled %d\n", >>> + printk(BIOS_SPEW, >>> + "%s: %s(%s) dtsname %s have_resources %d enabled %d\n", >>> __func__, bus->dev->dtsname, dev_path(bus->dev), >>> + curdev->dtsname, >>> curdev->have_resources, curdev->enabled); >>> if (curdev->have_resources) { >>> continue; >>> @@ -402,7 +404,11 @@ >>> min_align = 0; >>> base = bridge->base; >>> >>> - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); >>> + printk(BIOS_SPEW, >>> + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d\n", >>> + dev_path(bus->dev), >>> + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", >>> + base, bridge->size, bridge->align, bridge->gran); >>> >>> /* We want different minimum alignments for different kinds of >>> * resources. These minimums are not device type specific but >>> @@ -485,7 +491,7 @@ >>> base += size; >>> >>> printk(BIOS_SPEW, >>> - "%s %02lx * [0x%08Lx - 0x%08Lx] %s\n", >>> + "%s %02lx * [0x%08llx - 0x%08llx] %s\n", > > Yep, I guess so. If this works (didn't follow the last printk-fixes > thread too closely), then please make one patch for all of these and > related printk-fixes. Will do. >>> dev_path(dev), >>> resource->index, >>> resource->base, >>> @@ -503,7 +509,11 @@ >>> */ >>> bridge->size = align_up(base, bridge->gran) - bridge->base; >>> >>> - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d done\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); >>> + printk(BIOS_SPEW, >>> + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d done\n", >>> + dev_path(bus->dev), >>> + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", >>> + base, bridge->size, bridge->align, bridge->gran); >>> } >>> >>> #if defined(CONFIG_PCI_OPTION_ROM_RUN) && CONFIG_PCI_OPTION_ROM_RUN == 1 >>> Index: device/pnp_device.c >>> =================================================================== >>> --- device/pnp_device.c (Revision 476) >>> +++ device/pnp_device.c (Arbeitskopie) >>> @@ -87,7 +87,7 @@ >>> { >>> if (!(resource->flags & IORESOURCE_ASSIGNED)) { >>> printk(BIOS_ERR, >>> - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", >>> + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", >>> dev_path(dev), resource->index, resource_type(resource), >>> resource->size); >>> return; >>> Index: device/pci_device.c >>> =================================================================== >>> --- device/pci_device.c (Revision 476) >>> +++ device/pci_device.c (Arbeitskopie) >>> @@ -252,10 +252,10 @@ >>> printk(BIOS_DEBUG, "%s %02x ->", >>> dev_path(dev), resource->index); >>> printk(BIOS_DEBUG, >>> - " value: 0x%08Lx zeroes: 0x%08Lx ones: 0x%08Lx attr: %08lx\n", >>> + " value: 0x%08llx zeroes: 0x%08llx ones: 0x%08llx attr: %08lx\n", > > Are we sure %ll will never produce more than 8 digits? On all > architectures? No, it can produce up to 16 digits even on 32bit. However, the digits will not be truncated, the "08" is a minimum length of 8 with leading zeroes. >>> value, zeroes, ones, attr); >>> printk(BIOS_DEBUG, >>> - "%s %02x -> size: 0x%08Lx max: 0x%08Lx %s\n ", >>> + "%s %02x -> size: 0x%08llx max: 0x%08llx %s\n ", >>> dev_path(dev), resource->index, resource->size, >>> resource->limit, resource_type(resource)); >>> } >>> @@ -456,7 +456,7 @@ >>> /* Make certain the resource has actually been set. */ >>> if (!(resource->flags & IORESOURCE_ASSIGNED)) { >>> printk(BIOS_ERR, >>> - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", >>> + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", >>> dev_path(dev), resource->index, resource_type(resource), >>> resource->size); >>> return; >>> @@ -863,7 +863,7 @@ >>> (*list)->path.type); >>> continue; >>> } >>> - printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%x\n", >>> + printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%02x\n", > > ACK, same for all other %x -> %02x (etc.) changes. > > >>> __func__, (*list)->dtsname, (*list)->path.u.pci.devfn); >>> if ((*list)->path.u.pci.devfn == devfn) { >>> /* Unlink from the list. */ >>> Index: device/device_util.c >>> =================================================================== >>> --- device/device_util.c (Revision 476) >>> +++ device/device_util.c (Arbeitskopie) >>> @@ -229,7 +229,7 @@ >>> memcpy(buffer, "Root Device", 12); >>> break; >>> case DEVICE_ID_PCI: >>> - sprintf(buffer, "PCI: %02x:%02x", id->u.pci.vendor, >>> + sprintf(buffer, "PCI: %04x:%04x", id->u.pci.vendor, >>> id->u.pci.device); >>> break; >>> case DEVICE_ID_PNP: >>> @@ -243,7 +243,7 @@ >>> id->u.apic.device); >>> break; >>> case DEVICE_ID_PCI_DOMAIN: >>> - sprintf(buffer, "PCI_DOMAIN: %02x:%02x", >>> + sprintf(buffer, "PCI_DOMAIN: %04x:%04x", >>> id->u.pci_domain.vendor, >>> id->u.pci_domain.device); >>> break; >>> @@ -602,7 +602,7 @@ >>> #endif >>> } >>> printk(BIOS_DEBUG, >>> - "%s %02lx <- [0x%010Lx - 0x%010Lx] %s%s%s\n", >>> + "%s %02lx <- [0x%010llx - 0x%010llx] %s%s%s\n", >>> dev_path(dev), >>> resource->index, >>> base, end, buf, resource_type(resource), comment); >>> @@ -656,7 +656,7 @@ >>> for (i = 0; i < curdev->resources; i++) { >>> struct resource *resource = &curdev->resource[i]; >>> printk(BIOS_SPEW, >>> - "%s: dev %s, resource %d, flags %lx base 0x%Lx size 0x%Lx\n", >>> + "%s: dev %s, resource %d, flags %lx base 0x%llx size 0x%llx\n", >>> __func__, curdev->dtsname, i, resource->flags, >>> resource->base, resource->size); >>> /* If it isn't the right kind of resource ignore it. */ >>> Index: lib/stage2.c >>> =================================================================== >>> --- lib/stage2.c (Revision 476) >>> +++ lib/stage2.c (Arbeitskopie) >>> @@ -31,8 +31,9 @@ >>> /** >>> * Main function of the DRAM part of LinuxBIOS. >>> * >>> - * LinuxBIOS is divided into pre-DRAM part and DRAM part. The phases before >>> - * this part are phase 0 and phase 1. This part contains phases x through y. >>> + * LinuxBIOS is divided into pre-DRAM part and DRAM part. The stages before >>> + * this part are stage 0 and stage 1. This part contains stage 2, which >>> + * consists of phases 1 through 6. > > Looks correct, but using "stages" _and_ "phases" will confuse the hell > out of everyone. I vote for only using stage 0-2, just drop the phases > terminology completely. Or maybe something like "which consists of > multiple steps"? I was just making the code comments conform to the design document. >>> * >>> * Device Enumeration: in the dev_enumerate() phase. >>> * >>> @@ -53,6 +54,7 @@ >>> >>> post_code(0x20); >>> >>> + /* TODO: Explain why we use printk here although it is impossible */ >>> printk(BIOS_NOTICE, console_test); > > Hm, good point. It works in QEMU, but that's not a good indicator in > this case. > > >>> >>> dev_init(); >>> Index: lib/elfboot.c >>> =================================================================== >>> --- lib/elfboot.c (Revision 476) >>> +++ lib/elfboot.c (Arbeitskopie) >>> @@ -61,7 +61,7 @@ >>> } >>> if (i == mem_entries) { >>> printk(BIOS_ERR, "No matching RAM area found for range:\n"); >>> - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx)\n", start, end); >>> + printk(BIOS_ERR, " [0x%016llx, 0x%016llx)\n", start, end); >>> printk(BIOS_ERR, "RAM areas\n"); >>> for(i = 0; i < mem_entries; i++) { >>> u64 mstart, mend; >>> @@ -69,7 +69,7 @@ >>> mtype = mem->map[i].type; >>> mstart = unpack_lb64(mem->map[i].start); >>> mend = mstart + unpack_lb64(mem->map[i].size); >>> - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx) %s\n", >>> + printk(BIOS_ERR, " [0x%016llx, 0x%016llx) %s\n", >>> mstart, mend, (mtype == LB_MEM_RAM)?"RAM":"Reserved"); >>> >>> } >>> Index: northbridge/intel/i440bxemulation/i440bx.c >>> =================================================================== >>> --- northbridge/intel/i440bxemulation/i440bx.c (Revision 476) >>> +++ northbridge/intel/i440bxemulation/i440bx.c (Arbeitskopie) >>> @@ -79,7 +79,7 @@ >>> resource->size = ((resource_t) sizek) << 10; >>> resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE | >>> IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; >>> - printk(BIOS_DEBUG, "%s: add ram resoource %Ld bytes\n", __func__, >>> + printk(BIOS_DEBUG, "%s: add ram resource %lld bytes\n", __func__, >>> resource->size); >>> } >>> >>> Index: arch/x86/linuxbios_table.c >>> =================================================================== >>> --- arch/x86/linuxbios_table.c (Revision 476) >>> +++ arch/x86/linuxbios_table.c (Arbeitskopie) >>> @@ -177,7 +177,7 @@ >>> { >>> int entries; >>> >>> - printk(BIOS_DEBUG, "%s: start 0x%Lx size 0x%Lx\n", >>> + printk(BIOS_DEBUG, "%s: start 0x%llx size 0x%llx\n", >>> __func__, start, size); >>> >>> entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); >>> Index: arch/x86/pci_ops_mmconf.c >>> =================================================================== >>> --- arch/x86/pci_ops_mmconf.c (Revision 476) >>> +++ arch/x86/pci_ops_mmconf.c (Arbeitskopie) >>> @@ -18,32 +18,32 @@ >>> >>> #include >>> >>> -static uint8_t pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) >>> +static u8 pci_mmconf_read_config8(struct bus *pbus, int bus, int devfn, int where) > > ACK (same for the other occurences). > > >>> { >>> return (read8x(PCI_MMIO_ADDR(bus, devfn, where))); >>> } >>> >>> -static uint16_t pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) >>> +static u16 pci_mmconf_read_config16(struct bus *pbus, int bus, int devfn, int where) >>> { >>> return (read16x(PCI_MMIO_ADDR(bus, devfn, where))); >>> } >>> >>> -static uint32_t pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) >>> +static u32 pci_mmconf_read_config32(struct bus *pbus, int bus, int devfn, int where) >>> { >>> return (read32x(PCI_MMIO_ADDR(bus, devfn, where))); >>> } >>> >>> -static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, uint8_t value) >>> +static void pci_mmconf_write_config8(struct bus *pbus, int bus, int devfn, int where, u8 value) >>> { >>> write8x(PCI_MMIO_ADDR(bus, devfn, where), value); >>> } >>> >>> -static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, uint16_t value) >>> +static void pci_mmconf_write_config16(struct bus *pbus, int bus, int devfn, int where, u16 value) >>> { >>> write8x(PCI_MMIO_ADDR(bus, devfn, where), value); >>> } >>> >>> -static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, uint32_t value) >>> +static void pci_mmconf_write_config32(struct bus *pbus, int bus, int devfn, int where, u32 value) >>> { >>> write8x(PCI_MMIO_ADDR(bus, devfn, where), value); >>> } > > > Please repost all of this as two or three separate patches, each fixing > a single issue repository-wide. I think we can apply this soon. Will do. Thanks for the review. Regards, Carl-Daniel From uwe at hermann-uwe.de Thu Aug 23 15:57:40 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 15:57:40 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop useless header files In-Reply-To: <20070823111614.GA3171@coresystems.de> References: <20070823104904.GD15343@greenwood> <20070823111614.GA3171@coresystems.de> Message-ID: <20070823135740.GF15343@greenwood> On Thu, Aug 23, 2007 at 01:16:14PM +0200, Stefan Reinauer wrote: > > Signed-off-by: Uwe Hermann > Acked-by: Stefan Reinauer r2746. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Thu Aug 23 16:00:12 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 16:00:12 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop duplicated code Message-ID: <20070823140011.GG15343@greenwood> See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_drop_duplicated_code.patch Type: text/x-diff Size: 3722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From info at coresystems.de Thu Aug 23 16:21:44 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 23 Aug 2007 16:21:44 +0200 Subject: [LinuxBIOS] r2746 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2746 to the LinuxBIOS source repository and caused the following changes: Change Log: Drop a bunch of useless header files, merge them into flash.h. Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2746&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From stepan at coresystems.de Thu Aug 23 16:28:13 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 23 Aug 2007 16:28:13 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop duplicated code In-Reply-To: <20070823140011.GG15343@greenwood> References: <20070823140011.GG15343@greenwood> Message-ID: <20070823142813.GC5550@coresystems.de> * Uwe Hermann [070823 16:00]: > Drop duplicated code (copies of plain JEDEC functions). > > Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer -- 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 stepan at coresystems.de Thu Aug 23 16:54:15 2007 From: stepan at coresystems.de (Stefan Reinauer) Date: Thu, 23 Aug 2007 16:54:15 +0200 Subject: [LinuxBIOS] [PATCH][v3] small lar fix In-Reply-To: References: Message-ID: <20070823145415.GA14836@coresystems.de> * Patrick Georgi [070822 14:57]: > Index: util/lar/stream.c > =================================================================== > --- util/lar/stream.c (revision 478) > +++ util/lar/stream.c (working copy) > @@ -666,7 +666,7 @@ > > csum = 0; > for (walk = (u32 *) (lar->map + offset); > - walk < (u32 *) (temp + complen + hlen); > + walk < (u32 *) (lar->map + complen + hlen); I would think it should be walk < (u32 *) (lar->map + offset + complen + hlen) because temp was copied to lar->map + offset before. But I agree this needs fixing: Acked-by: Stefan Reinauer -- 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 svn at openbios.org Thu Aug 23 17:20:38 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 23 Aug 2007 17:20:38 +0200 Subject: [LinuxBIOS] r2747 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-08-23 17:20:38 +0200 (Thu, 23 Aug 2007) New Revision: 2747 Modified: trunk/util/flashrom/82802ab.c trunk/util/flashrom/m29f400bt.c trunk/util/flashrom/sharplhf00l04.c Log: Drop duplicated code (copies of plain JEDEC functions). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Modified: trunk/util/flashrom/82802ab.c =================================================================== --- trunk/util/flashrom/82802ab.c 2007-08-23 13:34:59 UTC (rev 2746) +++ trunk/util/flashrom/82802ab.c 2007-08-23 15:20:38 UTC (rev 2747) @@ -27,46 +27,6 @@ #include #include "flash.h" -void toggle_ready_82802ab(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; - - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -void data_polling_82802ab(volatile uint8_t *dst, uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -void protect_82802ab(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0xA0; - - usleep(200); -} - // I need that Berkeley bit-map printer void print_82802ab_status(uint8_t status) { @@ -215,6 +175,6 @@ printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); } printf("\n"); - protect_82802ab(bios); + protect_jedec(bios); return (0); } Modified: trunk/util/flashrom/m29f400bt.c =================================================================== --- trunk/util/flashrom/m29f400bt.c 2007-08-23 13:34:59 UTC (rev 2746) +++ trunk/util/flashrom/m29f400bt.c 2007-08-23 15:20:38 UTC (rev 2747) @@ -25,37 +25,6 @@ #include "flash.h" -void toggle_ready_m29f400bt(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; - - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -void data_polling_m29f400bt(volatile uint8_t *dst, uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - void protect_m29f400bt(volatile uint8_t *bios) { *(volatile uint8_t *)(bios + 0xAAA) = 0xAA; @@ -79,7 +48,7 @@ *dst = *src; //*(volatile char *) (bios) = 0xF0; //usleep(5); - toggle_ready_m29f400bt(dst); + toggle_ready_jedec(dst); printf ("Value in the flash at address %p = %#x, want %#x\n", (uint8_t *) (dst - bios), *dst, *src); @@ -129,7 +98,7 @@ *(volatile uint8_t *)(bios + 0xAAA) = 0x10; myusec_delay(10); - toggle_ready_m29f400bt(bios); + toggle_ready_jedec(bios); return (0); } @@ -147,7 +116,7 @@ *dst = 0x30; myusec_delay(10); - toggle_ready_m29f400bt(bios); + toggle_ready_jedec(bios); return (0); } Modified: trunk/util/flashrom/sharplhf00l04.c =================================================================== --- trunk/util/flashrom/sharplhf00l04.c 2007-08-23 13:34:59 UTC (rev 2746) +++ trunk/util/flashrom/sharplhf00l04.c 2007-08-23 15:20:38 UTC (rev 2747) @@ -26,46 +26,6 @@ #include #include "flash.h" -void toggle_ready_lhf00l04(volatile uint8_t *dst) -{ - unsigned int i = 0; - uint8_t tmp1, tmp2; - - tmp1 = *dst & 0x40; - - while (i++ < 0xFFFFFF) { - tmp2 = *dst & 0x40; - if (tmp1 == tmp2) { - break; - } - tmp1 = tmp2; - } -} - -void data_polling_lhf00l04(volatile uint8_t *dst, uint8_t data) -{ - unsigned int i = 0; - uint8_t tmp; - - data &= 0x80; - - while (i++ < 0xFFFFFF) { - tmp = *dst & 0x80; - if (tmp == data) { - break; - } - } -} - -void protect_lhf00l04(volatile uint8_t *bios) -{ - *(volatile uint8_t *)(bios + 0x5555) = 0xAA; - *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; - *(volatile uint8_t *)(bios + 0x5555) = 0xA0; - - usleep(200); -} - // I need that Berkeley bit-map printer void print_lhf00l04_status(uint8_t status) { @@ -217,6 +177,6 @@ printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); } printf("\n"); - protect_lhf00l04(bios); + protect_jedec(bios); return (0); } From uwe at hermann-uwe.de Thu Aug 23 17:21:21 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 17:21:21 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Drop duplicated code In-Reply-To: <20070823142813.GC5550@coresystems.de> References: <20070823140011.GG15343@greenwood> <20070823142813.GC5550@coresystems.de> Message-ID: <20070823152121.GH15343@greenwood> On Thu, Aug 23, 2007 at 04:28:13PM +0200, Stefan Reinauer wrote: > > Signed-off-by: Uwe Hermann > Acked-by: Stefan Reinauer r2747. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From info at coresystems.de Thu Aug 23 18:06:58 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 23 Aug 2007 18:06:58 +0200 Subject: [LinuxBIOS] r2747 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2747 to the LinuxBIOS source repository and caused the following changes: Change Log: Drop duplicated code (copies of plain JEDEC functions). Signed-off-by: Uwe Hermann Acked-by: Stefan Reinauer Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2747&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From svn at openbios.org Thu Aug 23 18:08:22 2007 From: svn at openbios.org (svn at openbios.org) Date: Thu, 23 Aug 2007 18:08:22 +0200 Subject: [LinuxBIOS] r2748 - trunk/util/flashrom Message-ID: Author: uwe Date: 2007-08-23 18:08:21 +0200 (Thu, 23 Aug 2007) New Revision: 2748 Modified: trunk/util/flashrom/82802ab.c trunk/util/flashrom/am29f040b.c trunk/util/flashrom/board_enable.c trunk/util/flashrom/chipset_enable.c trunk/util/flashrom/flashchips.c trunk/util/flashrom/flashrom.c trunk/util/flashrom/jedec.c trunk/util/flashrom/layout.c trunk/util/flashrom/lbtable.c trunk/util/flashrom/m29f400bt.c trunk/util/flashrom/msys_doc.c trunk/util/flashrom/mx29f002.c trunk/util/flashrom/pm49fl004.c trunk/util/flashrom/sharplhf00l04.c trunk/util/flashrom/sst28sf040.c trunk/util/flashrom/sst39sf020.c trunk/util/flashrom/sst49lf040.c trunk/util/flashrom/sst49lfxxxc.c trunk/util/flashrom/sst_fwhub.c trunk/util/flashrom/w49f002u.c Log: Cosmetic fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Modified: trunk/util/flashrom/82802ab.c =================================================================== --- trunk/util/flashrom/82802ab.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/82802ab.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -77,7 +77,6 @@ uint8_t wait_82802ab(volatile uint8_t *bios) { - uint8_t status; uint8_t id1, id2; @@ -100,9 +99,10 @@ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; *(volatile uint8_t *)(bios + 0x5555) = 0xF0; + return status; +} -} int erase_82802ab_block(struct flashchip *flash, int offset) { volatile uint8_t *bios = flash->virtual_memory + offset; @@ -126,8 +126,10 @@ status = wait_82802ab(flash->virtual_memory); //print_82802ab_status(status); printf("DONE BLOCK 0x%x\n", offset); - return (0); + + return 0; } + int erase_82802ab(struct flashchip *flash) { int i; @@ -138,7 +140,8 @@ for (i = 0; i < total_size; i += flash->page_size) erase_82802ab_block(flash, i); printf("DONE ERASE\n"); - return (0); + + return 0; } void write_page_82802ab(volatile uint8_t *bios, uint8_t *src, @@ -152,7 +155,6 @@ *dst++ = *src++; wait_82802ab(bios); } - } int write_82802ab(struct flashchip *flash, uint8_t *buf) @@ -176,5 +178,6 @@ } printf("\n"); protect_jedec(bios); - return (0); + + return 0; } Modified: trunk/util/flashrom/am29f040b.c =================================================================== --- trunk/util/flashrom/am29f040b.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/am29f040b.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -41,7 +41,7 @@ /* wait for Toggle bit ready */ toggle_ready_jedec(bios + address); - return (0); + return 0; } static __inline__ int write_sector_29f040b(volatile uint8_t *bios, @@ -68,7 +68,7 @@ printf("\b\b\b\b\b\b\b\b\b\b"); } - return (0); + return 0; } int probe_29f040b(struct flashchip *flash) @@ -108,7 +108,7 @@ myusec_delay(10); toggle_ready_jedec(bios); - return (0); + return 0; } int write_29f040b(struct flashchip *flash, uint8_t *buf) @@ -131,5 +131,5 @@ } printf("\n"); - return (0); + return 0; } Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/board_enable.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -22,7 +22,7 @@ #include "flash.h" /* - * Helper functions for many Winbond superIOs of the w836xx range. + * Helper functions for many Winbond Super I/Os of the W836xx range. */ #define W836_INDEX 0x2E #define W836_DATA 0x2F @@ -40,7 +40,7 @@ outb(0xAA, W836_INDEX); } -/* General functions for read/writing WB SuperIOs */ +/* General functions for reading/writing Winbond Super I/Os. */ static unsigned char wbsio_read(unsigned char index) { outb(index, W836_INDEX); @@ -53,8 +53,8 @@ outb(data, W836_DATA); } -static void -wbsio_mask(unsigned char index, unsigned char data, unsigned char mask) +static void wbsio_mask(unsigned char index, unsigned char data, + unsigned char mask) { unsigned char tmp; @@ -63,14 +63,13 @@ outb(tmp | (data & mask), W836_DATA); } -/* - * WinBond w83627hf: raise GPIO24. +/** + * Winbond W83627HF: Raise GPIO24. * * Suited for: - * * Agami Aruma - * * IWILL DK8-HTX + * - Agami Aruma + * - IWILL DK8-HTX */ - static int w83627hf_gpio24_raise(const char *name) { w836xx_ext_enter(); @@ -101,12 +100,11 @@ return 0; } -/* +/** * Suited for VIAs EPIA M and MII, and maybe other CLE266 based EPIAs. * - * We don't need to do this when using linuxbios, GPIO15 is never lowered there. + * We don't need to do this when using LinuxBIOS, GPIO15 is never lowered there. */ - static int board_via_epia_m(const char *name) { struct pci_dev *dev; @@ -135,12 +133,11 @@ return 0; } -/* +/** * Suited for: - * ASUS A7V8X-MX SE and A7V400-MX: AMD K7 + VIA KM400A + VT8235 - * Tyan Tomcat K7M: AMD Geode NX + VIA KM400 + VT8237. + * - ASUS A7V8X-MX SE and A7V400-MX: AMD K7 + VIA KM400A + VT8235 + * - Tyan Tomcat K7M: AMD Geode NX + VIA KM400 + VT8237. */ - static int board_asus_a7v8x_mx(const char *name) { struct pci_dev *dev; @@ -170,14 +167,13 @@ return 0; } -/* +/** * Suited for ASUS P5A. * * This is rather nasty code, but there's no way to do this cleanly. * We're basically talking to some unknown device on SMBus, my guess * is that it is the Winbond W83781D that lives near the DIP BIOS. */ - static int board_asus_p5a(const char *name) { uint8_t tmp; @@ -278,16 +274,14 @@ return 0; } -/* - * We use 2 sets of ids here, you're free to choose which is which. This - * to provide a very high degree of certainty when matching a board on - * the basis of Subsystem/card ids. As not every vendor handles - * subsystem/card ids in a sane manner. +/** + * We use 2 sets of IDs here, you're free to choose which is which. This + * is to provide a very high degree of certainty when matching a board on + * the basis of subsystem/card IDs. As not every vendor handles + * subsystem/card IDs in a sane manner. * - * Keep the second set nulled if it should be ignored. - * + * Keep the second set NULLed if it should be ignored. */ - struct board_pciid_enable { /* Any device, but make it sensible, like the isa bridge. */ uint16_t first_vendor; @@ -331,10 +325,9 @@ {0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL} /* Keep this */ }; -/* - * Match boards on linuxbios table gathered vendor and part name. - * Require main pci-ids to match too as extra safety. - * +/** + * Match boards on LinuxBIOS table gathered vendor and part name. + * Require main PCI IDs to match too as extra safety. */ static struct board_pciid_enable *board_match_linuxbios_name(char *vendor, char *part) @@ -359,9 +352,9 @@ return NULL; } -/* - * Match boards on pci ids and subsystem ids. - * Second set of ids can be main only or missing completely. +/** + * Match boards on PCI IDs and subsystem IDs. + * Second set of IDs can be main only or missing completely. */ static struct board_pciid_enable *board_match_pci_card_ids(void) { @@ -396,9 +389,6 @@ return NULL; } -/* - * - */ int board_flash_enable(char *vendor, char *part) { struct board_pciid_enable *board = NULL; Modified: trunk/util/flashrom/chipset_enable.c =================================================================== --- trunk/util/flashrom/chipset_enable.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/chipset_enable.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -112,6 +112,7 @@ printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", xbcs, new, name); return -1; } + return 0; } @@ -145,6 +146,7 @@ printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", bios_cntl, new, name); return -1; } + return 0; } @@ -158,14 +160,11 @@ return enable_flash_ich(dev, name, 0xdc); } -/* - * - */ static int enable_flash_vt823x(struct pci_dev *dev, char *name) { uint8_t val; - /* ROM Write enable */ + /* ROM write enable */ val = pci_read_byte(dev, 0x40); val |= 0x10; pci_write_byte(dev, 0x40, val); @@ -221,6 +220,7 @@ printf("tried to set register 0x%x to 0x%x on %s failed (WARNING ONLY)\n", 0x52, new, name); return -1; } + return 0; } @@ -243,6 +243,7 @@ printf("Stuck at 0x%x\n", newer); return -1; } + return 0; } @@ -275,6 +276,7 @@ printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", 0x40, new, name); return -1; } + return 0; } @@ -308,6 +310,7 @@ printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", 0x6d, new, name); return -1; } + return 0; } @@ -393,7 +396,6 @@ } return 0; - } static int enable_flash_ht1000(struct pci_dev *dev, char *name) @@ -406,7 +408,7 @@ pci_write_byte(dev, 0x41, byte); byte = pci_read_byte(dev, 0x43); - byte |= (1<<4); + byte |= (1 << 4); pci_write_byte(dev, 0x43, byte); return 0; @@ -473,9 +475,6 @@ {0x1166, 0x0205, "Broadcom HT-1000", enable_flash_ht1000}, }; -/* - * - */ int chipset_flash_enable(void) { struct pci_dev *dev = 0; Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/flashchips.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -150,5 +150,3 @@ probe_jedec, erase_chip_jedec, write_49f002}, {NULL,} }; - - Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/flashrom.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -49,12 +49,8 @@ struct pci_access *pacc; /* For board and chipset_enable */ int exclude_start_page, exclude_end_page; int force = 0, verbose = 0; - int fd_mem; -/* - * - */ struct pci_dev *pci_dev_find(uint16_t vendor, uint16_t device) { struct pci_dev *temp; @@ -71,9 +67,6 @@ return NULL; } -/* - * - */ struct pci_dev *pci_card_find(uint16_t vendor, uint16_t device, uint16_t card_vendor, uint16_t card_device) { @@ -163,6 +156,7 @@ flash++; } + return NULL; } @@ -196,6 +190,7 @@ printf("\b\b\b\b\b\b\b\b\b\b "); printf("- VERIFIED \n"); + return 0; } Modified: trunk/util/flashrom/jedec.c =================================================================== --- trunk/util/flashrom/jedec.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/jedec.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -135,7 +135,7 @@ /* wait for Toggle bit ready */ toggle_ready_jedec(bios); - return (0); + return 0; } int erase_block_jedec(volatile uint8_t *bios, unsigned int block) @@ -158,7 +158,7 @@ /* wait for Toggle bit ready */ toggle_ready_jedec(bios); - return (0); + return 0; } int erase_chip_jedec(struct flashchip *flash) @@ -182,7 +182,7 @@ toggle_ready_jedec(bios); - return (0); + return 0; } int write_page_write_jedec(volatile uint8_t *bios, uint8_t *src, @@ -229,7 +229,7 @@ fprintf(stderr, " page %d failed!\n", (unsigned int)(d - bios) / page_size); } - return (!ok); + return !ok; } int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, @@ -259,7 +259,7 @@ if (tried >= MAX_REFLASH_TRIES) ok = 0; - return (!ok); + return !ok; } int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, @@ -272,7 +272,7 @@ dst++, src++; } - return (0); + return 0; } int write_jedec(struct flashchip *flash, uint8_t *buf) @@ -301,5 +301,5 @@ printf("\n"); protect_jedec(bios); - return (0); + return 0; } Modified: trunk/util/flashrom/layout.c =================================================================== --- trunk/util/flashrom/layout.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/layout.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -134,6 +134,7 @@ } fclose(romlayout); + return 0; } @@ -155,6 +156,7 @@ } printf("not found.\n"); // Not found. Error. + return -1; } Modified: trunk/util/flashrom/lbtable.c =================================================================== --- trunk/util/flashrom/lbtable.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/lbtable.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -44,6 +44,7 @@ } value; unsigned long sum; unsigned long i; + /* In the most straight forward way possible, * compute an ip style checksum. */ @@ -64,6 +65,7 @@ } value.byte[0] = sum & 0xff; value.byte[1] = (sum >> 8) & 0xff; + return (~value.word) & 0xFFFF; } @@ -78,10 +80,12 @@ { struct lb_record *rec; int count; + count = 0; for_each_lbrec(head, rec) { count++; } + return count; } @@ -89,6 +93,7 @@ unsigned long end) { unsigned long addr; + /* For now be stupid.... */ for (addr = start; addr < end; addr += 16) { struct lb_header *head = @@ -123,6 +128,7 @@ return head; }; + return 0; } @@ -131,6 +137,7 @@ struct lb_mainboard *rec; int max_size; char vendor[256], part[256]; + rec = (struct lb_mainboard *)ptr; max_size = rec->size - sizeof(*rec); printf("vendor id: %.*s part id: %.*s\n", @@ -206,5 +213,6 @@ printf("No LinuxBIOS table found.\n"); return -1; } + return 0; } Modified: trunk/util/flashrom/m29f400bt.c =================================================================== --- trunk/util/flashrom/m29f400bt.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/m29f400bt.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -100,7 +100,7 @@ myusec_delay(10); toggle_ready_jedec(bios); - return (0); + return 0; } int block_erase_m29f400bt(volatile uint8_t *bios, volatile uint8_t *dst) @@ -118,7 +118,7 @@ myusec_delay(10); toggle_ready_jedec(bios); - return (0); + return 0; } int write_m29f400bt(struct flashchip *flash, uint8_t *buf) @@ -173,7 +173,7 @@ printf("\n"); //protect_m29f400bt (bios); - return (0); + return 0; } int write_linuxbios_m29f400bt(struct flashchip *flash, uint8_t *buf) @@ -215,5 +215,5 @@ printf("\n"); //protect_m29f400bt (bios); - return (0); + return 0; } Modified: trunk/util/flashrom/msys_doc.c =================================================================== --- trunk/util/flashrom/msys_doc.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/msys_doc.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -134,23 +134,23 @@ && id_0x55 == 0x55 && id_0xAA == 0xaa #endif /* !MSYSTEMS_DOC_NO_55AA_CHECKING */ ) { - return (1); + return 1; } - return (0); -} /* int probe_md2802(struct flashchip *flash) */ + return 0; +} int read_md2802(struct flashchip *flash, uint8_t *buf) { + return 0; +} - return (0); -} /* int read_md2802(struct flashchip *flash, uint8_t *buf) */ - int erase_md2802(struct flashchip *flash) { volatile uint8_t *bios = flash->virtual_memory; - return (1); + return 1; + *(volatile uint8_t *)(bios + 0x5555) = 0xAA; *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; *(volatile uint8_t *)(bios + 0x5555) = 0x80; @@ -158,7 +158,7 @@ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; *(volatile uint8_t *)(bios + 0x5555) = 0x10; -} /* int erase_md2802(struct flashchip *flash) */ +} int write_md2802(struct flashchip *flash, uint8_t *buf) { @@ -192,6 +192,7 @@ 0: ready -1: timeout expired */ + static int doc_wait(volatile uint8_t *bios, int timeout) { int i = 20; @@ -210,8 +211,8 @@ return (-1); } - return (0); -} /* static int doc_wait(volatile uint8_t *bios, int timeout) */ + return 0; +} static uint8_t doc_read_docstatus(volatile uint8_t *bios) { @@ -219,7 +220,7 @@ doc_read_2nop(bios); return (doc_read(bios, _DOCStatus)); -} /* static uint8_t doc_read_docstatus(volatile uint8_t *bios) */ +} static uint8_t doc_read_chipid(volatile uint8_t *bios) { @@ -227,7 +228,7 @@ doc_read_2nop(bios); return (doc_read(bios, _ChipID)); -} /* static uint8_t doc_read_chipid(volatile uint8_t *bios) */ +} static uint8_t doc_read_cdsncontrol(volatile uint8_t *bios) { @@ -240,11 +241,11 @@ value = doc_read(bios, _CDSNControl); doc_read_2nop(bios); - return (value); -} /* static uint8_t doc_read_chipid(volatile char *bios) */ + return value; +} static void doc_write_cdsncontrol(volatile uint8_t *bios, uint8_t data) { doc_write(data, bios, _CDSNControl); doc_read_4nop(bios); -} /* static void doc_write_chipid(volatile char *bios, uint8_t data) */ +} Modified: trunk/util/flashrom/mx29f002.c =================================================================== --- trunk/util/flashrom/mx29f002.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/mx29f002.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -79,7 +79,7 @@ *(bios + 0x3bfff) = 0x30; #endif - return (0); + return 0; } int write_29f002(struct flashchip *flash, uint8_t *buf) @@ -113,5 +113,5 @@ #endif printf("\n"); - return (0); + return 0; } Modified: trunk/util/flashrom/pm49fl004.c =================================================================== --- trunk/util/flashrom/pm49fl004.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/pm49fl004.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -51,5 +51,5 @@ } printf("\n"); - return (0); + return 0; } Modified: trunk/util/flashrom/sharplhf00l04.c =================================================================== --- trunk/util/flashrom/sharplhf00l04.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sharplhf00l04.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -77,7 +77,6 @@ uint8_t wait_lhf00l04(volatile uint8_t *bios) { - uint8_t status; uint8_t id1, id2; @@ -100,9 +99,10 @@ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; *(volatile uint8_t *)(bios + 0x5555) = 0xF0; + return status; +} -} int erase_lhf00l04_block(struct flashchip *flash, int offset) { volatile uint8_t *bios = flash->virtual_memory + offset; @@ -128,8 +128,10 @@ status = wait_lhf00l04(flash->virtual_memory); print_lhf00l04_status(status); printf("DONE BLOCK 0x%x\n", offset); - return (0); + + return 0; } + int erase_lhf00l04(struct flashchip *flash) { int i; @@ -140,7 +142,8 @@ for (i = 0; i < total_size; i += flash->page_size) erase_lhf00l04_block(flash, i); printf("DONE ERASE\n"); - return (0); + + return 0; } void write_page_lhf00l04(volatile uint8_t *bios, uint8_t *src, @@ -154,7 +157,6 @@ *dst++ = *src++; wait_lhf00l04(bios); } - } int write_lhf00l04(struct flashchip *flash, uint8_t *buf) @@ -178,5 +180,6 @@ } printf("\n"); protect_jedec(bios); - return (0); + + return 0; } Modified: trunk/util/flashrom/sst28sf040.c =================================================================== --- trunk/util/flashrom/sst28sf040.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sst28sf040.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -73,7 +73,7 @@ /* wait for Toggle bit ready */ toggle_ready_jedec(bios); - return (0); + return 0; } static __inline__ int write_sector_28sf040(volatile uint8_t *bios, @@ -98,7 +98,7 @@ toggle_ready_jedec(bios); } - return (0); + return 0; } int probe_28sf040(struct flashchip *flash) @@ -137,7 +137,7 @@ myusec_delay(10); toggle_ready_jedec(bios); - return (0); + return 0; } int write_28sf040(struct flashchip *flash, uint8_t *buf) @@ -164,5 +164,5 @@ protect_28sf040(bios); - return (0); + return 0; } Modified: trunk/util/flashrom/sst39sf020.c =================================================================== --- trunk/util/flashrom/sst39sf020.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sst39sf020.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -42,7 +42,7 @@ /* wait for Toggle bit ready */ toggle_ready_jedec(bios); - return (0); + return 0; } int write_39sf020(struct flashchip *flash, uint8_t *buf) @@ -65,5 +65,5 @@ } printf("\n"); - return (0); + return 0; } Modified: trunk/util/flashrom/sst49lf040.c =================================================================== --- trunk/util/flashrom/sst49lf040.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sst49lf040.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -24,6 +24,7 @@ * TODO: Consilidated to standard JEDEC code. * */ + #include #include "flash.h" @@ -39,6 +40,7 @@ * for the 49lf040. Use sector-erase instead */ erase_sector_jedec(bios, i * page_size); } + return 0; } @@ -67,5 +69,5 @@ } printf("\n"); - return (0); + return 0; } Modified: trunk/util/flashrom/sst49lfxxxc.c =================================================================== --- trunk/util/flashrom/sst49lfxxxc.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sst49lfxxxc.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -71,7 +71,7 @@ //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFc00000 - size + address + 2, *(bios + address + 2) ); *(bios + address + 2) = bits; - return (0); + return 0; } static __inline__ int erase_sector_49lfxxxc(volatile uint8_t *bios, @@ -91,7 +91,7 @@ } } while (!(status & STATUS_WSMS)); - return (0); + return 0; } static __inline__ int write_sector_49lfxxxc(volatile uint8_t *bios, @@ -124,7 +124,7 @@ } while (!(status & STATUS_WSMS)); } - return (0); + return 0; } int probe_49lfxxxc(struct flashchip *flash) @@ -164,7 +164,8 @@ return (-1); *bios = RESET; - return (0); + + return 0; } int write_49lfxxxc(struct flashchip *flash, uint8_t *buf) @@ -189,5 +190,6 @@ printf("\n"); *bios = RESET; - return (0); + + return 0; } Modified: trunk/util/flashrom/sst_fwhub.c =================================================================== --- trunk/util/flashrom/sst_fwhub.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/sst_fwhub.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -56,7 +56,7 @@ erase_block_jedec(flash->virtual_memory, offset); toggle_ready_jedec(flash->virtual_memory); - return (0); + return 0; } int erase_sst_fwhub(struct flashchip *flash) @@ -66,7 +66,8 @@ for (i = 0; i < total_size; i += flash->page_size) erase_sst_fwhub_block(flash, i); - return (0); + + return 0; } int write_sst_fwhub(struct flashchip *flash, uint8_t *buf) @@ -95,5 +96,6 @@ printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); } printf("\n"); - return (0); + + return 0; } Modified: trunk/util/flashrom/w49f002u.c =================================================================== --- trunk/util/flashrom/w49f002u.c 2007-08-23 15:20:38 UTC (rev 2747) +++ trunk/util/flashrom/w49f002u.c 2007-08-23 16:08:21 UTC (rev 2748) @@ -49,5 +49,5 @@ } printf("\n"); - return (0); + return 0; } From info at coresystems.de Thu Aug 23 18:53:44 2007 From: info at coresystems.de (LinuxBIOS information) Date: Thu, 23 Aug 2007 18:53:44 +0200 Subject: [LinuxBIOS] r2748 build service Message-ID: Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2748 to the LinuxBIOS source repository and caused the following changes: Change Log: Cosmetic fixes (trivial). Signed-off-by: Uwe Hermann Acked-by: Uwe Hermann Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=hdama&vendor=arima Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=e325&vendor=ibm Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=e326&vendor=ibm Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=juki-511p&vendor=iei Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=dk8s2&vendor=iwill Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2748&device=dk8x&vendor=iwill If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system From uwe at hermann-uwe.de Thu Aug 23 18:56:55 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Thu, 23 Aug 2007 18:56:55 +0200 Subject: [LinuxBIOS] [PATCH] flashrom: Merge common code into a function Message-ID: <20070823165655.GI15343@greenwood> See patch. This is _not_ tested (other than that it compiles). Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: flashrom_writeloop.patch Type: text/x-diff Size: 12976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From weatchu at gmail.com Thu Aug 23 22:06:42 2007 From: weatchu at gmail.com (Jon Bradley) Date: Thu, 23 Aug 2007 12:06:42 -0800 Subject: [LinuxBIOS] 440bx laptop(s) Message-ID: <4b86cc00708231306s468d7d1fu2195071067021e97@mail.gmail.com> Hi, I have (5) 440bx laptops, that would be much more useful if they booted fast, but messing with the bios seems like a scary thing. I compile LFS (linuxfromscratch) on all of these and customize them with fvwm, very few programs, firefox, abiword, xcalc, some quick scripts to reset the wifi, then give them away, (or sell them :) Anyway, my question: Would it be a cut and dry operation to install LinuxBIOS on the 440bx laptops? One is a ibm 240, 300mhz celeron, the other four are Solis (basicly renamed dell) 266mhz p2's .. all 440bx. Jon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 23 22:25:48 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 23 Aug 2007 22:25:48 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) Message-ID: <46CDED4C.4030202@gmx.net> This adds probing for almost all recent (since 1999) ITE Super I/O chips to probe_superio. Not much of the configuration is dumped, however I did verify against all ITE datasheets (including those not available any more) that the probing was non-destructive. More information can be extracted easily, however this needs loads of datasheet surfing. Signed-off-by: Carl-Daniel Hailfinger -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: linuxbios_probesuperio_itebasic02.diff URL: From rmh at aybabtu.com Thu Aug 23 22:42:06 2007 From: rmh at aybabtu.com (Robert Millan) Date: Thu, 23 Aug 2007 22:42:06 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) In-Reply-To: <46CDED4C.4030202@gmx.net> References: <46CDED4C.4030202@gmx.net> Message-ID: <20070823204206.GA22881@thorin> On Thu, Aug 23, 2007 at 10:25:48PM +0200, Carl-Daniel Hailfinger wrote: > This adds probing for almost all recent (since 1999) ITE Super I/O chips > to probe_superio. Not much of the configuration is dumped, however I did > verify against all ITE datasheets (including those not available any > more) that the probing was non-destructive. > More information can be extracted easily, however this needs loads of > datasheet surfing. Hi Carl-Daniel, Tried on a pair of boards as requested. With IT8702F-A: No SuperIO chip found at 0x002e No SuperIO chip found at 0x002e ITE? SuperIO found at 0x2e: id=0x8702, chipver=0x3 ITE chip index 20=87 index 21=02 index 22=03 index 23=40 index 24=00 UART1 is enabled No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e With IT8712F-A: No SuperIO chip found at 0x002e No SuperIO chip found at 0x002e ITE? SuperIO found at 0x2e: id=0x8712, chipver=0x7 ITE chip index 20=87 index 21=12 index 22=07 index 23=01 index 24=00 UART1 is enabled No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) From r.marek at assembler.cz Thu Aug 23 23:05:26 2007 From: r.marek at assembler.cz (Rudolf Marek) Date: Thu, 23 Aug 2007 23:05:26 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) In-Reply-To: <20070823204206.GA22881@thorin> References: <46CDED4C.4030202@gmx.net> <20070823204206.GA22881@thorin> Message-ID: <46CDF696.9060005@assembler.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt Here is a bunch of superIO detected. Hope it helps, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzfaW3J9wPJqZRNURAnloAKC202okrthWjhgvaoYhmQV1DJwYIgCePf54 mvqFCvvfmriH6oYbOTbDfWQ= =1f3U -----END PGP SIGNATURE----- From todthgie at hotmail.com Thu Aug 23 23:25:38 2007 From: todthgie at hotmail.com (todthgie) Date: Thu, 23 Aug 2007 23:25:38 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) References: <46CDED4C.4030202@gmx.net> Message-ID: i just ran it on my box ..under stock bios (no LB for this board yet ) ubuddie probe_superio # ./probe_superio No SuperIO chip found at 0x002e No SuperIO chip found at 0x002e ITE? SuperIO found at 0x2e: id=0x8705, chipver=0x2 ITE chip index 20=87 index 21=05 index 22=02 index 23=00 index 24=d9 UART1 is enabled No SuperIO chip found at 0x004e No SuperIO chip found at 0x004e ITE? SuperIO found at 0x4e: id=0x8705, chipver=0x2 ITE chip index 20=87 index 21=05 index 22=02 index 23=00 index 24=d9 UART1 is enabled ----- Original Message ----- From: "Carl-Daniel Hailfinger" To: "LinuxBIOS" Sent: Thursday, August 23, 2007 22:25 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) > This adds probing for almost all recent (since 1999) ITE Super I/O chips > to probe_superio. Not much of the configuration is dumped, however I did > verify against all ITE datasheets (including those not available any > more) that the probing was non-destructive. > More information can be extracted easily, however this needs loads of > datasheet surfing. > > Signed-off-by: Carl-Daniel Hailfinger > -------------------------------------------------------------------------------- > --- LinuxBIOSv2/util/probe_superio/probe_superio.c (Revision 2744) > +++ LinuxBIOSv2/util/probe_superio/probe_superio.c (Arbeitskopie) > @@ -3,6 +3,7 @@ > * > * Copyright (C) 2006 Ronald Minnich > * Copyright (C) 2006 coresystems GmbH > + * Copyright (C) 2007 Carl-Daniel Hailfinger > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > @@ -32,11 +33,16 @@ > * if we need this. > */ > > -unsigned char regval(unsigned short port, unsigned short reg) { > +unsigned char regval(unsigned short port, unsigned char reg) { > outb(reg, port); > return inb(port+1); > } > > +void regwrite(unsigned short port, unsigned char reg, unsigned char val) > { > + outb(reg, port); > + outb(val, port+1); > +} > + > void > dump_ns8374(unsigned short port) { > printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", > @@ -46,15 +52,13 @@ > /* check COM1. This is all we care about at present. */ > printf("COM 1 is Globally %s\n", regval(port,0x26)&8 ? "disabled" : > "enabled"); > /* select com1 */ > - outb(0x7, port); > - outb(3, port+1); > + regwrite(port, 0x07, 0x03); > printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : > "disabled"); > printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, > f0=%02x\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, > 0x71), > regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); > /* select gpio */ > - outb(0x7, port); > - outb(7, port+1); > + regwrite(port, 0x07, 0x07); > printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); > printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, > f0=%02x\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, > 0x71), > @@ -85,38 +89,33 @@ > printf("2b=%02x\n", regval(port, 0x2b)); > > /* select UART 1 */ > - outb(0x07, port); > - outb(0x01, port+1); > + regwrite(port, 0x07, 0x01); > printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); > printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, > regval(port, 0xf0)&0x10 ? "RS485":"RS232"); > > /* select UART 2 */ > - outb(0x07, port); > - outb(0x02, port+1); > + regwrite(port, 0x07, 0x02); > printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); > printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, > regval(port, 0xf0)&0x10 ? "RS485":"RS232"); > > /* select Parport */ > - outb(0x07, port); > - outb(0x03, port+1); > + regwrite(port, 0x07, 0x03); > printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : > "disabled"); > printf("PARPORT base=%02x%02x, irq=%02x\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); > > /* select hw monitor */ > - outb(0x07, port); > - outb(0x04, port+1); > + regwrite(port, 0x07, 0x04); > printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : > "disabled"); > printf("HW monitor base=%02x%02x, irq=%02x\n", > regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); > > /* select gpio */ > - outb(0x07, port); > - outb(0x06, port+1); > + regwrite(port, 0x07, 0x05); > printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); > printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, > e5=%02x\n", > regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, > 0xe2), > @@ -130,7 +129,30 @@ > > } > > +void > +dump_ite(unsigned short port, unsigned short id) > +{ > + int i; > + printf ("ITE chip\n"); > > + for (i=0x20; i<=0x24; i++) > + printf("index %02x=%02x\n", i, regval(port, i)); > + > + switch(id) { > + case 0x8702: > + case 0x8705: > + case 0x8710: > + case 0x8712: > + case 0x8716: > + case 0x8718: > + default: > + break; > + } > + /* select UART 1 */ > + regwrite(port, 0x07, 0x01); > + printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : > "disabled"); > +} > + > void > probe_idregs_simple(unsigned short port){ > unsigned char id; > @@ -167,9 +189,10 @@ > > void > probe_idregs_fintek(unsigned short port){ > - unsigned int vid, did; > + unsigned int vid, did, success = 0; > > // Enable configuration sequence (Fintek uses this for example) > + // Older ITE chips have the same enable sequence > outb(0x87, port); > outb(0x87, port); > > @@ -185,13 +208,10 @@ > } > did = inb(port+1); > > - outb(0x21, port); > - did = did|(inb(port+1)<<8); > + did = did|(regval(port, 0x21)<<8); > > - outb(0x23, port); > - vid = inb(port+1); > - outb(0x24, port); > - vid = vid|(inb(port+1)<<8); > + vid = regval(port, 0x23); > + vid = vid|(regval(port, 0x24)<<8); > > printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, > did); > > @@ -199,23 +219,103 @@ > return; > > // printf("%s\n", familyid[id]); > + switch(did) { > + case 0x1087: // reversed for ITE8710 > + success = 1; > + dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); > + // disable configuration > + regwrite(port, 0x02, 0x02); > + break; > + default: > + break; > + } > switch(vid) { > case 0x3419: > + success = 1; > dump_fintek(port, did); > break; > default: > - printf("no dump for 0x%04x/0x%04x\n", vid, did); > break; > } > + if (!success) > + printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); > > - // disable configuration > + // disable configuration (for Fintek, doesn't hurt ITE) > outb(0xaa, port); > } > > void > +probe_idregs_ite(unsigned short port){ > + unsigned int id, chipver; > + > + // Enable configuration sequence (ITE uses this for newer IT87[012]x) > + // IT871[01] uses 0x87, 0x87 -> fintek detection should handle it > + // IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa > + // IT86xx series uses different ports > + // IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes > + // IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes > + outb(0x87, port); > + outb(0x01, port); > + outb(0x55, port); > + if (port == 0x2e) > + outb(0x55, port); > + else > + outb(0xAA, port); > + > + // Read Chip ID Byte 1 > + id = regval(port, 0x20); > + if (id != 0x87) { > + if (inb(port) == 0xff ) > + printf ("No SuperIO chip found at 0x%04x\n", port); > + else > + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", > + port, inb(port), inb(port+1)); > + return; > + } > + > + id <<= 8; > + > + // Read Chip ID Byte 2 > + id |= regval(port, 0x21); > + > + // Read Chip Version, only bit 3..0 for all IT87xx > + chipver = regval(port, 0x22) & 0x0f; > + > + /* ID Mapping Table > + unknown -> IT8711 (no datasheet) > + unknown -> IT8722 (no datasheet) > + 0x8702 -> IT8702 > + 0x8705 -> IT8700 or IT8705 > + 0x8710 -> IT8710 > + 0x8712 -> IT8712 > + 0x8716 -> IT8716 or IT8726 (identical except CPU voltage control) > + 0x8718 -> IT8718 > + */ > + printf("ITE? SuperIO found at 0x%02x: id=0x%04x, chipver=0x%01x\n", > + port, id, chipver); > + > + switch(id) { > + case 0x8702: > + case 0x8705: > + case 0x8710: //pointless, IT8710 has different enable sequence > + case 0x8712: > + case 0x8716: > + case 0x8718: > + dump_ite(port, id); > + break; > + default: > + printf("no dump for id 0x%04x\n", id); > + break; > + } > + // disable configuration > + regwrite(port, 0x02, 0x02); > +} > + > +void > probe_superio(unsigned short port) { > probe_idregs_simple(port); > probe_idregs_fintek(port); > + probe_idregs_ite(port); > } > > int > -------------------------------------------------------------------------------- > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios From peter at stuge.se Thu Aug 23 23:23:21 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 23 Aug 2007 23:23:21 +0200 Subject: [LinuxBIOS] Questions to flashing BIOS chips In-Reply-To: <46CD7BCB.8050508@saxnet.de> References: <46C1A762.4060803@saxnet.de> <20070814133411.15022.qmail@stuge.se> <46C2A249.30502@saxnet.de> <20070815103502.11863.qmail@stuge.se> <46C2E993.4030505@saxnet.de> <20070815203256.14414.qmail@stuge.se> <46CD7BCB.8050508@saxnet.de> Message-ID: <20070823212321.23264.qmail@stuge.se> On Thu, Aug 23, 2007 at 02:21:31PM +0200, Thomas Buschhardt wrote: > in the short: the timing of the read/write-process was wrong and > the galep-producer change his software ;-) Excellent. > its so easy sometimes .... > ...no protection I was quite surprised that the manufacturer would let those chips out with the same model number printed on them but incompatible logic inside. I'm glad it got worked out! //Peter From c-d.hailfinger.devel.2006 at gmx.net Thu Aug 23 23:26:22 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 23 Aug 2007 23:26:22 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) In-Reply-To: <46CDF696.9060005@assembler.cz> References: <46CDED4C.4030202@gmx.net> <20070823204206.GA22881@thorin> <46CDF696.9060005@assembler.cz> Message-ID: <46CDFB7E.5080204@gmx.net> On 23.08.2007 23:05, Rudolf Marek wrote: > Hi all, > > http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt > > Here is a bunch of superIO detected. Hope it helps, Thanks, this is nice. However, it seems the following chunk disagrees with the datasheet: > name => "ITE IT8726F Super IO Sensors", > driver => "it87", > devid => 0x8726, > logdev => 0x04, According to the datasheet, devid for IT8726 is 0x8716. Regards, Carl-Daniel From peter at stuge.se Thu Aug 23 23:31:03 2007 From: peter at stuge.se (Peter Stuge) Date: Thu, 23 Aug 2007 23:31:03 +0200 Subject: [LinuxBIOS] 440bx laptop(s) In-Reply-To: <4b86cc00708231306s468d7d1fu2195071067021e97@mail.gmail.com> References: <4b86cc00708231306s468d7d1fu2195071067021e97@mail.gmail.com> Message-ID: <20070823213103.24711.qmail@stuge.se> On Thu, Aug 23, 2007 at 12:06:42PM -0800, Jon Bradley wrote: > Would it be a cut and dry operation to install LinuxBIOS on the > 440bx laptops? There's no support for any laptops in LB yet, so you would first have to create the mainboard and add any neccessary code for it to LB. This is usually difficult because of extra hardware in laptops that noone has documentation for. Once there is support, reflashing the boot flash chip should be rather straight forward on those laptops that in fact support flashing. Being able to flash may also be controlled in undocumented ways though, so it can be a bit of work. //Peter From pawn2be.wild at yahoo.de Fri Aug 24 00:00:49 2007 From: pawn2be.wild at yahoo.de (Quux) Date: Fri, 24 Aug 2007 00:00:49 +0200 Subject: [LinuxBIOS] yo, pre-bricking an A8N-E ! Message-ID: <46CE0391.70505@yahoo.de> wow, it only took me only 3 hrs to pre-brick the Asus A8N-E I got at ebay for ?22. I would have been faster, but the ROM / IMAGE SIZE of the current revision ist stated as 7F00 instead of 20000hex as in the M57SLI target. Once I fixed that I could flash the current revision - and the POST card gives me a steady 80. I keep you guys informed but the ASUS A8N target is not even flashable currently (Also the wiki - downloadable ROM image is bad size (20000hex required)). I plan to put together a CDROM .ISO file (a remastered dream linux) with the LB tree and ready-to-flash working filo-ROM-image. should be a quickie. --Q From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 24 03:36:11 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 24 Aug 2007 03:36:11 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: rewrite, add ITE support, sophisticated dumping Message-ID: <46CE360B.6040504@gmx.net> This patch rewrites probe_superio almost completely. Common code sequences have been factored out, the code has been made more generic, has better handling of corner cases and is actually much shorter. It also adds probing for almost all recent (since 1999) ITE Super I/O chips to probe_superio. I did verify against all ITE datasheets (including those not available any more) that the probing was non-destructive. For the ITE IT8712F, the complete configuration is dumped and as comparison the default value from the data sheet is printed. More information can be extracted easily, however this needs loads of datasheet surfing. This code has been tested extensively, dumping for other ITE chips will follow as a separate patch. Signed-off-by: Carl-Daniel Hailfinger --- LinuxBIOSv2/util/probe_superio/probe_superio.c (Revision 2748) +++ LinuxBIOSv2/util/probe_superio/probe_superio.c (Arbeitskopie) @@ -3,6 +3,7 @@ * * Copyright (C) 2006 Ronald Minnich * Copyright (C) 2006 coresystems GmbH + * Copyright (C) 2007 Carl-Daniel Hailfinger * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -32,11 +33,16 @@ * if we need this. */ -unsigned char regval(unsigned short port, unsigned short reg) { +unsigned char regval(unsigned short port, unsigned char reg) { outb(reg, port); return inb(port+1); } +void regwrite(unsigned short port, unsigned char reg, unsigned char val) { + outb(reg, port); + outb(val, port+1); +} + void dump_ns8374(unsigned short port) { printf("Enables: 21=%02x, 22=%02x, 23=%02x, 24=%02x, 26=%02x\n", @@ -46,15 +52,13 @@ /* check COM1. This is all we care about at present. */ printf("COM 1 is Globally %s\n", regval(port,0x26)&8 ? "disabled" : "enabled"); /* select com1 */ - outb(0x7, port); - outb(3, port+1); + regwrite(port, 0x07, 0x03); printf("COM 1 is locally %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("COM1 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), regval(port, 0x74), regval(port, 0x75), regval(port, 0xf0)); /* select gpio */ - outb(0x7, port); - outb(7, port+1); + regwrite(port, 0x07, 0x07); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("GPIO 60=%02x, 61=%02x, 70=%02x, 71=%02x, 74=%02x, 75=%02x, f0=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70), regval(port, 0x71), @@ -85,38 +89,33 @@ printf("2b=%02x\n", regval(port, 0x2b)); /* select UART 1 */ - outb(0x07, port); - outb(0x01, port+1); + regwrite(port, 0x07, 0x01); printf("UART1 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("UART1 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, regval(port, 0xf0)&0x10 ? "RS485":"RS232"); /* select UART 2 */ - outb(0x07, port); - outb(0x02, port+1); + regwrite(port, 0x07, 0x02); printf("UART2 is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("UART2 base=%02x%02x, irq=%02x, mode=%s\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f, regval(port, 0xf0)&0x10 ? "RS485":"RS232"); /* select Parport */ - outb(0x07, port); - outb(0x03, port+1); + regwrite(port, 0x07, 0x03); printf("PARPORT is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("PARPORT base=%02x%02x, irq=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); /* select hw monitor */ - outb(0x07, port); - outb(0x04, port+1); + regwrite(port, 0x07, 0x04); printf("HW monitor is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("HW monitor base=%02x%02x, irq=%02x\n", regval(port, 0x60), regval(port, 0x61), regval(port, 0x70)&0x0f); /* select gpio */ - outb(0x07, port); - outb(0x06, port+1); + regwrite(port, 0x07, 0x05); printf("GPIO is %s\n", regval(port, 0x30) & 1 ? "enabled" : "disabled"); printf("GPIO 70=%02x, e0=%02x, e1=%02x, e2=%02x, e3=%02x, e4=%02x, e5=%02x\n", regval(port, 0x70), regval(port, 0xe0), regval(port, 0xe1), regval(port, 0xe2), @@ -130,8 +129,152 @@ } +//End Of Table +#define EOT -1 +//NO LDN needed +#define NOLDN -2 +//Not Available +#define NANA -3 +//Biggest LDN +#define MAXLDN 0xa +//MAXimum NUMber of Indexes +#define MAXNUMIDX 70 +const static struct ite_registers { + signed short superio_id; //yes, it should be unsigned, but then EOT has to be positive + struct ite_ldnidx { + signed short ldn; + signed short idx[MAXNUMIDX+1]; + signed short def[MAXNUMIDX+1]; + } ldn[MAXLDN+3]; //biggestLDN+0+NOLDN+EOT +} ite_reg_table[] = { + {0x8712,{ + {NOLDN, + {0x07,0x20,0x21,0x22,0x23,0x24,0x2b,EOT}, + {NANA,0x87,0x12,0x08,0x00,0x00,0x00,EOT}}, + {0x0, + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x00,0x00,EOT}}, + {0x1, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x03,0xf8,0x04,0x00,0x50,0x00,0x7f,EOT}}, + {0x2, + {0x30,0x60,0x61,0x70,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0x02,0xf8,0x03,0x00,0x50,0x00,0x7f,EOT}}, + {0x3, + {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,EOT}, + {0x00,0x03,0x78,0x07,0x78,0x07,0x03,0x03,EOT}}, + {0x4, + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, + {0x5, + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, + {0x6, + {0x30,0x70,0x71,0xf0,EOT}, + {0x00,0x0c,0x02,0x00,EOT}}, + {0x7, + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc,0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x30,0x38,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, + {0x8, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x00,0x0a,0x00,EOT}}, + {0x9, + {0x30,0x60,0x61,EOT}, + {0x00,0x02,0x01,EOT}}, + {0xa, + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x03,0x10,0x0b,0x00,EOT}}, + {EOT}}}, + {EOT} +}; void +dump_ite(unsigned short port, unsigned short id) +{ + int i, j, k; + signed short *idx; + printf ("ITE "); + + + /* ID Mapping Table + unknown -> IT8711 (no datasheet) + unknown -> IT8722 (no datasheet) + 0x8702 -> IT8702 + 0x8705 -> IT8700 or IT8705 + 0x8708 -> IT8708 + 0x8710 -> IT8710 + 0x8712 -> IT8712 + 0x8716 -> IT8716 or IT8726 (identical except CPU voltage control) + 0x8718 -> IT8718 + 0x8726 does not exist according to datasheet, but experience differs + */ + switch(id) { + case 0x8702: + printf ("IT8702\n"); + break; + case 0x8705: + printf ("IT8700 or IT8705\n"); + break; + case 0x8710: + printf ("IT8710\n"); + break; + case 0x8712: + printf ("IT8712\n"); + for (i=0;; i++) { + if (ite_reg_table[i].superio_id == EOT) + break; + if ((unsigned short)ite_reg_table[i].superio_id != id) + continue; + for (j=0;; j++) { + if (ite_reg_table[i].ldn[j].ldn == EOT) + break; + if (ite_reg_table[i].ldn[j].ldn != NOLDN) { + printf("switching to LDN 0x%01x\n", ite_reg_table[i].ldn[j].ldn); + regwrite(port, 0x07, ite_reg_table[i].ldn[j].ldn); + } + idx = ite_reg_table[i].ldn[j].idx; + printf("idx "); + for (k=0;; k++) { + if (idx[k] == EOT) + break; + printf("%02x ", idx[k]); + } + printf("\nval "); + for (k=0;; k++) { + if (idx[k] == EOT) + break; + printf("%02x ", regval(port, idx[k])); + } + printf("\ndef "); + idx = ite_reg_table[i].ldn[j].def; + for (k=0;; k++) { + if (idx[k] == EOT) + break; + if (idx[k] == NANA) + printf("NA "); + else + printf("%02x ", idx[k]); + } + printf("\n"); + } + + } + break; + case 0x8716: + printf ("IT8716 or IT8726\n"); + break; + case 0x8718: + printf ("IT8718\n"); + break; + default: + printf ("unknown ITE chip, id=%04x\n", id); + for (i=0x20; i<=0x24; i++) + printf("index %02x=%02x\n", i, regval(port, i)); + break; + } +} + +void probe_idregs_simple(unsigned short port){ unsigned char id; outb(0x20, port); @@ -167,9 +310,10 @@ void probe_idregs_fintek(unsigned short port){ - unsigned int vid, did; + unsigned int vid, did, success = 0; // Enable configuration sequence (Fintek uses this for example) + // Older ITE chips have the same enable sequence outb(0x87, port); outb(0x87, port); @@ -185,13 +329,10 @@ } did = inb(port+1); - outb(0x21, port); - did = did|(inb(port+1)<<8); + did = did|(regval(port, 0x21)<<8); - outb(0x23, port); - vid = inb(port+1); - outb(0x24, port); - vid = vid|(inb(port+1)<<8); + vid = regval(port, 0x23); + vid = vid|(regval(port, 0x24)<<8); printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); @@ -199,23 +340,104 @@ return; // printf("%s\n", familyid[id]); + switch(did) { + case 0x0887: // reversed for ITE8708 + case 0x1087: // reversed for ITE8710 + success = 1; + dump_ite(port, ((did & 0xff) << 8) | ((did & 0xff00) >> 8)); + // disable configuration + regwrite(port, 0x02, 0x02); + break; + default: + break; + } switch(vid) { case 0x3419: + success = 1; dump_fintek(port, did); break; default: - printf("no dump for 0x%04x/0x%04x\n", vid, did); break; } + if (!success) + printf("no dump for vid 0x%04x, did 0x%04x\n", vid, did); - // disable configuration + // disable configuration (for Fintek, doesn't hurt ITE) outb(0xaa, port); } void +probe_idregs_ite(unsigned short port){ + unsigned int id, chipver; + + // Enable configuration sequence (ITE uses this for newer IT87[012]x) + // IT871[01] uses 0x87, 0x87 -> fintek detection should handle it + // IT8761 uses 0x87, 0x61, 0x55, 0x55/0xaa + // IT86xx series uses different ports + // IT8661 uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes + // IT8673 uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes + outb(0x87, port); + outb(0x01, port); + outb(0x55, port); + if (port == 0x2e) + outb(0x55, port); + else + outb(0xAA, port); + + // Read Chip ID Byte 1 + id = regval(port, 0x20); + if (id != 0x87) { + if (inb(port) == 0xff ) + printf ("No SuperIO chip found at 0x%04x\n", port); + else + printf("probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", + port, inb(port), inb(port+1)); + return; + } + + id <<= 8; + + // Read Chip ID Byte 2 + id |= regval(port, 0x21); + + // Read Chip Version, only bit 3..0 for all IT87xx + chipver = regval(port, 0x22) & 0x0f; + + /* ID Mapping Table + unknown -> IT8711 (no datasheet) + unknown -> IT8722 (no datasheet) + 0x8702 -> IT8702 + 0x8705 -> IT8700 or IT8705 + 0x8710 -> IT8710 + 0x8712 -> IT8712 + 0x8716 -> IT8716 or IT8726 (identical except CPU voltage control) + 0x8718 -> IT8718 + */ + printf("ITE? SuperIO found at 0x%02x: id=0x%04x, chipver=0x%01x\n", + port, id, chipver); + + switch(id) { + case 0x8702: + case 0x8705: + case 0x8710: //pointless, IT8710 has different enable sequence + case 0x8712: + case 0x8716: + case 0x8718: + dump_ite(port, id); + break; + default: + printf("no dump for id 0x%04x\n", id); + break; + } + // disable configuration + regwrite(port, 0x02, 0x02); +} + +void probe_superio(unsigned short port) { probe_idregs_simple(port); probe_idregs_fintek(port); + probe_idregs_ite(port); } int From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 24 04:09:53 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 24 Aug 2007 04:09:53 +0200 Subject: [LinuxBIOS] [PATCH] v3: printk: change %L to %ll Message-ID: <46CE3DF1.9090700@gmx.net> This patch changes all occurences of (working) %Lx to (standards conformant, working) %llx in printk/printf. While I'm at it, affected lines with 271 characters can be broken into smaller chunks. Signed-off-by: Carl-Daniel Hailfinger Index: device/device.c =================================================================== --- device/device.c (Revision 476) +++ device/device.c (Arbeitskopie) @@ -402,7 +402,11 @@ min_align = 0; base = bridge->base; - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); + printk(BIOS_SPEW, + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d\n", + dev_path(bus->dev), + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", + base, bridge->size, bridge->align, bridge->gran); /* We want different minimum alignments for different kinds of * resources. These minimums are not device type specific but @@ -485,7 +489,7 @@ base += size; printk(BIOS_SPEW, - "%s %02lx * [0x%08Lx - 0x%08Lx] %s\n", + "%s %02lx * [0x%08llx - 0x%08llx] %s\n", dev_path(dev), resource->index, resource->base, @@ -503,7 +507,11 @@ */ bridge->size = align_up(base, bridge->gran) - bridge->base; - printk(BIOS_SPEW, "%s compute_allocate_%s: base: %08Lx size: %08Lx align: %d gran: %d done\n", dev_path(bus->dev), (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); + printk(BIOS_SPEW, + "%s compute_allocate_%s: base: %08llx size: %08llx align: %d gran: %d done\n", + dev_path(bus->dev), + (bridge->flags & IORESOURCE_IO) ? "io" : (bridge->flags & IORESOURCE_PREFETCH) ? "prefmem" : "mem", + base, bridge->size, bridge->align, bridge->gran); } #if defined(CONFIG_PCI_OPTION_ROM_RUN) && CONFIG_PCI_OPTION_ROM_RUN == 1 Index: device/pnp_device.c =================================================================== --- device/pnp_device.c (Revision 476) +++ device/pnp_device.c (Arbeitskopie) @@ -87,7 +87,7 @@ { if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk(BIOS_ERR, - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", dev_path(dev), resource->index, resource_type(resource), resource->size); return; Index: device/pci_device.c =================================================================== --- device/pci_device.c (Revision 476) +++ device/pci_device.c (Arbeitskopie) @@ -252,10 +252,10 @@ printk(BIOS_DEBUG, "%s %02x ->", dev_path(dev), resource->index); printk(BIOS_DEBUG, - " value: 0x%08Lx zeroes: 0x%08Lx ones: 0x%08Lx attr: %08lx\n", + " value: 0x%08llx zeroes: 0x%08llx ones: 0x%08llx attr: %08lx\n", value, zeroes, ones, attr); printk(BIOS_DEBUG, - "%s %02x -> size: 0x%08Lx max: 0x%08Lx %s\n ", + "%s %02x -> size: 0x%08llx max: 0x%08llx %s\n ", dev_path(dev), resource->index, resource->size, resource->limit, resource_type(resource)); } @@ -456,7 +456,7 @@ /* Make certain the resource has actually been set. */ if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk(BIOS_ERR, - "ERROR: %s %02lx %s size: 0x%010Lx not assigned\n", + "ERROR: %s %02lx %s size: 0x%010llx not assigned\n", dev_path(dev), resource->index, resource_type(resource), resource->size); return; @@ -863,7 +863,7 @@ (*list)->path.type); continue; } - printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%x\n", + printk(BIOS_SPEW, "%s: check dev %s it has devfn 0x%02x\n", __func__, (*list)->dtsname, (*list)->path.u.pci.devfn); if ((*list)->path.u.pci.devfn == devfn) { /* Unlink from the list. */ Index: device/device_util.c =================================================================== --- device/device_util.c (Revision 476) +++ device/device_util.c (Arbeitskopie) @@ -229,7 +229,7 @@ memcpy(buffer, "Root Device", 12); break; case DEVICE_ID_PCI: - sprintf(buffer, "PCI: %02x:%02x", id->u.pci.vendor, + sprintf(buffer, "PCI: %04x:%04x", id->u.pci.vendor, id->u.pci.device); break; case DEVICE_ID_PNP: @@ -243,7 +243,7 @@ id->u.apic.device); break; case DEVICE_ID_PCI_DOMAIN: - sprintf(buffer, "PCI_DOMAIN: %02x:%02x", + sprintf(buffer, "PCI_DOMAIN: %04x:%04x", id->u.pci_domain.vendor, id->u.pci_domain.device); break; @@ -602,7 +602,7 @@ #endif } printk(BIOS_DEBUG, - "%s %02lx <- [0x%010Lx - 0x%010Lx] %s%s%s\n", + "%s %02lx <- [0x%010llx - 0x%010llx] %s%s%s\n", dev_path(dev), resource->index, base, end, buf, resource_type(resource), comment); @@ -656,7 +656,7 @@ for (i = 0; i < curdev->resources; i++) { struct resource *resource = &curdev->resource[i]; printk(BIOS_SPEW, - "%s: dev %s, resource %d, flags %lx base 0x%Lx size 0x%Lx\n", + "%s: dev %s, resource %d, flags %lx base 0x%llx size 0x%llx\n", __func__, curdev->dtsname, i, resource->flags, resource->base, resource->size); /* If it isn't the right kind of resource ignore it. */ Index: lib/elfboot.c =================================================================== --- lib/elfboot.c (Revision 476) +++ lib/elfboot.c (Arbeitskopie) @@ -61,7 +61,7 @@ } if (i == mem_entries) { printk(BIOS_ERR, "No matching RAM area found for range:\n"); - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx)\n", start, end); + printk(BIOS_ERR, " [0x%016llx, 0x%016llx)\n", start, end); printk(BIOS_ERR, "RAM areas\n"); for(i = 0; i < mem_entries; i++) { u64 mstart, mend; @@ -69,7 +69,7 @@ mtype = mem->map[i].type; mstart = unpack_lb64(mem->map[i].start); mend = mstart + unpack_lb64(mem->map[i].size); - printk(BIOS_ERR, " [0x%016Lx, 0x%016Lx) %s\n", + printk(BIOS_ERR, " [0x%016llx, 0x%016llx) %s\n", mstart, mend, (mtype == LB_MEM_RAM)?"RAM":"Reserved"); } Index: northbridge/intel/i440bxemulation/i440bx.c =================================================================== --- northbridge/intel/i440bxemulation/i440bx.c (Revision 476) +++ northbridge/intel/i440bxemulation/i440bx.c (Arbeitskopie) @@ -79,7 +79,7 @@ resource->size = ((resource_t) sizek) << 10; resource->flags = IORESOURCE_MEM | IORESOURCE_CACHEABLE | IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; - printk(BIOS_DEBUG, "%s: add ram resoource %Ld bytes\n", __func__, + printk(BIOS_DEBUG, "%s: add ram resource %lld bytes\n", __func__, resource->size); } Index: arch/x86/linuxbios_table.c =================================================================== --- arch/x86/linuxbios_table.c (Revision 476) +++ arch/x86/linuxbios_table.c (Arbeitskopie) @@ -177,7 +177,7 @@ { int entries; - printk(BIOS_DEBUG, "%s: start 0x%Lx size 0x%Lx\n", + printk(BIOS_DEBUG, "%s: start 0x%llx size 0x%llx\n", __func__, start, size); entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); From philipp.degler at gmx.de Fri Aug 24 00:48:29 2007 From: philipp.degler at gmx.de (Philipp Degler) Date: Fri, 24 Aug 2007 00:48:29 +0200 Subject: [LinuxBIOS] yo, pre-bricking an A8N-E ! In-Reply-To: <46CE0391.70505@yahoo.de> References: <46CE0391.70505@yahoo.de> Message-ID: <200708240048.35365.philipp.degler@gmx.de> On Friday 24 August 2007 00:00:49 Quux wrote: > wow, it only took me only 3 hrs to pre-brick the Asus A8N-E I got at > ebay for ?22. > > I would have been faster, but the ROM / IMAGE SIZE of the current > revision ist stated as 7F00 instead of 20000hex as in the M57SLI > target. Once I fixed that I could flash the current revision - and the > POST card gives me a steady 80. hm, that is interesting. Actually this is what flashrom returns on my A8N-E: # ./flashrom -V Calibrating delay loop... 340M loops per second. ok No LinuxBIOS table found. Found chipset "NVIDIA CK804": Enabling flash write... OK. Probing for Am29F040B, 512 KB probe_29f040b: id1 0x21, id2 0xa7 ... Probing for SST49LF004A/B, 512 KB probe_jedec: id1 0xbf, id2 0x60 SST49LF004A/B found at physical address: 0xfff80000 Flash part is SST49LF004A/B (512 KB) OK, only ENABLING flash write, but NOT FLASHING. > > I keep you guys informed but the ASUS A8N target is not even flashable > currently (Also the wiki - downloadable ROM image is bad size (20000hex > required)). can you identify the flash chip of your A8N-E ?? > I plan to put together a CDROM .ISO file (a remastered dream linux) with > the LB tree and ready-to-flash working filo-ROM-image. should be a > quickie. --Q beeing in the middle of my diploma thesis I havn't checked the current svn for a while. Next week I plan to be back at the university where I could get a hand on a bios savior in order to check the state of the current svn revision. The last revision, that did work for me was 2724 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From philipp.degler at gmx.de Fri Aug 24 10:12:54 2007 From: philipp.degler at gmx.de (Philipp Degler) Date: Fri, 24 Aug 2007 10:12:54 +0200 Subject: [LinuxBIOS] yo, pre-bricking an A8N-E ! In-Reply-To: <46CE0391.70505@yahoo.de> References: <46CE0391.70505@yahoo.de> Message-ID: <200708241012.59013.philipp.degler@gmx.de> On Friday 24 August 2007 00:00:49 Quux wrote: > wow, it only took me only 3 hrs to pre-brick the Asus A8N-E I got at > ebay for ?22. > > I would have been faster, but the ROM / IMAGE SIZE of the current > revision ist stated as 7F00 instead of 20000hex as in the M57SLI > target. Once I fixed that I could flash the current revision - and the > POST card gives me a steady 80. I had an issue with the ck408 on this board. I was only able to use a single dimm and I had to comment a line in raminit.c to get the RAM initialized and working with an athlon 64 cpu. Please see following mailing list entry for further details: http://thread.gmane.org/gmane.linux.bios/23159/focus=23204 > > I keep you guys informed but the ASUS A8N target is not even flashable > currently (Also the wiki - downloadable ROM image is bad size (20000hex > required)). > I plan to put together a CDROM .ISO file (a remastered dream linux) with > the LB tree and ready-to-flash working filo-ROM-image. should be a > quickie. --Q -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From uwe at hermann-uwe.de Fri Aug 24 11:05:12 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 24 Aug 2007 11:05:12 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: add ITE support (try2) In-Reply-To: <46CDFB7E.5080204@gmx.net> References: <46CDED4C.4030202@gmx.net> <20070823204206.GA22881@thorin> <46CDF696.9060005@assembler.cz> <46CDFB7E.5080204@gmx.net> Message-ID: <20070824090512.GB20805@greenwood> On Thu, Aug 23, 2007 at 11:26:22PM +0200, Carl-Daniel Hailfinger wrote: > Thanks, this is nice. However, it seems the following chunk disagrees > with the datasheet: > > > name => "ITE IT8726F Super IO Sensors", > > driver => "it87", > > devid => 0x8726, > > logdev => 0x04, > > > According to the datasheet, devid for IT8726 is 0x8716. Likely to be a typo in the datasheets, as they generally seem to follow the rule to make the ID identical to the actual Super I/O name, e.g. IT8712-F -> 0x8712 etc. Of course you can only be sure if this is tested by someone who has a board with such a Super I/O... Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From uwe at hermann-uwe.de Fri Aug 24 12:22:46 2007 From: uwe at hermann-uwe.de (Uwe Hermann) Date: Fri, 24 Aug 2007 12:22:46 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: rewrite, add ITE support, sophisticated dumping In-Reply-To: <46CE360B.6040504@gmx.net> References: <46CE360B.6040504@gmx.net> Message-ID: <20070824102246.GC20805@greenwood> On Fri, Aug 24, 2007 at 03:36:11AM +0200, Carl-Daniel Hailfinger wrote: > --- LinuxBIOSv2/util/probe_superio/probe_superio.c (Revision 2748) > +++ LinuxBIOSv2/util/probe_superio/probe_superio.c (Arbeitskopie) > @@ -3,6 +3,7 @@ > * > * Copyright (C) 2006 Ronald Minnich > * Copyright (C) 2006 coresystems GmbH > + * Copyright (C) 2007 Carl-Daniel Hailfinger Add email address? Or is this on purpose? > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > @@ -32,11 +33,16 @@ > * if we need this. > */ > > -unsigned char regval(unsigned short port, unsigned short reg) { > +unsigned char regval(unsigned short port, unsigned char reg) { Can we make the whole code use uint8_t etc. where appropriate? > outb(reg, port); > return inb(port+1); > } > > +void regwrite(unsigned short port, unsigned char reg, unsigned char val) { > + outb(reg, port); > + outb(val, port+1); Some coding style changes are needed, e.g. "port + 1" (and other changes in various other places; please use indent and/or fix this manually). > +//End Of Table Use C-style comments everywhere please (yes, it's only a minor issue). > + {0x4, > + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, > + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, > + {0x5, > + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, > + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, > + {0x6, > + {0x30,0x70,0x71,0xf0,EOT}, > + {0x00,0x0c,0x02,0x00,EOT}}, > + {0x7, > + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc,0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, > + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x30,0x38,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, Don't make these lines longer than 79 characters, please. > + case 0x8712: > + printf ("IT8712\n"); > + for (i=0;; i++) { > + if (ite_reg_table[i].superio_id == EOT) > + break; > + if ((unsigned short)ite_reg_table[i].superio_id != id) > + continue; > + for (j=0;; j++) { > + if (ite_reg_table[i].ldn[j].ldn == EOT) > + break; > + if (ite_reg_table[i].ldn[j].ldn != NOLDN) { > + printf("switching to LDN 0x%01x\n", ite_reg_table[i].ldn[j].ldn); > + regwrite(port, 0x07, ite_reg_table[i].ldn[j].ldn); > + } > + idx = ite_reg_table[i].ldn[j].idx; > + printf("idx "); > + for (k=0;; k++) { > + if (idx[k] == EOT) > + break; > + printf("%02x ", idx[k]); > + } > + printf("\nval "); > + for (k=0;; k++) { > + if (idx[k] == EOT) > + break; > + printf("%02x ", regval(port, idx[k])); > + } > + printf("\ndef "); > + idx = ite_reg_table[i].ldn[j].def; > + for (k=0;; k++) { > + if (idx[k] == EOT) > + break; > + if (idx[k] == NANA) > + printf("NA "); > + else > + printf("%02x ", idx[k]); > + } > + printf("\n"); > + } > + > + } The indentation level gets pretty high here, maybe this can rewritten with less nesting and/or using a helper function? > - outb(0x21, port); > - did = did|(inb(port+1)<<8); > + did = did|(regval(port, 0x21)<<8); did |= regval(port, 0x21) << 8; > - outb(0x23, port); > - vid = inb(port+1); > - outb(0x24, port); > - vid = vid|(inb(port+1)<<8); > + vid = regval(port, 0x23); > + vid = vid|(regval(port, 0x24)<<8); vid |= regval(port, 0x24) << 8; > printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); "Super I/O" to be consistent, we use that spelling everywhere else. > + /* ID Mapping Table > + unknown -> IT8711 (no datasheet) > + unknown -> IT8722 (no datasheet) > + 0x8702 -> IT8702 > + 0x8705 -> IT8700 or IT8705 > + 0x8710 -> IT8710 > + 0x8712 -> IT8712 > + 0x8716 -> IT8716 or IT8726 (identical except CPU voltage control) > + 0x8718 -> IT8718 > + */ > + printf("ITE? SuperIO found at 0x%02x: id=0x%04x, chipver=0x%01x\n", s/ITE?/ITE/ This is a really nice patch, on the long run we can make probe_superio (though I would rename it to 'superio-detect' personally) a general-purpose tool for detecting and investigating Super I/Os. Yes, there's sensor?-detect (from the lm-sensors project) which has an overlapping functionality, but I'm not sure how that works internally or how elaborate the detection and info is. We should check if it makes sense to merge our code into sensors-detect (or vice versa?) or not. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Fri Aug 24 15:09:21 2007 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Fri, 24 Aug 2007 15:09:21 +0200 Subject: [LinuxBIOS] [PATCH] probe_superio: rewrite, add ITE support, sophisticated dumping In-Reply-To: <20070824102246.GC20805@greenwood> References: <46CE360B.6040504@gmx.net> <20070824102246.GC20805@greenwood> Message-ID: <46CED881.8090404@gmx.net> On 24.08.2007 12:22, Uwe Hermann wrote: > On Fri, Aug 24, 2007 at 03:36:11AM +0200, Carl-Daniel Hailfinger wrote: >> --- LinuxBIOSv2/util/probe_superio/probe_superio.c (Revision 2748) >> +++ LinuxBIOSv2/util/probe_superio/probe_superio.c (Arbeitskopie) >> @@ -3,6 +3,7 @@ >> * >> * Copyright (C) 2006 Ronald Minnich >> * Copyright (C) 2006 coresystems GmbH >> + * Copyright (C) 2007 Carl-Daniel Hailfinger > > Add email address? Or is this on purpose? Purpose. My mail address will change soon, besides that it would violate the 72 char limit. >> * This program is free software; you can redistribute it and/or modify >> * it under the terms of the GNU General Public License as published by >> @@ -32,11 +33,16 @@ >> * if we need this. >> */ >> >> -unsigned char regval(unsigned short port, unsigned short reg) { >> +unsigned char regval(unsigned short port, unsigned char reg) { > > Can we make the whole code use uint8_t etc. where appropriate? I hate uint*_t, but yes, I can do that (or switch to u*). >> outb(reg, port); >> return inb(port+1); >> } >> >> +void regwrite(unsigned short port, unsigned char reg, unsigned char val) { >> + outb(reg, port); >> + outb(val, port+1); > > Some coding style changes are needed, e.g. "port + 1" (and other changes > in various other places; please use indent and/or fix this manually). OK >> +//End Of Table > > Use C-style comments everywhere please (yes, it's only a minor issue). OK >> + {0x4, >> + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT}, >> + {0x00,0x02,0x90,0x02,0x30,0x09,0x00,0x00,0x00,0x00,0x00,NANA,NANA,EOT}}, >> + {0x5, >> + {0x30,0x60,0x61,0x62,0x63,0x70,0x71,0xf0,EOT}, >> + {0x01,0x00,0x60,0x00,0x64,0x01,0x02,0x00,EOT}}, >> + {0x6, >> + {0x30,0x70,0x71,0xf0,EOT}, >> + {0x00,0x0c,0x02,0x00,EOT}}, >> + {0x7, >> + {0x25,0x26,0x27,0x28,0x29,0x2a,0x2c,0x60,0x61,0x62,0x63,0x64,0x65,0x70,0x71,0x72,0x73,0x74,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xc0,0xc1,0xc2,0xc3,0xc4,0xc8,0xc9,0xca,0xcb,0xcc,0xe0,0xe1,0xe2,0xe3,0xe4,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,EOT}, >> + {0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x30,0x38,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x40,0x00,0x01,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,NANA,0x00,EOT}}, > > Don't make these lines longer than 79 characters, please. Will fixup. >> + case 0x8712: >> + printf ("IT8712\n"); >> + for (i=0;; i++) { >> + if (ite_reg_table[i].superio_id == EOT) >> + break; >> + if ((unsigned short)ite_reg_table[i].superio_id != id) >> + continue; >> + for (j=0;; j++) { >> + if (ite_reg_table[i].ldn[j].ldn == EOT) >> + break; >> + if (ite_reg_table[i].ldn[j].ldn != NOLDN) { >> + printf("switching to LDN 0x%01x\n", ite_reg_table[i].ldn[j].ldn); >> + regwrite(port, 0x07, ite_reg_table[i].ldn[j].ldn); >> + } >> + idx = ite_reg_table[i].ldn[j].idx; >> + printf("idx "); >> + for (k=0;; k++) { >> + if (idx[k] == EOT) >> + break; >> + printf("%02x ", idx[k]); >> + } >> + printf("\nval "); >> + for (k=0;; k++) { >> + if (idx[k] == EOT) >> + break; >> + printf("%02x ", regval(port, idx[k])); >> + } >> + printf("\ndef "); >> + idx = ite_reg_table[i].ldn[j].def; >> + for (k=0;; k++) { >> + if (idx[k] == EOT) >> + break; >> + if (idx[k] == NANA) >> + printf("NA "); >> + else >> + printf("%02x ", idx[k]); >> + } >> + printf("\n"); >> + } >> + >> + } > > The indentation level gets pretty high here, maybe this can rewritten > with less nesting and/or using a helper function? Will look into that. >> - outb(0x21, port); >> - did = did|(inb(port+1)<<8); >> + did = did|(regval(port, 0x21)<<8); > > did |= regval(port, 0x21) << 8; > > >> - outb(0x23, port); >> - vid = inb(port+1); >> - outb(0x24, port); >> - vid = vid|(inb(port+1)<<8); >> + vid = regval(port, 0x23); >> + vid = vid|(regval(port, 0x24)<<8); > > vid |= regval(port, 0x24) << 8; This was mostly an automatic conversion, but yes. >> printf("SuperIO found at 0x%02x: vid=0x%04x/did=0x%04x\n", port, vid, did); > > "Super I/O" to be consistent, we use that spelling everywhere else. > > >> + /* ID Mapping Table >> + unknown -> IT8711 (no datasheet) >> + unknown -> IT8722 (no datasheet) >> + 0x8702 -> IT8702 >> + 0x8705 -> IT8700 or IT8705 >> +