From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: this point LLNL and linuxnetworx are building a 1000+ node linux cluster using linuxbios machines. > > - What are the main benefits in using LinuxBIOS? maintainable clusters maintainable systems fast boot (matters to some people) better control of the system LinuxBIOS in many cases does a better job of chipset config > Not as flexible as a normal BIOS. well, not really true in all cases. Check out the cwlinux offering, where flash boots into busybox linux. NO BIOS is that flexible! > Requires hardware and chipset documentation, it's hard to keep up > with the hardware development.. true for now, although at least two motherboard vendors are plannning to support linuxbios. > Hard to handle PCI cards with expansion ROMs on them that expect a > standard PC BIOS. partially true, but getting better. > > - What chipsets are supported by LinuxBIOS today? > Is there a list of supported chipsets? ls src/*bridge*/*/* ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: what you are talking about so you should do fine. Good Luck. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Does this look like a problem with BIOS or could this chipset be one that linux doesn't fully support yet? The customer bought it and had it sent to the server farm that will be hosting it so its not available to either of us. Yes, I know, why aren't we using scsi for a server. I would if I could. GO [root at taenaria root]# hdparm -d1 /dev/hda /dev/hda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) [root at taenaria root]# <[GNU]Order> type lspci [root at taenaria root]# lspci 00:00.0 Host bridge: Intel Corp. e7500 DRAM Controller (rev 02) 00:02.0 PCI bridge: Intel Corp. e7500 HI_B Virtual PCI-to-PCI Bridge (F0) (rev 02) 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 01:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 01:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c) 02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03) 02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03) 04:01.0 Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller (rev 02) PCI: Device 00:1f.1 not available because of resource collisions ICH3: (ide_setup_pci_device:) Could not enable device. <[GNU]Order> with lspci you got that last error? no, that was out of the dmesg <[GNU]Order> oh Just reprinting for reference. <[GNU]Order> the resource collisions one too? yes From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: On Thu, Nov 14, 2002 at 09:29:27AM -0500, McCarty, Paul wrote: > Why can't we just tweak the linux kernel a little to do more aggressive > disk caching? Or make use of RAM disks to keep things off the disk until > we want to save things? for wearable applications compact disk space is > more expensive then RAM: From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: that it is declared valid. If I examine code at 0x400000 it seems to be correct, meaning that it did copy the code over there. The processor never gets up there though. From tracing through the image it seems that the adjustment for Linuxbios' image in high memory is all messed up. After editing loglevel.h to allow "spew" level printks, the following is visible (I could see it throught the bochs debugger, but this just verifies that I'm not totally crazy. :-) Loaded segments verified segments closed down stream Jumping to boot code at 0x400000 entry = 0x00400000 lb_start = 0x00004000 lb_size = 0x0004e2d0 adjust = 0x3fbadd30 buffer = 0x3fb63a60 elf_boot_notes = 0x0000bc40 adjusted_boot_notes = 0x3fbb9970 now adjust and buffer are both waaaaaaaaaaaaaay beyond normal memory space... Is this normal or did I just fail to initialize something correctly? the objdump output for the natsemi.elf is also attached. From what I can tell it's nothing unusual. Regards, Andrew --Boundary-00=_TbT49FrWBdLVpdd Content-Type: text/plain; charset="us-ascii"; name="linuxbios.dump" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linuxbios.dump" LinuxBIOS-1.0.0 Sun Nov 24 14:12:38 EST 2002 starting... Ram1 OOps, can't write to PAM registers properly After 0x0000000 nop... Before 0x4000000 nop... After 0x4000000 nop... After 0x54... After 0x00... Before 0x4000000 nop... After 0x4000000 nop... After 0x4000000 nop... Before 0x4000000 nop... After 0x4000000 nop... After 0x0000000 nop... Before 0x4000000 nop... After 0x4000000 nop... After 0x54... After 0x00... Before 0x4000000 nop... After 0x4000000 nop... After 0x4000000 nop... First DRAM setup done Ram2 Ram3 Ram Enable 1 Ram Enable 2 Ram Enable 3 Ram Enable 4 Ram Enable 5 Ram4 Ram5 Ram6 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.0.0 Sun Nov 24 14:12:38 EST 2002 booting... Finding PCI configuration type. Scanning PCI bus...PCI: pci_scan_bus for bus 0 PCI: pci_scan_bus returning with max=00 done Allocating PCI resources... ASSIGN RESOURCES, bus 0 ASSIGNED RESOURCES, bus 0 done. Enabling PCI resourcess...done. Initializing PCI devices... PCI devices initialized totalram: 1020M Initializing CPU #0 Enabling cache...done. Max cpuid index : 1 Vendor ID : GenuineIntel Processor Type : 0x00 Processor Family : 0x05 Processor Model : 0x01 Processor Mask : 0x00 Processor Stepping : 0x03 Feature flags : 0x00800111 done. CPU #0 Initialized intel_mainboard_fixup() Testing SMI SMI disabled Enabling extended BIOS access...done. Checking IRQ routing tables.../home/andrew/linuxbios/freebios/src/arch/i386/lib/pirq_routing.c: 24:check_pirq_routing_table() - irq_routing_table located at: 0x00009720 /home/andrew/linuxbios/freebios/src/arch/i386/lib/pirq_routing.c: 31:check_pirq_routing_table() - checksum is: 0x63 but should be: 0xa6 /home/andrew/linuxbios/freebios/src/arch/i386/lib/pirq_routing.c: 49:check_pirq_routing_table() - checksum error in irq routing table done. Copying IRQ routing tables to 0xf0000...done. Wrote linuxbios table at: 00000500 - 00000644 checksum f2ff Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0x000c0000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 New segment addr 0x400000 size 0xb560 offset 0x60 filesize 0x7209 (cleaned up) New segment addr 0x400000 size 0xb560 offset 0x60 filesize 0x7209 Loading Segment: addr: 0x0000000000400000 memsz: 0x000000000000b560 filesz: 0x0000000000007209 Clearing Segment: addr: 0x0000000000407209 memsz: 0x0000000000004357 Jumping to boot code at 0x400000 registers just before 'cld' instruction: eax 0x3fbb9970 1069259120 ecx 0x80 128 edx 0x4d650 317008 ebx 0x3fb65360 1068913504 esp 0x115a4 0x115a4 ebp 0x115ac 0x115ac esi 0x400000 4194304 edi 0x115d8 71128 eip 0x8748 0x8748 eflags 0x7 7 cs 0x10 16 ss 0x18 24 ds 0x18 24 es 0x18 24 fs 0x18 24 gs 0x18 24 registers just before 'rep movsl' eax 0x3fbae9b0 1069214128 ecx 0x13594 79252 edx 0x4d650 317008 ebx 0x3fb65360 1068913504 esp 0x11580 0x11580 ebp 0x115ac 0x115ac esi 0x4000 16384 edi 0x3fbb29b0 1069230512 eip 0x877c 0x877c eflags 0x2 2 cs 0x10 16 ss 0x18 24 ds 0x18 24 es 0x18 24 fs 0x18 24 gs 0x18 24 registers after 'rep movsl' eax 0x3fbae9b0 1069214128 ecx 0x0 0 edx 0x4d650 317008 ebx 0x3fb65360 1068913504 esp 0x11580 0x11580 ebp 0x115ac 0x115ac esi 0x51650 333392 edi 0x3fc00000 1069547520 eip 0x877e 0x877e eflags 0x2 2 cs 0x10 16 ss 0x18 24 ds 0x18 24 es 0x18 24 fs 0x18 24 gs 0x18 24 --Boundary-00=_TbT49FrWBdLVpdd Content-Type: text/plain; charset="us-ascii"; name="natsemi.objdump" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="natsemi.objdump" ../natsemi.elf: file format elf32-i386 ../natsemi.elf architecture: i386, flags 0x00000002: EXEC_P start address 0x00400000 Program Header: LOAD off 0x00000060 vaddr 0x00400000 paddr 0x00400000 align 2**5 filesz 0x00007209 memsz 0x0000b560 flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text 00006109 00400000 00400000 00000060 2**2 CONTENTS, ALLOC, LOAD, CODE 1 .rodata 00000fbe 00406120 00406120 00006180 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 00000129 004070e0 004070e0 00007140 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 00004340 00407220 00407220 00007280 2**5 ALLOC 4 .comment 000000d0 00000000 00000000 00007280 2**0 CONTENTS, READONLY --Boundary-00=_TbT49FrWBdLVpdd Content-Type: text/plain; charset="us-ascii"; name="config" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config" target orasis-v1 mainboard dauphin/orasis-v1 option HAVE_PIRQ_TABLE=1 option SERIAL_CONSOLE=1 option INBUF_COPY=1 option DEFAULT_CONSOLE_LOGLEVEL=15 #option SERIAL_POST=1 option DEBUG=1 option USE_GENERIC_ROM=1 option ROM_SIZE=262144 option NO_KEYBOARD=0 keyboard pc80 option USE_ELF_BOOT=1 #option BOOT_IDE=1 #option BOOT_FLOPPY=1 #option BOOT_TFTP=1 option BOOT_ROM=1 #option IDE_OFFSET=0x7e00 option IDE_OFFSET=0x0 option IDE_DELAY=1 dir src/pc80/ide # Path to your kernel (vmlinux) linux /home/andrew/linuxbios/linux # Kernel command line parameters commandline root=/dev/hda2 console=ttyS0,9600 single option RAMTEST=0 payload ../natsemi.elf option PAYLOAD_SIZE=196608 --Boundary-00=_TbT49FrWBdLVpdd-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: of folks unfamilar with the BIOS projects, an and this FAQ hopes to clear up the confusion. http://www.eax.com/ADLO-FAQ.html Big Pilot, if I may call you that, does this FAQ answers tose questions? The way I see, the part below is answered by Q5. Since I assume you are asking about LinuxBIOS. If you are really asking about linux kernel, then it is definitely wrong mailing list. > > if Linux fails, how is one supposed to repair it? Or is the only > > option booting Linux off a floppy and repairing using that? > > I'm wondering whether it is still possible to boot DOS (or a free > > equivalent) from a floppy if LinuxBIOS is installed on the mobo. As for above. We had limited success with Win98 which is DOS based (we can get as far as desktop screen, but there are issues), but as the Q6 says it is still long way to go. As for the particular susbsystem -- floppy, it has not been tested at all, and is presumed not working at the moment. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: -------------------- I have the code to set the legacy registers to start VGA for a vga console, integrated into linuxbios, working on two different integrated chips, the stpc cpu/chipset, and the sis 630 chipset. It sets the registers for 640x400 std text vga, and also 640x480x4 graphics. I was working on the display of a .pcx graphics file when I had to get onto something else, but it was all working the last time I tried it. The only reason this hasn't been integrated into linuxbios codebase at this point is partly lack of interest (I think) in this group, since most use the serial console, and partly that I have been off on other things lately. Until this gets into the linuxbios base, anyone that wants the code just send me an email. ----------------------- I guess as interest picks up, we need to integrate it into linuxbios. File list is below. -Steve #added files #vga generic src/include/pc80/vga.h src/pc80/beep.c src/pc80/font_8x16.c src/pc80/vga_load_pcx.c src/pc80/vga_load_regs.c src/pc80/vga_set_mode.c #this is a replacement src/lib/video_subr.c #pcchips 787 specific util/config/pcchips787.config src/mainboard/pcchips/m787cl+/irq_tables.c src/mainboard/pcchips/m787cl+/Config src/mainboard/pcchips/m787cl+/dll.inc src/mainboard/pcchips/m787cl+/mainboard.c #sis-vga specific src/northsouthbridge/sis/630/chipinit.h src/northsouthbridge/sis/630/chipinit.inc src/northsouthbridge/sis/630/sis630_vga.c #stpc specific util/config/stpc.config src/include/cpu/stpc/consumer2/stpc.h src/include/cpu/stpc/consumer2/vga_stpc.h src/cpu/stpc/consumer2/stpc_ram_init.inc src/cpu/stpc/consumer2/stpc_shadow_rom.inc src/cpu/stpc/consumer2/stpc_chip.inc src/cpu/stpc/consumer2/stpc_ioinit.inc src/cpu/stpc/consumer2/stpc_memsize.inc src/cpu/stpc/consumer2/stpc_cache.inc src/cpu/stpc/consumer2/stpc_idt.inc src/cpu/stpc/consumer2/stpc_framebuffer.inc src/cpu/stpc/consumer2/stpc_vga.c src/cpu/stpc/consumer2/Config src/cpu/stpc/consumer2/stpc_conf.c src/superio/SMC/fdc37b78x src/superio/SMC/fdc37b78x/setup_serial.inc src/superio/SMC/fdc37b78x/superio.c src/superio/SMC/fdc37b78x/superio.o src/mainboard/stpc/consumer2/Config src/mainboard/stpc/consumer2/mainboard.c src/mainboard/stpc/consumer2/irq_tables.c src/northsouthbridge/stpc/consumer2/Config src/northsouthbridge/stpc/consumer2/nsbridge.c #changed (diff) files src/include/pc80/ide.h src/pc80/Config src/pc80/ide/ide.c src/lib/linuxbiosmain.c src/arch/i386/lib/hardwaremain.c src/arch/i386/lib/params.c src/arch/i386/include/arch/pirq_routing.h src/rom/ide_fill_inbuf.c src/rom/floppy_fill_inbuf.c src/cpu/p5/Config src/cpu/p5/delay_tsc.c src/northsouthbridge/sis/630/Config src/northsouthbridge/sis/630/raminit.inc src/northsouthbridge/sis/630/southbridge.c From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: ... Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 0000063c checksum f4eb ... From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: ... Probing...[SIS900]Found SIS 900 ROM address 0x0000 The PCI BIOS has not enabled this device! Updating PCI command 0003->0007. pci_bus 00 pci_device_fn 09 ... Linux startup messages: ... sis900.c: v1.08.04 4/25/2002 PCI: No IRQ known for interrupt pin C of device 00:01.1. Please try using pci=b. eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using transceiver found at address 1 as default eth0: SiS 900 PCI Fast Ethernet at 0x2000, IRQ 0, 00:d0:09:a2:0b:f0. ... From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: However, due to full support of VGA is necessary, I'm trying to figure out ADLO to run binary only VGABIOS rom image. Can I acomplish this with ADLO?. If yes, how much extra work will be needed you think? Thanks, - HeeChul Yun, Embedded S/W Team at ETRI phone: +82-42-860-1673 ------_=_NextPart_001_01C2E6A3.9894EDF0 Content-Type: text/html; charset="iso-2022-kr" ADLO for EPIA

Hello,

I'm trying to bring up VGA on EPIA board.
From the list, EPIA board is supported and I've tested with Angrew's image.
However, due to full support of VGA is necessary, I'm trying to figure out ADLO to run binary only
VGABIOS rom image.
Can I acomplish this with ADLO?. If yes, how much extra work will be needed you think?

Thanks,

-
HeeChul Yun,         
Embedded S/W Team at ETRI
phone: +82-42-860-1673

------_=_NextPart_001_01C2E6A3.9894EDF0-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: for the fallback image to be appended. It didn't work because you didn't have a fallback image at the top of the flash (the end of the image file). G'day, sjames On Thu, 10 Apr 2003, Atherton, Stephen wrote: > > I'm trying to get etherboot and linuxbios running on a supermicro p4dpe. > > The config file I'm using is below. It builds okay, and I get a > romimage of around 460k (not sure why it isn't 524288), but when I burn > it (using flash_and_burn), it doesn't seem to work. I get no output on > the serial port. Note that I have BOOT_IDE set to 1 because at this > point I would be happy just to see it boot anything, and I have linux on > the ide hard disk. Does BOOT_IDE do what I think it does, or is that > for something else? Is there something wrong with my config file, or > should I use some other flash program for this board? I tried the one > from supermicro, and doesn't seem to like my romimage file, it exits > with "cannot close filehandle". > > Also, a few other questions... > > Does linuxbios cause a beep or do anything so that when the machine is > powered on I would have some clue that it is working? > > Since I'm using the etherboot elf image as a payload, the linux and > commandline directives in the config file do nothing, right? > > What does USE_FALLBACK_IMAGE do exactly? > > > LinuxBios Config file: > > target supermicro > mainboard supermicro/p4dpe > option USE_FALLBACK_IMAGE=0 > option ROM_SIZE=524288 > option ROM_IMAGE_SIZE=49152 > option SERIAL_CONSOLE=1 > option TTYS0_BAUD=9600 > option TTYS0_BASE=0x3f8 > option TTYS0_LCS=0x3 > option DEFAULT_CONSOLE_LOGLEVEL=9 > option MAXIMUM_CONSOLE_LOGLEVEL=8 > option USE_ELF_BOOT=1 > option BOOT_IDE=1 > payload ../eepro100.elf > option CPU_CLOCK_MULTIPLIER=XEON_X17 > option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON > linux /usr/src/linux-2.4.18-14 > commandline root=/dev/hda2 console=ttyS0,9600 single > > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: G'day, sjames On Fri, 11 Apr 2003, ron minnich wrote: > On Fri, 11 Apr 2003, steven james wrote: > > > intel/Clearwater533 will be quite similar. Note that the e7501 code has > > reported problems with 533MHz CPUs. It looks like there are just a few > > registers in the northbridge that will need to be tweaked. I need to get a > > pair of CPUs to fix that unless someone beats me to it (patches greatfully > > accepted :-) > > I called Intel yesterday about this 533 Mhz. issue and the lack of > accurate docs. The person I talked to said he will try to help. > > ron > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 ----------------------------------------------------------------------- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: for the fallback image to be appended. It didn't work because you didn't have a fallback image at the top of the flash (the end of the image file). Ron Minnich expanded on fallback vs. primary: You need to build TWO linuxbioses, a fallback and a primary. The fallback is 64k. The primary is (romsize-64k). To build a romimage, you build the fallback, build the primary, then: cat primary/romimage fallback/romimage > final_romimage flash_rom final_romimage Steve Gehlbach wrote about using BOOT_IDE: See pcchips787.config in util/config for complete configuration. option BOOT_IDE=1 This enables booting from IDE, the file to use is linux.bin.gz: option IDE_BOOT_DRIVE=2 If you do not use drive 0 (default), then you can set which drive to boot; (0,1,2,3) are the four standard PC drives: option ONE_TRACK=32 The linux.bin.gz file is put in raw form at partition 1, ie, the first partition on the disk. This is located just past the partition table. The partition table size varies, it is "one track" from the beginning of the disk. "one track" in c/h/s notation is "s" or the number of sectors per track. ONE_TRACK is in sectors, the software multiplies by 512. Most disks are 63 sectors per track (the default), but my CF is 32 sectors per track. eg, the partion table is 63x512 or 32x512 bytes. You can partition your disk as you want, but Linux goes raw in partition 1; just make sure partition 1 is big enough, not a problem on today's disks. You could put the Linux root file system on partition 2, for example. In pcchips787.config, I put the Linux root file system on IDE 0, partition 2 (I was experimenting with Linux in partition 1), but I eventually put Linux on drive 2 using CF. You are right, copying of linux.bin.gz raw to the partition is dangerous, and something like "cat linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the wrong disk or partition. I recommend a shell script, fingers cannot be trusted. You can also use "dd" but "cat" works. Greg Watsons had some good comments on on the boot process and file layout: There seem to be two main parts to linuxbios. The first is arch/{arch}/config/ctr0.base which does the very low level initialization, like turning on memory, etc. The second is arch/{arch}/lib/c_start.S which does whatever else is necessary to call the C function hardwaremain(). hardwaremain() then does whatever else is necessary to load Linux. c_start.S is linked with linuxbios.a, a library containing generic support routines (those found in the lib directory) and anything specified using the 'object' directive in a Config file (and other stuff). The resultant 'executable' is called linuxbios_c. The loader script used to link linuxbios_c is config/linuxbios_c.ld, and is configured to be loaded relative to _RAMBASE. crt0.base is not linked against anything. Any additional assembly routines you need must be specified using the 'mainboardinit' directive in a Config file. This causes the specified assembly file to be added to "crt0_includes.h" which is in turn included at the start of crt0.base (or at the end in the case of the ppc version). The loader script used to link crt0.base is in arch/{arch}/config/ldscript.base. The resultant 'executable' is called linuxbios and will be loaded at _ROMBASE. The tricky thing is that this loader script will also load the linuxbios_c 'executable' at a location called _payload in this file. The main task of crt0.base is then to initialize enough hardware so that this payload can be copied from ROM into ram (which may also involve uncompressing code). Then control is transferred to _start, which is the first location in linuxbios_c. To get an idea of how crt0.base works, look at the following files. This is the order of execution specified by the configuration file for sis735. cpu/i386/entry16.inc cpu/i386/entry32.inc superio/sis/950/setup_serial.inc pc80/serial.inc arch/i386/lib/console.inc cpu/k7/earlymtrr.inc northsouthbridge/sis/735/raminit.inc arch/i386/config/crt0.base Next look at c_start.S which will show you what happens once control is transferred to _start. Finally, look at arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get Linux loaded. Most other files are specific to particular hardware, so it can be pretty confusing to just browse the tree. Hope this helps, Greg From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: cat image > /dev/mtd0 So it seems there is something 'sticky' in these parts when new, cured by programming individual blocks. Flash is very odd ... ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: _________________________________________________________________ ?????? ???????? ?????? ????????, ??????... ?????? ???? http://www.msn.co.kr/money/interlotto/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: _________________________________________________________________ MSN Messenger?? ???? ?????????? ???? ?????? ?????? ????????. http://messenger.msn.co.kr From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > LinuxBIOS-1.1.5.0Normal Sat Oct 11 00:21:05 MDT 2003 booting... > Finding PCI configuration type. > PCI: Using configuration type 1 > Enumerating: AMD K8 Northbridge > Enumerating: AMD K8 Northbridge > Enumerating: AMD K8 > Enumerating: AMD K8 > Enumerating: AMD 8111 > Enumerating: NSC 87360 > Enumerating buses...PCI: pci_scan_bus for bus 0 > PCI: 00:18.0 [1022/1100] enabled > PCI: 00:18.1 [1022/1101] enabled > PCI: 00:18.2 [1022/1102] enabled > PCI: 00:18.3 [1022/1103] ops > PCI: 00:18.3 [1022/1103] enabled > PCI: 00:19.0 [1022/1100] enabled > PCI: 00:19.1 [1022/1101] enabled > PCI: 00:19.2 [1022/1102] enabled > PCI: 00:19.3 [1022/1103] ops > PCI: 00:19.3 [1022/1103] enabled > amdk8_scan_chains max: 0 starting... > Hyper transport scan link: 0 max: 1 > PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 > PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 > HyperT reset not needed > PCI: pci_scan_bus for bus 1 > PCI: 01:01.0 [1022/7450] bus ops > PCI: 01:01.0 [1022/7450] enabled > PCI: 01:01.1 [1022/7451] ops > PCI: 01:01.1 [1022/7451] enabled > PCI: 01:02.0 [1022/7450] bus ops > PCI: 01:02.0 [1022/7450] enabled > PCI: 01:02.1 [1022/7451] ops > PCI: 01:02.1 [1022/7451] enabled > PCI: 01:03.0 [1022/7460] enabled > PCI: 01:04.0 [1022/7468] bus ops > PCI: 01:04.0 [1022/7468] enabled > PCI: 01:04.1 [1022/7469] ops > PCI: 01:04.1 [1022/7469] enabled > PCI: 01:04.2 [1022/746a] enabled > PCI: 01:04.3 [1022/746b] ops > PCI: 01:04.3 [1022/746b] enabled > amd8111_enable dev: PCI: 01:04.5 lpc_dev: PCI: 01:04.0 index: 5 reg: ffff -> ffdf done > PCI: 01:04.5 [ffff/ffff] disabled > amd8111_enable dev: PCI: 01:04.6 lpc_dev: PCI: 01:04.0 index: 6 reg: ffdf -> ff9f done > PCI: 01:04.6 [ffff/ffff] disabled > PCI: pci_scan_bus for bus 2 > PCI: 02:03.0 [14e4/16a6] enabled > PCI: 02:04.0 [14e4/16a6] enabled > PCI: pci_scan_bus returning with max=02 > PCI: pci_scan_bus for bus 3 > PCI: pci_scan_bus returning with max=03 > PCI: pci_scan_bus for bus 4 > PCI: 04:00.0 [1022/7464] ops > PCI: 04:00.0 [1022/7464] enabled > PCI: 04:00.1 [1022/7464] ops > PCI: 04:00.1 [1022/7464] enabled > PCI: 04:00.2 [1022/7463] ops > PCI: 04:00.2 [1022/7463] enabled > amd8111_enable dev: PCI: 04:01.0 lpc_dev: PCI: 01:04.0 index: 9 reg: ff9f -> fd9f done > PCI: 04:01.0 [ffff/ffff] disabled > PCI: 04:06.0 [1002/4752] enabled > PCI: pci_scan_bus returning with max=04 > PNP: 002e.0 enabled > PNP: 002e.1 enabled > PNP: 002e.2 enabled > PNP: 002e.3 enabled > PNP: 002e.4 enabled > PNP: 002e.5 enabled > PNP: 002e.6 enabled > PNP: 002e.7 enabled > PNP: 002e.8 enabled > PNP: 002e.9 enabled > PNP: 002e.a enabled > PCI: pci_scan_bus returning with max=04 > Hyper transport scan link: 0 new max: 4 > Hypertransport scan link done > amdk8_scan_chains max: 4 done > amdk8_scan_chains max: 4 starting... > amdk8_scan_chains max: 4 done > PCI: pci_scan_bus returning with max=04 > done > Allocating resources... > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 04:01.0 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > ASSIGN RESOURCES, bus 0 > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 c0 <- [0x00001000 - 0x00002fff] node 0 link 0 io > PCI: 01:04.5 missing read_resources > PCI: 01:04.6 missing read_resources > PCI: 00:18.0 b8 <- [0xfd000000 - 0xfe2fffff] node 0 link 0 mem > ASSIGN RESOURCES, bus 1 > PCI: 01:01.0 1c <- [0x00002000 - 0x00001fff] bus 2 io > PCI: 01:01.0 24 <- [0xfe200000 - 0xfe1fffff] bus 2 prefmem > PCI: 01:01.0 20 <- [0xfe100000 - 0xfe1fffff] bus 2 mem > ASSIGN RESOURCES, bus 2 > PCI: 02:03.0 10 <- [0xfe100000 - 0xfe10ffff] mem > PCI: 02:04.0 10 <- [0xfe110000 - 0xfe11ffff] mem > ASSIGNED RESOURCES, bus 2 > PCI: 01:01.1 10 <- [0xfe200000 - 0xfe200fff] mem > PCI: 01:02.0 1c <- [0x00002000 - 0x00001fff] bus 3 io > PCI: 01:02.0 24 <- [0xfe200000 - 0xfe1fffff] bus 3 prefmem > PCI: 01:02.0 20 <- [0xfe200000 - 0xfe1fffff] bus 3 mem > PCI: 01:02.1 10 <- [0xfe201000 - 0xfe201fff] mem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 1c <- [0x00001000 - 0x00001fff] bus 4 io > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 24 <- [0xfe200000 - 0xfe1fffff] bus 4 prefmem > PCI: 04:01.0 missing read_resources > PCI: 01:03.0 20 <- [0xfd000000 - 0xfeffffff] bus 4 mem > ASSIGN RESOURCES, bus 4 > PCI: 04:00.0 10 <- [0xfe000000 - 0xfe000fff] mem > PCI: 04:00.1 10 <- [0xfe001000 - 0xfe001fff] mem > PCI: 04:00.2 10 <- [0xfe003000 - 0xfe0030ff] mem > PCI: 04:00.2 14 <- [0xfe004000 - 0xfe00401f] mem > PCI: 04:01.0 missing set_resources > PCI: 04:06.0 10 <- [0xfd000000 - 0xfdffffff] mem > PCI: 04:06.0 14 <- [0x00001000 - 0x000010ff] io > PCI: 04:06.0 18 <- [0xfe002000 - 0xfe002fff] mem > ASSIGNED RESOURCES, bus 4 > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io > PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem > ASSIGN RESOURCES, bus 0 > PNP: 002e.0 60 <- [0x00002480 - 0x00002485 io > ERROR: PNP: 002e.0 70 not allocated > ERROR: PNP: 002e.0 74 not allocated > PNP: 002e.1 60 <- [0x00002000 - 0x00002307 io > ERROR: PNP: 002e.1 70 not allocated > ERROR: PNP: 002e.1 74 not allocated > PNP: 002e.2 60 <- [0x00002440 - 0x00002447 io > ERROR: PNP: 002e.2 70 not allocated > ERROR: PNP: 002e.2 74 not allocated > ERROR: PNP: 002e.2 75 not allocated > PNP: 002e.3 60 <- [0x000003f8 - 0x000003f7 io > PNP: 002e.3 70 <- [0x00000004 - 0x00000003 irq > PNP: 002e.4 60 <- [0x00002420 - 0x0000242f io > ERROR: PNP: 002e.4 70 not allocated > ERROR: PNP: 002e.5 70 not allocated > PNP: 002e.6 60 <- [0x00000060 - 0x0000005f io > PNP: 002e.6 62 <- [0x00000064 - 0x00000063 io > PNP: 002e.7 60 <- [0x00002450 - 0x00002457 io > ERROR: PNP: 002e.7 70 not allocated > PNP: 002e.8 60 <- [0x00002460 - 0x00002467 io > ERROR: PNP: 002e.8 70 not allocated > PNP: 002e.9 60 <- [0x00002470 - 0x00002477 io > ERROR: PNP: 002e.9 70 not allocated > PNP: 002e.a 60 <- [0x00002490 - 0x00002493 io > ERROR: PNP: 002e.a 70 not allocated > ASSIGNED RESOURCES, bus 0 > PCI: 01:04.1 20 <- [0x00002430 - 0x0000243f] io > PCI: 01:04.2 10 <- [0x00002400 - 0x0000241f] io > PCI: 01:04.5 missing set_resources > PCI: 01:04.6 missing set_resources > ASSIGNED RESOURCES, bus 1 > ASSIGNED RESOURCES, bus 0 > Allocating VGA resource > done. > Enabling resourcess... > PCI: 00:18.0 cmd <- 00 > PCI: 01:01.0 bridge ctrl <- 0000 > PCI: 01:01.0 cmd <- 07 > PCI: 02:03.0 cmd <- 02 > PCI: 02:04.0 cmd <- 02 > PCI: 01:01.1 cmd <- 02 > PCI: 01:02.0 bridge ctrl <- 0000 > PCI: 01:02.0 cmd <- 07 > PCI: 01:02.1 cmd <- 02 > PCI: 01:03.0 bridge ctrl <- 003e > PCI: 01:03.0 cmd <- 07 > PCI: 04:00.0 cmd <- 02 > PCI: 04:00.1 cmd <- 02 > PCI: 04:00.2 cmd <- 02 > PCI: 04:01.0 missing enable_resources > PCI: 04:06.0 cmd <- 83 > PCI: 01:04.0 cmd <- 0f > PCI: 01:04.1 cmd <- 01 > PCI: 01:04.2 cmd <- 01 > PCI: 01:04.3 cmd <- 00 > PCI: 01:04.5 missing enable_resources > PCI: 01:04.6 missing enable_resources > PCI: 00:18.1 cmd <- 00 > PCI: 00:18.2 cmd <- 00 > PCI: 00:18.3 cmd <- 00 > PCI: 00:19.0 cmd <- 00 > PCI: 00:19.1 cmd <- 00 > PCI: 00:19.2 cmd <- 00 > PCI: 00:19.3 cmd <- 00 > done. > Initializing devices... > PCI: 00:18.3 init > NB: Function 3 Misc Control.. done. > PCI: 00:19.3 init > NB: Function 3 Misc Control.. done. > PCI: 01:01.0 init > PCI: 01:02.0 init > PCI: 01:04.0 init > lpc_init > PCI: 01:04.1 init > ide_init > IDE1 IDE0 PCI: 01:04.3 init > set power on after power fail > PCI: 04:00.0 init > USB: Setting up controller.. done. > PCI: 04:00.1 init > USB: Setting up controller.. done. > PCI: 04:00.2 init > USB: Setting up controller.. done. > Devices initialized > mmio_base: 3932160KB > totalram: 2048M > Initializing CPU #0 > Enabling cache... > Setting fixed MTRRs(0-88) type: UC > Setting fixed MTRRs(0-88) type: WB > DONE fixed MTRRs > Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > DONE variable MTRRs > Clear out the extra MTRR's > call intel_enable_fixed_mtrr() > call intel_enable_var_mtrr() > Leave setup_mtrrs > done. > > Max cpuid index : 1 > Vendor ID : AuthenticAMD > Processor Type : 0x00 > Processor Family : 0x0f > Processor Model : 0x05 > Processor Mask : 0x00 > Processor Stepping : 0x01 > Feature flags : 0x078bfbff > > > MTRR check > Fixed MTRRs : Enabled > Variable MTRRs: Enabled > > Setting up local apic... apic_id: 0 done. > CPU #0 Initialized > secondary_cpu_init > Waiting for 2 CPUS to stop > mmio_base: 3932160KB > Initializing CPU #1 > Enabling cache... > Setting fixed MTRRs(0-88) type: UC > Setting fixed MTRRs(0-88) type: WB > DONE fixed MTRRs > Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > DONE variable MTRRs > Clear out the extra MTRR's > call intel_enable_fixed_mtrr() > call intel_enable_var_mtrr() > Leave setup_mtrrs > done. > > Max cpuid index : 1 > Vendor ID : AuthenticAMD > Processor Type : 0x00 > Processor Family : 0x0f > Processor Model : 0x05 > Processor Mask : 0x00 > Processor Stepping : 0x01 > Feature flags : 0x078bfbff > > > MTRR check > Fixed MTRRs : Enabled > Variable MTRRs: Enabled > > Setting up local apic... apic_id: 16777216 done. > CPU #1 Initialized > secondary_cpu_init 1/1 > All AP CPUs stopped > Checking IRQ routing tables... > Inconsistent IRQ routing table size > /home/eric/projects/linuxbios/checkin/hdama/foo/freebios2/src/arch/i386/boot/pirq_routing.c: 29:check_pirq_routing_table() - irq_routing_table located at: 0x0000f1c0 > done. > Copying IRQ routing tables to 0xf0000...done. > Verifing priq routing tables copy at 0xf0000...succeed > Wrote the mp table end at: 00000020 - 0000021c > Wrote linuxbios table at: 00000500 - 00000b00 checksum 4399 > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.3 > > Found ELF candiate at offset 0 > Loading Etherboot version: 5.2.1eb1 > Dropping non PT_LOAD segment > New segment addr 0x20000 size 0x3936f offset 0xc0 filesize 0x70d8 > (cleaned up) New segment addr 0x20000 size 0x3936f offset 0xc0 filesize 0x70d8 > Loading Segment: addr: 0x0000000000020000 memsz: 0x000000000003936f filesz: 0x00000000000070d8 > Clearing Segment: addr: 0x00000000000270d8 memsz: 0x0000000000032297 > Jumping to boot code at 0x20000 > ROM segment 0x0000 length 0x0000 reloc 0x00020000 > CPU 1457 Mhz > Etherboot 5.2.1eb1 (GPL) http://etherboot.org ELF64 ELF for [TG3][IDE] From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: range of helpful holiday info here. http://special.msn.com/network/happyholidays.armx From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: more robust than your armboot, so I'd like to merge your stuff into mine if possible. Now that 2.6.0 is out I can start sending patches again. - I avoid deliberately avoid vmalloc, the vmalloc area is a limited resource, and I support loading large kernel ramdisk combinations. - I avoid greater than page size memory allocations because random memory fragmentation can make that fail. - I don't leak memory. - I have an implementation that works on SMP machines. The worst part is getting all of the drivers to shut themselves down properly. But I have the appropriate hooks and it doesn't take an extension of the kernel api just lots of driver bug fixes. If even the arm guys are up to using a kernel it should be easier to make progress in this array. On several projects the people I have talked to are two size constrained to even try using a kernel. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: The Core Logic module positively decodes memory addresses 000F0000h-000FFFFFh (64 KB) and FFFC0000h-FFFFFFFFh (256 KB) at reset. These memory cycles cause the Core Logic module to claim the cycle, and generate an ISA bus memory cycle with ROMCS# asserted. The Core Logic module can also be configured to respond to memory addresses FF000000h-FFFFFFFFh (16 MB) and 000E0000h-000FFFFFh (128 KB). 8- or 16-bit wide ROM is supported. BOOT16 strap determines the width after reset. MCR[14,3] (Offset 34h) in the General Configuration Block allows program control of the width. Flash ROM is supported in the Core Logic module by enabling the ROMCS# signal on write accesses to the ROM region. Normally only read cycles are passed to the ISA bus, and the ROMCS# signal is suppressed for write cycles. When the ROM Write Enable bit (F0 Index 52h[1]) is set, a write access to the ROM address region causes a write cycle to occur with MEMW#,WR# and ROMCS# asserted. The Boot Flash supported by the SC1200/SC1201 can be up to 16 MB. It is supported with the ROMCS# signal. As the corelogic module positively decodes the memory addresses 000F0000h-000FFFFFh (64 KB) and FFFC0000h-FFFFFFFFh (256 KB) at reset, I can have my Flash memory mapped to the lower address. Is it? >From: ron minnich >To: Devi Priya >CC: linuxbios at clustermatic.org >Subject: Re: Flash mapped to lower address? >Date: Wed, 24 Dec 2003 18:39:20 -0700 (MST) > >On Tue, 23 Dec 2003, Devi Priya wrote: > > > If i have my Flash memory mapped to the lower address (0x0000-0x3FFFFF), > > then what modification should be made to linux bios? > >why on earth would you map flash to this address? it makes no sense to me. > >ron > >_______________________________________________ >Linuxbios mailing list >Linuxbios at clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ NRI?s, Free Money transfer to India. http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp?type=hottag Click here. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: it appears to be the equal of bk etc. I think I see some was to make it simpler and more powerful but that is not needed to make a good revision control system. I need to do a little more testing to see what arch is actually like to use. Before I seriously start advocating anything but I'm not expecting any weird issues to crop up. Except possibly for some issues running under cygwin, for the platform challenged. Once my evaluation is finished I plan on pushing the projects I work on in that direction. So this is something to think about. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: extra eeprom actually connected, so there is no real alternative other than downloading the controller firmware > Actually the FW download and controller starting can be done by Linux kernel > driver. Aha! This sounds really interesting. Looking into the code, there is /dev/mptctl. This can be used for firmware upload/download (ioctl interface) - Is there a utility to do this, yet? Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: buried within them. For example, ATi and their OEMs release a series of cards called "All-In-Wonder" with each new chip. These AIW cards have a ton of extras on them like TV-tuners, hardware media decoders, the works. So for people looking to by a single card to perform multiple tasks rather than buying a Radeon, DXR3, tv tuner, etc, this is a good deal. However, those extras such the TV tuner and media decoder chips aren't necessarily ATi's own design. And for some reason, ATi can't release specs on everything *but* the proprietary chips (And some industry "analysts" call the GPL viral!). But then again, I have no way of verifying this, and it's a discussion for another BBS :) On Mon, 9 Feb 2004, Terry Blunt wrote: > "Hendricks David W." wrote: > > > We don't need to with nVidia, we can run their VGA BIOS using testbios. > > > > Though in the perfect world, they'd be more forthcoming with specs so that > > someone can make an LB port for their nForce boards. > > > > On Mon, 9 Feb 2004, Carlos Silva wrote: > > > > > Really nice news... i'll keep dreaming that nvidia will do the same. > > Maybe I'm missing something, but I can never understand hardware > manufacturers being cagey about their specs. I would have thought it would > save them a lot of hassle if they *didn't* have to write drivers themselves. > If they made the information available with suggestions and worked examples, > the software industry would do it all for them. > > To forestall one argument, I really don't see anyone being able to reverse > engineer the *hardware* from the overall specs. > > From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: cards depend on, or can depend on at that stage so we should be in reasonably good shape long term. At least until x86 BIOS compatibility is given up. An important thing to verify here is that the standard cpu identification steps will show the emulated cpu to be a 386 or whatever minimal processor we support. And we should tightly restrict the emulated codes access to memory, presenting it with a virtual not a real view of what is going on. Keeping the code chained as much as possible. Beyond that... If we want the video card to provide int 0x10 services to a pcbios compatibility layer we need to rerun the video card initialization in the bochs bios. I think the simplest path to a flexible LinuxBIOS solution is to have a native LinuxBIOS loader like etherboot, the Linux kernel or possibly something much simpler act as a switch between the different personalities we can wear, PCBIOS openfirmware, efi, arc, etc. And we will boot with whichever one the user selects. Using a bootloader as a switch to select among the others is the only easy way I can see to have my cake and it too with supporting multiple personalities. You get only one at a time but I think that is easier to verify. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Some efforts are on their way, but still in development... ( VIA does not want to give all the information we need so far ) -----Original Message----- Subject: Epia-M IDE HowTo > > Hi, > I have a EPIA-M (ME6000) and I want to use Linuxbios for my HTPC. > > So I want to boot from hd. > Is there anywhere a good HowTo for this. > > The HowTo in the cvs for talks only about etherboot. > > greetz > From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Strange enough, since the Maxtor harddrive was installed using LinuxBIOS and Filo a while ago.. Stefan -- Stefan Reinauer, SUSE LINUX AG Head of Architecture Development From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Travel Guide! http://special.msn.com/local/springtravel.armx From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Travel Guide! http://special.msn.com/local/springtravel.armx From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > > I don't really think it is BIOS issue. > > OS can do it just fine on its own. I don't see why BIOS should be > invovled > here. > > > Has any work been done toward the goal of "Hibernation"? I'm writing > of > > the type that would use a separate partition equal to ram + swap space > > to store the current memory state. If no one has done any work to > this > > effect, how difficult would it be? I may be willing to help the > effort. > > I've never programmed for a BIOS, but I've done mmap() stuff before. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > > well I guess it depends on philosophy. if the idea is to have > minimalistic > bios then ability to suspend doesn't belong there. > > on the other hand some configurations of "bios" (where "bios" would be > the > thing in the thing in FLASH), often include linux kernel and that alone > could be re-used to enable suspend. Although the proper way to do this > is > probably to use "management mode" of the recent CPUs. > > On Fri, 14 May 2004 lbios_kk at redfenix.com wrote: > > > If the hibernation restore occurred from the BIOS, then one wouldn't > need to boot from disk, right? Also, if you don't need to boot from > disk, the BIOS could restore the entire memory state and then > re-initialize any peripherals that need it (PCI, PCMCIA, CF, VGA, etc.) > Should be quicker, elegant, and more effective, right? (and OS > independent if done right.) > > > > Question is, how much memory does LinuxBIOS use for itself? We'd have > to make sure that it doesn't "step on its own feet" trying to get the > memory state loaded. > > > > --Kevin > > > > >From Adam Sulmicki on 14 May 2004: > > > > > > > > I don't really think it is BIOS issue. > > > > > > OS can do it just fine on its own. I don't see why BIOS should be > > > invovled > > > here. > > > > > > > Has any work been done toward the goal of "Hibernation"? I'm > writing > > > of > > > > the type that would use a separate partition equal to ram + swap > space > > > > to store the current memory state. If no one has done any work to > > > this > > > > effect, how difficult would it be? I may be willing to help the > > > effort. > > > > I've never programmed for a BIOS, but I've done mmap() stuff > before. > > > > > > _______________________________________________ > > > Linuxbios mailing list > > > Linuxbios at clustermatic.org > > > http://www.clustermatic.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > On Friday 14 May 2004 4:36 pm, lbios_kk at redfenix.com wrote: > > > I'm not necessarily talking about handling a suspend or low-power > mode. > > I'm talking about copying the memory to disk, then powering off. > Then, > > upon power-on next time, reload the memory state, re-init peripherals > and > > go! > > I can't help feeling that it's a bit simplistic to just say "re-init > peripherals" like that. Some peripherals can have quite a complex > state > associated with them, and just re-initialising them as though you were > starting from power-up may not make the O/S happy when it finds itself > back > in control after the hibernation is over? > > There has to be some O/S involvement in going into, and returning from, > hibernation mode - the question for LinuxBIOS is "how much of a task is > left > over once you take out what the Linux kernel can already do for itself?" > > Regards, > > Antony. > > -- > Microsoft may sell more software than any other company, but McDonald's > sell > more burgers than any other company, and I think the other similarities > are > obvious... > > Please reply to the > list; > please don't > CC me. > > _______________________________________________ > Linuxbios mailing list > Linuxbios at clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: CPU feature. From what I have seen, embedded platforms seem to be a bit more developer friendly then normal x86 hardware. With just a small stack you can probably create much denser code at boot time. Especially since you don't have to inline everything. On the flip side cpu developers especially on the bleeding edge seem to be inovating with caches a lot so it is an easy way to run into cpu bugs. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: wanting to implement some form of code reuse. And to reuse code things must share and cooperate. I will argue that if want code reuse someone should be a library of the functions that will be reused. Then we don't need multiple PAYLOADs and all of the associated nastiness. Plus the act of putting the code in a library and cleaning it up so it can live in one is what is needed to actually make the code reusable. The current architecture of LinuxBIOS (not counting the weird FILO thing) works and does not leave us implementing an OS. As we approach being feature complete and quite general we accumulate a lot of code. But largely it is conditional upon what hardware actually exists on a motherboard. Another issue on this topic is what interface do we provide to the outside world to people who want to customize LinuxBIOS. The reason I am largely in favor of testbios, openbios, ADLO and the Linux kernel is those are interfaces that already exist. Commodity interfaces you might call them. We don't have to convince hardware manufacturers or software developers to support something new. That makes the option rom problem easier. For embedded developers the question is what will work best for their hardware and use the least amount of resources (to keep the price down) while doing so. So far LinuxBIOS has kept itself inside of 64K for x86 which is doing pretty good on general purpose server boards. As best I can tell there are two primary target configurations for LinuxBIOS. General purpose firmware that can do a lot of things. Embedded systems where things are well enough understood you can directly load your final image from flash. Except for a few issues like romcc being a code size pig I think we are ok on the minimal configurations. For the general purpose default configuration/configurations we still have a long ways to go. Etherboot when I proposed it was a stop gap that worked. And we could use it immediately because of it's size. Etherboot does not currently do everything we need. It works but is lousy at booting off of disks, for example. There are a lot of ways forward including enhancing etherboot, enhancing filo, or finally getting the Linux kernel small enough we can use it. So far I have been buried alive under the task of catching with the latest and greatest chipsets and doing all of the required ports. I have not had much time to work on the bootloader problem recently. I want people to understand the reason I have not followed through on my ideas have been scheduling conflicts and not because of any intrinsic problems with the ideas. Except possibly the romcc size optimizations :) Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Or if the CF FS crashed, how do you roll it back? Regards Yinghai Lu -----Original Message----- From: Li-Ta Lo [mailto:ollie at lanl.gov] Sent: Monday, November 01, 2004 12:05 PM To: YhLu Cc: Ronald G. Minnich; LinuxBIOS Subject: RE: FILO fixups On Mon, 2004-11-01 at 12:00, YhLu wrote: > The reason for put filo in etherboot. > 1. It can let boot from HD or net according to CMOS setting. > 2. Etherboot can produce zelf. We may got more space to put other stuff such > as USB support... > 3. Etherboot structure and support... > > I may check if filo.zlef only include FILO ..., even it is not, we still can > make it clean. > You have the same blind spot as Eric. For many people, boot over net is irrelevant. Why do they need to live with the overhead of network protocol stack and driver if all they want to to boot form some mass storage device ? Ollie From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: asm( "movl $1f, %esp\n\t" "jmp low_level_shell\n\t" "1:\n\t" ); Of course you won't come back unless you have your serial console working... Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: only. The broadband provider bundles in a 15" CRT from LG-India bringing the price up to USD$250 or so. Also, from what I've read, the simputer is more like a enhanced-PDA, ie: handheld device, rather than like a computer. From their FAQ; # Q: Is the Simputer like a PC? A: No. The Simputer is *NOT* a personal computer. It could however be a pocket computer. # Q: Is the Simputer like a Palm? A: Again no! The Simputer is much more powerful than a Palm. For example, in terms of screen size (320x240), memory capabilities (32MB RAM) and the OS (GNU/Linux). Ramesh __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: and most if not all flashchips that /dev/bios supports, plus it is less intrusive, being a userspace program. I should probably drop /dev/bios completely. Stefan From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: ROM-o-matic for the davicom card. Although one poster said he had to make mods to the etherboot loader since there is no INT19 support in the BIOS of the device and the NOINT19 stuff in etherboot didn't work. Perhaps thats all fixed now. Geting it to dhcp a linux kernel and then dumping the northbridge and sourthbridge settings is probably your only chance unless of course you can find a datasheet for OPTi somewhere. You should be able to get the SMC superIO to work pretty easily. All in all I would say the ROI on that is very low. Probably not worth the effort. -- Richard A. Smith From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: LinuxBIOS but rather chose the same name. But then again, changing a couple of strings is nothing too hard. The way to go is rather to convince them to go with the real LinuxBIOS[tm] in future. Stefan From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: That could be part of the problem. ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Small Linux' (DSL). With the latter I had to download the full X server = package to get the Via driver, and change configuration slightly to make = sure that this driver was the one that ran rather than the default Vesa = driver. Both of these setups use 2.4.x kernels, and I have no experience = with 2.6.x. To make Linuxbios VESA compatible would thus require Linuxbios to create = a persistent int 21 handler in 16 bit code. It could be made persistent = by creating it somewhere in the 0xf000 segment along with the various = tables which it creates. The int 21 handler itself is fairly trivial - it just seems to return = certain values describing the environment in which it is running: - The type and speed of main memory - which in turn is used to limit the = max resolution and refresh rate of the display so as not to hog main = memory bandwidth on slower memory - The type of display chosen and saved in CMOS - CRT, TV, Flat Panel - The size of a flat panel etc. The current int 21 handler simply returns hard coded values for these = i.e. 266Mhz DDR ram, and CRT display only. =20 Unless anyone feels that they would like to add such a handler, I would = thus recommend that folk stick with the native chipset drivers, and make = sure that they are configured to not use Bios calls for setting the = graphics mode. Other mailings have suggested that the Via 1.1.16 vga bios does not = work, whereas the 1.1.13 bios does. I suspect that Via have extended or = changed their definition of the int 21 call between these two versions - = Joy. Nick Barker From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: embedded systems, but I wonder if my board may work ? The website is a little vague on supported boards (out of date ?) so I have answered the questions from one of the FAQ entries below. Thanks for any pointers, Simon ============ If the above sources don't help, please send the following to the Mailinglist: * Step 1: A very brief description of your system: CPU and mainboard and optionally other important details. Gigabyte GA-8I848P-G / ATX / Pentium 4 / Socket 478 * Step 2: Linux lspci output for your system, generated by booting Linux via the original BIOS and runnning lspci. 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x] (rev c1) 02:02.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!Card DSL SL (rev 01) * Step 3: SuperIO chip on the mainboard (report the model numbers on the actual chip - doesn't appear in the lspci output) ITE 8712F * Step 4: Type of BIOS device (See the question "How do I identify the BIOS chip on my mainboard?" below.) * Step 5: URL to the mainboard specifications page (optional) http://www.giga-byte.com/Motherboard/Products/Products_GA-8I848P-G.htm * Step 6: Any other relevant information you can provide -- Simon Kellett, | Gentoo Linux, Fvwm, Firefox Darmstadt, Germany | Xemacs, Vm, Gnus From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: How would such an option in the chip struct look like? Should we have the revision and vendor of the SuperIO chip stored in the device tree's superio entry and enable the workaround if we find an adequate device in the tree? Yinghai, can we switch this on unconditionally or might that hurt some motherboards? 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: know if anyone has tried to get it yet. > Has anyone ever been able to work the Insyde/AMD VSA binaries into > LinuxBIOS? > I have pretty much idea about how the VSA is working. Once I got the most basic chipset init done. I will try to integrate VSA into LinuxBIOS. One advantage we just got is AMD has committed to provide support for the One Laptop per Poor Child project. Probably we will get something not normally avaliable to the public. BTW, I really need help from the LB community. I simply can't do all the hacking and coding by myself and meet OLPC/Quanta's tight schedule. Ollie From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: but does not talk. What format is the kernel image? (bzimage?) > [e1000-82541gi]Ethernet addr: 00:D0:68:09:EC:FE > Searching for server (DHCP)... > ...Me: xxx.xxx.xxx.xxx, Server: 134.155.45.16, Gateway xxx.xxx.xxx.xxx > Loading xxx.xxx.xxx.xxx:/htxlinux.0 ... > (ELF)... ............................................................................................................. > ........................................................................................................................................................... > ........................................................................................................................................................... > ........................................................................................................................................................... > ........................................................................................................................................................... > ...................................................................done > Firmware type: LinuxBIOS From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: with all bits set, while the vendor-supplied image contains meaningful data there. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: it seems that one is only meaningful for the extracted image. My first thought was to just exclude 0x006e000-0x006e8c0 from flashing, but the fact that flash_rom read only 0xff from 0x0040000-0x005fff0 made me worried. Do you have any suggestions how to find out whether the results above are expected? switch:/storage/LinuxBIOSv2-2251/util/flashrom # ./flashrom Calibrating delay loop... ok No LinuxBIOS table found. Enabling flash write on NVIDIA CK804...OK SST49LF004A/B found at physical address: 0xfff80000 Flash part is SST49LF004A/B OK, only ENABLING flash write, but NOT FLASHING. Thanks, Carl-Daniel -- http://www.hailfinger.org/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: gather that these boards have the problem: VIA EPIA-MS10000E EPIA-M mainboards EPIA-MII mainboards EPIA-TC mainboard EPIA-PD mainboard VIA EPIA M mainboard VIA EPIA MII mainboard VIA EPIA SP mainboard VIA EPIA CL mainboard Note that the "fix" is a new BIOS, which is useless to potential LB users. Also, the ML (my board) is not on there, but it has the EXACT same symptoms. > >> (mini-itx, preferrably), that has all the usual goodies >> (IDE,USB,VGA,serial, etc) that is known to work well with LinuxBios? >> Naturally, one without a VIA chipset? > > > Working well with LB is the kicker. You could join us on the GX1 > quest. There are several GX1 boards out there. If you get one like > Chris's with an external VGA chip then you won't have to mess with the > VSA stuff. I think the GX1 is close to working good but it just need > a few tweaks to get there. I'll look into them ... From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: answered them: 1. Can I fit LinuxBios with Etherboot to boot from SATA in 128KiB, it does not matter how much i chunk out as long as the machine boots! 2. If this is true, can someone PLEASE tell me how to build Etherboot under x86_64? Thanks, -- ------------------------ Arturo Mann, arturo.mann at gmail.com ------=_Part_17672_5643318.1151020394068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello there,
As i stated previously, i got my hands on a Tyan S2892, and it's included SST 49LF 8Mbit chip was botched,
after a flashing, it went completely dead, I actually tried to prom it with a big-time universal 8-gang flash PLCC prommer today.
Currently, there are no SST49LF 8Mbit replacements available in mexico (or any equivalents, actually), so, I got my hands
on the best i could get on the spot, a 128KiB (Kilobyte) AMD chip which is supported by uniFlash.
From this, I got two questions, and I would be very grateful if you lot answered them:
1. Can I fit LinuxBios with Etherboot to boot from SATA in 128KiB, it does not matter how much i chunk out as long as the machine boots!
2. If this is true, can someone PLEASE tell me how to build Etherboot under x86_64?
Thanks,

--
------------------------
Arturo Mann, arturo.mann at gmail.com

------=_Part_17672_5643318.1151020394068-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Ive just tried LB on a VIA-EPAI-PD10000 board using the EPAI-M LB config (i dont have a serial cable connected at present, going to grab one tomorow!) using my post card i get the following sequance displayed : 10/80/05 (all hex) can anyone poinbt me in the write direction ether for a list of the bios codes or if thats not available, then what the above codes indicate. I get no video output when trying to boot to the LB. It has been compiled from latest svn, with filo. If there is any other info that might help, please let me know, im hoping the post codes may point to something stupid i did in configuring/installing LB. Thanks Matt P.S. The EIPA-PD apears to use the saem chipsets as the EPIA-M, so im asuming the LB should work (at least to some extent) --bound1151714580-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: them, 1000 boards probably is. Maybe this is an area where the FSF could help to gain momentum? I got some pretty good contacts to some of the companies meanwhile, but most of our customers think 1000 boards is a whole lot. 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: We have been trying to solve the via EPIA vt8601 problem but its complicated by the fact that most of the older revs won't build anymore. Compiling romcc pukes on a lot of them. Upgrading romcc and then trying and older rev gets ugly quick. What toolchain were you on when you did most of your work on romcc? -- Richard A. Smith From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: into an existing ELF file. Cheers, Adam. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: The board is industrial grade, and it can be found here: http://www.icpamerica.com/products/single_board_computers/5_25_NOVA/NOVA-4899.html The version I have has the realtek ethernet chips. Now, for my questions: 1) if I don't specify a device in config.lb, Linux will still be able to recognize it 2) about IRQ sharing, what is the best solution 3) is it possible to enable ACPI without having the tables from the factory bios Below you'll find an 'lspci -vvv' that I managed to produce Thanks for all the input you may provide. Luis Correia lspci -vvv output 00:00.0 Host bridge: Cyrix Corporation PCI Master Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- problems tracking down just where it hangs. At first sight it appears to happen inside the SMBus read function, but that is a guess from the debug output. The problem I get is if I try and add any debug output inside SMBus read it gets worse and locks more frequently. If I have the memory test enabled it can also lock up when doing the verify. So I guess I can think of 3 reason for it to lock. 1. Some enabled, but not handled interrupt is happening. (I would assume that all interrupts are disabled at powerup but hardware so this is probably not it) 2. Southbridge is not configured properly. (would be very bad chip design if the SMBus part of the southbridge interferred with the rest of the functionality) 3. It is actually running, but serial output has stopped. ( don't think this is the case as it never boots up) I guess I need to look for loops that can become locked, probably withing the serial output code. Can anyone think of some other reason for it to lock up ? From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: off list into the issue tracker. When a new patch occurs for the same issue, it should be attached to an existing ticket. Also, Acked-By: and Signed-off-by: messages should be added to the tracker instead of using emails now (emails will be sent to the list when you do this, anyways), so we have a logically structured overview on changes that happen to LinuxBIOS. Have fun using the tool! Questions, ideas and flames are welcome, as always. Best regards, 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: The PROMJet has a clever function where a sequence of reads from ROM are interpreted as a debug write, and sent to the host. Could be a killer feature if we can't use any kind of serial. (I know that the PROMJet is expensive, but the feature is simple.) Will at least some part of the ROM always be readable after reset? Is that defined by the CPU? Does/will it happen that something between CPU and flash actually pre-loads the ROM so that there's no direct communication path? //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: living with 15-second BIOS times? If so, pointers on how to get started would be appreciated. Thanks George #lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04) Subsystem: AOPEN Inc. Unknown device 0589 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [50] #0d [0000] 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04) Subsystem: AOPEN Inc. Unknown device 0589 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at f000 [size=16] 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04) Subsystem: AOPEN Inc. Unknown device 0589 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- I'd like to get LinuxBIOS running on an AOpen Mini PC.
 
From the output below, do you think this is doable?  Or am I doomed to living with 15-second BIOS times?
 
If so, pointers on how to get started would be appreciated.
 
Thanks
 
George
 
 
#lspci -vvv
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04)
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04) (prog-if 00 [VGA])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 193
        Region 0: Memory at d0180000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at ea00 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at d0200000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at d0100000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 177
        Region 4: I/O ports at eb00 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 185
        Region 4: I/O ports at ed00 [size=32]

00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04) (prog-if 00 [UHCI])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 169
        Region 4: I/O ports at e800 [size=32]

00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04) (prog-if 00 [UHCI])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin D routed to IRQ 193
        Region 4: I/O ports at e900 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) (prog-if 20 [EHCI])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 177
        Region 0: Memory at d0240000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4) (prog-if 01 [Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: d0000000-d00fffff
        Prefetchable memory behind bridge: 0000000010000000-0000000010000000
        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [50] #0d [0000]

00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04)
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 201
        Region 0: I/O ports at e000 [size=256]
        Region 1: I/O ports at ec00 [size=64]
        Region 2: Memory at d0241000 (32-bit, non-prefetchable) [size=512]
        Region 3: Memory at d0242000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
        Subsystem: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 04) (prog-if 8a [Master SecP PriP])
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 169
        Region 0: I/O ports at <unassigned>
        Region 1: I/O ports at <unassigned>
        Region 2: I/O ports at <unassigned>
        Region 3: I/O ports at <unassigned>
        Region 4: I/O ports at f000 [size=16]

00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 04)
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 185
        Region 4: I/O ports at 5000 [size=32]

01:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) (prog-if 10 [OHCI])
        Subsystem: AOPEN Inc. Unknown device 030a
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (3000ns min, 6000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 185
        Region 0: Memory at d0021000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Subsystem: AOPEN Inc. Unknown device 0589
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 169
        Region 0: I/O ports at d000 [size=256]
        Region 1: Memory at d0020000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 10000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

 
------=_Part_186_33092904.1164678298128-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: ----> nForce 550/570/570/590 SLI (C51+MCP55) driver package 9.16 WHQL consists of the following components: . Ethernet Driver MCP55 (v60.15) "WHQL" . Network Management Tools MCP55 (v55.23) . SMBus Driver (v4.52) "WHQL" . Installer (v5.05) . WinXP IDE SataRAID Driver (v6.66) "WHQL" . WinXP IDE SataIDE Driver (v6.66) "WHQL" . WinXP RAIDTOOL Application (v6.63) This WinXP 64-bit nForce (MCP55) 9.16 driver package consists of the following components: . Ethernet Driver MCP55 (v60.15) "WHQL" . Network Management Tools MCP55 (v55.23) . SMBus Driver (v4.52) "WHQL" . Installer (v5.05) . WinXP IDE SataRAID Driver (v6.66) "WHQL" . WinXP IDE SataIDE Driver (v6.66) "WHQL" . WinXP RAIDTOOL Application (v6.63) So I think it's C51+MCP55, but maybe a true "hardware" guy could confirm ;) Simon Labrecque -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu at amd.com] Sent: Thursday, November 30, 2006 1:52 PM To: Carl-Daniel Hailfinger; Simon Labrecque Cc: ron minnich; linuxbios at linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU -----Original Message----- From: linuxbios-bounces+yinghai.lu=amd.com at linuxbios.org [mailto:linuxbios- >Both of them would be good targets. Both have onboard serial ports and both >are passively cooled. > >Differences between the two boards: >K9N Platinum >* nForce 570 >* 6 internal USB ports >* 6 SATA ports >* 2x Gbit LAN >* Firewire <------ good for Media Center What is NForce 570? Is it C51+MCP55? YH From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: some lines in buffer. YH From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 0. Now if the base address is set wrongly that would explain why the ide enable is coming back with what appears to be invalid register values. Anyone have any thoughts ? many thanks Ben From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: I have the 4M version - it's my main computer. What else would you like to know? Russ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. Unknown device 6010 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- but the SMM registers on the AMD K8 platform are locked using the SMMLOCK bit. How does the platform then handle SMI when using LinuxBIOS? I would be grateful for any advice or gotchas for my implementation. Thanks, Arvind From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: "The new Technologic Systems Bootloader is totally Linux-based, enabling much more control over the system through all the standard Linux utility commands from inside the bootloader itself. Meanwhile, it delivers fast bootup time, as short as 1.1 seconds, and small footprint, not only meeting the requirements of the real-world embedded systems, but delivering additional flexibility and power instead. After all, it is Linux booting Linux. The "bootload" facility may be useful for kernel developers, since they now have a faster way to test their new kernels without rebooting the whole system. In case a fast bootup solution is not being used, developers benefit from the use of the "bootload" program given that the time spent with firmware loading will be saved. Also, the new Bootloader solution allows the use of standard shell scripts for the programmatic selection of appropriate kernels, Linux initrd's, and kernel command line arguments for maximum flexibility. Click on the link below and find out how the TS-7400 takes advantage of these features in order to provide multiple booting options via Linux shell scripts:" ron ---------- Forwarded message ---------- Date: Jan 10, 2007 9:21 AM Subject: 1.1 sec from power on to Linux shell (busybox) prompt To: ron minnich I know these guys provided the lunchbox boards you described in your Linux Journal article. I like how they accelerated flash boot by implementing HW ECC in the CPLD. Nice work. This would have been nice in OLPC. http://www.embeddedarm.com/linux/linuxbootloader.htm From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: segment is reserved, and a part is available as memory. Does the linux code require that a 64k segment be all one or the other? What are the rules here? thanks ron === Hello, I have this situation: Linuxbios boots an Opteron motherboard with 1GB memory. Linuxbios directly loads a recent linux kernel. The memory layout is like this: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable) The f0000-f0400 region contains IRQ and ACPI tables. At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 As you can see, the 00000000000f0400-0000000040000000 region is not listed. It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping. The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory. This must be fixed either in linux or linuxbios. Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable) The /proc/iomem contains: # cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0 Kexec is happier with the patch. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: ROM signature. Regardless with my patch that switches the order the current error handling challenged code will simply drop those regions. Eric From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: after 0xC0000 segment, but it is pointing to wrong place (segment 0x32). I don't know why it is occuring with LinuxBIOS. All appear go fine, but just the Interrupt Pointer is wrong. There is someone running X Server (with Driver "vesa" on X config)? I verified this error occur with default X Server as with Xvesa. Cheers, Alan P.S.: I am sending the serial console log attached, maybe it give some help. LinuxBIOS-2.0.0_s2850_Fallback Sun Feb 25 16:10:36 BRT 2007 starting... SBLink=00 NC node|link=00 Ram1.00 Ram2.00 Ram3 Initializing memory: done Ram4 v_esp=000cffe4 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to RAM. src=fffe0000 dst=00004000 linxbios_ram.nrv2b length = 0000d7d7 linxbios_ram.bin length = 00023150 Jumping to LinuxBIOS. LinuxBIOS-2.0.0_s2850_Fallback Sun Feb 25 18:34:50 BRT 2007 booting... Enumerating buses... APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled PCI: 00:18.3 siblings=0 CPU: APIC: 00 enabled PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] enabled PCI: 01:00.0 [1022/7460] enabled PCI: 01:01.0 [1022/7460] enabled next_unitid: 0005 PCI: pci_scan_bus for bus 01 PCI: 01:01.0 [1022/7460] enabled PCI: 01:02.0 [1022/7468] enabled PCI: 01:02.1 [1022/7469] enabled PCI: 01:02.2 [1022/746a] enabled PCI: 01:02.3 [1022/746b] enabled PCI: 01:02.5 [1022/746d] enabled PCI: pci_scan_bus for bus 02 PCI: 02:00.0 [1022/7464] enabled PCI: 02:00.1 [1022/7464] enabled PCI: 02:0b.0 [1002/4752] enabled PCI: 02:0d.0 [14e4/1653] enabled PCI: 02:0e.0 [14e4/1653] enabled PCI: pci_scan_bus returning with max=002 PNP: 002e.0 enabled PNP: 002e.1 disabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.5 enabled PNP: 002e.6 disabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b enabled smbus: PCI: 01:02.3[0]->I2C: 01:50 enabled smbus: PCI: 01:02.3[0]->I2C: 01:51 enabled smbus: PCI: 01:02.3[0]->I2C: 01:52 enabled smbus: PCI: 01:02.3[0]->I2C: 01:53 enabled PCI: pci_scan_bus returning with max=002 PCI: pci_scan_bus returning with max=002 done Allocating resources... Reading resources... PCI: 01:01.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 02 prefmem Done reading resources. Allocating VGA resource PCI: 02:0b.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:01.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device PCI: 00:18.0 1b8 <- [0x00fd100000 - 0x00fd0fffff] prefmem PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd0fffff] mem PCI: 01:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 02 io PCI: 01:01.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 02 mem PCI: 02:00.0 10 <- [0x00fd040000 - 0x00fd040fff] mem PCI: 02:00.1 10 <- [0x00fd041000 - 0x00fd041fff] mem PCI: 02:0b.0 10 <- [0x00fc000000 - 0x00fcffffff] mem PCI: 02:0b.0 14 <- [0x0000001000 - 0x00000010ff] io PCI: 02:0b.0 18 <- [0x00fd042000 - 0x00fd042fff] mem PCI: 02:0b.0 30 <- [0x00ffe00000 - 0x00ffe1ffff] romem PCI: 02:0d.0 10 <- [0x00fd000000 - 0x00fd00ffff] mem64 PCI: 02:0d.0 30 <- [0x00fd010000 - 0x00fd01ffff] romem PCI: 02:0e.0 10 <- [0x00fd020000 - 0x00fd02ffff] mem64 PCI: 02:0e.0 30 <- [0x00fd030000 - 0x00fd03ffff] romem PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq PCI: 01:02.1 20 <- [0x0000002860 - 0x000000286f] io PCI: 01:02.2 10 <- [0x0000002840 - 0x000000285f] io PCI: 01:02.3 58 <- [0x0000002000 - 0x00000020ff] io PCI: 01:02.5 10 <- [0x0000002400 - 0x00000024ff] io PCI: 01:02.5 14 <- [0x0000002800 - 0x000000283f] io PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem Done setting resources. Done allocating resources. Enabling resources... PCI: 00:18.0 cmd <- 140 PCI: 01:01.0 bridge ctrl <- 000b PCI: 01:01.0 cmd <- 147 PCI: 02:00.0 subsystem <- 10f1/2850 PCI: 02:00.0 cmd <- 142 PCI: 02:00.1 subsystem <- 10f1/2850 PCI: 02:00.1 cmd <- 142 PCI: 02:0b.0 subsystem <- 10f1/2850 PCI: 02:0b.0 cmd <- 1c3 PCI: 02:0d.0 cmd <- 142 PCI: 02:0e.0 cmd <- 142 PCI: 01:02.0 subsystem <- 10f1/2850 PCI: 01:02.0 cmd <- 14f w83627hf hwm smbus enabled PCI: 01:02.1 subsystem <- 10f1/2850 PCI: 01:02.1 cmd <- 141 PCI: 01:02.2 subsystem <- 10f1/2850 PCI: 01:02.2 cmd <- 141 PCI: 01:02.3 subsystem <- 10f1/2850 PCI: 01:02.3 cmd <- 141 PCI: 01:02.5 subsystem <- 10f1/2850 PCI: 01:02.5 cmd <- 141 PCI: 00:18.1 subsystem <- 10f1/2850 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 10f1/2850 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 done. Initializing devices... Root Device init APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device f5a CPU: family 0f, model 05, stepping 0a Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 512MB, type WB DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled microcode: equivalent processor rev id = 0x004a, patch id = 0x00000000 microcode: patch id that want to apply= 0x00000047 microcode: updated to patch id = 0x00000047 success CPU model AMD Athlon(tm) 64 FX-53 Processor Setting up local apic... apic_id: 0x00 done. Clearing memory 2048K - 524288K: ------- done CPU #0 Initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 01:01.0 init PCI: 02:0b.0 init rom address for PCI: 02:0b.0 = ffe00000 copying VGA ROM Image from 0xffe00000 to 0xc0000, 0x9000 bytes entering emulator halt_sys: file /home/alan/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 47PCI: 01:02.0 init amd8111: ioapic bsp_apicid = 00 RTC Init Invalid CMOS LB checksum enabling HPET @0xfed00000 PNP: 002e.0 init PNP: 002e.2 init PNP: 002e.5 init PNP: 002e.b init PCI: 01:02.1 init IDE1 IDE0 PCI: 01:02.3 init set power on after power fail PCI: 00:18.1 init PCI: 00:18.2 init PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 02:0d.0 init rom address for PCI: 02:0d.0 = fd000000 Incorrect Expansion ROM Header Signature 14e4 PCI: 02:0e.0 init rom address for PCI: 02:0e.0 = fd020000 Incorrect Expansion ROM Header Signature 14e4 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/alan/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routddone. Wrote the mp table end at: 00000020 - 000001e8 Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 00000db8 checksum 2104 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 rom_stream: 0xffe09000 - 0xfffdffff Found ELF candidate at offset 0 Dropping non PT_LOAD segment New segment addr 0x10000 size 0x1ab24 offset 0x134 filesize 0x561c (cleaned up) New segment addr 0x10000 size 0x1ab24 offset 0x134 filesize 0x561c New segment addr 0x91000 size 0x70 offset 0x5750 filesize 0x0 (cleaned up) New segment addr 0x91000 size 0x70 offset 0x5750 filesize 0x0 New segment addr 0x100000 size 0x700000 offset 0x5750 filesize 0x1bb5f9 (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x5750 filesize 0x19Loading Segment: addr: 0x000000001ffb0000 memsz: 0x000000000001ab24 filesz: 0x0cClearing Segment: addr: 0x000000001ffb561c memsz: 0x0000000000015508 Loading Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 filesz: 0x00Clearing Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x09Clearing Segment: addr: 0x00000000002bb5f9 memsz: 0x0000000000544a07 Jumping to boot code at 0x10000 Firmware type: LinuxBIOS From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > How do the bytes change every time in 5 boots? Are > bytes just increasing? > > > So.... are flashrom and Q-flash doing the right thing (disabling shadowing), > > and if so, what's causing those 3 bytes to be different each time? > > Yes, shadow handling seems to work fine. The BIOS has _some_ reason to > change it's config (which is far bigger than the 256 bytes of nvram > nowadays, --> ESCD/DMI) > > Have you changed the configuration of the machine? (Enable/Disable > Floppy, ...?) I have not changed anything after enabling the floppy - and 3 bytes change every boot, indeed. > Can you please observe the changes over several consequtive reboots (5 > or so) I will do that Monday or Tuesday, and report back. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: plain IDE device will in fact work, but I did not want to do that because the card could be unplugged after boot and Linux would surely not like that. (At the very least, the slot would stop working until reboot, not good enough.) Linux pcmcia did not start the CF slot until after udevstart was run, so initramfs/initrd was required for root on CF. I discussed this on linux-pcmcia and it seems that in the 2.6.18rc7 kernel I was using the CF card just wasn't added to the kernel drivers, but it has been added since. I'd like to try this with a recent kernel, it may just work now. > As for my current issue, I just read something that leads me to > believe that I need to disable PCI support in filo, but I won't be > able to try until later tonight. Yes, that is correct. From my FILO Config: IDE_DISK=1 PCMCIA_CF=1 #SUPPORT_PCI=1 Re long cycles, I suggest using an Etherboot payload. You can even send FILO as a boot image to Etherboot, and experimenting with kernel parameters becomes simple. dhcpd.conf: subnet 192.168.3.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.3.25 192.168.3.99; option routers 192.168.3.1; option domain-name-servers 192.168.3.1; if substring (option vendor-class-identifier, 0, 9) = "PXEClient" { filename "/eb-5.4.1-via-rhine.zpxe"; } else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" { filename "/boot.elf"; option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff; } } Starting tftpd from the shell: (make sure to use hpa-tftp) in.tftpd -l -s -p -u root /root/epia //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > Google Summer of Code(tm) is a program that offers student developers > stipends to write code for various open source projects. Google will > be working with a several open source, free software and > technology-related groups to identify and fund several projects over a > three month period. Historically, the program has brought together > over 1,000 students with over 100 open source projects, to create > hundreds of thousands of lines of code. Find more information at http://code.google.com/soc/ We also started setting up a list of ideas for student projects. http://linuxbios.org/GSoC If you wish to participate, and take one of the projects, or have another idea for a project, please contact me via email or apply via the Google GSoC page. Have fun! Best regards, 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Is this still the vt8601 northbridge board? what southbridge? In one of your previous mails you wrote 82C686, in another one VT8231? You don't post any code that would allow people to help you debug the problem. The memory test in auto.c is not qualifying. If that jmp does not work, your memory does not work. It really is that simple. This can be frustrating, don't despair. Have you compared northbridge register dumps between linuxbios and the legacy bios? -- 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Is this still the vt8601 northbridge board? what southbridge? In one of your previous mails you wrote 82C686, in another one VT8231? You don't post any code that would allow people to help you debug the problem. The memory test in auto.c is not qualifying. If that jmp does not work, your memory does not work. It really is that simple. This can be frustrating, don't despair. Have you compared northbridge register dumps between linuxbios and the legacy bios? -- 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/ -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. --0-1154785091-1174762188=:44083 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Stepen,
 
I would like to thank you for the movitation you given to me.
 
A. For the conveniance of clarity, i am again recapitulate the facts/figures about my board.
1. Northbridge: VT8605  almost similar to VT8601 or VT8603
2.Southbridge: VT 82C686 which has integrated super I/O controller
3. CPU: 300Mhz Celeron Processor
4. Memory: 512 MB SDRAM
---------------------------------------------------------
if any other info, pls let me know
 
B.
--------
    1. In this mail, i am sending you data as much as possible for you
         comments/suggestion   for improvment the porting process.
    2. Now i would like to ask couple of question. Since raminit does not complain any failure and ramcheck also passes ramtest.Next, code in crt0.S is able to copy the code from ROM to RAM. I am also able to read the code and print them in the serial output.So my question is, if i am able to read/write correct data to/from RAM, why is there doubt on incorrect DRAM initialisation?
If i am not able to jump to a designated place (0x4000) in RAM simply due incorrect DRAM initialisation, then what are those things which i am not taking care of during DRAM initialization? Can u pls hightlight those area in RAMINIT so that i can re-walk those area.
 3. if really, the DRAM initialization is correct, then what are the factors that may stop/misdirect the control to jump to a correct location in RAM.
I tried to print the contents from the RAM which is copied from the ROM to RAM in the start of crt0.S, they are byte by byte same as is for c_start.o
 
4. Are there any role of the register like AX,BX, CX and DX & other index register while control is try to jump at ram location. For reference, i am also printed the contents of the register before jumping i.e jmp *%edi
5. In my config, i have set DCAHE_RAM =0
 
6. i have compared the register dump for linuxbios and legacy bios.They are not exactly same. Should i try to cpmpare the entire dump or the register dump of device 00.0 only? 
 
 
 
B. I would also like to give you the register dump( for the Device 00.0) of legacy BIOS
     The ouput given below has been taken by lspci
     --------------------------------------------------------------------
00: 06 11 05 06 06 00 10 22 00 00 00 06 00 00 00 00
10: 08 00 00 ec 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: fd db c8 fe 02 00 20 20 e0 00 10 20 20 20 20 20
60: 3f 2a 00 a0 e6 00 00 00 41 7c 43 0f 08 21 00 00
70: c4 80 cc 0c 0e a1 d2 00 01 b4 09 00 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 01 02 00 1f 00 00 00 00 27 12 00 00
b0: c0 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 04 00 32 42 00 b0 00 00 00 00
 
 
 
C. linuxbios log
------------------------------------------------------------------------
LinuxBIOS-2.0.0.fallback Fri Mar 23 18:50:48 IST 2007 starting...
01 is the comm register
SMBus controller enabled
vt8605  init starting
00000000 is the north 1106 0605
0120NOP
PRECHARGE
DUMMY READS
CBR
MRS
NORMAL
set ref. rate
enable multi-page open
Register Dump (from LinuxBIOS) for Device 00.0
--------------------------------------------------
00:06 11 05 06 06 00 10 22 00 00 00 06 00 00 00 00
10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:ac 08 80 03 00 00 20 20 e0 00 20 20 20 20 20 20
60:3f 00 00 30 e6 00 00 00 41 7c 43 01 08 21 00 00
70:00 00 00 00 00 00 00 00 01 f0 00 02 00 00 00 00
80:00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 01 02 00 1f 00 00 00 00 00 02 00 00
b0:80 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00
 
---Register Dump End here--------------------------
---RAM CHECKING (from 0-640K & 1M-16M)-------------
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000  00040000 00050000
00060000 00070000 00080000 00090000  000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000  00040000 00050000
00060000 00070000 00080000 00090000  000a0000
DRAM range verified.
Done.
 
Testing DRAM : 00100000-01000000
DRAM fill: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000 00170000
00180000 00190000 001a0000 001b0000 001c0000 001d0000 001e0000 001f0000
00200000 00210000 00220000 00230000 00240000 00250000 00260000 00270000
00280000 00290000 002a0000 002b0000 002c0000 002d0000 002e0000 002f0000
00300000 00310000 00320000 00330000 00340000 00350000 00360000 00370000
00380000 00390000 003a0000 003b0000 003c0000 003d0000 003e0000 003f0000
00400000 00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000 004f0000
00500000 00510000 00520000 00530000 00540000 00550000 00560000 00570000
00580000 00590000 005a0000 005b0000 005c0000 005d0000 005e0000 005f0000
00600000 00610000 00620000 00630000 00640000 00650000 00660000 00670000
00680000 00690000 006a0000 006b0000 006c0000 006d0000 006e0000 006f0000
00700000 00710000 00720000 00730000 00740000 00750000 00760000 00770000
00780000 00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000 00870000
00880000 00890000 008a0000 008b0000 008c0000 008d0000 008e0000 008f0000
00900000 00910000 00920000 00930000 00940000 00950000 00960000 00970000
00980000 00990000 009a0000 009b0000 009c0000 009d0000 009e0000 009f0000
00a00000 00a10000 00a20000 00a30000 00a40000 00a50000 00a60000 00a70000
00a80000 00a90000 00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000
00b00000 00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000 00bf0000
00c00000 00c10000 00c20000 00c30000 00c40000 00c50000 00c60000 00c70000
00c80000 00c90000 00ca0000 00cb0000 00cc0000 00cd0000 00ce0000 00cf0000
00d00000 00d10000 00d20000 00d30000 00d40000 00d50000 00d60000 00d70000
00d80000 00d90000 00da0000 00db0000 00dc0000 00dd0000 00de0000 00df0000
00e00000 00e10000 00e20000 00e30000 00e40000 00e50000 00e60000 00e70000
00e80000 00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000 00f70000
00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000 00fe0000 00ff0000
01000000
DRAM filled
DRAM verify: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000 00170000
00180000 00190000 001a0000 001b0000 001c0000 001d0000 001e0000 001f0000
00200000 00210000 00220000 00230000 00240000 00250000 00260000 00270000
00280000 00290000 002a0000 002b0000 002c0000 002d0000 002e0000 002f0000
00300000 00310000 00320000 00330000 00340000 00350000 00360000 00370000
00380000 00390000 003a0000 003b0000 003c0000 003d0000 003e0000 003f0000
00400000 00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000 004f0000
00500000 00510000 00520000 00530000 00540000 00550000 00560000 00570000
00580000 00590000 005a0000 005b0000 005c0000 005d0000 005e0000 005f0000
00600000 00610000 00620000 00630000 00640000 00650000 00660000 00670000
00680000 00690000 006a0000 006b0000 006c0000 006d0000 006e0000 006f0000
00700000 00710000 00720000 00730000 00740000 00750000 00760000 00770000
00780000 00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000 00870000
00880000 00890000 008a0000 008b0000 008c0000 008d0000 008e0000 008f0000
00900000 00910000 00920000 00930000 00940000 00950000 00960000 00970000
00980000 00990000 009a0000 009b0000 009c0000 009d0000 009e0000 009f0000
00a00000 00a10000 00a20000 00a30000 00a40000 00a50000 00a60000 00a70000
00a80000 00a90000 00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000
00b00000 00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000 00bf0000
00c00000 00c10000 00c20000 00c30000 00c40000 00c50000 00c60000 00c70000
00c80000 00c90000 00ca0000 00cb0000 00cc0000 00cd0000 00ce0000 00cf0000
00d00000 00d10000 00d20000 00d30000 00d40000 00d50000 00d60000 00d70000
00d80000 00d90000 00da0000 00db0000 00dc0000 00dd0000 00de0000 00df0000
00e00000 00e10000 00e20000 00e30000 00e40000 00e50000 00e60000 00e70000
00e80000 00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000 00f70000
00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000 00fe0000 00ff0000
01000000
DRAM range verified.
Done.
-------------END OF AUTO.C----------------------------------
 
 
vt8605 done
 
-----WE are in crt0.S-------
Copying LinuxBIOS to RAM.
--regsister dump when copying is done-----
Printing eax=00003333
Printing ebx=ffffd14a     
Printing ecx=00000000
Printing edx=ffff03f8
Printing esi=ffff7094
Printing edi=00004000
Printing cs=00000008
Printing ds=00000010
End of Register dump
 
Memory dump (from RAM 0x4000 upto 7094byte)
[I have intentionaly put some ee at the start of c_start.s for conveniance of identification. I have also deleted some of the last byte for saving space]
-------------------------------------------
ee2e0f011538410000ea104000001000b8180000008ed88ec08ed08ee08ee8b013
e680fc8d3d00600100b90080010029f9c1e90231c0f3ab8d3d2c340100b9e85401
0029f97407c1e90231c0f3abbc008001006a006a005589e58d3d10dc00008d1da1
400000b8000010006689d889da66ba008e89470089570483c30683c70881ffb0dc
000075e30f011d08dc0000b0fee68089ece8a21e0000b0eee680f4ebf96a006a00
eb726a006a01eb6c6a006a02eb666a006a03eb606a006a04eb5a6a006a05eb546a
006a06eb4e6a006a07eb486a08eb4490906a006a09eb3c6a0aeb3890906a0beb32
90906a0ceb2c90906a0deb2690906a0eeb2090906a006a0feb186a006a10eb126a
11eb0e90906a006a12eb066a006a13eb005756558d6c2420555352515054e8b51e
00005858595a5b5d5d5e5f83c408cf2700e0db000090905589e56a036a0668f803
0000e8bf33000083c40cc9c35589e50fb645085068f8030000e838340000585ac9
c35589e568f8030000e8643400000fb6c0c9c35589e568f8030000e840340000c9
c39090905589e556538b750868d4c000006a07e8bc0700006a6c56e8b305000083
c8800fb6c0506a6c56e8330600006a7f6a4156e82906000083c4286a4056e88f05
00000fb6c0506a4056e8120600006a4256e87b05000083c8f00fb6c0506a4256e8
fb05000083c4286a4a56e86105000083c8080fb6c0506a4a56e8e10500006a4f56
e84a05000083c8080fb6c0506a4f56e8ca05000083c4286a036a5856e8bd050000
83c40c85f6741a6a5156e81f05000083c8180fb6c0506a5156e89f05000083c414
6a5056e80505000088c30fb6c05068e4c000006a07e8f406000081e3f700000053
6803c100006a07e8e106000083c420536a5056e8630500006a4c56e8cc04000088
c389d883e00f50681cc100006a07e8b906000081e3f000000083cb0483c42053683
6c100006a07e8a0060000536a4c56e8250500006a046a4656e81b05000083c4246a
036a4756e80e05000068980000006a6e56e8010500006a546a4056e8f704000083c
4246a00e8c24d00005668ecdc0000684fc100006a06e84d06000083c41485f6742a
Jumping to LinuxBIOS.
[After that, it simply hangs]
---------------------------------------------------------------------------
if any other info is required to get out this problem, pls let me know.
 
 
Regards,
Sanjay
Stefan Reinauer <stepan at coresystems.de> wrote:
* sanjay tiwary [070323 14:20]:
> Hi
>
> I am not able to go beyound "Jumping to LinuxBIOS".Initially i thought
> it is a DRAM problem. But ram test passes. I am also able to
> read/write from/to RAM.So i guess my jump is not working. But i am not
> able to find out.
> So, Can anybody see the register dump which is taken before the jmp
> *%edi.
>
> LinuxBIOS-"2.0.0"".fallback" "Fri Mar 23 18:28:27 IST 2007" starting...
> Copying LinuxBIOS to RAM.
> Printing eax=00003333
> Printing ebx=ffffd14a
> Printing ecx=00000000
> Printing edx=ffff03f8
> Printing esi=ffff7092
> Printing edi=00004000
> Printing cs=00000008
> Printing ds=00000010
> End of Register dump
> --------------------------------------------

Sorry, this log contains no information useful for debugging the
problem.

From the log it seems no memory init is done at all?

Is this still the vt8601 northbridge board?
what southbridge? In one of your previous mails you wrote 82C686,
in another one VT8231?

You don't post any code that would allow people to help you debug the
problem.

The memory test in auto.c is not qualifying. If that jmp does not work,
your memory does not work. It really is that simple. This can be
frustrating, don't despair.

Have you compared northbridge register dumps between linuxbios and the
legacy bios?


--
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/

--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios


It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar. --0-1154785091-1174762188=:44083-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: be used to lock the chip write or chip select line. 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Is this still the vt8601 northbridge board? what southbridge? In one of your previous mails you wrote 82C686, in another one VT8231? You don't post any code that would allow people to help you debug the problem. The memory test in auto.c is not qualifying. If that jmp does not work, your memory does not work. It really is that simple. This can be frustrating, don't despair. Have you compared northbridge register dumps between linuxbios and the legacy bios? -- 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/ -- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar.-- linuxbios mailing list linuxbios at linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. --0-1591968864-1174842609=:72724 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Stepen ,
Thanks !!!
 
I tried to use the same sequence of RAM initialisation as is in northbridge/via/vt8601/raminit.c but i have use the legacy bios value whenever i am try to program the register you pointed out.
I have also programmed Reg 50-55 for CPU setup with the proper value from the legacy BIOS.Did proper setting for 0xf8 and 0xf9 at the end of DRAM initialisation.
 
Still it is not jumping. I guess i am missing somewhere in the sequence of initialisation .
If u have any pointer , pls let me know.
Some of the more facts , i would like to tell you
1.I am enabling Shadow ram before starting the ram initialization. I dont know what impact it will make. Shadow ram register are 0x61, 0x62 and 0x63.
2. After SDRAM normal operation setiing to the 0x6c register, i am setting 0x5A-0x5F and 0x56,0x57 , 0x58 with the correct value as per the legacy BIOS. (Will this impact??).
3. I have also include the dump of northbridge device, pls have a look.
 
----------------------
You were talking of Crystall Ball, can u tell me in details or any url to get this??
-----------------------
 
This is the new log after setting the required register.
-----------------------------------------------------------------------------------------------
Enabling vt82c686a_serial ...Enabling UART...Initializing Console ...
LinuxBIOS-2.0.0.SANJAY Mon Mar 26 03:18:17 IST 2007 starting...
Enabling Mainboard Devices ...Enabling smbus ...01 is the comm register
SMBus controller enabled
Enabling shadow ram...
Setting SDRAM Registervt8605 init starting
00000000 is the north
1106 0605
01d4 is the computed timing
Enabling SDRAMNOP
PRECHARGE
DUMMY READS
CBR
MRS
NORMAL
set ref. rate
enable multi-page open
Slot 00 is SDRAM 08000000 bytes x2
0100 is the chip size
000e is the MA type
vt8605 done
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000
00070000 00080000 00090000 000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000
00070000 00080000 00090000 000a0000
DRAM range verified.
Done.
Testing DRAM : 00100000-01000000
DRAM fill: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000
00170000 00180000 00190000 001a0000 001b0000 001c0000 001d0000
001e0000 001f0000 00200000 00210000 00220000 00230000 00240000
00250000 00260000 00270000 00280000 00290000 002a0000 002b0000
002c0000 002d0000 002e0000 002f0000 00300000 00310000 00320000
00330000 00340000 00350000 00360000 00370000 00380000 00390000
003a0000 003b0000 003c0000 003d0000 003e0000 003f0000 00400000
00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000
004f0000 00500000 00510000 00520000 00530000 00540000 00550000
00560000 00570000 00580000 00590000 005a0000 005b0000 005c0000
005d0000 005e0000 005f0000 00600000 00610000 00620000 00630000
00640000 00650000 00660000 00670000 00680000 00690000 006a0000
006b0000 006c0000 006d0000 006e0000 006f0000 00700000 00710000
00720000 00730000 00740000 00750000 00760000 00770000 00780000
00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000
00870000 00880000 00890000 008a0000 008b0000 008c0000 008d0000
008e0000 008f0000 00900000 00910000 00920000 00930000 00940000
00950000 00960000 00970000 00980000 00990000 009a0000 009b0000
009c0000 009d0000 009e0000 009f0000 00a00000 00a10000 00a20000
00a30000 00a40000 00a50000 00a60000 00a70000 00a80000 00a90000
00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000 00b00000
00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000
00bf0000 00c00000 00c10000 00c20000 00c30000 00c40000 00c50000
00c60000 00c70000 00c80000 00c90000 00ca0000 00cb0000 00cc0000
00cd0000 00ce0000 00cf0000 00d00000 00d10000 00d20000 00d30000
00d40000 00d50000 00d60000 00d70000 00d80000 00d90000 00da0000
00db0000 00dc0000 00dd0000 00de0000 00df0000 00e00000 00e10000
00e20000 00e30000 00e40000 00e50000 00e60000 00e70000 00e80000
00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000
00f70000 00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000
00fe0000 00ff0000 01000000
DRAM filled
DRAM verify: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000
00170000 00180000 00190000 001a0000 001b0000 001c0000 001d0000
001e0000 001f0000 00200000 00210000 00220000 00230000 00240000
00250000 00260000 00270000 00280000 00290000 002a0000 002b0000
002c0000 002d0000 002e0000 002f0000 00300000 00310000 00320000
00330000 00340000 00350000 00360000 00370000 00380000 00390000
003a0000 003b0000 003c0000 003d0000 003e0000 003f0000 00400000
00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000
004f0000 00500000 00510000 00520000 00530000 00540000 00550000
00560000 00570000 00580000 00590000 005a0000 005b0000 005c0000
005d0000 005e0000 005f0000 00600000 00610000 00620000 00630000
00640000 00650000 00660000 00670000 00680000 00690000 006a0000
006b0000 006c0000 006d0000 006e0000 006f0000 00700000 00710000
00720000 00730000 00740000 00750000 00760000 00770000 00780000
00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000
00870000 00880000 00890000 008a0000 008b0000 008c0000 008d0000
008e0000 008f0000 00900000 00910000 00920000 00930000 00940000
00950000 00960000 00970000 00980000 00990000 009a0000 009b0000
009c0000 009d0000 009e0000 009f0000 00a00000 00a10000 00a20000
00a30000 00a40000 00a50000 00a60000 00a70000 00a80000 00a90000
00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000 00b00000
00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000
00bf0000 00c00000 00c10000 00c20000 00c30000 00c40000 00c50000
00c60000 00c70000 00c80000 00c90000 00ca0000 00cb0000 00cc0000
00cd0000 00ce0000 00cf0000 00d00000 00d10000 00d20000 00d30000
00d40000 00d50000 00d60000 00d70000 00d80000 00d90000 00da0000
00db0000 00dc0000 00dd0000 00de0000 00df0000 00e00000 00e10000
00e20000 00e30000 00e40000 00e50000 00e60000 00e70000 00e80000
00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000
00f70000 00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000
00fe0000 00ff0000 01000000
DRAM range verified.
Done.
DUMP NORTH
00:06 11 05 06 06 00 10 22 00 00 00 06 00 00 00 00
10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:fd db c8 fe 02 00 20 20 e0 00 10 20 20 20 20 20
60:3f 2a 00 30 e6 00 00 00 41 7c 43 0f 08 21 00 00
70:00 00 00 00 00 00 00 00 01 f0 00 02 00 00 00 00
80:00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 01 02 00 1f 00 00 00 00 00 02 00 00
b0:80 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 04 00 32 42 00 00 00 00 00 00
*************End of AUTO.C************
Copying LinuxBIOS to RAM.
Jumping to LinuxBIOS.
 
 
 
 
sanjay tiwary <stiwary20 at yahoo.com> wrote:
Hi Stepen,
 
I would like to thank you for the movitation you given to me.
 
A. For the conveniance of clarity, i am again recapitulate the facts/figures about my board.
1. Northbridge: VT8605  almost similar to VT8601 or VT8603
2.Southbridge: VT 82C686 which has integrated super I/O controller
3. CPU: 300Mhz Celeron Processor
4. Memory: 512 MB SDRAM
---------------------------------------------------------
if any other info, pls let me know
 
B.
--------
    1. In this mail, i am sending you data as much as possible for you
         comments/suggestion   for improvment the porting process.
    2. Now i would like to ask couple of question. Since raminit does not complain any failure and ramcheck also passes ramtest.Next, code in crt0.S is able to copy the code from ROM to RAM. I am also able to read the code and print them in the serial output.So my question is, if i am able to read/write correct data to/from RAM, why is there doubt on incorrect DRAM initialisation?
If i am not able to jump to a designated place (0x4000) in RAM simply due incorrect DRAM initialisation, then what are those things which i am not taking care of during DRAM initialization? Can u pls hightlight those area in RAMINIT so that i can re-walk those area.
 3. if really, the DRAM initialization is correct, then what are the factors that may stop/misdirect the control to jump to a correct location in RAM.
I tried to print the contents from the RAM which is copied from the ROM to RAM in the start of crt0.S, they are byte by byte same as is for c_start.o
 
4. Are there any role of the register like AX,BX, CX and DX & other index register while control is try to jump at ram location. For reference, i am also printed the contents of the register before jumping i.e jmp *%edi
5. In my config, i have set DCAHE_RAM =0
 
6. i have compared the register dump for linuxbios and legacy bios.They are not exactly same. Should i try to cpmpare the entire dump or the register dump of device 00.0 only? 
 
 
 
B. I would also like to give you the register dump( for the Device 00.0) of legacy BIOS
     The ouput given below has been taken by lspci
     --------------------------------------------------------------------
00: 06 11 05 06 06 00 10 22 00 00 00 06 00 00 00 00
10: 08 00 00 ec 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: fd db c8 fe 02 00 20 20 e0 00 10 20 20 20 20 20
60: 3f 2a 00 a0 e6 00 00 00 41 7c 43 0f 08 21 00 00
70: c4 80 cc 0c 0e a1 d2 00 01 b4 09 00 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 01 02 00 1f 00 00 00 00 27 12 00 00
b0: c0 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 04 00 32 42 00 b0 00 00 00 00
 
 
 
C. linuxbios log
------------------------------------------------------------------------
LinuxBIOS-2.0.0.fallback Fri Mar 23 18:50:48 IST 2007 starting...
01 is the comm register
SMBus controller enabled
vt8605  init starting
00000000 is the north 1106 0605
0120NOP
PRECHARGE
DUMMY READS
CBR
MRS
NORMAL
set ref. rate
enable multi-page open
Register Dump (from LinuxBIOS) for Device 00.0
--------------------------------------------------
00:06 11 05 06 06 00 10 22 00 00 00 06 00 00 00 00
10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:ac 08 80 03 00 00 20 20 e0 00 20 20 20 20 20 20
60:3f 00 00 30 e6 00 00 00 41 7c 43 01 08 21 00 00
70:00 00 00 00 00 00 00 00 01 f0 00 02 00 00 00 00
80:00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 01 02 00 1f 00 00 00 00 00 02 00 00
b0:80 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00
 
---Register Dump End here--------------------------
---RAM CHECKING (from 0-640K & 1M-16M)-------------
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000  00040000 00050000
00060000 00070000 00080000 00090000  000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000  00040000 00050000
00060000 00070000 00080000 00090000  000a0000
DRAM range verified.
Done.
 
Testing DRAM : 00100000-01000000
DRAM fill: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000 00170000
00180000 00190000 001a0000 001b0000 001c0000 001d0000 001e0000 001f0000
00200000 00210000 00220000 00230000 00240000 00250000 00260000 00270000
00280000 00290000 002a0000 002b0000 002c0000 002d0000 002e0000 002f0000
00300000 00310000 00320000 00330000 00340000 00350000 00360000 00370000
00380000 00390000 003a0000 003b0000 003c0000 003d0000 003e0000 003f0000
00400000 00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000 004f0000
00500000 00510000 00520000 00530000 00540000 00550000 00560000 00570000
00580000 00590000 005a0000 005b0000 005c0000 005d0000 005e0000 005f0000
00600000 00610000 00620000 00630000 00640000 00650000 00660000 00670000
00680000 00690000 006a0000 006b0000 006c0000 006d0000 006e0000 006f0000
00700000 00710000 00720000 00730000 00740000 00750000 00760000 00770000
00780000 00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000 00870000
00880000 00890000 008a0000 008b0000 008c0000 008d0000 008e0000 008f0000
00900000 00910000 00920000 00930000 00940000 00950000 00960000 00970000
00980000 00990000 009a0000 009b0000 009c0000 009d0000 009e0000 009f0000
00a00000 00a10000 00a20000 00a30000 00a40000 00a50000 00a60000 00a70000
00a80000 00a90000 00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000
00b00000 00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000 00bf0000
00c00000 00c10000 00c20000 00c30000 00c40000 00c50000 00c60000 00c70000
00c80000 00c90000 00ca0000 00cb0000 00cc0000 00cd0000 00ce0000 00cf0000
00d00000 00d10000 00d20000 00d30000 00d40000 00d50000 00d60000 00d70000
00d80000 00d90000 00da0000 00db0000 00dc0000 00dd0000 00de0000 00df0000
00e00000 00e10000 00e20000 00e30000 00e40000 00e50000 00e60000 00e70000
00e80000 00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000 00f70000
00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000 00fe0000 00ff0000
01000000
DRAM filled
DRAM verify: 00100000-01000000
00100000 00110000 00120000 00130000 00140000 00150000 00160000 00170000
00180000 00190000 001a0000 001b0000 001c0000 001d0000 001e0000 001f0000
00200000 00210000 00220000 00230000 00240000 00250000 00260000 00270000
00280000 00290000 002a0000 002b0000 002c0000 002d0000 002e0000 002f0000
00300000 00310000 00320000 00330000 00340000 00350000 00360000 00370000
00380000 00390000 003a0000 003b0000 003c0000 003d0000 003e0000 003f0000
00400000 00410000 00420000 00430000 00440000 00450000 00460000 00470000
00480000 00490000 004a0000 004b0000 004c0000 004d0000 004e0000 004f0000
00500000 00510000 00520000 00530000 00540000 00550000 00560000 00570000
00580000 00590000 005a0000 005b0000 005c0000 005d0000 005e0000 005f0000
00600000 00610000 00620000 00630000 00640000 00650000 00660000 00670000
00680000 00690000 006a0000 006b0000 006c0000 006d0000 006e0000 006f0000
00700000 00710000 00720000 00730000 00740000 00750000 00760000 00770000
00780000 00790000 007a0000 007b0000 007c0000 007d0000 007e0000 007f0000
00800000 00810000 00820000 00830000 00840000 00850000 00860000 00870000
00880000 00890000 008a0000 008b0000 008c0000 008d0000 008e0000 008f0000
00900000 00910000 00920000 00930000 00940000 00950000 00960000 00970000
00980000 00990000 009a0000 009b0000 009c0000 009d0000 009e0000 009f0000
00a00000 00a10000 00a20000 00a30000 00a40000 00a50000 00a60000 00a70000
00a80000 00a90000 00aa0000 00ab0000 00ac0000 00ad0000 00ae0000 00af0000
00b00000 00b10000 00b20000 00b30000 00b40000 00b50000 00b60000 00b70000
00b80000 00b90000 00ba0000 00bb0000 00bc0000 00bd0000 00be0000 00bf0000
00c00000 00c10000 00c20000 00c30000 00c40000 00c50000 00c60000 00c70000
00c80000 00c90000 00ca0000 00cb0000 00cc0000 00cd0000 00ce0000 00cf0000
00d00000 00d10000 00d20000 00d30000 00d40000 00d50000 00d60000 00d70000
00d80000 00d90000 00da0000 00db0000 00dc0000 00dd0000 00de0000 00df0000
00e00000 00e10000 00e20000 00e30000 00e40000 00e50000 00e60000 00e70000
00e80000 00e90000 00ea0000 00eb0000 00ec0000 00ed0000 00ee0000 00ef0000
00f00000 00f10000 00f20000 00f30000 00f40000 00f50000 00f60000 00f70000
00f80000 00f90000 00fa0000 00fb0000 00fc0000 00fd0000 00fe0000 00ff0000
01000000
DRAM range verified.
Done.
-------------END OF AUTO.C----------------------------------
 
 
vt8605 done
 
-----WE are in crt0.S-------
Copying LinuxBIOS to RAM.
--regsister dump when copying is done-----
Printing eax=00003333
Printing ebx=ffffd14a     
Printing ecx=00000000
Printing edx=ffff03f8
Printing esi=ffff7094
Printing edi=00004000
Printing cs=00000008
Printing ds=00000010
End of Register dump
 
Memory dump (from RAM 0x4000 upto 7094byte)
[I have intentionaly put some ee at the start of c_start.s for conveniance of identification. I have also deleted some of the last byte for saving space]
-------------------------------------------
ee2e0f011538410000ea104000001000b8180000008ed88ec08ed08ee08ee8b013
e680fc8d3d00600100b90080010029f9c1e90231c0f3ab8d3d2c340100b9e85401
0029f97407c1e90231c0f3abbc008001006a006a005589e58d3d10dc00008d1da1
400000b8000010006689d889da66ba008e89470089570483c30683c70881ffb0dc
000075e30f011d08dc0000b0fee68089ece8a21e0000b0eee680f4ebf96a006a00
eb726a006a01eb6c6a006a02eb666a006a03eb606a006a04eb5a6a006a05eb546a
006a06eb4e6a006a07eb486a08eb4490906a006a09eb3c6a0aeb3890906a0beb32
90906a0ceb2c90906a0deb2690906a0eeb2090906a006a0feb186a006a10eb126a
11eb0e90906a006a12eb066a006a13eb005756558d6c2420555352515054e8b51e
00005858595a5b5d5d5e5f83c408cf2700e0db000090905589e56a036a0668f803
0000e8bf33000083c40cc9c35589e50fb645085068f8030000e838340000585ac9
c35589e568f8030000e8643400000fb6c0c9c35589e568f8030000e840340000c9
c39090905589e556538b750868d4c000006a07e8bc0700006a6c56e8b305000083
c8800fb6c0506a6c56e8330600006a7f6a4156e82906000083c4286a4056e88f05
00000fb6c0506a4056e8120600006a4256e87b05000083c8f00fb6c0506a4256e8
fb05000083c4286a4a56e86105000083c8080fb6c0506a4a56e8e10500006a4f56
e84a05000083c8080fb6c0506a4f56e8ca05000083c4286a036a5856e8bd050000
83c40c85f6741a6a5156e81f05000083c8180fb6c0506a5156e89f05000083c414
6a5056e80505000088c30fb6c05068e4c000006a07e8f406000081e3f700000053
6803c100006a07e8e106000083c420536a5056e8630500006a4c56e8cc04000088
c389d883e00f50681cc100006a07e8b906000081e3f000000083cb0483c42053683
6c100006a07e8a0060000536a4c56e8250500006a046a4656e81b05000083c4246a
036a4756e80e05000068980000006a6e56e8010500006a546a4056e8f704000083c
4246a00e8c24d00005668ecdc0000684fc100006a06e84d06000083c41485f6742a
Jumping to LinuxBIOS.
[After that, it simply hangs]
---------------------------------------------------------------------------
if any other info is required to get out this problem, pls let me know.
 
 
Regards,
Sanjay
Stefan Reinauer <stepan at coresystems.de> wrote:
* sanjay tiwary [070323 14:20]:
> Hi
>
> I am not able to go beyound "Jumping to LinuxBIOS".Initially i thought
> it is a DRAM problem. But ram test passes. I am also able to
> read/write from/to RAM.So i guess my jump is not working. But i am not
> able to find out.
> So, Can anybody see the register dump which is taken before the jmp
> *%edi.
>
> LinuxBIOS-"2.0.0"".fallback" "Fri Mar 23 18:28:27 IST 2007" starting...
> Copying LinuxBIOS to RAM.
> Printing eax=00003333
> Printing ebx=ffffd14a
> Printing ecx=00000000
> Printing edx=ffff03f8
> Printing esi=ffff7092
> Printing edi=00004000
> Printing cs=00000008
> Printing ds=00000010
> End of Register dump
> --------------------------------------------

Sorry, this log contains no information useful for debugging the
problem.

From the log it seems no memory init is done at all?

Is this still the vt8601 northbridge board?
what southbridge? In one of your previous mails you wrote 82C686,
in another one VT8231?

You don't post any code that would allow people to help you debug the
problem.

The memory test in auto.c is not qualifying. If that jmp does not work,
your memory does not work. It really is that simple. This can be
frustrating, don't despair.

Have you compared northbridge register dumps between linuxbios and the
legacy bios?


--
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/

--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios


It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.--
linuxbios mailing list
linuxbios at linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios


It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar. --0-1591968864-1174842609=:72724-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: The Via VT8235 in linuxbios has code to set up serial output. But the VT8235M datasheet, which is the part I have, doesn't mention anything about super io functions. And there's definately no other super io chip. I'm so lost right now... I've tried setting up the ite super io at 0x4e, and still no dice. Tomorrow I'm going to play with VGA roms, I think. Thanks, Corey From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: nVIDIA MCP55 southbridge. However, the Super I/O chip on the S2927 is a SMSC SCH5017 and not the Winbond W83627HF found on the S2912. The S2915 uses the nVIDIA NFP3600 + NPF3050 as the southbridge and the SMSC 5307 Super I/O controller. Would Yinghai's patch support either of these two boards? Thanks, Arvind From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Have you done any other config changes? Is it possible for you to send me (gzipped?) the version of videobios you used (I suspect, I missed something). BTW, do you have any card in the HTX slot installed? Alexei I. Adamovich From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: motherboard. Does it mean that every hope is lost, or would it be possible to use an external BIOS to do the development, or another simila solution ? Thanks, S=E9bastien. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Reworking TSOP chips without the right tools is no fun, but it can be done even with just a very warm soldering iron, and if the chip doesn't have to be re-used it's even easier. (Just cut off all the pins and then use any soldering iron and a soldering wick to clean up all the pins and the solder that held them to the mainboard.) There are TSOP sockets that could be installed where the chip used to be, but I haven't found them available in smaller quantities than what would cost a few $100. (Maybe segor.de have some though.) //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: h the RD1-PL is the version of the bios saviour that I need for this particular motherboard, however I am having a hard time find a place to buy this specific model. I was wondering if anyone knows where I can purchase this model or if there is another model that will work equally a= s well. Also, if anyone can recommend a place to buy PLCC chips or any other solutions I would greatly appreciate it. William From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 0 -- Resource Indicator -- RO. tied to 1 to indicate I/O space Should it be pmbase_value = pci_read_long(LPCBridge, 0x40) & 0xff80; ? Is shifting necessary, too (see attached file)? On my machine, output from my variant: Extracted address from PMBASE: 0x00000800 Offset to SMI_EN (PMBASE + 0x30): 0x00000830 Offset to SMI_STS (PMBASE + 0x34): 0x00000834 Value in SMI_EN: 0xffffffff Value in SMI_STS: 0xffffffff Output from Stefans variant: the same as from above Output from my variant with shift: Extracted address from PMBASE: 0x00000010 Offset to SMI_EN (PMBASE + 0x30): 0x00000040 Offset to SMI_STS (PMBASE + 0x34): 0x00000044 Value in SMI_EN: 0x00000801 Value in SMI_STS: 0x00000010 Output from Stefans variant with shift: the same as from above Which of these four variants is correct? Regards Andon --------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. --0-465367909-1179837539=:83441 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
>> Hello,
>> pmbase_value = pci_read_long(LPCBridge, 0x40);
>
>This neads to read
>
>pmbase_value = pci_read_long(LPCBridge, 0x40) & 0xfffffffe ;
>
>I have not checked the data sheets but I would bet the lowest bit is
>enable.

From datasheet ICH3M, according to PMBASE:
31:16 --  reserved
15:7   --  Base address
6:1     -- reserved
0        -- Resource Indicator -- RO. tied to 1 to indicate I/O space

Should it be
pmbase_value = pci_read_long(LPCBridge, 0x40) & 0xff80;
?

Is shifting necessary, too (see attached file)?

On my machine, output from my variant:
Extracted address from PMBASE: 0x00000800
Offset to SMI_EN  (PMBASE + 0x30): 0x00000830
Offset to SMI_STS (PMBASE + 0x34): 0x00000834
Value in SMI_EN:  0xffffffff
Value in SMI_STS: 0xffffffff

Output from Stefans variant:
the same as from above

Output from my variant with shift:
Extracted address from PMBASE: 0x00000010
Offset to SMI_EN  (PMBASE + 0x30): 0x00000040
Offset to SMI_STS (PMBASE + 0x34): 0x00000044
Value in SMI_EN:  0x00000801
Value in SMI_STS: 0x00000010

Output from Stefans variant with shift:
the same as from above

Which of these four variants is correct?

Regards

Andon


Building a website is a piece of cake.
Yahoo! Small Business gives you all the tools to get online. --0-465367909-1179837539=:83441-- --0-628321999-1179837539=:83441 Content-Type: text/x-csrc; name="get_content_of_pmbase_libpci.c" Content-Description: 2332724126-get_content_of_pmbase_libpci.c Content-Disposition: inline; filename="get_content_of_pmbase_libpci.c" #include #include int main(void) { struct pci_access *pacc; struct pci_dev *LPCBridge; u32 pmbase_value, smi_en_offset, smi_sts_offset, smi_en_value, smi_sts_value; pacc = pci_alloc(); pci_init(pacc); LPCBridge = pci_get_dev(pacc, 0, 0, 0x1f, 0); //pmbase_value = pci_read_long(LPCBridge, 0x40) & 0xff80; /* my variant */ //pmbase_value = pci_read_long(LPCBridge, 0x40) & 0xfffffffe; /* Stefans variant */ //pmbase_value = (pci_read_long(LPCBridge, 0x40) & 0xff80) >> 7; /* my variant with shift */ pmbase_value = (pci_read_long(LPCBridge, 0x40) & 0xfffffffe) >> 7; /* Stefans variant with shift */ printf("Extracted address from PMBASE: 0x%08x\n", pmbase_value); smi_en_offset = pmbase_value + 0x30; smi_sts_offset = pmbase_value + 0x34; printf("Offset to SMI_EN (PMBASE + 0x30): 0x%08x\n", smi_en_offset); printf("Offset to SMI_STS (PMBASE + 0x34): 0x%08x\n", smi_sts_offset); smi_en_value = pci_read_long(LPCBridge, smi_en_offset); smi_sts_value = pci_read_long(LPCBridge, smi_sts_offset); printf("Value in SMI_EN: 0x%08x\n", smi_en_value); printf("Value in SMI_STS: 0x%08x\n", smi_sts_value); return 0; } --0-628321999-1179837539=:83441-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: will always be 24 bytes, and the LinuxBIOS Table header will never be extended in the future (or is this just a bug that makes "lbtdump" unable to handle forward/backward compatability)? The file "src/include/boot/linuxbios_tables.h" defines 3 types of memory ranges: #define LB_MEM_RAM 1 /* Memory anyone can use */ #define LB_MEM_RESERVED 2 /* Don't use this memory region */ #define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */ The file "util/lbtdump/lbtdump.c" doesn't agree: switch(rec->map[i].type) { case 1: mem_type = "ram"; break; case 3: mem_type = "acpi"; break; case 4: mem_type = "nvs"; break; default: case 2: mem_type = "reserved"; break; } Can I assume that the defines in "linuxbios_tables.h" are out-of-date, and that the memory type field is the same as specified by version 2 of the ACPI specification (but perhaps not version 3, as that defines a new "5 = faulty RAM" type)? If "linuxbios_tables.h" is out-of-date, is "16 = RAM configuration tables are stored in" still possible on older versions of LinuxBIOS (and how would I detect which version of LinuxBIOS is present, considering there's no version number in the LinuxBIOS Table header)? What is the LB_TAG_HWRPB structure. Is it something to do with a "Hardware Restart Parameter Block", and what does it contain? For e.g. would a value of zero indicate that the computer was shutdown correctly before boot, and a non-zero value indicate that the computer crashed or had hardware problems? Would I also be correct to assume that a payload doesn't need to care about any of the "cmos_entries" and "cmos_enums", unless a BIOS setup/configuration utility is being built into the payload? Alternatively, could/would a payload search for strings to find CMOS values (e.g. search for the cmos_entry with the name string "power_on_after_fail" to see if additional hardware testing can be skipped, search for "baud_rate" to determine the serial port configuration, etc)? > It is of course not unique. It is the index of the vendor name within > the strings array of struct lb_mainboard. Since we're not trying to > close things down, we don't have to work with magic numbers. So nothing > needs to stay unique. Of course - it's similar to the way SMI/DMI does strings, yet are the strings themselves guaranteed to be unique, or is it possible for one manufacturer to use an identifying string in the future that another (possibly out of business) manufacturer had used in the past? Motherboard manufacturer identification is one of the things that (IMHO) should be unique. The motherboard part number string should also be unique for that manufacturer ID. Otherwise it'd be difficult for payloads/utilities/OSs to use these IDs to avoid any hardware problems in specific motherboards. > > > > I assume there may also be ACPI, MP specification, PIRQ routing and/or > > > > (possibly) SMI/DMI tables, and I'm guessing that (if present) these > > > > tables can be searched for using the same methods as described in > > > > their corresponding specifications. > > > > > > They're not used by payloads (except the Linux kernel) > > > > Surely LinuxBIOS isn't intended as a "Linux only" BIOS though.... > > Of course not. ACPI is not really useful for payloads though, unless the > payload wants to carry a full blown ACPI interpreter. Which rules out > basically anything but an OS. I can think of a variety of uses, ranging from utilities that do nothing more than display hardware information, to diagnostics, to benchmarking, to hyper-visors, to full OSs... > > > > - are AP CPUs started (or waiting for a SIPI sequence)? > > > > > > yes, hardware is completely up when linuxbios is done. > > > > I tried it on a dual CPU Bochs emulation (second CPU was left in "wait > > for SIPI" state) - I'm guessing I need to enable multi-CPU support > > via. some compile time option for the "emulation/qemu-i386" target? > > Yes, the emulation/qemu-i386 is per default not supporting SMP. I'm becoming skeptical here. I can't find anything in LinuxBIOS source code that starts AP CPUs, but in "src/arch/i386/smp/mpspec.c" I did find: /* If we assume a symmetric processor configuration we can * get all of the information we need to write the processor * entry from the bootstrap processor. * Plus I don't think linux really even cares. * Having the proper apicid's in the table so the non-bootstrap * processors can be woken up should be enough. */ It might be possible that no AP CPUs are ever started, and are instead left in a "wait for SIPI" default state, assumed to be identical to the BSP, and even assumed to be working (no BIST checks). AFAIK the normal approach is to send a broadcast INIT-SIPI sequence and wait to see which AP CPUs start (if any), and then either record details somewhere or have each AP CPU add itself to the MP specification and ACPI tables, then setup their MTTRs, thermal monitoring, HT links, SMBASE, etc before sending the APs back to the "wait for SIPI" state - i.e. in theory it should be mostly "configuration-less". In any case, I'm guessing I need to get LinuxBIOS to generate MP specification and ACPI tables to suit the number of CPUs being emulated by Bochs/Qemu. Is this as simple as adding something like "option CPUs = ?" to the "targets/emulation/qemu-i386/Config.lb" file? I'm guessing it's more involved than this, as I couldn't find an example in the "Config.lb" of other targets. > > Either: > > a) PCI buses and bridges aren't guaranteed to be enumerated, or > > b) PCI buses and bridges are guaranteed to be enumerated but PCI > > devices aren't guaranteed to be assigned resources, or > > c) PCI buses and bridges are guaranteed to be enumerated and PCI > > devices are guaranteed to have resources assigned (including ROMs) > > d) PCI buses and bridges are guaranteed to be enumerated and PCI > > devices are guaranteed to have resources assigned (except ROMs) > > > "They have their resources." would mean either c) or d), where each > > device may or may not be in a power saving state (if supported by the > > device), and may or may not be still configured to use MSI (if > > supported by the device).... > > yes, either c or d. You choose. You mean all LinuxBIOS developers are willing to make sure all PCI device ROMs either have physical addresses assigned or don't have physical addresses assigned based on my advice? Perhaps I've misunderstood... :-) > > > Not at the moment. But in General this is easy. If no VGA class PCI > > > device is there, the machine is 99.99% headless. > > > > And if a VGA class PCI device is present, you've got no idea if no > > monitor is attached... > > Obviously not. and if the device does not do EDD you have no reliable > way of finding out either. There's a simple and easy way to find out if a monitor is attached or not, and it doesn't involve messing about with EDD - simply give the end-user the option of setting (or not setting) a value in the CMOS. My (limited) reverse engineering has already shown that there's CMOS entries for a serial port (possibly intended for setting up a serial cable to communicate with a terminal emulator?). > > > > - can anything be assumed about AGP and the first video card (if the > > > > computer isn't headless)? > > > > > > What would you like to assume? > > > > Video card set to default "80 * 25" text mode accessible at 0xB8000; > > or some video mode set with display memory directly accessible at some > > physical address (where video mode details and physical address > > included in LinuxBIOS Table); or AGP aperture configured, AGP transfer > > speed set, MTRRs set to "write combining" and some video mode set with > > display memory directly accessible at some physical address; or > > anything else, as long as a payload writer knows how much or how > > little they can assume about it (and hopefully doesn't need to > > implement a wide range of video drivers just to do a "Hello World" > > that works on all video cards)... ;) > > Ok, the video hardware is in the state that the VGA Option ROM sets it > to. Since that is closed source, we can not guarantee anything, > obviously. A rule of thumb tells you that 80x25 at B8000 is a reasonable > assumption. The AGP setup is chipset specific, so it might vary from > chipset to chipset. Cool :-) Next question would be how to get that to work under Qemu and/or Bochs. I realise this may not be easy (I've had problems with Bochs before, as the VGA ROM seems to behave like an ISA card ROM and doesn't behave like a PCI card ROM - i.e. the ROM ignores settings in PCI configuration space)... Thanks, Brendan From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: used. For e.g. if my code knows it can't drop back to real mode and use legacy BIOS interrupts, then it can skip it or use an alternative (in this specific case, I only used legacy BIOS interrupts to allow the user to select and change the video mode). > > Consider the multi-boot specification. OS developers can write code > > that complies with the multi-boot specification without regard to any > > bootloader, and bootloader writers can write code with that complies > > with the multi-boot specification without caring about any OS. Despite > > this, all OSs and all boot loaders that comply with the multi-boot > > specification will work together without problems. The same applies to > > EFI and OpenFirmware. > > I think some of this is actually more in the domain of EFI and Open > Firmware than in LinuxBIOS, which is more a low level firmware. So we > should work on getting EFI / OFW easily usable as an interface for everyone > instead of defining a third interface. to the OS and user. Our interface > is to OFW / EFI though (plus other options of course) Put more generally, all interfaces between components developed by different parties should be adequately documented. This includes the interface between hardware and LinuxBIOS, the interface between LinuxBIOS and it's payloads, the interface/s between payloads and anything that use the payload/s, the interface between boot loaders and OSs, the interface between an OS and software designed for that OS, etc. BTW I'm more interested in "boot from ROM" systems, where the "OS" is stored in ROM, and doesn't require or rely on disk drives or networking (but may use disk drives and/or networking if present, after the system is running). GRUB, Openfirmware and EFI payloads would consume too much of the limited space in ROM. Cheers, Brendan From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: we even have the serial console. 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: to work. More below. USB and PS/2 are quite different code paths in the kernel, until one of them is working there is surely some generic problem, quite possibly in LB. > 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. Can you get more details from kudzu about why it fails? Perhaps by running it manually after the system has booted? Perhaps by looking in the syslog files? I don't know much about RedHat so I can't give much advice on kudzu. (On the other hand, kudzu itself is not very important, having the hardware work is important, and then kudzu will be happy too.) > The attached is a log, maybe you can help me find some clue. Thank > you. Great - see some comments below. > We just want to gain some BIOS experience, so the LinuxBIOS > version is very old. This can be both good and bad. If you started from a known working LB version then there's no big problem, but if a lot of changes and bugfixes have gone into LB since the version you are using, it could be worthwhile to try also a new version. Comments on the log: > PCI: pci_scan_bus for bus 00 > PCI: 00:01.0 [1166/0036] enabled HT1000 PCI/PCI-X bridge > PCI: 00:02.0 [1166/0205] enabled HT1000 Legacy South Bridge > PCI: 00:02.1 [1166/0214] enabled HT1000 Legacy IDE controller > PCI: 00:02.2 [1166/0234] enabled HT1000 LPC Bridge > PCI: 00:02.3 [1166/0238] enabled > PCI: 00:02.4 [1166/0235] enabled > PCI: 00:02.5 [1166/0235] enabled > PCI: 00:02.6 [1166/0235] enabled Not in my pci.ids. > PCI: 00:03.0 [1166/0223] enabled > PCI: 00:03.1 [1166/0223] enabled > PCI: 00:03.2 [1166/0223] enabled 3x HT1000 USB Controller > PCI: 00:04.0 [8086/1229] enabled 82557/8/9 [Ethernet Pro 100] [..] > Reading resources... [..] > PCI: 00:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 01 prefmem [..] > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:04.0 missing read_resources > PCI: 00:05.0 missing read_resources > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:01.1 missing read_resources > PCI: 00:01.2 missing read_resources > PCI: 00:01.3 missing read_resources > PCI: 00:01.4 missing read_resources > PCI: 00:01.5 missing read_resources > PCI: 00:01.6 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:02.1 missing read_resources > PCI: 00:02.2 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:04.0 missing read_resources > PCI: 00:05.0 missing read_resources > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:01.1 missing read_resources > PCI: 00:01.2 missing read_resources > PCI: 00:01.3 missing read_resources > PCI: 00:01.4 missing read_resources > PCI: 00:01.5 missing read_resources > PCI: 00:01.6 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:02.1 missing read_resources > PCI: 00:02.2 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:04.0 missing read_resources > PCI: 00:05.0 missing read_resources > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:01.1 missing read_resources > PCI: 00:01.2 missing read_resources > PCI: 00:01.3 missing read_resources > PCI: 00:01.4 missing read_resources > PCI: 00:01.5 missing read_resources > PCI: 00:01.6 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:02.1 missing read_resources > PCI: 00:02.2 missing read_resources > PCI: 00:03.0 missing read_resources > Done reading resources. [..] > Setting resources... [..] > PCI: 00:00.0 missing read_resources > PCI: 00:01.0 missing read_resources > PCI: 00:02.0 missing read_resources > PCI: 00:03.0 missing read_resources > PCI: 00:04.0 missing read_resources > PCI: 00:05.0 missing read_resources [..] Does this matter, anyone? If there's no read_resources() op (or even no dev->ops) there's no fallback to generic routines in the code - are the devices likely to work anyway? [..] > PCI: 00:02.0 90 <- [0x0000003040 - 0x000000304f] io > PCI: 00:02.1 10 <- [0x0000003060 - 0x0000003067] io > PCI: 00:02.1 14 <- [0x0000003080 - 0x0000003083] io > PCI: 00:02.1 18 <- [0x0000003070 - 0x0000003077] io > PCI: 00:02.1 1c <- [0x0000003090 - 0x0000003093] io > PCI: 00:02.1 20 <- [0x0000003050 - 0x000000305f] io > PCI: 00:02.1 64 <- [0x00000030a0 - 0x00000030a3] io > PCI: 00:02.3 10 <- [0x00fc250000 - 0x00fc250fff] mem > PCI: 00:02.4 10 <- [0x00fc251000 - 0x00fc251fff] mem > PCI: 00:02.5 10 <- [0x00fc252000 - 0x00fc252fff] mem > PCI: 00:02.6 10 <- [0x00fc253000 - 0x00fc253fff] mem Some resources are being assigned either way.. [..] > Done setting resources. > Done allocating resources. > Enabling resources... [..] > PCI: 00:01.0 bridge ctrl <- 0003 > PCI: 00:01.0 cmd <- 147 [..] > PCI: 00:02.0 cmd <- 147 > PCI: 00:02.1 cmd <- 141 > PCI: 00:02.2 cmd <- 144 > PCI: 00:02.3 cmd <- 146 > PCI: 00:02.4 cmd <- 146 > PCI: 00:02.5 cmd <- 146 > PCI: 00:02.6 cmd <- 146 > PCI: 00:03.0 cmd <- 143 > PCI: 00:03.1 cmd <- 143 > PCI: 00:03.2 cmd <- 143 > PCI: 00:04.0 cmd <- 143 [..] And some command seems to be sent, but.. > PCI: 00:00.0 missing enable_resources > PCI: 00:01.0 missing enable_resources > PCI: 00:02.0 missing enable_resources > PCI: 00:03.0 missing enable_resources > PCI: 00:04.0 missing enable_resources > PCI: 00:05.0 missing enable_resources > PCI: 00:00.0 missing enable_resources > PCI: 00:01.0 missing enable_resources > PCI: 00:01.1 missing enable_resources > PCI: 00:01.2 missing enable_resources > PCI: 00:01.3 missing enable_resources > PCI: 00:01.4 missing enable_resources > PCI: 00:01.5 missing enable_resources > PCI: 00:01.6 missing enable_resources > PCI: 00:02.0 missing enable_resources > PCI: 00:02.1 missing enable_resources > PCI: 00:02.2 missing enable_resources > PCI: 00:03.0 missing enable_resources Here we go again about missing *_resources op or even dev->ops. Is it just that none is needed for HT1000 or can this be the cause of the problems? > NB: Function 3 Misc Control.. done. > PCI: 00:02.0 init > PCI: 00:02.1 init > PCI: 00:02.2 init > RTC Init > Invalid CMOS LB checksum > PCI: 00:02.3 init > PCI: 00:02.4 init > PCI: 00:02.5 init > PCI: 00:02.6 init > PCI: 00:03.0 init > PCI: 00:03.1 init > PCI: 00:03.2 init > PCI: 00:04.0 init [..] > Devices initialized So most of the devices are initialized, but that may not mean much. > FILO version 0.5 (fengl at localhost.localdomain) Sat Jul 7 02:41:14 CST 2007 > menu: hda1:/grub/grub.conf What about FILO - have you tried using a PS/2 keyboard there? (Compile FILO with a timeout for the boot prompt.) Until that works, there is not much reason to boot Linux. (Quicker cycles) [..] > Linux version 2.6.9-22.ELsmp (bhcompile at crowe.devel.redhat.com) > (gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)) #1 SMP Mon Sep 19 > 18:00:54 EDT 2005 This kernel is almost two years old, you are ignoring the last 1/5 part of the lifetime of the Linux project. I would strongly suggest building a recent kernel.org version of Linux (2.6.21.6 or 2.6.22.1) without modules and making sure it is configured according to the hardware you're working with. If you want the list to review your configuration, please feel free to send the .config created by make menuconfig. (or make xconfig or make qconfig) [..] > usbcore: registered new driver hiddev > usbcore: registered new driver usbhid > drivers/usb/input/hid-core.c: v2.0:USB HID core driver > mice: PS/2 mouse device common for all mice No USB host controllers are found by Linux so it is impossible for a USB keyboard to work. The HID driver is loaded but it only depends on the USB core. Maybe the host controller drivers aren't enabled in this kernel, maybe the PCI devices don't respond properly (LB's fault) or maybe there are bugs in the HCI drivers. Too many unknowns. There are at least two interesting things you could try: 1. Investigate the {read,enable}_resources messages from LB for HT1000 and fix the problem if there is in fact a problem. Best case this makes everything work. A good first test is if a PS/2 keyboard works in FILO. 2. Upgrade to the latest kernel, correctly configured for the system, and see what works/does not work. Perhaps that can give clues about what is wrong in LB. (if there is something more than 1) (Could be useful to try 2 before 1 as well.) //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 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. //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: on which mainboard (and other hardware stats) Linux was installed. http://smolt.fedoraproject.org/stats -- With best regards! From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: contacts seem easier to solder, but I like the idea of having one factory bios stuffed away in a safe place, away from the mobo and that seems easier to achieve with a socket. :) /Rasmus From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Right now, you would probably get a MB with an SPI BIOS if you buy one, and those boards seem to be a bit of work in progress. You may want to try any of the boards listed on if you feel adventurous. /Rasmus From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: (publicly-available) laptop hardware. To quote Uwe Hermann: http://article.gmane.org/gmane.linux.bios/26520 "Correct. No laptop whatsoever (except for the OLPC) is supported by LinuxBIOS at the moment. We definately like to change that, but at the moment there's no support at all." Now before you consider purchasing an OLPC, please note that Uwe is referring to alpha/beta OLPC hardware; the final mass-produced model does not use LinuxBIOS, and the hardware has changed significantly enough that it would take quite a bit of effort to get it to support LinuxBIOS. Don't give up hope: a significant number of people (myself included) would very much like to have a laptop that supports LinuxBIOS. If you're interested in making this happen, you might consider staying on the mailing list and seeing what you can do to help LinuxBIOS in general. Cheers, -- R From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: PlayStation 3. It's based on the existing kboot project, plus the twin windowing system for the GUI." Maybe this is something we can list in the wiki as possible payload. Carl-Daniel From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: >> + >> + >> + // enable the internal I/O decode >> + enables = pci_read_config8(dev, 0x6C); >> + enables |= 0x80; >> + pci_write_config8(dev, 0x6C, enables); >> + >> + //FIXME Map 4MB of FLASH into the address space >> + pci_write_config8(dev, 0x41, 0x0); >> > > Should be the maximum possible, does that make sense? Or it could be > a config option. > I'll test this soon. Do as you wish with it, I can patch it up later if needed. >> + >> + // Set bit 6 of 0x40, because Award does it (IO recovery time) >> + // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI >> + // interrupts can be properly marked as level triggered. >> + enables = pci_read_config8(dev, 0x40); >> + enables |= 0x44; >> + pci_write_config8(dev, 0x40, enables); >> + >> + // Set 0x42 to 0xf8 to match Award bios >> > > Nah, please don't try to blindly match what other BIOSes do, only if > there's a good reason (functionality or performance). We want to > know exactly _why_ this is done (or not). > It's interrupt options, explaning would be a pain without just copy and pasting the datasheet. Perhaps a "refer to the datasheet" would be best. >> + enables = pci_read_config8(dev, 0x42); >> + enables |= 0xf8; >> + pci_write_config8(dev, 0x42, enables); >> + >> + >> + /* Delay Transaction Control */ >> + pci_write_config8(dev, 0x43, 0xb); >> + >> + /* IO Recovery time */ >> + pci_write_config8(dev, 0x4c, 0x44); >> + >> + /* ROM Memory Cycles Go To LPC */ >> + pci_write_config8(dev, 0x59, 0x80); >> + >> + /* bypass Bypass APIC De-Assert Message, INTE#, INTF#, INTG#, INTH# as PCI */ >> + pci_write_config8(dev, 0x5B, 0xb); >> + >> + /* set Read Pass Write Control Enable (force A2 from APIC FSB to low) */ >> + pci_write_config8(dev, 0x48, 0x8c); >> + >> + /* Set 0x58 to 0x43 APIC and RTC */ >> + pci_write_config8(dev, 0x58, 0x43); >> + >> + /* Set bit 3 of 0x4f to match award (use INIT# as cpu reset) */ >> + enables = pci_read_config8(dev, 0x4f); >> + enables |= 0x08; >> + pci_write_config8(dev, 0x4f, enables); >> + >> + /* enable serial irq */ >> + pci_write_config8(dev, 0x52, 0x9); >> + >> + >> + >> + /* dma */ >> + //pci_write_config8(dev, 0x53, 0x00); >> + >> + //enable HPET, ACPI has define to fixed addr >> +#define HPET_ADDR 0xfed00000ULL >> > > Put this at the top of the file or in the *.h file. Does it make sense > to make a config option out of it? > No config option, it's a fixed address. I'm writing this from the bottom up, so the lower posts explain a bit more. Should be at the top of the file though, or else hardcoded (or perhaps even defined in acpi files, since these seem to be generic values). It might already be defined in some acpi file. >> +void vt8237r_read_resources(device_t dev) >> +{ >> + struct resource *res; >> + >> + pci_dev_read_resources(dev); >> + >> + /* fixed APIC resource */ >> + res = new_resource(dev, 0x44); >> + res->base = 0xfec00000; >> > > Is this different from HPET_ADDR? Should it? > Yes, this is ioapic not hpet. >> + vt8237r_init(dev); >> + pci_routing_fixup(dev); >> + setup_ioapic(0xfec00000); >> > > Why hardcode this number here again? > This is a non-configurable address, messing around with it will bork things up. >> + if (resource) { >> + report_resource_stored(dev, resource, ""); >> + >> + /* Remember this resource has been stored */ >> + resource->flags |= IORESOURCE_STORED; >> + pci_write_config8(dev, 0x61, (resource->base >> 28)); >> + reg = pci_read_config8(dev, 0x60); >> + reg |= 0x3; >> + /* enable MMCONFIG decoding */ >> + pci_write_config8(dev, 0x60, reg); >> + } >> + >> + pci_dev_set_resources(dev); >> +} >> + >> + >> + >> +static void apic_mmconfig_read_resources(device_t dev) >> +{ >> + struct resource *res; >> + pci_dev_read_resources(dev); >> + >> + res = new_resource(dev, 0x40); >> + /* NB APIC fixed to this addr */ >> + res->base = 0xfecc0000; >> > > Hardcoded again. I think this should be a #define in *.h or even a > config option, rather than hardcoding it in all places. > Another fixed address, I think this one is LAPIC. Config options are not an option, these aren't configurable. >> + >> +## >> +## Build code to export an x86 MP table >> +## Useful for specifying IRQ routing values >> +## >> +default HAVE_MP_TABLE=1 >> + >> +## >> +## Build code to export a CMOS option table >> +## >> +##default HAVE_OPTION_TABLE=1 >> > > Either enable it, or drop cmos.layout below. > Huh? afaik it is enabled (with default USE_OPTION_TABLE != USE_FALLBACK_IMAGE below). >> Index: src/mainboard/asus/a8v/acpi_tables.c >> =================================================================== >> --- src/mainboard/asus/a8v/acpi_tables.c (revision 0) >> +++ src/mainboard/asus/a8v/acpi_tables.c (revision 0) >> @@ -0,0 +1,155 @@ >> +/* >> + * LinuxBIOS ACPI Table support >> + * written by Stefan Reinauer >> + * ACPI FADT, FACS, and DSDT table support added by >> + * Nick Barker , and those portions >> + * (C) Copyright 2004 Nick Barker >> + * (C) Copyright 2005 Stefan Reinauer >> + */ >> > > Missing license. Please check back with Stefan/Nick, but I guess it's > GPL (v2? v2-or-later?). > > How similar is this file to the original one? Does it make sense to > drop this file and make the original one a generic version which can be > used by multiple chipsets? > Nope, different boards have different tables. A uniprocessor board has fewer tables than a multiprocessor board, and different archs also have different/other tables. I think acpi is as generic as it's going to get. >> Index: src/mainboard/asus/a8v/fadt.c >> =================================================================== >> --- src/mainboard/asus/a8v/fadt.c (revision 0) >> +++ src/mainboard/asus/a8v/fadt.c (revision 0) >> @@ -0,0 +1,157 @@ >> +/* >> + * ACPI - create the Fixed ACPI Description Tables (FADT) >> + * (C) Copyright 2004 Nick Barker >> + * >> + * >> + * 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., 51 Franklin St, Fifth Floor, Boston, >> + * MA 02110-1301 USA >> + */ >> + >> + >> +#include >> +#include >> + >> +void acpi_create_fadt(acpi_fadt_t * fadt, acpi_facs_t * facs, void *dsdt) >> +{ >> > > Did you modify this file? How? Should probably be a common global file, > not copied in each target? The FADT is/should be mainboard-specific. So please don't try to generic-ize it. My fadt is somewhat different, FWIW. -Corey From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: similar. Could you write a few lines about it? Like a changelog message.. "fix" is not very informative. :\ (Yes, I could try to understand the code.) //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Does anybody have an idea what's missing/changed? Thanks, Andi From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: easy. Very small changes frequently require you to run make oldconfig so that you can handle all of the options that were not set, but now need to be set because you changed an option. Maybe there is a good way to do hierarchical make menuconfig, but then you get the problem that the sources haven't been downloaded yet when you are configuring buildrom. That said, I haven't used v3 yet. It seems like in the current state, the addition of new options (a new form of compression, for instance) in v3's config files might require patching all of the .config files in buildrom. That doesn't seem nice. I'm just hoping that when v3 supports the platforms I'm interested in it will be easy for buildrom to select which images to include and do some rudimentary calculations to see if they'll fit in the ROM. Thanks, Myles PS If I'm overlooking the obvious, easy ways to do things I'm all ears. It's easy to end up doing things the hard way if you don't know what the easy way is. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: contains hardware other then just normal things found on the average desktop. = There are controllers in use that are normally not documented for special = features for example. Take a look for example at the Linux kernel features for enabling the = GPIO found on the VAIO from Sony, since the firm probably was reluctant to release information on it, it was sorted out by reverse engineering. That's just one example. I would imagine that the others can bring up = more items to this discussion. -- Gregg C Levine hansolofalcon at worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi =A0=20 > -----Original Message----- > From: linuxbios-bounces+hansolofalcon=3Dworldnet.att.net at linuxbios.org [mailto:linuxbios- > bounces+hansolofalcon=3Dworldnet.att.net at linuxbios.org] On Behalf Of = Jun Koi > Sent: Tuesday, December 11, 2007 7:41 PM > To: Uwe Hermann > Cc: linuxbios at linuxbios.org > Subject: Re: [LinuxBIOS] Will linuxBIOS Work on My Machine? >=20 > On 12/10/07, Uwe Hermann wrote: > > On Wed, Dec 05, 2007 at 12:31:54PM -0800, Wakefield, John wrote: > > > I have an Acer 5102WLMi Notebook with Dual Core AMD TL50s, which = are 64 > > > > I'm afraid LinuxBIOS doesn't yet work on laptops, those are much = harder > > to support than "normal" PCs for various reasons. It's on our TODO = list to > > support laptops too sooner or later, but it's not a trivial task. > > >=20 > Uwe, could you elaborate a bit here? Why supporting laptops is > technically much harder than desktop?? >=20 > Many thanks, > Jun >=20 > -- > linuxbios mailing list > linuxbios at linuxbios.org > http://www.linuxbios.org/mailman/listinfo/linuxbios From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: that caused this problem. I saw you allocated 32MB for agp aperture memory in agp.c, so reserving 32MB works for you, and I changed this to 128MB for agp aperture memory so 128MB works for me. The problem is why this agp aperture memory is at physical memory range (tolm - agp_aperture_size to tolm) while we have set this agp aperture memory base at some very large address(e.g 0xe0000000). should this memory range be assigned a mtrr? The changes I made to your code are : 1) some registers in host bus, as their values are different from the factory BIOS ones; 2) dram size releated registers 3) dram timing is ok. and I found couldn't change dram operating frequency ;-( ------=_Part_255_23671061.1198250742389 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 21, 2007 1:40 PM, Corey Osgood <corey.osgood at gmail.com> wrote:
aaron lwe wrote:
> Dear All,
>
> I'm terribly sorry that I just found I've mistakenly configured the
> dram MA Map Type, and now memtest
> showed no errors. But I still have to reduce the mem size when
> reporting to system through ram_resource
> or filo couldn't be started.  I have disabled the integrated graphics
> card and the agp, so I don't think the top
> memory should be reserved for frame buffer.

And now you're where I am. For some reason there's a reserved memory
range _somewhere_ at the tolm, of some unknown size. I've found that
reserving an extra 1MB doesn't work, but 32MB does. I've found nothing
in the documentation I have to explain this. BTW, have you had to make
any code changes other than the MA Map, and board-specific fixes? I'm
wondering how generic that code really is.

-Corey


From what you have said, I guess it might be AGP aperture memory
that caused this problem. I saw you allocated 32MB for agp
aperture memory in agp.c, so reserving 32MB works for you, and I
changed this to 128MB for agp aperture memory so 128MB works for me.
The problem is why this agp aperture memory is at physical memory range
(tolm - agp_aperture_size to tolm) while we have set this agp aperture memory
base at some very large address(e.g 0xe0000000). should this memory range
be assigned a mtrr?
 
The changes I made to your code are :
1) some registers in host bus, as their values are different from the factory BIOS ones;
2) dram size releated registers
3) dram timing is ok. and I found couldn't change dram operating frequency ;-(
 
------=_Part_255_23671061.1198250742389-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: that caused this problem. I saw you allocated 32MB for agp aperture memory in agp.c, so reserving 32MB works for you, and I changed this to 128MB for agp aperture memory so 128MB works for me. The problem is why this agp aperture memory is at physical memory range (tolm - agp_aperture_size to tolm) while we have set this agp aperture memory base at some very large address(e.g 0xe0000000). should this memory range be assigned a mtrr? The changes I made to your code are : 1) some registers in host bus, as their values are different from the factory BIOS ones; 2) dram size releated registers 3) dram timing is ok. and I found couldn't change dram operating frequency ;-( ------=_Part_279_2122024.1198252516299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Dec 21, 2007 1:40 PM, Corey Osgood <corey.osgood at gmail.com> wrote:
aaron lwe wrote:
> Dear All,
>
> I'm terribly sorry that I just found I've mistakenly configured the
> dram MA Map Type, and now memtest
> showed no errors. But I still have to reduce the mem size when
> reporting to system through ram_resource
> or filo couldn't be started.  I have disabled the integrated graphics
> card and the agp, so I don't think the top
> memory should be reserved for frame buffer.

And now you're where I am. For some reason there's a reserved memory
range _somewhere_ at the tolm, of some unknown size. I've found that
reserving an extra 1MB doesn't work, but 32MB does. I've found nothing
in the documentation I have to explain this. BTW, have you had to make
any code changes other than the MA Map, and board-specific fixes? I'm
wondering how generic that code really is.

-Corey

 
It seems that the last message I sent is wrong...

From what you have said, I guess it might be AGP aperture memory
that caused this problem. I saw you allocated 32MB for agp
aperture memory in agp.c, so reserving 32MB works for you, and I
changed this to 128MB for agp aperture memory so 128MB works for me.
The problem is why this agp aperture memory is at physical memory range
(tolm - agp_aperture_size to tolm) while we have set this agp aperture memory
base at some very large address(e.g 0xe0000000). should this memory range
be assigned a mtrr?
 
The changes I made to your code are :
1) some registers in host bus, as their values are different from the factory BIOS ones;
2) dram size releated registers
3) dram timing is ok. and I found couldn't change dram operating frequency ;-(
------=_Part_279_2122024.1198252516299-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: around 7 seconds. I've got access to device programmers and 2m repair stuff, so flashing isn't a huge issue. Would this be a good board for a proof of concept, or should I look at something else. The board is a Kino LX800, AMD GEODE 500mhz, sata/pata, onboard amd video, onboard realtek 8139 ethernet. I'd like to to LB and kernel in flash, but if the hardware won't suppor a 16mbit flash, then I'll do lb/filo and boot from CF over the standard ide channel. The board currently has a 49fl004 socketed flash. Plan on using a stripped down debian install, since that's the only one I can reliably shrink. Thanks, Mark Here's all the specs: http://tinyurl.com/3ajv9l Here's the output of lspci. 00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 2080 (rev 31) 00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block 00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03) 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) 00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01) 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02) 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02) 00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:11.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) 00:11.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) 00:12.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Here's the more verbose lspci output recommend by the guys on irc. 00:01.0 0600: 1022:2080 (rev 31) Subsystem: 1022:2080 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- biosint: INT# 0x18 biosint: eax 0x84e53 ebx 0x38 ecx 0xff0 edx 0x87ed8 biosint: ebp 0x60000000 esp 0x87f60 edi 0x15 esi 0x0 biosint: ip 0x28 cs 0x1000 flags 0x26 That's just bogus as far as I can tell. Note that edi is 15, kind of looks like the interrupt. ebp is 60000000, kind of looks like cs and something else. And so on. It's like we got someone else's stack frame. ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: "In the LAN controller the D0 state is partitioned into two substates, D0 Uninitialized (D0u) and D0 Active (D0a). [...] Initialization of the CSR, Memory, or I/O Base Registers in the PCI Configuration space switches the LAN controller D0u state to the D0a state." and "The integrated LAN controller will be disabled if no Platform LAN Connect component is detected (See Section 5.2.1.3)." Any help? -Corey On Feb 5, 2008 11:44 AM, Peter Stuge wrote: > On Tue, Feb 05, 2008 at 10:51:39AM -0500, joe at smittys.pointclark.netwrote: > > So I found this in the ICH4 datasheet: > > > > The LAN controller enters Wake on LAN mode after reset if the Wake > > on LAN bit in the EEPROM is set *(which it is)*. > > You could try changing this bit in the EEPROM before running > coreboot and see if you get different results from the PCI scan. > > > > When the LAN controller is in Wake on LAN mode: > > ? The LAN controller scans incoming packets for a Magic Packet and > > asserts the PME# signal for 52 ms when a one is detected in Wake on > > LAN mode. > > .. > > ? The PCI Configuration registers are accessible to the host *(this > > is what I'm looking for!!)*. > > Right, and this says that they are accessible even when the NIC is in > WoL mode. > > > > So, if this is correct I think I was right in saying the nic seemed > > like it was powered off?? At this point I need to figure out how to > > assert a PME# signal to wake up the nic. Maybe from the Power > > Managment Control register?? > > Note that PME# is asserted by the NIC. Ie. PME# is considered an > output from the NIC. Remember that Wake on LAN means that the NIC > wakes up the computer if a special packet is received. > > I'm afraid I don't think this is causing the problem you're seeing. > :\ > > > //Peter > > -- > coreboot mailing list > coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > ------=_Part_742_15635457.1202240992449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID:
and

"The integrated LAN controller will be disabled if no Platform LAN Connect component is detected (See Section 5.2.1.3)."


Any help?

-Corey

On Feb 5, 2008 11:44 AM, Peter Stuge <peter at stuge.se> wrote:
On Tue, Feb 05, 2008 at 10:51:39AM -0500, joe at smittys.pointclark.net wrote:
> So I found this in the ICH4 datasheet:
>
> The LAN controller enters Wake on LAN mode after reset if the Wake
> on LAN bit in the EEPROM is set *(which it is)*.

You could try changing this bit in the EEPROM before running
coreboot and see if you get different results from the PCI scan.


> When the LAN controller is in Wake on LAN mode:
> ? The LAN controller scans incoming packets for a Magic Packet and
> asserts the PME# signal for 52 ms when a one is detected in Wake on
> LAN mode.

..
> ? The PCI Configuration registers are accessible to the host *(this
> is what I'm looking for!!)*.

Right, and this says that they are accessible even when the NIC is in
WoL mode.


> So, if this is correct I think I was right in saying the nic seemed
> like it was powered off?? At this point I need to figure out how to
> assert a PME# signal to wake up the nic. Maybe from the Power
> Managment Control register??

Note that PME# is asserted by the NIC. Ie. PME# is considered an
output from the NIC. Remember that Wake on LAN means that the NIC
wakes up the computer if a special packet is received.

I'm afraid I don't think this is causing the problem you're seeing.
:\


//Peter

------=_Part_742_15635457.1202240992449-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: want to read some partition information from, I would guess, the MBR -- and there is no MBR from the process we used to generate the disk image file. I think that is the problem. I don't know much about qemu-img options that may get around this or if some FILO options do this. I would guess that that would be where to try and find a way out of this. I'm told, near the beginning, one can run fdisk on the image file, to create an MBR, but then adding the OS files becomes a problem because you must copy them to some offset in the disk image file. IS the problem that an MBR is needed and that it should have been created or is there something else to do, to make it boot without an MBR? > -----Original Message----- > From: ron minnich [mailto:rminnich at gmail.com] > Sent: Thursday, March 06, 2008 4:01 PM > To: David Edrich > Cc: Myles Watson; Coreboot > Subject: Re: [coreboot] qemu error message: "Unrecognized partitioning scheme" > > david, can you just send me your disk image file? > > ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: S-records which contain both address and data. Because x86 always starts at top of 4GB there is no need for address information. The flash chip must always be at the top of 4GB. The binary flash file is always written to the top of the flash. > (or) how can I locate the code inside the coreboot.rom,if it is > there inside the rom file. The dd and objdump trick I show above will work but is very clumsy and does not scale well. I recommend the DOS utility HIEW (Hackers View) if you're going to be taking apart binary files. It has some useful disassembly options. The thing with dd and objdump is that because there are bytes in the coreboot.rom stream that are not instructions but instead data, it is not neccessarily possible to disassemble the entire coreboot.rom file in one go and then take it apart. When data at one byte position is parsed as an instruction it may parse the following byte as part of the same instruction which causes an error in alignment in the disassembler because the data byte in the first position was actually the last data byte and the following byte was the first byte of an instruction. This is why you usually have to explicitly chop up the binary file at whatever boundary you are interested in. But why are you doing this anyway? Wouldn't it be easier to just look at the source code? //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: $ telnet smittys.pointclark.net 25 Trying 65.175.181.44... Connected to smittys.pointclark.net. Escape character is '^]'. 220 smittys.pointclark.net ESMTP Postfix quit 221 Bye Connection closed by foreign host. Traceroute looks normal: khepri:/var/log/exim $ traceroute smittys.pointclark.net traceroute to smittys.pointclark.net (65.175.181.44), 30 hops max, 40 byte packets 1 gw.rtr1.colo1.NBG1.ip-exchange.de (212.123.124.185) 0.317 ms 0.490 ms 0.501 ms 2 ge3-5.cr2.NBG1.content-core.net (212.123.127.65) 0.224 ms 0.227 ms 0.217 ms 3 Tenge2-4-57.cr3.FRA3.content-core.net (212.123.123.203) 3.525 ms 3.471 ms 3.484 ms 4 4G-p2.cr1.FRA3.content-core.net (212.123.123.42) 3.503 ms 3.458 ms 3.402 ms 5 193.159.224.21 (193.159.224.21) 3.707 ms 3.700 ms 3.509 ms 6 f-ea5.F.DE.net.DTAG.DE (62.154.16.161) 3.741 ms 3.753 ms 3.759 ms 7 te-4-4.car2.Frankfurt1.Level3.net (4.68.110.253) 4.089 ms 4.119 ms 4.101 ms 8 ae-32-54.ebr2.Frankfurt1.Level3.net (4.68.118.126) 6.728 ms 16.346 ms 13.799 ms 9 ae-1-100.ebr1.Frankfurt1.Level3.net (4.69.132.125) 13.597 ms 6.701 ms 6.489 ms 10 ae-2.ebr2.Paris1.Level3.net (4.69.132.141) 13.381 ms 26.367 ms 25.514 ms 11 ae-44.ebr2.Washington1.Level3.net (4.69.137.62) 100.867 ms ae-41.ebr2.Washington1.Level3.net (4.69.137.50) 97.342 ms ae-42.ebr2.Washington1.Level3.net (4.69.137.54) 97.593 ms 12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 107.265 ms ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 97.440 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 101.640 ms 13 ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 97.547 ms ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 103.698 ms * 14 ae-4-4.car1.Cleveland1.Level3.net (4.69.132.193) 101.302 ms 102.199 ms 102.147 ms 15 ae-11-11.car2.Cleveland1.Level3.net (4.69.132.198) 102.603 ms 101.464 ms 101.079 ms 16 ROADRUNNER.car2.Cleveland1.Level3.net (4.78.59.46) 122.099 ms 122.230 ms 121.963 ms 17 gig15-0-0.ptldmeptl-rtr02.nyroc.rr.com (24.24.7.150) 134.609 ms 135.359 ms 134.807 ms 18 rrcs-24-39-3-2.nys.biz.rr.com (24.39.3.2) 134.779 ms 136.254 ms 135.865 ms 19 * * * ... And from here in Boston: $ traceroute smittys.pointclark.net traceroute to smittys.pointclark.net (65.175.181.44), 30 hops max, 40 byte packets ... 3 vl200.aggr1.sbo.ma.rcn.net (209.6.160.100) 16.420 ms 16.833 ms 17.103 ms 4 ge3-4.border1.sbo.ma.rcn.net (207.172.19.85) 46.691 ms 47.108 ms 47.312 ms 5 gigabitethernet6-24.car2.bos1.Level3.net (63.211.176.17) 17.384 ms 20.025 ms 20.415 ms 6 ae-5-5.ebr1.NewYork1.Level3.net (4.69.132.250) 28.679 ms 27.749 ms 25.022 ms 7 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 28.837 ms ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) 31.413 ms ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 22.518 ms 8 ae-74-74.ebr4.NewYork1.Level3.net (4.69.134.117) 25.795 ms ae-83-83.ebr3.NewYork1.Level3.net (4.69.134.105) 21.125 ms ae-93-93.ebr3.NewYork1.Level3.net (4.69.134.109) 19.931 ms 9 ae-3.ebr3.Washington1.Level3.net (4.69.132.89) 26.395 ms ae-3.ebr4.Washington1.Level3.net (4.69.132.93) 26.157 ms ae-3.ebr3.Washington1.Level3.net (4.69.132.89) 27.952 ms 10 ae-74-74.csw2.Washington1.Level3.net (4.69.134.182) 27.395 ms ae-83-83.csw3.Washington1.Level3.net (4.69.134.170) 35.010 ms ae-94-94.csw4.Washington1.Level3.net (4.69.134.190) 33.347 ms 11 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 26.157 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 26.932 ms ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 26.572 ms 12 ae-4-4.car1.Cleveland1.Level3.net (4.69.132.193) 32.026 ms 32.630 ms 32.396 ms 13 ae-11-11.car2.Cleveland1.Level3.net (4.69.132.198) 32.929 ms 33.136 ms 35.418 ms 14 ROADRUNNER.car2.Cleveland1.Level3.net (4.78.59.46) 34.417 ms 34.816 ms 35.012 ms 15 gig15-0-0.ptldmeptl-rtr02.nyroc.rr.com (24.24.7.150) 42.779 ms 42.381 ms 46.577 ms 16 rrcs-24-39-3-2.nys.biz.rr.com (24.39.3.2) 49.243 ms 48.864 ms 48.490 ms 17 rrcs-24-39-50-36.nys.biz.rr.com (24.39.50.36) 51.890 ms 48.315 ms 51.254 ms 18 * * * 19 * * * 20 * * * 21 * * * ... So, "the internet is broken". Routing problem somewhere between Germany and the US? Or... you're not doing fancy antispam based on RBLs or something are you, that would just drop incoming tcp connections from 'suspicious' IPs? If you hop on IRC, we can discuss further there. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: "The OS driver initiates an ownership request by setting the OS Owned semaphore to a one. The OS waits for the BIOS Owned bit to go to a zero before attempting to use the EHCI controller. The time that OS must wait for BIOS to respond to the request for ownership is beyond the scope of this specification." "If the BIOS has set SMI on OS Ownership Change in the USBLEGCTLSTS register to a one, it receives an SMI when the OS Driver sets the OS Owned semaphore to a one. BIOS observes that OS has changed the value of the OS Owned bit..." What happens if the BIOS doesn't relinquish control of the EHCI? Does hardware somehow prevent the OS from accessing the USB controller? What happens if the OS tries to use the USB controller without using these semaphores at all? It seems to me that the OS can at least cause a Denial-of-Service by sending commands to the USB controller, but I suspect it can also eavesdrop on keyboard events. Can anybody confirm or deny this attack? If this is outside the scope of coreboot, I'm sorry for bothering the list. Thank you for your time, -Jon From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: I can confirm that PS/2 still does not work. Unfortunately I do not have a USB keyboard anymore; once I tested it did not work, too. Is this a A8N-E topic only? All other mainboards with that superio are without such a problem? The A8N-E boots with coreboot-v2 and I could reach a console over the serial port from a second computer. Is anyone investigating this behaviour? Unfortunately I do not have C programming skills yet. I promise to learn, but I assume to do research-programming a mainboard is just a much higher level. So thanks for all the good work until now and any answers to my topic! -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: tyan s2892 tyan s2895 sun ultra40 Since you've already tested an s2892, I'd be happy to supply a patch and you can ack it? Same for s2895 - you have that hardware right? Anyone got a sun ultra40 with sata problems to test this patch on? Myles - have you ever run bonnie++ on your s2892 or s2895? Or noticed poor sata performance? I'd really like to solve that multi-mode problem... Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior System Administrator From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: your ethernet is using only one. For the USB to work, you probably need all three of INTA, INTB, and INTC working. properly. For ethernet, you only need the one hooked to the ethernet's INTA to work. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: likely more flexible. -Kevin From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Space that gets eaten 0___________________20___________________40____________________________________80 enter handle_17: a=00000178 b=00000008 c=00000040 d=000a0000 si=00005017 di=00000000 ds=00001a49 es=00000040 ip=00003dd6 cs=00001000 f=00000206 r=00000c48 enter handle_17: a=00000200 b=00000008 c=00000040 d=000a0000 si=00005017 di=00000000 ds=00001a49 es=00000040 ip=0000a2fc cs=00001000 f=00000206 r=00000c3e enter handle_11: a=00000000 b=00000007 c=00000040 d=000a0000 si=00001338 di=00000000 ds=00001a49 es=00005030 ip=0000412e cs=00001000 f=00000202 r=00000d06 KBD: int09h_handler(): unknown scancode read: 0x00000061! DSsDSsDSsDSsfail_with_code floppy_13XX: a=00001505 b=00000001 c=0000000d d=000a5000 si=00005017 di=00000000 ds=00001a49 es=00005040 ip=000055be cs=00001000 f=00000212 r=00000c02 Returning 00000001 Space that gets eaten 0___________________20___________________40____________________________________80 From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Space that gets eaten 0___________________20___________________40_________enter handle_11: a=00000000 b=0000000c c=00000040 d=00040000 si=00001338 di=00000000 ds=00001a49 es=00000040 ip=0000412e cs=00001000 f=00000246 r=00000d06 sendmouse: keyboard input buffer full Thanks, Myles From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: general, debugging OS boot of a full installation is usually much easier than trying to debug the installation process of an OS. There are less obstacles to booting an already-installed image, and there are much more tools available for debugging the aleady-installed OS. Once you get that working, you can go back to debugging the CD. It would be interesting to see if your platform has the same sort of success that Kevin got on the epia. Maybe your different graphics controller will work even better. From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: it has limited size) in the boot block. That avoids any and all requirements to keep code in RAM, thereby taking away the problem of code relocation. > In the case of the SMM handler, this would also confine us, because the > actual SMI# handling code (written in C) would not be shared between > CPUs but has to be duplicated for every CPU core. However, my current > approach only keeps a very small amount of code per CPU, that is just > enough to enter gcc compiled functions and return from them, cleanly. > AFAIK factory BIOS SMM handlers have the ability to lock down the memory segment they are using, protecting them from accidental or deliberate tampering by the OS (which could lead to interesting security issues). Can we do that even if the handler is "somewhere" in RAM? > One of the questions in my mind is: where should we put the coreboot > image, if we want to keep it around? > > A little excerpt from coreboot v2: > > I know the problem of where to put coreboot has been thought about > before, elfboot() relocates coreboot to another place when loading an > ELF binary that demands the space where coreboot lives: > * coreboot tries to load a segment and finds out, that it is in the way. > * coreboot copies itself to a new position > * coreboot jumps into the assembler handler in jmp_to_elf_entry at the > new position > * coreboot tries to start the ELF binary. > * If it fails, it overwrites the loaded ELF binary by copying itself > back and jumping to the original position. > > This is quite an interesting concept, but it also makes clear that the > ram portion of coreboot itself ("stage2") can not be relocated freely in > memory. Yet. > Please see my other mail in this thread about possible problems with a relocatable stage2. Besides that, we'd need a way in v3 to tag a LAR member as PIC (sort of done for the special case of XIP in initram) and new code to figure out a good load address during run time. > Since we know how big our RAM is when we copy coreboot to RAM, I suggest > that we copy coreboot to the end of memory and run it from there. It is > a pretty good assumption that no payload will require that space. During > memory map creation, we just reserve 256k at the upper end, and we're good. > Hm... I assume end of memory is "end of memory below 4G". If we want to avoid conflicts with mapped memory areas of extension cards, stage2 code has to be loaded twice: Once before setting up extension cards (load stage2 to above 1M or other failsafe location) and after setting up extension cards (load stage2 to end of memory below 4G and below extension card space). That's not exactly the nicest code flow I can think of. Regards, Carl-Daniel -- http://www.hailfinger.org/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: > + if (memcmp(cmos_entry->name, name, len)) .. > +#define CB_TAG_OPTION 0x00c9 > +#define CMOS_MAX_NAME_LENGTH 32 > +struct cb_cmos_entries { > + u32 tag; > + u32 size; > + u32 bit; > + u32 length; > + u32 config; > + u32 config_id; > + u8 name[CMOS_MAX_NAME_LENGTH]; > +}; memcmp() expects char * What should change? I'm thinking memcmp() and friends. Later revisions breaks more stuff. :\ //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: CPU core glued to an Intel 3100 northbridge/southbridge/SuperIO, with a slightly fancier DDR2 memory controller. Thus my patches augment the existing Intel 3100 code in coreboot. The code was written using information in the datasheet available on the Intel web site, and has been tested on an EP80579 Development Board (codename "Truxton"), booting a Linux 2.6.25.1 kernel payload. --Ed From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Use dev_path() to have nice debug output patch is run-time tested Trivial, thus: Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Modified: trunk/coreboot-v2/src/devices/pci_device.c =================================================================== --- trunk/coreboot-v2/src/devices/pci_device.c 2008-09-10 20:40:46 UTC (rev 3571) +++ trunk/coreboot-v2/src/devices/pci_device.c 2008-09-11 06:52:22 UTC (rev 3572) @@ -923,7 +923,7 @@ if ( (id == 0xffffffff) || (id == 0x00000000) || (id == 0x0000ffff) || (id == 0xffff0000)) { - printk_spew("PCI: devfn 0x%x, bad id 0x%x\n", devfn, id); + printk_spew("%s, bad id 0x%x\n", dev_path(&dummy), id); return NULL; } dev = alloc_dev(bus, &dummy.path); From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Use dev_path() to have nice debug output patch is run-time tested Trivial, thus: Signed-off-by: Stefan Reinauer Acked-by: Stefan Reinauer Build Log: Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3572&device=j7f24&vendor=jetway Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3572&device=epia-cn&vendor=via If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: SIO and the HW monitoring chip. I'll doublecheck for other devices (and serial config ROMs) in the evening, but I don't have much hope. >> Excerpt from lspci -vvnnxx I've got lying around: > > Would be nice to see the full output. Here you go. Note that the VGA and ethernet are PCI cards, not onboard. Kind regards, Tim. 00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: agpgart-intel Kernel modules: intel-agp 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 40 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 0c aa 00 ff 00 00 00 09 03 10 11 01 00 00 00 00 60: 00 08 10 18 28 28 28 28 00 2f 00 f0 03 ca 00 00 70: 20 1f 0a 78 54 02 03 01 27 ff 10 38 00 00 00 00 80: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 98 88 00 00 04 61 00 00 00 05 00 00 00 00 00 00 a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 b0: 80 20 00 00 30 00 00 00 00 00 4d 13 20 10 00 00 c0: 00 00 00 00 00 00 00 00 18 0c 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00 f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00 00:01.0 PCI bridge [0604]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge [8086:7191] (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- Reset- FastB2B+ PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Kernel modules: shpchp 00: 86 80 91 71 07 01 20 02 03 00 04 06 00 40 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 40 d0 d0 a0 22 20: 00 e4 f0 e5 00 e6 f0 e7 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel modules: nvidiafb 00: de 10 28 00 07 00 b0 02 15 00 00 03 00 40 00 00 10: 00 00 00 e4 08 00 00 e6 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 00 40 30: 00 00 00 e5 60 00 00 00 00 00 00 00 0b 01 05 01 40: 43 10 00 40 02 00 20 00 07 00 00 1f 00 00 00 00 50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00 60: 01 44 01 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: onto LPC in steps of 64k, meaning that you will be able to use as large a flash chip as you can find. I suggest trying to find one of two SST flash chips; SST49LF016C-33-4C-NHE or SST49LF160C-33-4C-NHE (66 instead of 33 is fine, but N in NHE means PLCC so is important) If I remember correctly, one is LPC only and the other is combined FWH/LPC, but I would like someone else to confirm this. The data sheets on these two parts are unfortunately not at all helpful. These parts are both 16Mbit = 2Mbyte so you'll have some room for using a Linux kernel as payload. //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: the v3 printk at the moment because I've not reviewed r921 yet. Oh, and please be aware that any multicore/multiprocessor machine in v3 is completely BROKEN right now and has been that way for months. (Yes, I have a fix in the queue. Remind me in a few days.) Regards, Carl-Daniel -- http://www.hailfinger.org/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: we'll need 'superiotool -dV' output, 'getpir' output (a file called irq_table.c), 'mptable' output, maybe others Done! See attachments. 2008/10/12 razor1394 > Hello > > I'm really interested in putting Coreboot on my firmware chip but I'm not > entirely sure it will work. My motherboard is on the desktop candidates list > which is good news I presume. > > I've attached output of some hardware info commands. Super I/O is ITE > IT8712F. The bios chip is removable and I have 5 spare. It says: > > SST > 49LF004B > 0446053-C > > Some questions... > > Can you have bluetooth compiled inside the kernel of Coreboot? I was > thinking of using bluetooth keyboards to access firmware settings. This is > something that BIOS does not let me. Only thing that works on my computer is > PS/2 and USB. > > Thanks. > > > -- > RaZoR1394 > -- RaZoR1394 ------=_Part_60734_1218327.1224461427314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some more info.

From irc:

<uwe___> we'll need 'superiotool -dV' output, 'getpir' output (a file called irq_table.c), 'mptable' output, maybe others

Done!

See attachments.

2008/10/12 razor1394 <razor1394 at gmail.com>
Hello

I'm really interested in putting Coreboot on my firmware chip but I'm not entirely sure it will work. My motherboard is on the desktop candidates list which is good news I presume.

I've attached output of some hardware info commands. Super I/O is ITE IT8712F. The bios chip is removable and I have 5 spare. It says:

SST
49LF004B
0446053-C

Some questions...

Can you have bluetooth compiled inside the kernel of Coreboot? I was thinking of using bluetooth keyboards to access firmware settings. This is something that BIOS does not let me. Only thing that works on my computer is PS/2 and USB.

Thanks.


--
RaZoR1394



--
RaZoR1394
------=_Part_60734_1218327.1224461427314-- ------=_Part_60733_14096137.1224461427314 Content-Type: text/plain; name=getpir.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fmicop605 Content-Disposition: attachment; filename=getpir.txt UHJvYmluZyBQSVJRIHRhYmxlIGluIG1lbW9yeS4KRm91bmQgUENJIElSUSByb3V0aW5nIHRhYmxl IHNpZ25hdHVyZSBhdCAweGZjOGIwLgpWYWxpZGF0aW5nLi4uIGNoZWNrc3VtIGlzIHdyb25nLgpD cmVhdGluZyBpcnFfdGFibGVzLmMgLi4uCkRvbmUsIHlvdSBjYW4gbW92ZSB0aGUgZmlsZSB0byB0 aGUgY29yZWJvb3QgdHJlZSBub3cuCg== ------=_Part_60733_14096137.1224461427314 Content-Type: text/x-csrc; name=irq_tables.c Content-Transfer-Encoding: base64 X-Attachment-Id: f_fmicp8ru6 Content-Disposition: attachment; filename=irq_tables.c LyogVGhpcyBmaWxlIHdhcyBnZW5lcmF0ZWQgYnkgZ2V0cGlyLmMsIGRvIG5vdCBtb2RpZnkhCiAq IChidXQgaWYgeW91IGRvLCBwbGVhc2UgcnVuIGNoZWNrcGlyIG9uIGl0IHRvIHZlcmlmeSkKICoK ICogQ29udGFpbnMgdGhlIElSUSBSb3V0aW5nIFRhYmxlIGR1bXBlZCBkaXJlY3RseSBmcm9tIHlv dXIKICogbWVtb3J5LCB3aGljaCBCSU9TIHNldHMgdXAuCiAqCiAqIERvY3VtZW50YXRpb24gYXQ6 IGh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS93aGRjL2FyY2hpdmUvcGNpaXJxLm1zcHgKICovCgoj aWZkZWYgR0VUUElSCiNpbmNsdWRlICJwaXJxX3JvdXRpbmcuaCIKI2Vsc2UKI2luY2x1ZGUgPGFy Y2gvcGlycV9yb3V0aW5nLmg+CiNlbmRpZgoKY29uc3Qgc3RydWN0IGlycV9yb3V0aW5nX3RhYmxl IGludGVsX2lycV9yb3V0aW5nX3RhYmxlID0gewoJUElSUV9TSUdOQVRVUkUsICAvKiB1MzIgc2ln bmF0dXJlICovCglQSVJRX1ZFUlNJT04sICAgIC8qIHUxNiB2ZXJzaW9uICAgKi8KCTMyKzE2KjE1 LAkgLyogVGhlcmUgY2FuIGJlIHRvdGFsIDE1IGRldmljZXMgb24gdGhlIGJ1cyAqLwoJMHgwMCwJ CSAvKiBXaGVyZSB0aGUgaW50ZXJydXB0IHJvdXRlciBsaWVzIChidXMpICovCgkoMHgwMDw8Myl8 MHgwLCAgIC8qIFdoZXJlIHRoZSBpbnRlcnJ1cHQgcm91dGVyIGxpZXMgKGRldikgKi8KCTB4YzM4 LAkJIC8qIElSUXMgZGV2b3RlZCBleGNsdXNpdmVseSB0byBQQ0kgdXNhZ2UgKi8KCTAsCQkgLyog VmVuZG9yICovCgkwLAkJIC8qIERldmljZSAqLwoJMCwJCSAvKiBDcmFwIChtaW5pcG9ydCkgKi8K CXsgMCwgMCwgMCwgMCwgMCwgMCwgMCwgMCwgMCwgMCwgMCB9LCAvKiB1OCByZnVbMTFdICovCgkw eDg1LAkJIC8qIHU4IGNoZWNrc3VtLiBUaGlzIGhhcyB0byBiZSBzZXQgdG8gc29tZQoJCQkgICAg dmFsdWUgdGhhdCB3b3VsZCBnaXZlIDAgYWZ0ZXIgdGhlIHN1bSBvZiBhbGwKCQkJICAgIGJ5dGVz IGZvciB0aGlzIHN0cnVjdHVyZSAoaW5jbHVkaW5nIGNoZWNrc3VtKSAqLwoJewoJCS8qIGJ1cywg ICAgIGRldnxmbiwgICB7bGluaywgYml0bWFwfSwge2xpbmssIGJpdG1hcH0sIHtsaW5rLCBiaXRt YXB9LCB7bGluaywgYml0bWFwfSwgIHNsb3QsIHJmdSAqLwoJCXsweDAxLCgweDA2PDwzKXwweDAs IHt7MHgwMywgMHhkZWI4fSwgezB4MDQsIDB4ZGViOH0sIHsweDAxLCAweGRlYjh9LCB7MHgwMiwg MHgwZGViOH19LCAweDEsIDB4MH0sCgkJezB4MDEsKDB4MDc8PDMpfDB4MCwge3sweDA0LCAweGRl Yjh9LCB7MHgwMSwgMHhkZWI4fSwgezB4MDIsIDB4ZGViOH0sIHsweDAzLCAweDBkZWI4fX0sIDB4 MiwgMHgwfSwKCQl7MHgwMSwoMHgwODw8Myl8MHgwLCB7ezB4MDEsIDB4ZGViOH0sIHsweDAyLCAw eGRlYjh9LCB7MHgwMywgMHhkZWI4fSwgezB4MDQsIDB4MGRlYjh9fSwgMHgzLCAweDB9LAoJCXsw eDAxLCgweDA5PDwzKXwweDAsIHt7MHgwMiwgMHhkZWI4fSwgezB4MDMsIDB4ZGViOH0sIHsweDA0 LCAweGRlYjh9LCB7MHgwMSwgMHgwZGViOH19LCAweDQsIDB4MH0sCgkJezB4MDEsKDB4MGE8PDMp fDB4MCwge3sweDAzLCAweGRlYjh9LCB7MHgwNCwgMHhkZWI4fSwgezB4MDEsIDB4ZGViOH0sIHsw eDAyLCAweDBkZWI4fX0sIDB4NSwgMHgwfSwKCQl7MHgwNSwoMHgwMDw8Myl8MHgwLCB7ezB4MDMs IDB4ZGViOH0sIHsweDA0LCAweGRlYjh9LCB7MHgwMSwgMHhkZWI4fSwgezB4MDIsIDB4MGRlYjh9 fSwgMHg2LCAweDB9LAoJCXsweDA0LCgweDAwPDwzKXwweDAsIHt7MHgwNCwgMHhkZWI4fSwgezB4 MDEsIDB4ZGViOH0sIHsweDAyLCAweGRlYjh9LCB7MHgwMywgMHgwZGViOH19LCAweDcsIDB4MH0s CgkJezB4MDMsKDB4MDA8PDMpfDB4MCwge3sweDAxLCAweGRlYjh9LCB7MHgwMiwgMHhkZWI4fSwg ezB4MDMsIDB4ZGViOH0sIHsweDA0LCAweDBkZWI4fX0sIDB4OCwgMHgwfSwKCQl7MHgwMiwoMHgw MDw8Myl8MHgwLCB7ezB4MDIsIDB4ZGViOH0sIHsweDAzLCAweGRlYjh9LCB7MHgwNCwgMHhkZWI4 fSwgezB4MDEsIDB4MGRlYjh9fSwgMHg5LCAweDB9LAoJCXsweDAwLCgweDAxPDwzKXwweDAsIHt7 MHgwNiwgMHhkZWI4fSwgezB4MDYsIDB4ZGViOH0sIHsweDAwLCAweGRlYjh9LCB7MHgwMCwgMHgw ZGViOH19LCAweDAsIDB4MH0sCgkJezB4MDAsKDB4MDI8PDMpfDB4MCwge3sweDA3LCAweGRlYjh9 LCB7MHgwOSwgMHhkZWI4fSwgezB4MDAsIDB4ZGViOH0sIHsweDAwLCAweDBkZWI4fX0sIDB4MCwg MHgwfSwKCQl7MHgwMCwoMHgwNDw8Myl8MHgwLCB7ezB4MGEsIDB4ZGViOH0sIHsweDBiLCAweGRl Yjh9LCB7MHgwMCwgMHhkZWI4fSwgezB4MDAsIDB4MGRlYjh9fSwgMHgwLCAweDB9LAoJCXsweDAw LCgweDBhPDwzKXwweDAsIHt7MHgwYywgMHhkZWI4fSwgezB4MDAsIDB4ZGViOH0sIHsweDAwLCAw eGRlYjh9LCB7MHgwMCwgMHgwZGViOH19LCAweDAsIDB4MH0sCgkJezB4MDAsKDB4MDc8PDMpfDB4 MCwge3sweDBkLCAweGRlYjh9LCB7MHgwMCwgMHhkZWI4fSwgezB4MDAsIDB4ZGViOH0sIHsweDAw LCAweDBkZWI4fX0sIDB4MCwgMHgwfSwKCQl7MHgwMCwoMHgwODw8Myl8MHgwLCB7ezB4MGUsIDB4 ZGViOH0sIHsweDAwLCAweGRlYjh9LCB7MHgwMCwgMHhkZWI4fSwgezB4MDAsIDB4MGRlYjh9fSwg MHgwLCAweDB9LAoJfQp9OwoKdW5zaWduZWQgbG9uZyB3cml0ZV9waXJxX3JvdXRpbmdfdGFibGUo dW5zaWduZWQgbG9uZyBhZGRyKQp7CglyZXR1cm4gY29weV9waXJxX3JvdXRpbmdfdGFibGUoYWRk cik7Cn0K ------=_Part_60733_14096137.1224461427314 Content-Type: text/plain; name=mptable.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fmicpci67 Content-Disposition: attachment; filename=mptable.txt LyogZ2VuZXJhdGVkIGJ5IE1QVGFibGUsIHZlcnNpb24gMi4wLjE1Ki8KLyogYXMgbW9kaWZpZWQg YnkgUkdNIGZvciBjb3JlYm9vdCAqLwojaW5jbHVkZSA8Y29uc29sZS9jb25zb2xlLmg+CiNpbmNs dWRlIDxhcmNoL3NtcC9tcHNwZWMuaD4KI2luY2x1ZGUgPGRldmljZS9wY2kuaD4KI2luY2x1ZGUg PHN0cmluZy5oPgojaW5jbHVkZSA8c3RkaW50Lmg+Cgp2b2lkICpzbXBfd3JpdGVfY29uZmlnX3Rh YmxlKHZvaWQgKnYpCnsKICAgICAgICBzdGF0aWMgY29uc3QgY2hhciBzaWdbNF0gPSAiUENNUCI7 CiAgICAgICAgc3RhdGljIGNvbnN0IGNoYXIgb2VtWzhdID0gIkxOWEkgICAgIjsKICAgICAgICBz dGF0aWMgY29uc3QgY2hhciBwcm9kdWN0aWRbMTJdID0gIlA0RFBFICAgICAgICI7CiAgICAgICAg c3RydWN0IG1wX2NvbmZpZ190YWJsZSAqbWM7CgogICAgICAgIG1jID0gKHZvaWQgKikoKChjaGFy ICopdikgKyBTTVBfRkxPQVRJTkdfVEFCTEVfTEVOKTsKICAgICAgICBtZW1zZXQobWMsIDAsIHNp emVvZigqbWMpKTsKCiAgICAgICAgbWVtY3B5KG1jLT5tcGNfc2lnbmF0dXJlLCBzaWcsIHNpemVv ZihzaWcpKTsKICAgICAgICBtYy0+bXBjX2xlbmd0aCA9IHNpemVvZigqbWMpOyAvKiBpbml0aWFs bHkganVzdCB0aGUgaGVhZGVyICovCiAgICAgICAgbWMtPm1wY19zcGVjID0gMHgwNDsKICAgICAg ICBtYy0+bXBjX2NoZWNrc3VtID0gMDsgLyogbm90IHlldCBjb21wdXRlZCAqLwogICAgICAgIG1l bWNweShtYy0+bXBjX29lbSwgb2VtLCBzaXplb2Yob2VtKSk7CiAgICAgICAgbWVtY3B5KG1jLT5t cGNfcHJvZHVjdGlkLCBwcm9kdWN0aWQsIHNpemVvZihwcm9kdWN0aWQpKTsKICAgICAgICBtYy0+ bXBjX29lbXB0ciA9IDA7CiAgICAgICAgbWMtPm1wY19vZW1zaXplID0gMDsKICAgICAgICBtYy0+ bXBjX2VudHJ5X2NvdW50ID0gMDsgLyogTm8gZW50cmllcyB5ZXQuLi4gKi8KICAgICAgICBtYy0+ bXBjX2xhcGljID0gTEFQSUNfQUREUjsKICAgICAgICBtYy0+bXBlX2xlbmd0aCA9IDA7CiAgICAg ICAgbWMtPm1wZV9jaGVja3N1bSA9IDA7CiAgICAgICAgbWMtPnJlc2VydmVkID0gMDsKCiAgICAg ICAgc21wX3dyaXRlX3Byb2Nlc3NvcnMobWMpOwoKCi8qQnVzOgkJQnVzIElECVR5cGUqLwoJc21w X3dyaXRlX2J1cyhtYywgMCwgIlBDSSAgICIpOwoJc21wX3dyaXRlX2J1cyhtYywgMSwgIlBDSSAg ICIpOwoJc21wX3dyaXRlX2J1cyhtYywgMiwgIlBDSSAgICIpOwoJc21wX3dyaXRlX2J1cyhtYywg MywgIlBDSSAgICIpOwoJc21wX3dyaXRlX2J1cyhtYywgNCwgIlBDSSAgICIpOwoJc21wX3dyaXRl X2J1cyhtYywgNSwgIlBDSSAgICIpOwoJc21wX3dyaXRlX2J1cyhtYywgNiwgIklTQSAgICIpOwov KkkvTyBBUElDczoJQVBJQyBJRAlWZXJzaW9uCVN0YXRlCQlBZGRyZXNzKi8KCXNtcF93cml0ZV9p b2FwaWMobWMsIDIsIDB4MjAsIDB4ZmVjMDAwMDApOwoJewoJCWRldmljZV90IGRldjsKCQlzdHJ1 Y3QgcmVzb3VyY2UgKnJlczsKCQlkZXYgPSBkZXZfZmluZF9zbG90KDEsIFBDSV9ERVZGTigweDFl LDApKTsKCQlpZiAoZGV2KSB7CgkJCXJlcyA9IGZpbmRfcmVzb3VyY2UoZGV2LCBQQ0lfQkFTRV9B RERSRVNTXzApOwoJCQlpZiAocmVzKSB7CgkJCQlzbXBfd3JpdGVfaW9hcGljKG1jLCAzLCAweDIw LCByZXMtPmJhc2UpOwoJCQl9CgkJfQoJCWRldiA9IGRldl9maW5kX3Nsb3QoMSwgUENJX0RFVkZO KDB4MWMsMCkpOwoJCWlmIChkZXYpIHsKCQkJcmVzID0gZmluZF9yZXNvdXJjZShkZXYsIFBDSV9C QVNFX0FERFJFU1NfMCk7CgkJCWlmIChyZXMpIHsKCQkJCXNtcF93cml0ZV9pb2FwaWMobWMsIDQs IDB4MjAsIHJlcy0+YmFzZSk7CgkJCX0KCQl9CiAgICAgICAgICAgICAgICBkZXYgPSBkZXZfZmlu ZF9zbG90KDQsIFBDSV9ERVZGTigweDFlLDApKTsKICAgICAgICAgICAgICAgIGlmIChkZXYpIHsK CQkJcmVzID0gZmluZF9yZXNvdXJjZShkZXYsIFBDSV9CQVNFX0FERFJFU1NfMCk7CgkJCWlmIChy ZXMpIHsKCQkJCXNtcF93cml0ZV9pb2FwaWMobWMsIDUsIDB4MjAsIHJlcy0+YmFzZSk7CgkJCX0K ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIGRldiA9IGRldl9maW5kX3Nsb3QoNCwg UENJX0RFVkZOKDB4MWMsMCkpOwogICAgICAgICAgICAgICAgaWYgKGRldikgewoJCQlyZXMgPSBm aW5kX3Jlc291cmNlKGRldiwgUENJX0JBU0VfQUREUkVTU18wKTsKCQkJaWYgKHJlcykgewoJCQkJ c21wX3dyaXRlX2lvYXBpYyhtYywgOCwgMHgyMCwgcmVzLT5iYXNlKTsKCQkJfQogICAgICAgICAg ICAgICAgfQoJfQovKkkvTyBJbnRzOglUeXBlCVBvbGFyaXR5ICAgIFRyaWdnZXIJQnVzIElECSBJ UlEJQVBJQyBJRAlQSU4jCiovCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RS SUdHRVJfTEVWRUx8TVBfSVJRX1BPTEFSSVRZX0xPVywgMHgwLCAweDQsIDB4MiwgMHg0KTsKCXNt cF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfTEVWRUx8TVBfSVJRX1BP TEFSSVRZX0xPVywgMHgwLCAweDgsIDB4MiwgMHgzKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1w X0lOVCwgTVBfSVJRX1RSSUdHRVJfTEVWRUx8TVBfSVJRX1BPTEFSSVRZX0xPVywgMHgwLCAweDks IDB4MiwgMHg1KTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJf TEVWRUx8TVBfSVJRX1BPTEFSSVRZX0xPVywgMHgxLCAweDE5LCAweDIsIDB4NSk7CglzbXBfd3Jp dGVfaW50c3JjKG1jLCBtcF9JTlQsIE1QX0lSUV9UUklHR0VSX0xFVkVMfE1QX0lSUV9QT0xBUklU WV9MT1csIDB4MSwgMHgyNCwgMHgyLCAweGEpOwoJc21wX3dyaXRlX2ludHNyYyhtYywgbXBfSU5U LCBNUF9JUlFfVFJJR0dFUl9MRVZFTHxNUF9JUlFfUE9MQVJJVFlfTE9XLCAweDAsIDB4MjgsIDB4 MiwgMHhiKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfTEVW RUx8TVBfSVJRX1BPTEFSSVRZX0xPVywgMHgxLCAweDE4LCAweDIsIDB4Myk7CglzbXBfd3JpdGVf aW50c3JjKG1jLCBtcF9JTlQsIE1QX0lSUV9UUklHR0VSX0xFVkVMfE1QX0lSUV9QT0xBUklUWV9M T1csIDB4MCwgMHgxMCwgMHgyLCAweDQpOwoJc21wX3dyaXRlX2ludHNyYyhtYywgbXBfSU5ULCBN UF9JUlFfVFJJR0dFUl9MRVZFTHxNUF9JUlFfUE9MQVJJVFlfTE9XLCAweDUsIDB4MCwgMHgyLCAw eDMpOwoJc21wX3dyaXRlX2ludHNyYyhtYywgbXBfSU5ULCBNUF9JUlFfVFJJR0dFUl9MRVZFTHxN UF9JUlFfUE9MQVJJVFlfTE9XLCAweDEsIDB4MjgsIDB4MiwgMHgzKTsKCXNtcF93cml0ZV9pbnRz cmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfTEVWRUx8TVBfSVJRX1BPTEFSSVRZX0xPVywg MHgxLCAweDFjLCAweDIsIDB4NSk7CglzbXBfd3JpdGVfaW50c3JjKG1jLCBtcF9JTlQsIE1QX0lS UV9UUklHR0VSX0xFVkVMfE1QX0lSUV9QT0xBUklUWV9MT1csIDB4MCwgMHgyMCwgMHgyLCAweGIp OwoJc21wX3dyaXRlX2ludHNyYyhtYywgbXBfSU5ULCBNUF9JUlFfVFJJR0dFUl9MRVZFTHxNUF9J UlFfUE9MQVJJVFlfTE9XLCAweDAsIDB4MWMsIDB4MiwgMHhhKTsKCXNtcF93cml0ZV9pbnRzcmMo bWMsIG1wX0V4dElOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVG QVVMVCwgMHg2LCAweDAsIDB4MiwgMHgwKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwg TVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweDEs IDB4MiwgMHgxKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJf REVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweDAsIDB4MiwgMHgyKTsKCXNt cF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFf UE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweDYsIDB4MiwgMHg2KTsKCXNtcF93cml0ZV9pbnRzcmMo bWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVGQVVM VCwgMHg2LCAweDcsIDB4MiwgMHg3KTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBf SVJRX1RSSUdHRVJfRURHRXxNUF9JUlFfUE9MQVJJVFlfSElHSCwgMHg2LCAweDgsIDB4MiwgMHg4 KTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxN UF9JUlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweDksIDB4MiwgMHg5KTsKCXNtcF93cml0ZV9p bnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlf REVGQVVMVCwgMHg2LCAweGMsIDB4MiwgMHhjKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lO VCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAw eGQsIDB4MiwgMHhkKTsKCXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdH RVJfREVGQVVMVHxNUF9JUlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweGUsIDB4MiwgMHhlKTsK CXNtcF93cml0ZV9pbnRzcmMobWMsIG1wX0lOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9J UlFfUE9MQVJJVFlfREVGQVVMVCwgMHg2LCAweGYsIDB4MiwgMHhmKTsKLypMb2NhbCBJbnRzOglU eXBlCVBvbGFyaXR5ICAgIFRyaWdnZXIJQnVzIElECSBJUlEJQVBJQyBJRAlQSU4jKi8KCXNtcF93 cml0ZV9pbnRzcmMobWMsIG1wX0V4dElOVCwgTVBfSVJRX1RSSUdHRVJfREVGQVVMVHxNUF9JUlFf UE9MQVJJVFlfREVGQVVMVCwgMHgwLCAweDAsIE1QX0FQSUNfQUxMLCAweDApOwoJc21wX3dyaXRl X2ludHNyYyhtYywgbXBfTk1JLCBNUF9JUlFfVFJJR0dFUl9ERUZBVUxUfE1QX0lSUV9QT0xBUklU WV9ERUZBVUxULCAweDAsIDB4MCwgTVBfQVBJQ19BTEwsIDB4MSk7CgkvKiBUaGVyZSBpcyBubyBl eHRlbnNpb24gaW5mb3JtYXRpb24uLi4gKi8KCgkvKiBDb21wdXRlIHRoZSBjaGVja3N1bXMgKi8K CW1jLT5tcGVfY2hlY2tzdW0gPSBzbXBfY29tcHV0ZV9jaGVja3N1bShzbXBfbmV4dF9tcGNfZW50 cnkobWMpLCBtYy0+bXBlX2xlbmd0aCk7CgltYy0+bXBjX2NoZWNrc3VtID0gc21wX2NvbXB1dGVf Y2hlY2tzdW0obWMsIG1jLT5tcGNfbGVuZ3RoKTsKCXByaW50a19kZWJ1ZygiV3JvdGUgdGhlIG1w IHRhYmxlIGVuZCBhdDogJXAgLSAlcFxuIiwKCQltYywgc21wX25leHRfbXBlX2VudHJ5KG1jKSk7 CglyZXR1cm4gc21wX25leHRfbXBlX2VudHJ5KG1jKTsKfQoKdW5zaWduZWQgbG9uZyB3cml0ZV9z bXBfdGFibGUodW5zaWduZWQgbG9uZyBhZGRyKQp7Cgl2b2lkICp2OwoJdiA9IHNtcF93cml0ZV9m bG9hdGluZ190YWJsZShhZGRyKTsKCXJldHVybiAodW5zaWduZWQgbG9uZylzbXBfd3JpdGVfY29u ZmlnX3RhYmxlKHYpOwp9Cg== ------=_Part_60733_14096137.1224461427314 Content-Type: text/plain; name=superiotool.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fmicpi2o8 Content-Disposition: attachment; filename=superiotool.txt c3VwZXJpb3Rvb2wgcjMxMjUKUHJvYmluZyBmb3IgQUxpIFN1cGVyIEkvTyBhdCAweDNmMC4uLgog IEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQ9MHhmZmZmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBB TGkgU3VwZXIgSS9PIGF0IDB4MzcwLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0weGZm ZmYsIHJldj0weGZmClByb2JpbmcgZm9yIEZpbnRlayBTdXBlciBJL08gYXQgMHgyZS4uLgogIEZh aWxlZC4gUmV0dXJuZWQgZGF0YTogdmlkPTB4ZmZmZiwgaWQ9MHhmZmZmClByb2JpbmcgZm9yIEZp bnRlayBTdXBlciBJL08gYXQgMHg0ZS4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogdmlkPTB4 ZmZmZiwgaWQ9MHhmZmZmClByb2JpbmcgZm9yIElURSBTdXBlciBJL08gKGluaXQ9MHg4NywweDAx LDB4NTUsMHg1NS8weGFhKSBhdCAweDJlLi4uCkZvdW5kIElURSBJVDg3MTJGIChpZD0weDg3MTIs IHJldj0weDcpIGF0IDB4MmUKUmVnaXN0ZXIgZHVtcDoKaWR4IDA3IDIwIDIxIDIyIDIzIDI0IDJi CnZhbCAwYSA4NyAxMiAwNyAwMSAwMCAwMApkZWYgTkEgODcgMTIgMDggMDAgMDAgMDAKTEROIDB4 MDAgKEZsb3BweSkKaWR4IDMwIDYwIDYxIDcwIDc0IGYwIGYxCnZhbCAwMCAwMCAwMCAwMCAwNCAw MCAwMApkZWYgMDAgMDMgZjAgMDYgMDIgMDAgMDAKTEROIDB4MDEgKENPTTEpCmlkeCAzMCA2MCA2 MSA3MCBmMCBmMSBmMiBmMwp2YWwgMDAgMDAgMDAgMDAgMDAgNTAgMDAgN2YKZGVmIDAwIDAzIGY4 IDA0IDAwIDUwIDAwIDdmCkxETiAweDAyIChDT00yKQppZHggMzAgNjAgNjEgNzAgZjAgZjEgZjIg ZjMKdmFsIDAwIDAwIDAwIDAwIDEwIDUwIDAwIDdmCmRlZiAwMCAwMiBmOCAwMyAwMCA1MCAwMCA3 ZgpMRE4gMHgwMyAoUGFyYWxsZWwgcG9ydCkKaWR4IDMwIDYwIDYxIDYyIDYzIDcwIDc0IGYwCnZh bCAwMCAwMCAwMCAwMCAwMCAwMCAwNCAwOApkZWYgMDAgMDMgNzggMDcgNzggMDcgMDMgMDMKTERO IDB4MDQgKEVudmlyb25tZW50IGNvbnRyb2xsZXIpCmlkeCAzMCA2MCA2MSA2MiA2MyA3MCBmMCBm MSAgZjIgZjMgZjQgZjUgZjYKdmFsIDAxIDAyIDkwIDAwIDAwIDAwIDgwIDAwICAwYSAwMCAwMCAw MCBmZgpkZWYgMDAgMDIgOTAgMDIgMzAgMDkgMDAgMDAgIDAwIDAwIDAwIE5BIE5BCkxETiAweDA1 IChLZXlib2FyZCkKaWR4IDMwIDYwIDYxIDYyIDYzIDcwIDcxIGYwCnZhbCAwMSAwMCA2MCAwMCA2 NCAwMSAwMiA2OApkZWYgMDEgMDAgNjAgMDAgNjQgMDEgMDIgMDgKTEROIDB4MDYgKE1vdXNlKQpp ZHggMzAgNzAgNzEgZjAKdmFsIDAwIDAwIDAyIDAwCmRlZiAwMCAwYyAwMiAwMApMRE4gMHgwNyAo R1BJTykKaWR4IDI1IDI2IDI3IDI4IDI5IDJhIDJjIDYwICA2MSA2MiA2MyA2NCA2NSA3MCA3MSA3 MiAgNzMgNzQgYjAgYjEgYjIgYjMgYjQgYjUgIGI4IGI5IGJhIGJiIGJjIGJkIGMwIGMxICBjMiBj MyBjNCBjOCBjOSBjYSBjYiBjYyAgZTAgZTEgZTIgZTMgZTQgZjAgZjEgZjIgIGYzIGY0IGY1IGY2 IGY3IGY4IGY5IGZhICBmYiBmYyBmZAp2YWwgYzEgY2YgMDAgMDMgMDggMDAgMWYgMDAgIDAwIDAy IDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwNCBjMCBjMCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAg MDggMDggYzAgY2YgIDAwIDAxIDAwIDAwIDBmIDAwIDAxIDAwICAwMCAwMCAwMCAwMCAwMCAxMCAw MCAwMCAgMDAgMDAgMmIgMjAgMDAgMDAgMDEgMDAgIDAwIDI4IDAwCmRlZiAwMSAwMCAwMCA0MCAw MCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgIGMwIDAwIDAwIDAwIDAwIDAwIDAw IDAwICAwMCAwMCAwMCAwMCAwMCAwMCAwMSAwMCAgMDAgNDAgMDAgMDEgMDAgMDAgNDAgMDAgIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgTkEgMDAK TEROIDB4MDggKE1JREkgcG9ydCkKaWR4IDMwIDYwIDYxIDcwIGYwCnZhbCAwMCAwMyAwMCAwYSAw MApkZWYgMDAgMDMgMDAgMGEgMDAKTEROIDB4MDkgKEdhbWUgcG9ydCkKaWR4IDMwIDYwIDYxCnZh bCAwMCAwMiAwMQpkZWYgMDAgMDIgMDEKTEROIDB4MGEgKENvbnN1bWVyIElSKQppZHggMzAgNjAg NjEgNzAgZjAKdmFsIDAwIDAzIDEwIDBiIDA2CmRlZiAwMCAwMyAxMCAwYiAwMApQcm9iaW5nIGZv ciBJVEUgU3VwZXIgSS9PIChpbml0PTB4ODcsMHg4NykgYXQgMHgyZS4uLgogIEZhaWxlZC4gUmV0 dXJuZWQgZGF0YTogaWQ9MHhmZmZmLCByZXY9MHhmClByb2JpbmcgZm9yIElURSBTdXBlciBJL08g KGluaXQ9MHg4NywweDAxLDB4NTUsMHg1NS8weGFhKSBhdCAweDRlLi4uCiAgRmFpbGVkLiBSZXR1 cm5lZCBkYXRhOiBpZD0weGZmZmYsIHJldj0weGYKUHJvYmluZyBmb3IgSVRFIFN1cGVyIEkvTyAo aW5pdD0weDg3LDB4ODcpIGF0IDB4NGUuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkPTB4 ZmZmZiwgcmV2PTB4ZgpQcm9iaW5nIGZvciBOU0MgU3VwZXIgSS9PIGF0IDB4MmUuLi4KICBGYWls ZWQuIFJldHVybmVkIGRhdGE6IHBvcnQ9MHhmZiwgcG9ydCsxPTB4ZmYKUHJvYmluZyBmb3IgTlND IFN1cGVyIEkvTyBhdCAweDRlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBwb3J0PTB4ZmYs IHBvcnQrMT0weGZmClByb2JpbmcgZm9yIFNNU0MgU3VwZXIgSS9PIChpZHJlZ3M9MHgyMC8weDIx KSBhdCAweDJlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0weGZmLCByZXY9MHhmZgpQ cm9iaW5nIGZvciBTTVNDIFN1cGVyIEkvTyAoaWRyZWdzPTB4MGQvMHgwZSkgYXQgMHgyZS4uLgog IEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQ9MHhmZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgU01T QyBTdXBlciBJL08gKGlkcmVncz0weDIwLzB4MjEpIGF0IDB4NGUuLi4KICBGYWlsZWQuIFJldHVy bmVkIGRhdGE6IGlkPTB4ZmYsIHJldj0weGZmClByb2JpbmcgZm9yIFNNU0MgU3VwZXIgSS9PIChp ZHJlZ3M9MHgwZC8weDBlKSBhdCAweDRlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0w eGZmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBTTVNDIFN1cGVyIEkvTyAoaWRyZWdzPTB4MjAvMHgy MSkgYXQgMHgxNjJlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0weGZmLCByZXY9MHhm ZgpQcm9iaW5nIGZvciBTTVNDIFN1cGVyIEkvTyAoaWRyZWdzPTB4MGQvMHgwZSkgYXQgMHgxNjJl Li4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0weGZmLCByZXY9MHhmZgpQcm9iaW5nIGZv ciBTTVNDIFN1cGVyIEkvTyAoaWRyZWdzPTB4MjAvMHgyMSkgYXQgMHgxNjRlLi4uCiAgRmFpbGVk LiBSZXR1cm5lZCBkYXRhOiBpZD0weGZmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBTTVNDIFN1cGVy IEkvTyAoaWRyZWdzPTB4MGQvMHgwZSkgYXQgMHgxNjRlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBk YXRhOiBpZD0weGZmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBTTVNDIFN1cGVyIEkvTyAoaWRyZWdz PTB4MjAvMHgyMSkgYXQgMHgzZjAuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkPTB4ZmYs IHJldj0weGZmClByb2JpbmcgZm9yIFNNU0MgU3VwZXIgSS9PIChpZHJlZ3M9MHgwZC8weDBlKSBh dCAweDNmMC4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQ9MHhmZiwgcmV2PTB4ZmYKUHJv YmluZyBmb3IgU01TQyBTdXBlciBJL08gKGlkcmVncz0weDIwLzB4MjEpIGF0IDB4MzcwLi4uCiAg RmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZD0weGZmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBTTVND IFN1cGVyIEkvTyAoaWRyZWdzPTB4MGQvMHgwZSkgYXQgMHgzNzAuLi4KICBGYWlsZWQuIFJldHVy bmVkIGRhdGE6IGlkPTB4ZmYsIHJldj0weGZmClByb2JpbmcgZm9yIFdpbmJvbmQgU3VwZXIgSS9P IChpbml0PTB4ODgpIGF0IDB4MmUuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlk PTB4ZmYvMHgwZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9 MHg4OSkgYXQgMHgyZS4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQvb2xkaWQ9MHhmZi8w eDBmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBXaW5ib25kIFN1cGVyIEkvTyAoaW5pdD0weDg2LDB4 ODYpIGF0IDB4MmUuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlkPTB4ZmYvMHgw ZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9MHg4NywweDg3 KSBhdCAweDJlLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZC9vbGRpZD0weGZmLzB4MGYs IHJldj0weGZmClByb2JpbmcgZm9yIFdpbmJvbmQgU3VwZXIgSS9PIChpbml0PTB4ODgpIGF0IDB4 NGUuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlkPTB4ZmYvMHgwZiwgcmV2PTB4 ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9MHg4OSkgYXQgMHg0ZS4uLgog IEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQvb2xkaWQ9MHhmZi8weDBmLCByZXY9MHhmZgpQcm9i aW5nIGZvciBXaW5ib25kIFN1cGVyIEkvTyAoaW5pdD0weDg2LDB4ODYpIGF0IDB4NGUuLi4KICBG YWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlkPTB4ZmYvMHgwZiwgcmV2PTB4ZmYKUHJvYmlu ZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9MHg4NywweDg3KSBhdCAweDRlLi4uCiAgRmFp bGVkLiBSZXR1cm5lZCBkYXRhOiBpZC9vbGRpZD0weGZmLzB4MGYsIHJldj0weGZmClByb2Jpbmcg Zm9yIFdpbmJvbmQgU3VwZXIgSS9PIChpbml0PTB4ODgpIGF0IDB4M2YwLi4uCiAgRmFpbGVkLiBS ZXR1cm5lZCBkYXRhOiBpZC9vbGRpZD0weGZmLzB4MGYsIHJldj0weGZmClByb2JpbmcgZm9yIFdp bmJvbmQgU3VwZXIgSS9PIChpbml0PTB4ODkpIGF0IDB4M2YwLi4uCiAgRmFpbGVkLiBSZXR1cm5l ZCBkYXRhOiBpZC9vbGRpZD0weGZmLzB4MGYsIHJldj0weGZmClByb2JpbmcgZm9yIFdpbmJvbmQg U3VwZXIgSS9PIChpbml0PTB4ODYsMHg4NikgYXQgMHgzZjAuLi4KICBGYWlsZWQuIFJldHVybmVk IGRhdGE6IGlkL29sZGlkPTB4ZmYvMHgwZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBT dXBlciBJL08gKGluaXQ9MHg4NywweDg3KSBhdCAweDNmMC4uLgogIEZhaWxlZC4gUmV0dXJuZWQg ZGF0YTogaWQvb2xkaWQ9MHhmZi8weDBmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBXaW5ib25kIFN1 cGVyIEkvTyAoaW5pdD0weDg4KSBhdCAweDM3MC4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTog aWQvb2xkaWQ9MHhmZi8weDBmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBXaW5ib25kIFN1cGVyIEkv TyAoaW5pdD0weDg5KSBhdCAweDM3MC4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQvb2xk aWQ9MHhmZi8weDBmLCByZXY9MHhmZgpQcm9iaW5nIGZvciBXaW5ib25kIFN1cGVyIEkvTyAoaW5p dD0weDg2LDB4ODYpIGF0IDB4MzcwLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZC9vbGRp ZD0weGZmLzB4MGYsIHJldj0weGZmClByb2JpbmcgZm9yIFdpbmJvbmQgU3VwZXIgSS9PIChpbml0 PTB4ODcsMHg4NykgYXQgMHgzNzAuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlk PTB4ZmYvMHgwZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9 MHg4OCkgYXQgMHgyNTAuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlkPTB4ZmYv MHgwZiwgcmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9MHg4OSkg YXQgMHgyNTAuLi4KICBGYWlsZWQuIFJldHVybmVkIGRhdGE6IGlkL29sZGlkPTB4ZmYvMHgwZiwg cmV2PTB4ZmYKUHJvYmluZyBmb3IgV2luYm9uZCBTdXBlciBJL08gKGluaXQ9MHg4NiwweDg2KSBh dCAweDI1MC4uLgogIEZhaWxlZC4gUmV0dXJuZWQgZGF0YTogaWQvb2xkaWQ9MHhmZi8weDBmLCBy ZXY9MHhmZgpQcm9iaW5nIGZvciBXaW5ib25kIFN1cGVyIEkvTyAoaW5pdD0weDg3LDB4ODcpIGF0 IDB4MjUwLi4uCiAgRmFpbGVkLiBSZXR1cm5lZCBkYXRhOiBpZC9vbGRpZD0weGZmLzB4MGYsIHJl dj0weGZmCg== ------=_Part_60733_14096137.1224461427314-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: memset(dev, 0, sizeof(*dev)); dev->path = *path; dev->id = *devid; /* Initialize the back pointers in the link fields. */ for (link = 0; link < MAX_LINKS; link++) { dev->link[link].dev = dev; dev->link[link].link = link; } /* By default devices are enabled. */ dev->enabled = 1; /* Add the new device to the list of children of the bus. */ dev->bus = parent; if (child) { child->sibling = dev; } else { parent->children = dev; } /* Append a new device to the global device list. * The list is used to find devices once everything is set up. */ *last_dev_p = dev; last_dev_p = &dev->next; /* Give the device a name. */ sprintf(dev->dtsname, "dynamic %s", dev_path(dev)); /* Run the device specific constructor as last part of the chain * so it gets the chance to overwrite the "inherited" values above */ constructor(dev); ------=_Part_50322_8025613.1224875135292 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Why do we call the constructor function of a new device?   I can't see where we ever set it.
Thanks,
Myles

From device/device.c:

   memset(dev, 0, sizeof(*dev));
    dev->path = *path;
    dev->id = *devid;

    /* Initialize the back pointers in the link fields. */
    for (link = 0; link < MAX_LINKS; link++) {
        dev->link[link].dev = dev;
        dev->link[link].link = link;
    }

    /* By default devices are enabled. */
    dev->enabled = 1;

    /* Add the new device to the list of children of the bus. */
    dev->bus = parent;
    if (child) {
        child->sibling = dev;
    } else {
        parent->children = dev;
    }

    /* Append a new device to the global device list.
     * The list is used to find devices once everything is set up.
     */
    *last_dev_p = dev;
    last_dev_p = &dev->next;

    /* Give the device a name. */
    sprintf(dev->dtsname, "dynamic %s", dev_path(dev));

    /* Run the device specific constructor as last part of the chain
     * so it gets the chance to overwrite the "inherited" values above
     */

    constructor(dev);
------=_Part_50322_8025613.1224875135292-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 19.[0123] and other processor devices all live on PCI bus 0? Is that bus somewhat related to the buses attached via ncHT? IIRC I once saw a machine where 18.[0123] was alone on bus 0 and all other PCI devices were on separate buses. Taking the "everything is PCI" model, how would I specify the virtual PCI buses attached via ncHT? Are they children (secondary buses) of 18.0 which would act like a PCI-to-PCI bridge? > The dts should be easy for people to fill in to make a platform work. Agreed. > They don't know (or need to know) what ht links are connecting the cpu > and what ones go to pci bus. They need a way to specify settings for any given PCI device. Since most modern machines have multiple PCI devices with the same vendor/device ID, we have to be able to identify devices based on their logical path. For that, we have to model the logical PCI bus/device/tree reasonably well. I'm trying to do that, but no model seems to fit. Regards, Carl-Daniel -- http://www.hailfinger.org/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: right. I may be wrong but I am not sure all those issues are being taken into consideration. A writeup of all this by a person who'd never looked at it before would be really useful. Why? because they won't take things for granted -- they'll look at it with a fresh perspective. Stefan and I are going to walk this stuff as well. ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: congruent with the logical PCI tree, but they differ significantly in a few places. It is desirable to have both trees available: One for resource allocation, one for device discovery. Killing either is calling for problems down the road. Besides that, in reality we're neither dealing with a real tree nor a completely acyclic graph. There are easy ways out which either make the dts completely unreadable or beget some unholy device tree code. Neither is acceptable if we consider maintainability to be important. The good thing is that my diploma thesis provides solutions for exactly that class of problems. It's not about coreboot, but the problems we face right now are so strikingly similar that I regret not writing the whole thing in English. Anyway, I'll try to create a short writeup which captures the essential results, and how to apply them without losing mental sanity (or maintainability, for that matter). The trick is to declare a preferred and readable form for storing device relations (the existing dts structure works quite well in that regard) and to handle different requirements for that representation like database views. With a nice set of node properties and the right amount of abstraction, we can keep both the code and the dts human readable and have them provide easily understood views of their respective purposes (resource allocation vs. device discovery). If we do it right, even such horrors as wandering PATA/SATA PCI devices (after disabling PATA, SATA will change its PCI devfn) are easily expressed and handled. Regards, Carl-Daniel -- http://www.hailfinger.org/ From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: memory smaller than a page, and failing. It would be helpful if you posted your command line and the complete output. Probably the output of ./flashrom -V too. Thanks, Myles _____ From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Collin Gregory Sent: Friday, October 31, 2008 2:17 PM To: coreboot at coreboot.org Subject: [coreboot] Flashrom problem Hello everyone, I'm a newbies in coreboot installation but not in linux, hopefully :) When i'm launching flashrom, i get this error message : Can't mmap memory using /dev/mem : Invalid ARgument ... Does anyone knows what does it means ? My motherboard is the D945gclf with these technical informations : - Soldered-down IntelR AtomR processor 230 with a 533 MHz system bus - IntelR 945GC Chipset, consisting of: . IntelR 82945GC Graphics Memory Controller Hub (GMCH) . IntelR 82801GB I/O Controller Hub (ICH7) - Realtek* ALC662 for the sound chipset - IntelR GMA950 onboard graphics subsystem Video - SMSC LPC47M997 based Legacy I/O controller for hardware management, serial, parallel, and PS/2* ports - Realtek RTL8102EL LAN adapter device Thanks for your help !!!! Greg ------=_NextPart_000_005A_01C93B65.8C0986A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the comment in flashrom.c, it = looks like flashrom is trying to allocate memory smaller than a page, and = failing.  It would be helpful if you posted your command line and the complete = output.  Probably the output of ./flashrom –V = too.

 

Thanks,

=

Myles

 


From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] = On Behalf Of Collin Gregory
Sent: Friday, October 31, = 2008 2:17 PM
To: = coreboot at coreboot.org
Subject: [coreboot] = Flashrom problem

 

Hello everyone,

I'm a newbies in coreboot installation but not in linux, hopefully = :)
When i'm launching flashrom, i get this error message :

Can't mmap memory using /dev/mem : Invalid ARgument ...

Does anyone knows what does it means ?

My motherboard is the D945gclf with these technical informations :

- Soldered-down Intel® Atom® processor 230 with a 533 MHz system = bus
- Intel® 945GC Chipset, consisting of:

• Intel® 82945GC Graphics Memory Controller Hub = (GMCH)

• Intel® 82801GB I/O Controller Hub = (ICH7)

- Realtek* ALC662 for the sound chipset
- Intel® GMA950 onboard graphics subsystem Video
- SMSC LPC47M997 based Legacy I/O controller for hardware management, = serial, parallel, and PS/2* ports
- Realtek RTL8102EL LAN adapter device

Thanks for your help !!!!

Greg

------=_NextPart_000_005A_01C93B65.8C0986A0-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: 3.1 Configuration Space Accesses The AMD Athlon=99 64 and AMD Opteron=99 Processors implement configuration = space as defined in the PCI Local Bus Specification, Rev. 2.2, and the HyperTransport=99 I/O Li= nk Specification, Rev. 1.03. I read that to mean that even though the processor reports Rev 1.02, it's 1.03. Thanks, Myles ------=_Part_62430_28029580.1225729485377 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Fri, Oct 24, 2008 at 9:21 AM, Carl-Da= niel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
=
On 24.10.2008 17:13, Carl-Daniel Hailfinger wrote: > Hi,
>
> I'm getting the following message from lspci on my K8 machine:
>
> 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]=
>         Control: I/O- Mem- BusMaster- SpecCycle- M= emWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- = DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Capabilities: [80] HyperTransport: Host or= Secondary Interface
>                 !!! Possibly i= ncomplete decoding for revision 1.02
>                 Command: WarmR= st+ DblEnd-
>                 Link Control: = CFlE- CST- CFE- <LkFail- Init+ EOC- TXO-
> <CRCErr=3D0
>                 Link Config: M= LWI=3D16bit MLWO=3D16bit LWI=3D16bit LWO=3D16bit
>                 Revision ID: 1= .02
>         Kernel modules: ipmi_si
>
> Note the warning about "Possibly inco= mplete decoding" which stems from
> the fact that the processor mentions HT revision 1.02 which is the las= t
> non-public revision. Every revision from 1.03 and beyond seems to be > publically available. Now the big question is: Can we decode HT 1.02 > like HT 1.03 or have there been fundamental changes in between? I'= d like
> to create a patch for PCIutils (lspci) so we can have full info withou= t
> a warning message.

From the BKDG:
3.= 1 Configuration Space Accesses
The AMD Athlon=99 64 and AMD Opteron=99 P= rocessors implement configuration space as defined in
the PCI Local Bus = Specification, Rev. 2.2, and the HyperTransport=99 I/O Link Specification, = Rev.
1.03.

I read that to mean that even though the processor reports Rev= 1.02, it's 1.03.

Thanks,
Myles

------=_Part_62430_28029580.1225729485377-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: const struct pci_bus_operations *pci_check_direct(void) { unsigned int tmp; /* * Check if configuration type 1 works. */ { outb(0x01, 0xCFB); tmp = inl(0xCF8); outl(0x80000000, 0xCF8); if ((inl(0xCF8) == 0x80000000) && pci_sanity_check(&pci_cf8_conf1)) { outl(tmp, 0xCF8); printk(BIOS_DEBUG, "PCI: Using configuration type 1\n"); return &pci_cf8_conf1; } outl(tmp, 0xCF8); } die("pci_check_direct failed\n"); return NULL; } /** Set the method to be used for PCI, type I or type II */ void pci_set_method(struct device * dev) { printk(BIOS_INFO, "Finding PCI configuration type.\n"); dev->ops->ops_pci_bus = pci_check_direct(); post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD); } Here are the interesting things: 1. pci_check_direct either returns pci_cfg8_conf1 or dies 2. This code is only used by geodelx I think the const struct is the right way to do this. Can we change these functions? Two solutions: 1. Set the entire ops 2. Initialize it correctly and die if the check fails Comments? Thanks, Myles ------=_Part_15249_19644244.1225916673157 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Nov 5, 2008 at 1:24 PM, Myles Watson <mylesgw at gmail.com> wrote:
> Are you testing these on qemu I assume?

I can.  I don't think I've made any functional changes, but it's probably
good to check.

Most of this patch isn't exercised by qemu, though.  There are no bridges
which are not in the dts.

It turns out that I forgot the importance of make clean for build testing.  I wish I knew better how to fix the dependencies.

This breaks the build now that I made the change for the pci_ops structs to be const.

From pci_ops_auto.c:
const struct pci_bus_operations *pci_check_direct(void)
{
    unsigned int tmp;

    /*
     * Check if configuration type 1 works.
     */
    {
        outb(0x01, 0xCFB);
        tmp = inl(0xCF8);
        outl(0x80000000, 0xCF8);
        if ((inl(0xCF8) == 0x80000000) &&
            pci_sanity_check(&pci_cf8_conf1))
        {
            outl(tmp, 0xCF8);
            printk(BIOS_DEBUG, "PCI: Using configuration type 1\n");
            return &pci_cf8_conf1;
        }
        outl(tmp, 0xCF8);
    }

    die("pci_check_direct failed\n");
    return NULL;
}

/** Set the method to be used for PCI, type I or type II
 */
void pci_set_method(struct device * dev)
{
    printk(BIOS_INFO, "Finding PCI configuration type.\n");
    dev->ops->ops_pci_bus = pci_check_direct();
    post_code(POST_STAGE2_PHASE2_PCI_SET_METHOD);
}

Here are the interesting things:
1. pci_check_direct either returns pci_cfg8_conf1 or dies
2. This code is only used by geodelx

I think the const struct is the right way to do this.  Can we change these functions?

Two solutions:
1. Set the entire ops
2. Initialize it correctly and die if the check fails

Comments?

Thanks,
Myles
------=_Part_15249_19644244.1225916673157-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: v2 auto.c did this. Things were set up just enough that the basic legacy devices worked. Note that config space doesn't change later -- just some basic routing. So if the subtractive path doesn't get messed up, and no other resource positively decodes this, we're ok. Let's not bring the IOINDEX_SUBTRACTIVE resources into this discussion -- I did that already and it got me into trouble. The SUBTRACTIVE name in the resource code is misleading IMHO. ron From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: size are serial flash chips, and the ones with non-uniform size are parallel flash chips. I propose a new design the 'flashchip' structure. In this new design, serial and parallel flash chip information is stored in 'serial_flashchip' and 'parallel_flashchip' seperately, with a common 'flashchip_common' internal struct as their first field. serial_flashchip +------------------+------------------------------+ | flashchip_common | sector_size, block_size, ... | +------------------+------------------------------+ parallel_flashchip +------------------+------------------------------+ | flashchip_common | erase_block | +------------------+------------------------------+ 'flashchip_common' contains names, id's and common operation functions. The design above looks clearer. And There is another advantage. I guess(confirm and disproof welcome) one chipset only provides one of the two flash interface. When a chipset is detected, we can probe only one kind of them, (hopefully) faster and safer. It is ok if we want to probe the other kind. > Index: flashrom-eraseblocks/flashrom.c > =================================================================== > --- flashrom-eraseblocks/flashrom.c (Revision 3776) > +++ flashrom-eraseblocks/flashrom.c (Arbeitskopie) > @@ -534,11 +534,33 @@ > > if (erase_it) { > printf("Erasing flash chip.\n"); > - if (!flash->erase) { > - fprintf(stderr, "Error: flashrom has no erase function for this flash chip.\n"); > + if (!flash->block_erase && flash->eraseblocks[0].count) { > + fprintf(stderr, "Hint: flashrom knows the eraseblock " > + "layout, but there is no blockwise erase " > + "function for this flash chip. " > + "Using whole-chip erase.\n"); > + } > + if (flash->block_erase && !flash->eraseblocks[0].count) { > + fprintf(stderr, "Hint: flashrom has a blockwise erase " > + "function for this flash chip, but the " > + "eraseblock layout is unknown. " > + "Using whole-chip erase.\n"); > + } > + if (flash->block_erase && flash->eraseblocks[0].count) { > + unsigned long done = 0; > + int i, j; > + for (i = 0; done < flash->total_size * 1024; i++) { > + for (j = 0; j < flash->eraseblocks[i].count; j++) { > + flash->block_erase(flash, done + flash->eraseblocks[i].size * j); > + } > + done += flash->eraseblocks[i].count * flash->eraseblocks[i].size; > + } > + } else if (flash->erase) { > + flash->erase(flash); > + } else { > + fprintf(stderr, "Error: flashrom has no chip erase function for this flash chip.\n"); > return 1; > } > - flash->erase(flash); > exit(0); > } else if (read_it) { > if ((image = fopen(filename, "w")) == NULL) { No comment to the logic. But the new code has a different degree of detail compared to other 'if (do_it)' blocks(i.e., the for loop). yu ning From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: LV2 ??? Level 2 Register I/O Address: PMBASE + 14h ... Reads to this register return all 0s, writes to this register have no effect. Reads to this register generate a ???enter a level 2 power state??? (C2) to the clock control logic. This will cause the STPCLK# signal to go active, and stay active until a break event occurs. Throttling (due either to THTL_EN or FORCE_THTL) will be ignored. ... NOTE: This register should not be used by IA-64 processors or systems with more than 1 logical processor, unless appropriate semaphoring software has been put in place to ensure that all threads/processors are ready for the C2 state when the read to this register occurs. The subsequent byte registers are LV3, LV4, LV5 and for mobile version LV6 intended for entering C3, C4, C5 and C6 states. -- Andriy Gapon From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: the parallel port. One way is to use /dev/parportX. The /dev/parportX method is a higher level driver. I'm still looking into this to see if it will be better. I think Stefan was referring to the parport_find_base() function which wouldn't work for me. For that you input a base address and it returns the corresponding parallel port. The other method is directly controlling the I/O. It is a lower level driver directly accessing the hardware. It is supposed to be faster, which will be good for flashing. It is also very simple, using outb and inb. This is the method I prefer. But it seems in all the examples I have looked at the the base address is statically defined. That is what I am trying to do is automate that. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: the parallel port. One way is to use /dev/parportX. The /dev/parportX method is a higher level driver. I'm still looking into this to see if it will be better. I think Stefan was referring to the parport_find_base() function which wouldn't work for me. For that you input a base address and it returns the corresponding parallel port. The other method is directly controlling the I/O. It is a lower level driver directly accessing the hardware. It is supposed to be faster, which will be good for flashing. It is also very simple, using outb and inb. This is the method I prefer. But it seems in all the examples I have looked at the the base address is statically defined. That is what I am trying to do is automate that. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Celeron M (4xx) Processor FSB 667MHz Socket M It is just in a different package, It supports the Socket (M) uFCBGA PBGA479 (mobile) processor. Not the LGA775. Should that matter??? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: L1 Cache: 128K 3265 MB/s Memory : 480M 240 MB/s That's right, faster then v2 :) I've managed to coerce the northbridge into running the memory at 200MHz (DDR400) without locking up the system like it does in v2, and also to use 1GB of ram, which the fuctory BIOS only sees as 512MB, and v2 for some reason trips over. However, it's a mixed blessing, even though memtest86 now runs at an acceptable speed, coreboot is still running fairly slowly. I'm attaching a patch that brings over mtrr.c from v2 and hacks it to work with v3, but no sign-off because IMO it's not ready to be committed. I'll try booting a FILO payload and a kernel tomorrow, but right now it's time for some sleep. -Corey ------=_Part_22001_11095918.1229582308095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood <corey.osgood at gmail.com> wrote:
On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge <peter at stuge.se> wrote:
Corey Osgood wrote:
> would there be any problem with calling functions to enable mtrrs
> and the cache (if it's not already) from the end of disable_car()?

None whatsoever. Commit at will.

It didn't help, disable_car() already does essentially the same thing; disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between the stock bios and coreboot right now, the throughput for the stock bios is 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191, respectively (using ROMCC), with v3 it's 15 and 18. So something's not right somewhere. The other thing is that in v2 and v3, the CPU is only running at 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's probably the reason for the differing cache throughputs. Anyways, I'm diving into both v2 and v3 and trying to track down why this is running so slowly.

<insert happy dance here>

From the currently-running memtest86 on coreboot-v3:
L1 Cache:  128K   3265 MB/s
Memory  :  480M    240 MB/s

That's right, faster then v2 :) I've managed to coerce the northbridge into running the memory at 200MHz (DDR400) without locking up the system like it does in v2, and also to use 1GB of ram, which the fuctory BIOS only sees as 512MB, and v2 for some reason trips over. However, it's a mixed blessing, even though memtest86 now runs at an acceptable speed, coreboot is still running fairly slowly. I'm attaching a patch that brings over mtrr.c from v2 and hacks it to work with v3, but no sign-off because IMO it's not ready to be committed. I'll try booting a FILO payload and a kernel tomorrow, but right now it's time for some sleep.

-Corey
------=_Part_22001_11095918.1229582308095-- ------=_Part_22000_17087428.1229582308095 Content-Type: text/plain; name=cn700_speedup.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fov10po50 Content-Disposition: attachment; filename=cn700_speedup.patch SW5kZXg6IHNvdXRoYnJpZGdlL3ZpYS92dDgyMzcvc3RhZ2UxLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc291 dGhicmlkZ2UvdmlhL3Z0ODIzNy9zdGFnZTEuYwkocmV2aXNpb24gMTA3OCkKKysrIHNvdXRoYnJp ZGdlL3ZpYS92dDgyMzcvc3RhZ2UxLmMJKHdvcmtpbmcgY29weSkKQEAgLTE1NSw4ICsxNTUsOSBA QAogICovCiB2b2lkIGVuYWJsZV9zbWJ1cyh1MTYgc21idXNfaW9fYmFzZSkKIHsKLQl1MzIgZGV2 OworCXUzMiBkZXYgPSBQQ0lfQkRGKDAsIDE3LCAwKTsKIAorI2lmIDAKIAkvKiBQb3dlciBtYW5h Z2VtZW50IGNvbnRyb2xsZXIgKi8KIAlwY2lfY29uZjFfZmluZF9kZXZpY2UoUENJX1ZFTkRPUl9J RF9WSUEsIFBDSV9ERVZJQ0VfSURfVklBX1ZUODIzN1JfTFBDLCAKIAkJCQkmZGV2KTsKQEAgLTE3 OCw2ICsxNzksNyBAQAogCQlwcmludGsoQklPU19ERUJVRywgIlZUODIzN1IgUG93ZXIgbWFuYWdl bWVudCBjb250cm9sbGVyIGZvdW5kICIKIAkJCQkJCSJhdCAweCV4XG4iLCBkZXYpOwogCX0KKyNl bmRpZgogCiAJLyogNyA9IFNNQnVzIENsb2NrIGZyb20gUlRDIDMyLjc2OEtIegogCSAqIDUgPSBJ bnRlcm5hbCBQTEwgcmVzZXQgZnJvbSBzdXNwCkBAIC0yMDEsMzYgKzIwMywxNCBAQAogCWluYihz bWJ1c19pb19iYXNlICsgU01CSFNUQ1RMKTsKIH0KIAotLyogVGhlIGNoYW5nZSBmcm9tIFJBSUQg dG8gU0FUQSBpbiBwaGFzZTYgY2F1c2VzIGNvcmVib290IHRvIGxvY2sgdXAsIHNvIGRvIGl0Ci0g KiBhcyBlYXJseSBhcyBwb3NzaWJsZS4gTW92ZSBiYWNrIHRvIHN0YWdlMiBsYXRlciAqLyAKLXN0 YXRpYyB2b2lkIHNhdGFfc3RhZ2UxKHZvaWQpCi17Ci0JdTMyIGRldjsKLQl1OCByZWc7Ci0KLQlw Y2lfY29uZjFfZmluZF9kZXZpY2UoUENJX1ZFTkRPUl9JRF9WSUEsIFBDSV9ERVZJQ0VfSURfVklB X1ZUODIzN1JfU0FUQSwgJmRldik7Ci0KLQlwcmludGsoQklPU19ERUJVRywgIkNvbmZpZ3VyaW5n IFZJQSBTQVRBIGNvbnRyb2xsZXJcbiIpOwotCi0JLyogQ2xhc3MgSURFIERpc2sgKi8KLQlyZWcg PSBwY2lfY29uZjFfcmVhZF9jb25maWc4KGRldiwgU0FUQV9NSVNDX0NUUkwpOwotCXJlZyAmPSAw eDdmOwkJLyogU3ViIENsYXNzIFdyaXRlIFByb3RlY3Qgb2ZmICovCi0JcGNpX2NvbmYxX3dyaXRl X2NvbmZpZzgoZGV2LCBTQVRBX01JU0NfQ1RSTCwgcmVnKTsKLQotCS8qIENoYW5nZSB0aGUgZGV2 aWNlIGNsYXNzIHRvIFNBVEEgZnJvbSBSQUlELiAqLwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4 KGRldiwgUENJX0NMQVNTX0RFVklDRSwgMHgxKTsKLQlyZWcgfD0gMHg4MDsJCS8qIFN1YiBDbGFz cyBXcml0ZSBQcm90ZWN0IG9uICovCi0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgoZGV2LCBTQVRB X01JU0NfQ1RSTCwgcmVnKTsKLX0KLQogdm9pZCB2dDgyMzdfc3RhZ2UxKHUxNiBzbWJ1c19pb19i YXNlKQogewotCXUzMiBkZXY7CisJdTMyIGRldiA9IFBDSV9CREYoMCwgMTcsIDApOwogCXUzMiBp ZGVfZGV2OwogCQogCXByaW50ayhCSU9TX0RFQlVHLCAiRG9pbmcgdnQ4MjM3ci9zIHN0YWdlMSBp bml0XG4iKTsKIAotCXBjaV9jb25mMV9maW5kX2RldmljZSgweDExMDYsIDB4MzIyNywgJmRldik7 CisJLy9wY2lfY29uZjFfZmluZF9kZXZpY2UoMHgxMTA2LCAweDMyMjcsICZkZXYpOwogCXBjaV9j b25mMV9maW5kX2RldmljZSgweDExMDYsIDB4MDU3MSwgJmlkZV9kZXYpOwogCQogCS8qIERpc2Fi bGUgR1AzIHRpbWVyLCBvciBlbHNlIHRoZSBzeXN0ZW0gcmVib290cyB3aGVuIGl0IHJ1bnMgb3V0 LgpJbmRleDogbWFpbmJvYXJkL2pldHdheS9qN2YyL2R0cwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBtYWluYm9h cmQvamV0d2F5L2o3ZjIvZHRzCShyZXZpc2lvbiAxMDc4KQorKysgbWFpbmJvYXJkL2pldHdheS9q N2YyL2R0cwkod29ya2luZyBjb3B5KQpAQCAtNjYsNyArNjYsNyBAQAogCQkvKiBIb3cgZG8gSSBy ZXByZXNlbnQgdGhlIGJ1cyBhbmQgcGNpIGRldmljZXMgaGFuZ2luZyBoZXJlPyAqLwogCQlwY2lA MSwwIHsKIAkJCS9jb25maWcvKCJub3J0aGJyaWRnZS92aWEvY243MDAvcGNpLmR0cyIpOwotCQkJ cGNpQDAsMSB7CisJCQlwY2lAMCwwIHsKIAkJCQkvY29uZmlnLygibm9ydGhicmlkZ2UvdmlhL2Nu NzAwL3ZnYS5kdHMiKTsKIAkJCX07CiAJCX07CkluZGV4OiBub3J0aGJyaWRnZS92aWEvY243MDAv cGNpX2RvbWFpbi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG5vcnRoYnJpZGdlL3ZpYS9jbjcwMC9wY2lfZG9t YWluLmMJKHJldmlzaW9uIDEwNzgpCisrKyBub3J0aGJyaWRnZS92aWEvY243MDAvcGNpX2RvbWFp bi5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMDgsMTEgKzEwOCwxMiBAQAogCX0KIAkvKiBSZXBvcnQg dGhlIG1lbW9yeSByZWdpb25zLiAqLwogCWlkeCA9IDEwOwotCS8qIFRPRE86IEhvbGUgbmVlZGVk PyAqLwotCXJhbV9yZXNvdXJjZShkZXYsIGlkeCsrLCAwLCA2NDApOwkvKiBGaXJzdCA2NDBrICov CisKKwlyYW1fcmVzb3VyY2UoZGV2LCBpZHgrKywgMCwgNjQwKTsKIAkvKiBMZWF2ZSBhIGhvbGUg Zm9yIFZHQSwgMHhhMDAwMCAtIDB4YzAwMDAgKi8KLQlyYW1fcmVzb3VyY2UoZGV2LCBpZHgrKywg NzY4LAotCQkgICAgICh0b2xtayAtIDc2OCAtIChDT05GSUdfQ043MDBfVklERU9fTUIgKiAxMDI0 KSkpOworCS8qIFRPRE86IHNoYWRvdyByYW0gbmVlZHMgdG8gYmUgY29udHJvbGxlZCB2aWEgZHRz ICovCisJcmFtX3Jlc291cmNlKGRldiwgaWR4KyssIDEwMjQsCisJCSAgICAgKHRvbG1rIC0gMTAy NCAtIChDT05GSUdfQ043MDBfVklERU9fTUIgKiAxMDI0KSkpOwogCXBoYXNlNF9hc3NpZ25fcmVz b3VyY2VzKCZkZXYtPmxpbmtbMF0pOwogfQogCkBAIC0xMjksNSArMTMwLDMgQEAKIAkucGhhc2U2 X2luaXQJCQk9IDAsCiAJLm9wc19wY2lfYnVzCQkJPSAmcGNpX2NmOF9jb25mMSwKIH07Ci0KLQpJ bmRleDogbm9ydGhicmlkZ2UvdmlhL2NuNzAwL3N0YWdlMS5jCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG5vcnRo YnJpZGdlL3ZpYS9jbjcwMC9zdGFnZTEuYwkocmV2aXNpb24gMTA3OCkKKysrIG5vcnRoYnJpZGdl L3ZpYS9jbjcwMC9zdGFnZTEuYwkod29ya2luZyBjb3B5KQpAQCAtMjQsNTkgKzI0LDYgQEAKICNp bmNsdWRlIDxjb25maWcuaD4KICNpbmNsdWRlICJjbjcwMC5oIgogCi1zdGF0aWMgdm9pZCBlbmFi bGVfc2hhZG93X3JhbSh2b2lkKSAKLXsKLQl1OCBzaGFkb3dyZWc7Ci0KLQlwcmludGsoQklPU19E RUJVRywgIkVuYWJsaW5nIHNoYWRvdyByYW1cbiIpOwotCS8qIEVuYWJsZSBzaGFkb3cgcmFtIGFz IG5vcm1hbCBkcmFtICovCi0JLyogMHhjMDAwMC0weGNmZmZmICovCi0JcGNpX2NvbmYxX3dyaXRl X2NvbmZpZzgoUENJX0JERigwLCAwLCAzKSwgMHg4MCwgMHhmZik7Ci0JcGNpX2NvbmYxX3dyaXRl X2NvbmZpZzgoUENJX0JERigwLCAwLCA3KSwgMHg2MSwgMHhmZik7Ci0JLyogMHhkMDAwMC0weGRm ZmZmICovCi0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgoUENJX0JERigwLCAwLCAzKSwgMHg4MSwg MHhmZik7Ci0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgoUENJX0JERigwLCAwLCA3KSwgMHg2Miwg MHhmZik7Ci0JLyogMHhlMDAwMC0weGVmZmZmICovCi0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgo UENJX0JERigwLCAwLCAzKSwgMHg4MiwgMHhmZik7Ci0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgo UENJX0JERigwLCAwLCA3KSwgMHg2NCwgMHhmZik7Ci0KLQkvKiAweGYwMDAwLTB4ZmZmZmYgKi8K LQlzaGFkb3dyZWcgPSBwY2lfY29uZjFfcmVhZF9jb25maWc4KFBDSV9CREYoMCwgMCwgMyksIDB4 ODMpOwotCXNoYWRvd3JlZyB8PSAweDMwOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBDSV9C REYoMCwgMCwgMyksIDB4ODMsIHNoYWRvd3JlZyk7Ci0KLQkvKiBEbyBpdCBhZ2FpbiBmb3IgdGhl IHZsaW5rIGNvbnRyb2xsZXIgKi8KLQlzaGFkb3dyZWcgPSBwY2lfY29uZjFfcmVhZF9jb25maWc4 KFBDSV9CREYoMCwgMCwgNyksIDB4NjMpOwotCXNoYWRvd3JlZyB8PSAweDMwOwotCXBjaV9jb25m MV93cml0ZV9jb25maWc4KFBDSV9CREYoMCwgMCwgNyksIDB4NjMsIHNoYWRvd3JlZyk7Ci19Ci0K LXN0YXRpYyB2b2lkIGVuYWJsZV92bGluayh2b2lkKQotewotCXByaW50ayhCSU9TX0RFQlVHLCAi RW5hYmxpbmcgVmlhIFYtTGlua1xuIik7Ci0KLQlwY2lfY29uZjFfd3JpdGVfY29uZmlnOChQQ0lf QkRGKDAsIDAsIDcpLCAweDQyLCAweDg4KTsKLQlwY2lfY29uZjFfd3JpdGVfY29uZmlnOChQQ0lf QkRGKDAsIDAsIDcpLCAweDQ1LCAweDQ0KTsKLQlwY2lfY29uZjFfd3JpdGVfY29uZmlnOChQQ0lf QkRGKDAsIDAsIDcpLCAweDQ2LCAweDAwKTsKLQlwY2lfY29uZjFfd3JpdGVfY29uZmlnOChQQ0lf QkRGKDAsIDAsIDcpLCAweDQ3LCAweDA0KTsKLQkvL3BjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NDgsIDB4MTMpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NGIsIDB4ODApOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NGMsIDB4ODIpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NGQsIDB4NDQpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NGUsIDB4MDApOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4NGYsIDB4MDEpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjQsIDB4MzUpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjUsIDB4NjYpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjYsIDB4NjYpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjcsIDB4NjQpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjgsIDB4NDUpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YjksIDB4OTgpOwotCXBjaV9jb25mMV93cml0ZV9jb25maWc4KFBD SV9CREYoMCwgMCwgNyksIDB4YmEsIDB4NzcpOwotCi0JLyogVGhpcyBoYXMgdG8gYmUgZG9uZSBs YXN0LCBJIHRoaW5rICovCi0JcGNpX2NvbmYxX3dyaXRlX2NvbmZpZzgoUENJX0JERigwLCAwLCA3 KSwgMHg0OCwgMHgxMyk7Ci19Ci0KIC8qKgogICogQ29uZmlndXJlIHRoZSBidXMgYmV0d2VlbiB0 aGUgY3B1IGFuZCB0aGUgbm9ydGhicmlkZ2UuIFRoaXMgbWlnaHQgYmUgYWJsZSB0byAKICAqIGJl IG1vdmVkIHRvIHBvc3QtcmFtIGNvZGUgaW4gdGhlIGZ1dHVyZS4gRm9yIHRoZSBtb3N0IHBhcnQs IHRoZXNlIHJlZ2lzdGVycwpAQCAtOTIsNiArMzksNyBAQAogc3RhdGljIHZvaWQgYzdfY3B1X3Nl dHVwKHZvaWQpCiB7CiAJdTMyIGRldiA9IFBDSV9CREYoMCwgMCwgMik7CisJdTggcmVnODsKIAog CS8qIEhvc3QgYnVzIGludGVyZmFjZSByZWdpc3RlcnMgKEQwRjIgMHg1MC0weDY3KSAqLwogCS8q IFJlcXVlc3QgcGhhc2UgY29udHJvbCAqLwpAQCAtMTE0LDYgKzYyLDEzIEBACiAJICogICAgICAx MTAvMTExIDogUmVzZXJ2ZWQKIAkgKiBiaXRzIDQ6MDogUmVzZXJ2ZWQKIAkgKi8KKworCXJlZzgg PSBwY2lfY29uZjFfcmVhZF9jb25maWc4KGRldiwgMHg1Nyk7CisJcmVnOCAmPSAoMHg3IDw8IDUp OworCS8vcmVnOCB8PSAoMHg0IDw8IDUpOworCXJlZzggfD0gKDB4MyA8PCA1KTsKKwlwY2lfY29u ZjFfd3JpdGVfY29uZmlnOChkZXYsIDB4NTcsIHJlZzgpOworCQogCS8qIENQVSBNaXNjZWxsYW5l b3VzIENvbnRyb2wgKi8KIAlwY2lfY29uZjFfd3JpdGVfY29uZmlnOChkZXYsIDB4NTksIDB4NDQp OwogCS8qIFdyaXRlIFBvbGljeSAqLwpAQCAtMTc5LDcgKzEzNCw1IEBACiAJcGNpX2NvbmYxX3dy aXRlX2NvbmZpZzgoUENJX0JERigwLCAxLCAwKSwgMHgxOSwgMHgxKTsKIAlwY2lfY29uZjFfd3Jp dGVfY29uZmlnOChQQ0lfQkRGKDAsIDEsIDApLCAweDFhLCAweDEpOwogCi0JZW5hYmxlX3NoYWRv d19yYW0oKTsKLQllbmFibGVfdmxpbmsoKTsKIAljN19jcHVfc2V0dXAoKTsKIH0KSW5kZXg6IGFy Y2gveDg2L3ZpYS9jNy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGFyY2gveDg2L3ZpYS9jNy5jCShyZXZpc2lv biAxMDc4KQorKysgYXJjaC94ODYvdmlhL2M3LmMJKHdvcmtpbmcgY29weSkKQEAgLTIwMyw4ICsy MDMsOCBAQAogCiAJLyogU2V0IHVwIE1lbW9yeSBUeXBlIFJhbmdlIFJlZ2lzdGVycyAqLwogCS8v dGhlc2UgZG9uJ3QgZXhpc3QgeWV0Ci0JLy94ODZfc2V0dXBfbXRycnMoMzYpOwotCS8veDg2X210 cnJfY2hlY2soKTsKKwl4ODZfc2V0dXBfbXRycnMoMzYpOworCXg4Nl9tdHJyX2NoZWNrKCk7CiAK IAkvKiBFbmFibGUgdGhlIGxvY2FsIGNwdSBhcGljcyAqLwogCS8vc2V0dXBfbGFwaWMoKTsKSW5k ZXg6IGFyY2gveDg2L210cnIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhcmNoL3g4Ni9tdHJyLmMJKHJldmlz aW9uIDApCisrKyBhcmNoL3g4Ni9tdHJyLmMJKHJldmlzaW9uIDApCkBAIC0wLDAgKzEsNDQ5IEBA CisvKgorICogbXRyci5jOiBzZXR0aW5nIE1UUlIgdG8gZGVjZW50IHZhbHVlcyBmb3IgY2FjaGUg aW5pdGlhbGl6YXRpb24gb24gUDYKKyAqCisgKiBEZXJpdmVkIGZyb20gaW50ZWxfc2V0X210cnIg aW4gaW50ZWxfc3Vici5jIGFuZCBtdHJyLmMgaW4gbGludXgga2VybmVsCisgKgorICogQ29weXJp Z2h0IDIwMDAgU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbSBDb3Jwb3JhdGlvbgorICoKKyAqCVRo aXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQv b3IgbW9kaWZ5CisgKglpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1Ymxp YyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorICoJdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv bjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyAqCShhdCB5b3VyIG9wdGlv bikgYW55IGxhdGVyIHZlcnNpb24uCisgKgorICoJVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVk IGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisgKglidXQgV0lUSE9VVCBBTlkg V0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorICoJTUVSQ0hB TlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQor ICoJR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKglZ b3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg TGljZW5zZQorICoJYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhl IEZyZWUgU29mdHdhcmUKKyAqCUZvdW5kYXRpb24sIEluYy4sIDY3NSBNYXNzIEF2ZSwgQ2FtYnJp ZGdlLCBNQSAwMjEzOSwgVVNBLgorICoKKyAqCisgKiBSZWZlcmVuY2U6IEludGVsIEFyY2hpdGVj dHVyZSBTb2Z0d2FyZSBEZXZlbG9wZXIncyBNYW51YWwsIFZvbHVtZSAzOiBTeXN0ZW0gUHJvZ3Jh bW1pbmcKKyAqLworCisvKgorICAgICAgICAyMDA1LjEgeWhsdSBhZGQgTkMgc3VwcG9ydCB0byBz cGFyZSBtdHJycyBmb3IgNjRHIG1lbW9yeSBhYm92ZSBpbnN0YWxsZWQKKwkyMDA1LjYgRXJpYyBh ZGQgYWRkcmVzcyBiaXQgaW4geDg2X3NldHVwX210cnJzCisJMjAwNS42IHlobHUgc3BsaXQgeDg2 X3NldHVwX3Zhcl9tdHJycyBhbmQgeDg2X3NldHVwX2ZpeGVkX210cnJzLAorCQlmb3IgQU1ELCBp dCB3aWxsIG5vdCB1c2UgeDg2X3NldHVwX2ZpeGVkX210cnJzCisqLworCisjaW5jbHVkZSA8dHlw ZXMuaD4KKyNpbmNsdWRlIDxjb25zb2xlLmg+CisjaW5jbHVkZSA8YXJjaC94ODYvbXNyLmg+Cisj aW5jbHVkZSA8YXJjaC94ODYvbXRyci5oPgorI2luY2x1ZGUgPGFyY2gveDg2L2NwdS5oPgorCitz dGF0aWMgdW5zaWduZWQgaW50IG10cnJfbXNyW10gPSB7CisJTVRSUmZpeDY0S18wMDAwMF9NU1Is IE1UUlJmaXgxNktfODAwMDBfTVNSLCBNVFJSZml4MTZLX0EwMDAwX01TUiwKKwlNVFJSZml4NEtf QzAwMDBfTVNSLCBNVFJSZml4NEtfQzgwMDBfTVNSLCBNVFJSZml4NEtfRDAwMDBfTVNSLCBNVFJS Zml4NEtfRDgwMDBfTVNSLAorCU1UUlJmaXg0S19FMDAwMF9NU1IsIE1UUlJmaXg0S19FODAwMF9N U1IsIE1UUlJmaXg0S19GMDAwMF9NU1IsIE1UUlJmaXg0S19GODAwMF9NU1IsCit9OworCit2b2lk IGVuYWJsZV9maXhlZF9tdHJyKHZvaWQpCit7CisJc3RydWN0IG1zciBtc3I7CisKKwltc3IgPSBy ZG1zcihNVFJSZGVmVHlwZV9NU1IpOworCW1zci5sbyB8PSAweGMwMDsKKwl3cm1zcihNVFJSZGVm VHlwZV9NU1IsIG1zcik7Cit9CisKK3N0YXRpYyB2b2lkIGVuYWJsZV92YXJfbXRycih2b2lkKQor eworCXN0cnVjdCBtc3IgbXNyOworCisJbXNyID0gcmRtc3IoTVRSUmRlZlR5cGVfTVNSKTsKKwlt c3IubG8gfD0gMHg4MDA7CisJd3Jtc3IoTVRSUmRlZlR5cGVfTVNSLCBtc3IpOworfQorCisvKiBz ZXR0aW5nIHZhcmlhYmxlIG10cnIsIGNvbWVzIGZyb20gbGludXgga2VybmVsIHNvdXJjZSAqLwor c3RhdGljIHZvaWQgc2V0X3Zhcl9tdHJyX3N0YWdlMigKKwl1bnNpZ25lZCBpbnQgcmVnLCB1bnNp Z25lZCBsb25nIGJhc2VrLCB1bnNpZ25lZCBsb25nIHNpemVrLCAKKwl1bnNpZ25lZCBsb25nIHR5 cGUsIHVuc2lnbmVkIGFkZHJlc3NfYml0cykKK3sKKwlzdHJ1Y3QgbXNyIGJhc2UsIG1hc2s7CisJ dW5zaWduZWQgYWRkcmVzc19tYXNrX2hpZ2g7CisKKyAgICAgICAgaWYgKHJlZyA+PSA4KQorICAg ICAgICAgICAgICAgIHJldHVybjsKKworICAgICAgICAvLyBpdCBpcyByZWNvbW1lbmRlZCB0aGF0 IHdlIGRpc2FibGUgYW5kIGVuYWJsZSBjYWNoZSB3aGVuIHdlCisgICAgICAgIC8vIGRvIHRoaXMu CisgICAgICAgIGlmIChzaXplayA9PSAwKSB7CisgICAgICAgIAlkaXNhYmxlX2NhY2hlKCk7CisJ CisgICAgICAgICAgICAgICAgc3RydWN0IG1zciB6ZXJvOworICAgICAgICAgICAgICAgIHplcm8u bG8gPSB6ZXJvLmhpID0gMDsKKyAgICAgICAgICAgICAgICAvKiBUaGUgaW52YWxpZCBiaXQgaXMg a2VwdCBpbiB0aGUgbWFzaywgc28gd2Ugc2ltcGx5IGNsZWFyIHRoZQorICAgICAgICAgICAgICAg ICAgIHJlbGV2YW50IG1hc2sgcmVnaXN0ZXIgdG8gZGlzYWJsZSBhIHJhbmdlLiAqLworICAgICAg ICAgICAgICAgIHdybXNyIChNVFJScGh5c01hc2tfTVNSKHJlZyksIHplcm8pOworCisgICAgICAg IAllbmFibGVfY2FjaGUoKTsKKwkJcmV0dXJuOworICAgICAgICB9CisKKworCWFkZHJlc3NfbWFz a19oaWdoID0gKCgxdSA8PCAoYWRkcmVzc19iaXRzIC0gMzJ1KSkgLSAxdSk7CisKKwliYXNlLmhp ID0gYmFzZWsgPj4gMjI7CisJYmFzZS5sbyAgPSBiYXNlayA8PCAxMDsKKworCXByaW50ayhCSU9T X1NQRVcsICJBRERSRVNTX01BU0tfSElHSD0lI3hcbiIsIGFkZHJlc3NfbWFza19oaWdoKTsKKwor CWlmIChzaXplayA8IDQqMTAyNCoxMDI0KSB7CisJCW1hc2suaGkgPSBhZGRyZXNzX21hc2tfaGln aDsKKwkJbWFzay5sbyA9IH4oKHNpemVrIDw8IDEwKSAtMSk7CisJfQorCWVsc2UgeworCQltYXNr LmhpID0gYWRkcmVzc19tYXNrX2hpZ2ggJiAofigoc2l6ZWsgPj4gMjIpIC0xKSk7CisJCW1hc2su bG8gPSAwOworCX0KKworCS8vIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgd2UgZGlzYWJsZSBhbmQg ZW5hYmxlIGNhY2hlIHdoZW4gd2UgCisJLy8gZG8gdGhpcy4gCisJZGlzYWJsZV9jYWNoZSgpOwor CisJLyogQml0IDMyLTM1IG9mIE1UUlJwaHlzTWFzayBzaG91bGQgYmUgc2V0IHRvIDEgKi8KKwli YXNlLmxvIHw9IHR5cGU7CisJbWFzay5sbyB8PSAweDgwMDsKKwl3cm1zciAoTVRSUnBoeXNCYXNl X01TUihyZWcpLCBiYXNlKTsKKwl3cm1zciAoTVRSUnBoeXNNYXNrX01TUihyZWcpLCBtYXNrKTsK KworCWVuYWJsZV9jYWNoZSgpOworfQorCisvKiBmbXM6IGZpbmQgbW9zdCBzaWdpZmljYW50IGJp dCBzZXQsIHN0b2xlbiBmcm9tIExpbnV4IEtlcm5lbCBTb3VyY2UuICovCitzdGF0aWMgaW5saW5l IHVuc2lnbmVkIGludCBmbXModW5zaWduZWQgaW50IHgpCit7CisJaW50IHI7CisKKwlfX2FzbV9f KCJic3JsICUxLCUwXG5cdCIKKwkgICAgICAgICJqbnogMWZcblx0IgorCSAgICAgICAgIm1vdmwg JDAsJTBcbiIKKwkgICAgICAgICIxOiIgOiAiPXIiIChyKSA6ICJnIiAoeCkpOworCXJldHVybiBy OworfQorCisvKiBmbXM6IGZpbmQgbGVhc3Qgc2lnaWZpY2FudCBiaXQgc2V0ICovCitzdGF0aWMg aW5saW5lIHVuc2lnbmVkIGludCBmbHModW5zaWduZWQgaW50IHgpCit7CisJaW50IHI7CisKKwlf X2FzbV9fKCJic2ZsICUxLCUwXG5cdCIKKwkgICAgICAgICJqbnogMWZcblx0IgorCSAgICAgICAg Im1vdmwgJDMyLCUwXG4iCisJICAgICAgICAiMToiIDogIj1yIiAocikgOiAiZyIgKHgpKTsKKwly ZXR1cm4gcjsKK30KKworLyogc2V0dGluZyB1cCB2YXJpYWJsZSBhbmQgZml4ZWQgbXRycgorICoK KyAqIEZyb20gSW50ZWwgVm9sLiBJSUkgU2VjdGlvbiA5LjEyLjQsIHRoZSBSYW5nZSBTaXplIGFu ZCBCYXNlIEFsaWdubWVudCBoYXMgc29tZSBraW5kIG9mIHJlcXVpcmVtZW50OgorICoJMS4gVGhl IHJhbmdlIHNpemUgbXVzdCBiZSAyXk4gYnl0ZSBmb3IgTiA+PSAxMiAoaS5lIDRLQiBtaW5pbXVt KS4KKyAqCTIuIFRoZSBiYXNlIGFkZHJlc3MgbXVzdCBiZSAyXk4gYWxpZ25lZCwgd2hlcmUgdGhl IE4gaGVyZSBpcyBlcXVhbCB0byB0aGUgTiBpbiBwcmV2aW91cworICoJICAgcmVxdWlyZW1lbnQu IFNvIGEgOEsgcmFuZ2UgbXVzdCBiZSA4SyBhbGlnbmVkIG5vdCA0SyBhbGlnbmVkLgorICoKKyAq IFRoZXNlIHJlcXVpcmVtZW50IGlzIG1lZXQgYnkgImRlY29tcG9zaXRpbmciIHRoZSByYW1zaXpl IGludG8gU3VtKENuICogMl5uLCBuID0gWzAuLk5dLCBDbiA9IFswLCAxXSkuCisgKiBGb3IgQ20g PSAxLCB0aGVyZSBpcyBhIFdCIHJhbmdlIG9mIDJebSBzaXplIGF0IGJhc2UgYWRkcmVzcyBTdW0o Q20gKiAyXm0sIG0gPSBbTi4ubl0pLgorICogQSAxMjRNQiAoMTI4TUIgLSA0TUIgU01BKSBleGFt cGxlOgorICogCXJhbXNpemUgPSAxMjRNQiA9PSA2NE1CIChhdCAwTUIpICsgMzJNQiAoYXQgNjRN QikgKyAxNk1CIChhdCA5Nk1CICkgKyA4TUIgKGF0IDExMk1CKSArIDRNQiAoMTIwTUIpLgorICog QnV0IHRoaXMgd2FzdGVzIGEgbG90IG9mIE1UUlIgcmVnaXN0ZXJzIHNvIHdlIHVzZSBhbm90aGVy IG1vcmUgImFnZ3Jlc2l2ZSIgd2F5IHdpdGggVW5jYWNoZWFibGUgUmVnaW9ucy4KKyAqCisgKiBJ biB0aGUgVW5jYWNoZWFibGUgUmVnaW9uIHNjaGVtZSwgd2UgdHJ5IHRvIGNvdmVyIHRoZSB3aG9s ZSByYW1zaXplIGJ5IG9uZSBXQiByZWdpb24gYXMgcG9zc2libGUsCisgKiBJZiAoYW4gb25seSBp ZikgdGhpcyBjYW4gbm90IGJlIGRvbmUgd2Ugd2lsbCB0cnkgdG8gZGVjb21wb3NpdGUgdGhlIHJh bWVzaXplLCB0aGUgbWF0aGVtYXRpY2FsIGZvcm11bGEKKyAqIHdob3VsZCBiZSByYW1zaXplID0g U3VtKENuICogMl5uLCBuID0gWzAuLk5dLCBDbiA9IFstMSwgMCwgMV0pLiBGb3IgQ24gPSAtMSwg YSBVbmNhY2hhYmxlIFJlZ2lvbiBpcyB1c2VkLgorICogVGhlIHNhbWUgMTI0TUIgZXhhbXBsZToK KyAqIAlyYW1zaXplID0gMTI0TUIgPT0gMTI4TUIgV0IgKGF0IDBNQikgKyA0TUIgVUMgKGF0IDEy NE1CKQorICogb3IgYSAxNTZNQiAoMTI4TUIgKyAzMk1CIC0gNE1CIFNNQSkgZXhhbXBsZToKKyAq CXJhbXNpemUgPSAxNTZNQiA9PSAxMjhNQiBXQiAoYXQgME1CKSArIDMyTUIgV0IgKGF0IDEyOE1C KSArIDRNQiBVQyAoYXQgMTU2TUIpCisgKi8KKy8qIDIgTVRSUlMgYXJlIHJlc2VydmVkIGZvciB0 aGUgb3BlcmF0aW5nIHN5c3RlbSAqLworI2lmIDAKKyNkZWZpbmUgQklPU19NVFJSUyA2CisjZGVm aW5lIE9TX01UUlJTICAgMgorI2Vsc2UKKyNkZWZpbmUgQklPU19NVFJSUyA4CisjZGVmaW5lIE9T X01UUlJTICAgMAorI2VuZGlmCisjZGVmaW5lIE1UUlJTICAgICAgICAoQklPU19NVFJSUyArIE9T X01UUlJTKQorCitzdGF0aWMgdm9pZCBzZXRfZml4ZWRfbXRycnModW5zaWduZWQgaW50IGZpcnN0 LCB1bnNpZ25lZCBpbnQgbGFzdCwgdW5zaWduZWQgY2hhciB0eXBlKQoreworCXVuc2lnbmVkIGlu dCBpOworCXVuc2lnbmVkIGludCBmaXhlZF9tc3IgPSBOVU1fRklYRURfUkFOR0VTID4+IDM7CisJ c3RydWN0IG1zciBtc3I7CisJbXNyLmxvID0gbXNyLmhpID0gMDsgLyogU2h1dCB1cCBnY2MgKi8K Kwlmb3IoaSA9IGZpcnN0OyBpIDwgbGFzdDsgaSsrKSB7CisJCS8qIFdoZW4gSSBzd2l0Y2ggdG8g YSBuZXcgbXNyIHJlYWQgaXQgaW4gKi8KKwkJaWYgKGZpeGVkX21zciAhPSBpID4+IDMpIHsKKwkJ CS8qIEJ1dCBmaXJzdCB3cml0ZSBvdXQgdGhlIG9sZCBtc3IgKi8KKwkJCWlmIChmaXhlZF9tc3Ig PCAoTlVNX0ZJWEVEX1JBTkdFUyA+PiAzKSkgeworCQkJCWRpc2FibGVfY2FjaGUoKTsKKwkJCQl3 cm1zcihtdHJyX21zcltmaXhlZF9tc3JdLCBtc3IpOworCQkJCWVuYWJsZV9jYWNoZSgpOworCQkJ fQorCQkJZml4ZWRfbXNyID0gaT4+MzsKKwkJCW1zciA9IHJkbXNyKG10cnJfbXNyW2ZpeGVkX21z cl0pOworCQl9CisJCWlmICgoaSAmIDcpIDwgNCkgeworCQkJbXNyLmxvICY9IH4oMHhmZiA8PCAo KGkmMykqOCkpOworCQkJbXNyLmxvIHw9IHR5cGUgPDwgKChpJjMpKjgpOworCQl9IGVsc2Ugewor CQkJbXNyLmhpICY9IH4oMHhmZiA8PCAoKGkmMykqOCkpOworCQkJbXNyLmhpIHw9IHR5cGUgPDwg KChpJjMpKjgpOworCQl9CisJfQorCS8qIFdyaXRlIG91dCB0aGUgZmluYWwgbXNyICovCisJaWYg KGZpeGVkX21zciA8IChOVU1fRklYRURfUkFOR0VTID4+IDMpKSB7CisJCWRpc2FibGVfY2FjaGUo KTsKKwkJd3Jtc3IobXRycl9tc3JbZml4ZWRfbXNyXSwgbXNyKTsKKwkJZW5hYmxlX2NhY2hlKCk7 CisJfQorfQorCitzdGF0aWMgdW5zaWduZWQgZml4ZWRfbXRycl9pbmRleCh1bnNpZ25lZCBsb25n IGFkZHJrKQoreworCXVuc2lnbmVkIGluZGV4OworCWluZGV4ID0gKGFkZHJrIC0gMCkgPj4gNjsK KwlpZiAoaW5kZXggPj0gOCkgeworCQlpbmRleCA9ICgoYWRkcmsgLSA4KjY0KSA+PiA0KSArIDg7 CisJfQorCWlmIChpbmRleCA+PSAyNCkgeworCQlpbmRleCA9ICgoYWRkcmsgLSAoOCo2NCArIDE2 KjE2KSkgPj4gMikgKyAyNDsKKwl9CisJaWYgKGluZGV4ID4gTlVNX0ZJWEVEX1JBTkdFUykgewor CQlpbmRleCA9IE5VTV9GSVhFRF9SQU5HRVM7CisJfQorCXJldHVybiBpbmRleDsKK30KKworc3Rh dGljIHVuc2lnbmVkIGludCByYW5nZV90b19tdHJyKHVuc2lnbmVkIGludCByZWcsIAorCXVuc2ln bmVkIGxvbmcgcmFuZ2Vfc3RhcnRrLCB1bnNpZ25lZCBsb25nIHJhbmdlX3NpemVrLAorCXVuc2ln bmVkIGxvbmcgbmV4dF9yYW5nZV9zdGFydGssIHVuc2lnbmVkIGNoYXIgdHlwZSwgdW5zaWduZWQg YWRkcmVzc19iaXRzKQoreworCWlmICghcmFuZ2Vfc2l6ZWsgfHwgKHJlZyA+PSBCSU9TX01UUlJT KSkgeworCQlyZXR1cm4gcmVnOworCX0KKwl3aGlsZShyYW5nZV9zaXplaykgeworCQl1bnNpZ25l ZCBsb25nIG1heF9hbGlnbiwgYWxpZ247CisJCXVuc2lnbmVkIGxvbmcgc2l6ZWs7CisJCS8qIENv bXB1dGUgdGhlIG1heGltdW0gc2l6ZSBJIGNhbiBtYWtlIGEgcmFuZ2UgKi8KKwkJbWF4X2FsaWdu ID0gZmxzKHJhbmdlX3N0YXJ0ayk7CisJCWFsaWduID0gZm1zKHJhbmdlX3NpemVrKTsgCisJCWlm IChhbGlnbiA+IG1heF9hbGlnbikgeworCQkJYWxpZ24gPSBtYXhfYWxpZ247CisJCX0KKwkJc2l6 ZWsgPSAxIDw8IGFsaWduOworCQlwcmludGsoQklPU19ERUJVRywgIlNldHRpbmcgdmFyaWFibGUg TVRSUiAlZCwgYmFzZTogJTRkTUIsIHJhbmdlOiAlNGRNQiwgdHlwZSAlc1xuIiwKKwkJCXJlZywg cmFuZ2Vfc3RhcnRrID4+MTAsIHNpemVrID4+IDEwLAorCQkJKHR5cGU9PU1UUlJfVFlQRV9VTkNB Q0hFQUJMRSk/IlVDIjoKKwkJCSAgICAoKHR5cGU9PU1UUlJfVFlQRV9XUkJBQ0spPyJXQiI6Ik90 aGVyIikKKwkJCSk7CisJCXNldF92YXJfbXRycl9zdGFnZTIocmVnKyssIHJhbmdlX3N0YXJ0aywg c2l6ZWssIHR5cGUsIGFkZHJlc3NfYml0cyk7CisJCXJhbmdlX3N0YXJ0ayArPSBzaXplazsKKwkJ cmFuZ2Vfc2l6ZWsgLT0gc2l6ZWs7CisJCWlmIChyZWcgPj0gQklPU19NVFJSUykKKwkJCWJyZWFr OworCX0KKwlyZXR1cm4gcmVnOworfQorCitzdGF0aWMgdW5zaWduZWQgbG9uZyByZXNrKHU2NCB2 YWx1ZSkgCit7CisJdW5zaWduZWQgbG9uZyByZXN1bHRrOworCWlmICh2YWx1ZSA8ICgxVUxMIDw8 IDQyKSkgeworCQlyZXN1bHRrID0gdmFsdWUgPj4gMTA7CisJfQorCWVsc2UgeworCQlyZXN1bHRr ID0gMHhmZmZmZmZmZjsKKwl9CisJcmV0dXJuIHJlc3VsdGs7Cit9CisKK3N0YXRpYyB2b2lkIHNl dF9maXhlZF9tdHJyX3Jlc291cmNlKHZvaWQgKmdwLCBzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVj dCByZXNvdXJjZSAqcmVzKQoreworCXVuc2lnbmVkIGludCBzdGFydF9tdHJyOworCXVuc2lnbmVk IGludCBsYXN0X210cnI7CisJc3RhcnRfbXRyciA9IGZpeGVkX210cnJfaW5kZXgocmVzayhyZXMt PmJhc2UpKTsKKwlsYXN0X210cnIgID0gZml4ZWRfbXRycl9pbmRleChyZXNrKChyZXMtPmJhc2Ug KyByZXMtPnNpemUpKSk7CisJaWYgKHN0YXJ0X210cnIgPj0gTlVNX0ZJWEVEX1JBTkdFUykgewor CQlyZXR1cm47CisJfQorCXByaW50ayhCSU9TX0RFQlVHLCAiU2V0dGluZyBmaXhlZCBNVFJScygl ZC0lZCkgVHlwZTogV0JcbiIsCisJCXN0YXJ0X210cnIsIGxhc3RfbXRycik7CisJc2V0X2ZpeGVk X210cnJzKHN0YXJ0X210cnIsIGxhc3RfbXRyciwgTVRSUl9UWVBFX1dSQkFDSyk7CisJCit9CisK KyNpZm5kZWYgQ09ORklHX1ZBUl9NVFJSX0hPTEUKKyNkZWZpbmUgQ09ORklHX1ZBUl9NVFJSX0hP TEUgMQorI2VuZGlmCisKK3N0cnVjdCB2YXJfbXRycl9zdGF0ZSB7CisJdW5zaWduZWQgbG9uZyBy YW5nZV9zdGFydGssIHJhbmdlX3NpemVrOworCXVuc2lnbmVkIGludCByZWc7CisjaWYgQ09ORklH X1ZBUl9NVFJSX0hPTEUKKwl1bnNpZ25lZCBsb25nIGhvbGVfc3RhcnRrLCBob2xlX3NpemVrOwor I2VuZGlmCisJdW5zaWduZWQgYWRkcmVzc19iaXRzOworfTsKKwordm9pZCBzZXRfdmFyX210cnJf cmVzb3VyY2Uodm9pZCAqZ3AsIHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IHJlc291cmNlICpy ZXMpCit7CisJc3RydWN0IHZhcl9tdHJyX3N0YXRlICpzdGF0ZSA9IGdwOworCXVuc2lnbmVkIGxv bmcgYmFzZWssIHNpemVrOworCWlmIChzdGF0ZS0+cmVnID49IEJJT1NfTVRSUlMpCisJCXJldHVy bjsKKwliYXNlayA9IHJlc2socmVzLT5iYXNlKTsKKwlzaXplayA9IHJlc2socmVzLT5zaXplKTsK KwkvKiBTZWUgaWYgSSBjYW4gbWVyZ2Ugd2l0aCB0aGUgbGFzdCByYW5nZQorCSAqIEVpdGhlciBJ IGFtIGJlbG93IDFNIGFuZCB0aGUgZml4ZWQgbXRycnMgaGFuZGxlIGl0LCBvcgorCSAqIHRoZSBy YW5nZXMgdG91Y2guCisJICovCisJaWYgKChiYXNlayA8PSAxMDI0KSB8fCAoc3RhdGUtPnJhbmdl X3N0YXJ0ayArIHN0YXRlLT5yYW5nZV9zaXplayA9PSBiYXNlaykpIHsKKwkJdW5zaWduZWQgbG9u ZyBlbmRrID0gYmFzZWsgKyBzaXplazsKKwkJc3RhdGUtPnJhbmdlX3NpemVrID0gZW5kayAtIHN0 YXRlLT5yYW5nZV9zdGFydGs7CisJCXJldHVybjsKKwl9CisJLyogV3JpdGUgdGhlIHJhbmdlIG10 cnJzICovCisJaWYgKHN0YXRlLT5yYW5nZV9zaXplayAhPSAwKSB7CisjaWYgQ09ORklHX1ZBUl9N VFJSX0hPTEUKKwkJaWYgKHN0YXRlLT5ob2xlX3NpemVrID09IDApIHsKKwkJCS8qIFdlIG5lZWQg dG8gcHV0IHRoYXQgb24gdG8gaG9sZSAqLworCQkJdW5zaWduZWQgbG9uZyBlbmRrID0gYmFzZWsg KyBzaXplazsKKwkJCXN0YXRlLT5ob2xlX3N0YXJ0ayA9IHN0YXRlLT5yYW5nZV9zdGFydGsgKyBz dGF0ZS0+cmFuZ2Vfc2l6ZWs7CisJCQlzdGF0ZS0+aG9sZV9zaXplayAgPSBiYXNlayAtIHN0YXRl LT5ob2xlX3N0YXJ0azsKKwkJCXN0YXRlLT5yYW5nZV9zaXplayA9IGVuZGsgLSBzdGF0ZS0+cmFu Z2Vfc3RhcnRrOworCQkJcmV0dXJuOworCQl9CisjZW5kaWYKKwkJc3RhdGUtPnJlZyA9IHJhbmdl X3RvX210cnIoc3RhdGUtPnJlZywgc3RhdGUtPnJhbmdlX3N0YXJ0aywgCisJCQlzdGF0ZS0+cmFu Z2Vfc2l6ZWssIGJhc2VrLCBNVFJSX1RZUEVfV1JCQUNLLCBzdGF0ZS0+YWRkcmVzc19iaXRzKTsK KyNpZiBDT05GSUdfVkFSX01UUlJfSE9MRQorCQlzdGF0ZS0+cmVnID0gcmFuZ2VfdG9fbXRycihz dGF0ZS0+cmVnLCBzdGF0ZS0+aG9sZV9zdGFydGssIAorCQkJc3RhdGUtPmhvbGVfc2l6ZWssIGJh c2VrLCAgTVRSUl9UWVBFX1VOQ0FDSEVBQkxFLCBzdGF0ZS0+YWRkcmVzc19iaXRzKTsKKyNlbmRp ZgorCQlzdGF0ZS0+cmFuZ2Vfc3RhcnRrID0gMDsKKwkJc3RhdGUtPnJhbmdlX3NpemVrID0gMDsK KyNpZiBDT05GSUdfVkFSX01UUlJfSE9MRQorICAgICAgICAgICAgICAgIHN0YXRlLT5ob2xlX3N0 YXJ0ayA9IDA7CisgICAgICAgICAgICAgICAgc3RhdGUtPmhvbGVfc2l6ZWsgPSAwOworI2VuZGlm CisJfQorCS8qIEFsbG9jYXRlIGFuIG1zciAqLyAgCisJcHJpbnRrKEJJT1NfU1BFVywgIiBBbGxv Y2F0ZSBhbiBtc3IgLSBiYXNlayA9ICUwOHgsIHNpemVrID0gJTA4eCxcbiIsIGJhc2VrLCBzaXpl ayk7CisJc3RhdGUtPnJhbmdlX3N0YXJ0ayA9IGJhc2VrOworCXN0YXRlLT5yYW5nZV9zaXplayAg PSBzaXplazsKK30KKwordm9pZCB4ODZfc2V0dXBfZml4ZWRfbXRycnModm9pZCkKK3sKKyAgICAg ICAgLyogVHJ5IHRoaXMgdGhlIHNpbXBsZSB3YXkgb2YgaW5jcmVtZW50YWxseSBhZGRpbmcgdG9n ZXRoZXIKKyAgICAgICAgICogbXRycnMuICBJZiB0aGlzIGRvZXNuJ3Qgd29yayBvdXQgd2UgY2Fu IGdldCBzbWFydCBhZ2FpbiAKKyAgICAgICAgICogYW5kIGNsZWFyIG91dCB0aGUgbXRycnMuCisg ICAgICAgICAqLworCisgICAgICAgIHByaW50ayhCSU9TX0RFQlVHLCAiXG4iKTsKKyAgICAgICAg LyogSW5pdGlhbGl6ZWQgdGhlIGZpeGVkX210cnJzIHRvIHVuY2FjaGVkICovCisgICAgICAgIHBy aW50ayhCSU9TX0RFQlVHLCAiU2V0dGluZyBmaXhlZCBNVFJScyglZC0lZCkgVHlwZTogVUNcbiIs CisJICAgICAgICAwLCBOVU1fRklYRURfUkFOR0VTKTsKKyAgICAgICAgc2V0X2ZpeGVkX210cnJz KDAsIE5VTV9GSVhFRF9SQU5HRVMsIE1UUlJfVFlQRV9VTkNBQ0hFQUJMRSk7CisKKyAgICAgICAg LyogTm93IHNlZSB3aGljaCBvZiB0aGUgZml4ZWQgbXRycnMgY292ZXIgcmFtLgorICAgICAgICAg ICAgICAgICAqLworICAgICAgICBzZWFyY2hfZ2xvYmFsX3Jlc291cmNlcygKKwkJSU9SRVNPVVJD RV9NRU0gfCBJT1JFU09VUkNFX0NBQ0hFQUJMRSwgSU9SRVNPVVJDRV9NRU0gfCBJT1JFU09VUkNF X0NBQ0hFQUJMRSwKKwkJc2V0X2ZpeGVkX210cnJfcmVzb3VyY2UsIE5VTEwpOworICAgICAgICBw cmludGsoQklPU19ERUJVRywgIkRPTkUgZml4ZWQgTVRSUnNcbiIpOworCisgICAgICAgIC8qIGVu YWJsZSBmaXhlZCBNVFJSICovCisgICAgICAgIHByaW50ayhCSU9TX1NQRVcsICJjYWxsIGVuYWJs ZV9maXhlZF9tdHJyKClcbiIpOworICAgICAgICBlbmFibGVfZml4ZWRfbXRycigpOworCit9Cit2 b2lkIHg4Nl9zZXR1cF92YXJfbXRycnModW5zaWduZWQgYWRkcmVzc19iaXRzKQorLyogdGhpcyBy b3V0aW5lIG5lZWRzIHRvIGtub3cgaG93IG1hbnkgYWRkcmVzcyBiaXRzIGEgZ2l2ZW4gcHJvY2Vz c29yCisgKiBzdXBwb3J0cy4gIENQVXMgZ2V0IGdydW1weSB3aGVuIHlvdSBzZXQgdG9vIG1hbnkg Yml0cyBpbiAKKyAqIHRoZWlyIG10cnIgcmVnaXN0ZXJzIDooICBJIHdvdWxkIGdlbmVyaWNhbGx5 IGNhbGwgY3B1aWQgaGVyZQorICogYW5kIGZpbmQgb3V0IGhvdyBtYW55IHBoeXNpY2FsbHkgc3Vw cG9ydGVkIGJ1dCBzb21lIGNwdXMgYXJlCisgKiBidWdneSwgYW5kIHJlcG9ydCBtb3JlIGJpdHMg dGhlbiB0aGV5IGFjdHVhbGx5IHN1cHBvcnQuCisgKi8KK3sKKwkvKiBUcnkgdGhpcyB0aGUgc2lt cGxlIHdheSBvZiBpbmNyZW1lbnRhbGx5IGFkZGluZyB0b2dldGhlcgorCSAqIG10cnJzLiAgSWYg dGhpcyBkb2Vzbid0IHdvcmsgb3V0IHdlIGNhbiBnZXQgc21hcnQgYWdhaW4gCisJICogYW5kIGNs ZWFyIG91dCB0aGUgbXRycnMuCisJICovCisJc3RydWN0IHZhcl9tdHJyX3N0YXRlIHZhcl9zdGF0 ZTsKKworCS8qIENhY2hlIGFzIG1hbnkgbWVtb3J5IGFyZWFzIGFzIHBvc3NpYmxlICovCisJLyog RklYTUUgaXMgdGhlcmUgYW4gYWxnb3JpdGhtIGZvciBjb21wdXRpbmcgdGhlIG9wdGltYWwgc2V0 IG9mIG10cnJzPyAKKwkgKiBJbiBzb21lIGNhc2VzIGl0IGlzIGRlZmluaXRlbHkgcG9zc2libGUg dG8gZG8gYmV0dGVyLgorCSAqLworCXZhcl9zdGF0ZS5yYW5nZV9zdGFydGsgPSAwOworCXZhcl9z dGF0ZS5yYW5nZV9zaXplayA9IDA7CisjaWYgQ09ORklHX1ZBUl9NVFJSX0hPTEUKKwl2YXJfc3Rh dGUuaG9sZV9zdGFydGsgPSAwOworCXZhcl9zdGF0ZS5ob2xlX3NpemVrID0gMDsKKyNlbmRpZgor CXZhcl9zdGF0ZS5yZWcgPSAwOworCXZhcl9zdGF0ZS5hZGRyZXNzX2JpdHMgPSBhZGRyZXNzX2Jp dHM7CisJc2VhcmNoX2dsb2JhbF9yZXNvdXJjZXMoCisJCUlPUkVTT1VSQ0VfTUVNIHwgSU9SRVNP VVJDRV9DQUNIRUFCTEUsIElPUkVTT1VSQ0VfTUVNIHwgSU9SRVNPVVJDRV9DQUNIRUFCTEUsCisJ CXNldF92YXJfbXRycl9yZXNvdXJjZSwgJnZhcl9zdGF0ZSk7CisKKwkvKiBXcml0ZSB0aGUgbGFz dCByYW5nZSAqLworCXZhcl9zdGF0ZS5yZWcgPSByYW5nZV90b19tdHJyKHZhcl9zdGF0ZS5yZWcs IHZhcl9zdGF0ZS5yYW5nZV9zdGFydGssIAorCQl2YXJfc3RhdGUucmFuZ2Vfc2l6ZWssIDAsIE1U UlJfVFlQRV9XUkJBQ0ssIHZhcl9zdGF0ZS5hZGRyZXNzX2JpdHMpOworI2lmIENPTkZJR19WQVJf TVRSUl9IT0xFCisJdmFyX3N0YXRlLnJlZyA9IHJhbmdlX3RvX210cnIodmFyX3N0YXRlLnJlZywg dmFyX3N0YXRlLmhvbGVfc3RhcnRrLAorCQl2YXJfc3RhdGUuaG9sZV9zaXplaywgIDAsIE1UUlJf VFlQRV9VTkNBQ0hFQUJMRSwgdmFyX3N0YXRlLmFkZHJlc3NfYml0cyk7CisjZW5kaWYKKwlwcmlu dGsoQklPU19ERUJVRywgIkRPTkUgdmFyaWFibGUgTVRSUnNcbiIpOworCXByaW50ayhCSU9TX0RF QlVHLCAiQ2xlYXIgb3V0IHRoZSBleHRyYSBNVFJSJ3NcbiIpOworCS8qIENsZWFyIG91dCB0aGUg ZXh0cmEgTVRSUidzICovCisJd2hpbGUodmFyX3N0YXRlLnJlZyA8IE1UUlJTKSB7CisJCXNldF92 YXJfbXRycl9zdGFnZTIodmFyX3N0YXRlLnJlZysrLCAwLCAwLCAwLCB2YXJfc3RhdGUuYWRkcmVz c19iaXRzKTsKKwl9CisJcHJpbnRrKEJJT1NfU1BFVywgImNhbGwgZW5hYmxlX3Zhcl9tdHJyKClc biIpOworCWVuYWJsZV92YXJfbXRycigpOworCXByaW50ayhCSU9TX1NQRVcsICJMZWF2ZSAlc1xu IiwgX19GVU5DVElPTl9fKTsKKwlwb3N0X2NvZGUoMHg2QSk7Cit9CisKK3ZvaWQgeDg2X3NldHVw X210cnJzKHVuc2lnbmVkIGFkZHJlc3NfYml0cykKK3sKKwl4ODZfc2V0dXBfZml4ZWRfbXRycnMo KTsKKwl4ODZfc2V0dXBfdmFyX210cnJzKGFkZHJlc3NfYml0cyk7Cit9CisKKworaW50IHg4Nl9t dHJyX2NoZWNrKHZvaWQpCit7CisJLyogT25seSBQZW50aXVtIFBybyBhbmQgbGF0ZXIgaGF2ZSBN VFJSICovCisJc3RydWN0IG1zciBtc3I7CisJcHJpbnRrKEJJT1NfREVCVUcsICJcbk1UUlIgY2hl Y2tcbiIpOworCisJbXNyID0gcmRtc3IoMHgyZmYpOworCW1zci5sbyA+Pj0gMTA7CisKKwlwcmlu dGsoQklPU19ERUJVRywgIkZpeGVkIE1UUlJzICAgOiAiKTsKKwlpZiAobXNyLmxvICYgMHgwMSkK KwkJcHJpbnRrKEJJT1NfREVCVUcsICJFbmFibGVkXG4iKTsKKwllbHNlCisJCXByaW50ayhCSU9T X0RFQlVHLCAiRGlzYWJsZWRcbiIpOworCisJcHJpbnRrKEJJT1NfREVCVUcsICJWYXJpYWJsZSBN VFJSczogIik7CisJaWYgKG1zci5sbyAmIDB4MDIpCisJCXByaW50ayhCSU9TX0RFQlVHLCAiRW5h YmxlZFxuIik7CisJZWxzZQorCQlwcmludGsoQklPU19ERUJVRywgIkRpc2FibGVkXG4iKTsKKwor CXByaW50ayhCSU9TX0RFQlVHLCAiXG4iKTsKKworCXBvc3RfY29kZSgweDkzKTsKKwlyZXR1cm4g KChpbnQpIG1zci5sbyk7Cit9CkluZGV4OiBhcmNoL3g4Ni9NYWtlZmlsZQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBhcmNoL3g4Ni9NYWtlZmlsZQkocmV2aXNpb24gMTA3OCkKKysrIGFyY2gveDg2L01ha2VmaWxl CSh3b3JraW5nIGNvcHkpCkBAIC0yMDUsNyArMjA1LDcgQEAKIAogU1RBR0UyX0FSQ0hfWDg2X1NS QyAgPSBhcmNodGFibGVzLmMgY29yZWJvb3RfdGFibGUuYyBtdWx0aWJvb3QuYyB1ZGVsYXlfaW8u YwogU1RBR0UyX0FSQ0hfWDg2X1NSQyArPSBwY2lfb3BzX2F1dG8uYyBwY2lfb3BzX2NvbmYxLmMg Ci1TVEFHRTJfQVJDSF9YODZfU1JDICs9IGtleWJvYXJkLmMgaTgyNTkuYyBpc2EtZG1hLmMKK1NU QUdFMl9BUkNIX1g4Nl9TUkMgKz0ga2V5Ym9hcmQuYyBpODI1OS5jIGlzYS1kbWEuYyBtdHJyLmMK IAogaWZlcSAoJChDT05GSUdfUElSUV9UQUJMRSkseSkKIFNUQUdFMl9BUkNIX1g4Nl9TUkMgKz0g cGlycV9yb3V0aW5nLmMK ------=_Part_22000_17087428.1229582308095-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: or some such. This might even be caused by my high tables patch from recently, but it looks like a bug to me. >>> However, a subtractive setup is not always more efficient. >>> >>> >> Is it not? It sounds like at least if we have 2^x bytes of memory and >> subtract a small chunk or two, we would be quite well off with it. >> >> > > Assuming you don't have anything you want to cache near 4 GB (like flash): > Both strategies are equally efficient if the contiguous cacheable area > has a size of 2^n+2^(n-1). > The additive strategy is more efficient if the size is 2^n+2^(n-k) and k>1. > The subtractive strategy is more efficient if the size is 2^n-2^(n-k) > and k>1. > > I hope that you accept this without a detailed mathematical proof. ;-) > So in a setup with 2 equally sized DIMMs or only one DIMM, and possibly UMA the subtractive method will always be the way to go. > >>> That means we >>> have to select the best setup type. I devised a slightly tricky >>> algorithm to do that: >>> 1. Check if there are multiple disjoint cached areas in a given >>> power-of-two sized area. >>> 1a. If no, go to step 2 >>> 1b. If yes, stop here. Need advanced setup not described here. >>> >>> >>> >> please describe ;) >> >> > > 1b. Take the largest contiguous power-of-2 sized natually aligned chunk. > Use additive setup for that chunk. Look at the remaining area. Does it > still contain two disjoint chunks? If yes, go to 1b. If no, go to 2. > > > >>> 2. additive_count=bitcount(top_cached_addr+1) >>> 3. >>> subtractive_count=bitcount(rounduptonextpowerof2(top_cached_addr)-(top_cached_addr+1)) >>> 4. if (additive_count>subtractive_count) go to subtractive_method else >>> go to additive_method >>> >>> >>> >> Yes, sounds good. >> >> > > Glad to hear that. I hope the rest of the algorithm is OK for you as well. > Thinking about it again I'm not sure we're ever going to see multiple disjoint cached areas in a given 2^x sized area. That would be... UMA in the middle of the memory or something? Uh.. or more than 4G of memory? -- 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 bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Signed-off-by: Peter Stuge Acked-by: Peter Stuge Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2009-01-26 03:23:50 UTC (rev 3912) +++ trunk/util/flashrom/flash.h 2009-01-26 03:37:40 UTC (rev 3913) @@ -523,6 +523,7 @@ int spi_disable_blockprotect(void); void spi_byte_program(int address, uint8_t byte); int spi_nbyte_read(int address, uint8_t *bytes, int len); +int spi_aai_write(struct flashchip *flash, uint8_t *buf); /* 82802ab.c */ int probe_82802ab(struct flashchip *flash); Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2009-01-26 03:23:50 UTC (rev 3912) +++ trunk/util/flashrom/flashchips.c 2009-01-26 03:37:40 UTC (rev 3913) @@ -1128,6 +1128,20 @@ { .vendor = "SST", + .name = "SST25VF040B.REMS", + .manufacture_id = 0xbf, + .model_id = 0x8d, + .total_size = 512, + .page_size = 64*1024, + .tested = TEST_OK_PR, + .probe = probe_spi_rems, + .erase = spi_chip_erase_c7, + .write = spi_chip_aai_write, + .read = spi_chip_read, + }, + + { + .vendor = "SST", .name = "SST25VF080B", .manufacture_id = SST_ID, .model_id = SST_25VF080B, Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2009-01-26 03:23:50 UTC (rev 3912) +++ trunk/util/flashrom/spi.c 2009-01-26 03:37:40 UTC (rev 3913) @@ -615,3 +615,29 @@ return 1; } + +int spi_aai_write(struct flashchip *flash, uint8_t *buf) { + uint32_t pos = 2, size = flash->total_size * 1024; + unsigned char w[6] = {0xad, 0, 0, 0, buf[0], buf[1]}; + switch (flashbus) { + case BUS_TYPE_WBSIO_SPI: + fprintf(stderr, "%s: impossible with Winbond SPI masters, degrading to byte program\n", __func__); + return spi_chip_write(flash, buf); + default: + break; + } + flash->erase(flash); + spi_write_enable(); + spi_command(6, 0, w, NULL); + while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP) + myusec_delay(5); /* SST25VF040B Tbp is max 10us */ + while (pos < size) { + w[1] = buf[pos++]; + w[2] = buf[pos++]; + spi_command(3, 0, w, NULL); + while (spi_read_status_register() & JEDEC_RDSR_BIT_WIP) + myusec_delay(5); /* SST25VF040B Tbp is max 10us */ + } + spi_write_disable(); + return 0; +} From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: etherboot folks. They had coreboot support in etherboot, but it has not (yet?) been implemented in gPXE. With libpayload, this might actually be a lot easier now that it would have been. Thanks, Ward. -- Ward Vandewege Free Software Foundation - Senior Systems Administrator From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: struct lb_memory_range { struct lb_uint64 start; struct lb_uint64 size; uint32_t type; #define LB_MEM_RAM 1 /* Memory anyone can use */ #define LB_MEM_RESERVED 2 /* Don't use this memory region */ #define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */ }; And the e820 looks like: #define E820_RAM 1 #define E820_RESERVED 2 #define E820_ACPI 3 #define E820_NVS 4 #define E820_UNUSABLE 5 struct e820entry { u64 start; u64 size; u32 type; }; So, SeaBIOS just copies the info over (with special handling for LB_MEM_TABLE). -Kevin From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: Signed-off-by: Carl-Daniel Hailfinger Index: flashrom-unneeded_volatile/sst28sf040.c =================================================================== --- flashrom-unneeded_volatile/sst28sf040.c (Revision 3971) +++ flashrom-unneeded_volatile/sst28sf040.c (Arbeitskopie) @@ -32,8 +32,7 @@ static __inline__ void protect_28sf040(volatile uint8_t *bios) { - /* ask compiler not to optimize this */ - volatile uint8_t tmp; + uint8_t tmp; tmp = readb(bios + 0x1823); tmp = readb(bios + 0x1820); @@ -46,8 +45,7 @@ static __inline__ void unprotect_28sf040(volatile uint8_t *bios) { - /* ask compiler not to optimize this */ - volatile uint8_t tmp; + uint8_t tmp; tmp = readb(bios + 0x1823); tmp = readb(bios + 0x1820); -- http://www.hailfinger.org/ --------------020309010001020702000905 Content-Type: text/plain; name="flashrom_unneeded_volatile.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="flashrom_unneeded_volatile.diff" SW5kZXg6IGZsYXNocm9tLXVubmVlZGVkX3ZvbGF0aWxlL3NzdDI4c2YwNDAuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBmbGFzaHJvbS11bm5lZWRlZF92b2xhdGlsZS9zc3QyOHNmMDQwLmMJKFJl dmlzaW9uIDM5NzEpCisrKyBmbGFzaHJvbS11bm5lZWRlZF92b2xhdGlsZS9zc3QyOHNmMDQw LmMJKEFyYmVpdHNrb3BpZSkKQEAgLTMyLDggKzMyLDcgQEAKIAogc3RhdGljIF9faW5saW5l X18gdm9pZCBwcm90ZWN0XzI4c2YwNDAodm9sYXRpbGUgdWludDhfdCAqYmlvcykKIHsKLQkv KiBhc2sgY29tcGlsZXIgbm90IHRvIG9wdGltaXplIHRoaXMgKi8KLQl2b2xhdGlsZSB1aW50 OF90IHRtcDsKKwl1aW50OF90IHRtcDsKIAogCXRtcCA9IHJlYWRiKGJpb3MgKyAweDE4MjMp OwogCXRtcCA9IHJlYWRiKGJpb3MgKyAweDE4MjApOwpAQCAtNDYsOCArNDUsNyBAQAogCiBz dGF0aWMgX19pbmxpbmVfXyB2b2lkIHVucHJvdGVjdF8yOHNmMDQwKHZvbGF0aWxlIHVpbnQ4 X3QgKmJpb3MpCiB7Ci0JLyogYXNrIGNvbXBpbGVyIG5vdCB0byBvcHRpbWl6ZSB0aGlzICov Ci0Jdm9sYXRpbGUgdWludDhfdCB0bXA7CisJdWludDhfdCB0bXA7CiAKIAl0bXAgPSByZWFk YihiaW9zICsgMHgxODIzKTsKIAl0bXAgPSByZWFkYihiaW9zICsgMHgxODIwKTsK --------------020309010001020702000905-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: snapshot version=20 http://tracker.coreboot.org/trac/coreboot/changeset/latest/trunk/coreboo t-v2?old_path=3D%2F&format=3Dzip (text: ... You can also download the = most current snapshot directly.) does not contain the complete source thus is causing 'buildingtarget' to fail. I just did a file diff, it is missing 91 files from the util directory. =20 Meanwhile, If I get it from http://qa.coreboot.org/ ->=20 http://qa.coreboot.org/snapshots/coreboot-v2-3973.tar.bz2 , I am was able to do 'buildtarget' and 'gmake' for example, on serengeti_cheetah_fam10 fine. =20 Is there a reason to keep both mechanism ? It seems like=20 http://qa.coreboot.org/ is a better way to go, since it also doing regression build on every svn checkin. =20 =20 Best Regards, =20 Vincent Lim SimNow Team Performance CoE Central Engineering T 512.602.1618 F 512.602.7745 =20 =20 ------_=_NextPart_002_01C99E7E.C33FC9BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All:

 

From http://www.coreboot.org/Download_coreboot = page, I discovered that snapshot version http://tracker.coreboot.org/= trac/coreboot/changeset/latest/trunk/coreboot-v2?old_path=3D%2F&forma= t=3Dzip (text: ... You can also download the most current snapshot directly.) =  does not contain the complete source thus is causing 'buildingtarget' to = fail. I just did a file diff, it is missing 91 files from the util = directory.

 

Meanwhile, If I get it from http://qa.coreboot.org/ -> http:/= /qa.coreboot.org/snapshots/coreboot-v2-3973.tar.bz2, I am was able to do 'buildtarget' and 'gmake' for example, on = serengeti_cheetah_fam10 fine.

 

Is there a reason to keep both mechanism ? It seems = like http://qa.coreboot.org/ is a better = way to go, since it also doing regression build on every svn = checkin.

 

 

Best Regards,

 

Vincent Lim
SimNow Team

Performance CoE
Central Engineering
T 512.602.1618
F 512.602.7745

3D"fusion_sig_file"

 

------_=_NextPart_002_01C99E7E.C33FC9BB-- ------_=_NextPart_001_01C99E7E.C33FC9BB Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhIAFhAPcAAJSTiu/t1jY3NaSkmu7s1URFRerq6oODe6GiooqLg5SUle7t5d7czPTx2dHR 0YKDg9LRwtXV1s7Nvunm1Lm5rdbUxSYnJcDBwaysobm5ubGxpU1NScXEtvX079rYyHt7c769sMnI utTu5aKhluzr4aqqn/z8/LW1qe7s4nR0bOnm0u3t7fr6+ubl2Xp6emRkZPLy8qysrFJSTcrKyvTy 7NrYxMLBtOvq3/z53ujm2vT09Nzayfn49Obj0ezp1J6dkfn23NjWxhcXF1lZWu/v5lxbVWxsZfLx 62FhWrW1tuLg0eDg4Ovo0/Hu18HAs3V1dezp3uXi0MbGuPf38mxsbOLfzuXl5bCuo5uajurn0+rp 3r+/sujk0pmakP/+4uThz/j38uTj1vb270pLRp2elM3KufLx7JCQh/f39+Th0OPgzsvKvAAAAPb1 8Pj486mpqezq0urn1Lu7rujl0fb29qCekefk0tPRvVRVUPX08d3bzNDPwefk1sjGtcTExOzo1Oro 3Hl2bvPw2PLv1+zp08vItu/s1sPCtdTTxL28r/Dw5+Pj4+DezPHw6PPy6s7NumlnYXh4b8zLvYGB dtnXyO7r1vbz2uDf0Li3q7OyqA4ODu3r1Ojn3PTx3Pf18oiIf+nnzri2pLCunebj0vf03Onn2vX2 8Ovq4N/ezj8/P+fo3NTSw+jp3rSzqLu5p8PBr7y6qdDNurm4qt3cy+Dexu3q1tbUw+flzOTi08XD sfHy6ainm+nm0eXiyqemluLg0yAgHzMzMAUHCACZZubk0PPy7Ofl0f7+/vLy7PLy7eLfzfHx68jH ud/f3/Hx6PPy7b/l2c/Ov+/v8ECzjGC/oNnZ2Z/ZxX/Msu/59evq3ufk0RCfcDCsg+Th0vHy67W0 rqennYyMje/s2MPEtby7uubk0efl0PTz7pyckkdHQ/r69rm4s7q4tbi3sv//6H5+dtPSwywsK09P TOfm0ZeXjfTz7cfGse3q05+floCAeMjIuVhYUo+OgnBvaIaFff///yH/C01TT0ZGSUNFOS4wFwAA AAttc09QTVNPRkZJQ0U5LjBCPKT1ACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIAAAAD SABzvAAsAAAAACABYQAACP8A/wkcSLCgwYMIEypcyLChw4cQI0qcSLGixYsYM2rcyLGjx48Vj4k0 YYIFCzQoU5okKfIYyJcwY8qcSXPiyJM6YKywsqRaBAdAHUSotsTKChg60LAwIbKm06dQo0pFeIwk GhgGmjnwkyFGvifyUokdK++JixgZ/DhoZgAGGpZT48qdSzdiVTTSFjm48IZKKiFsAgseTJiNkFRU YlxwsEjaW5d1I0ue/LSqDgMOyH1KpUmwJiHBCsgr0i+FadNFZKQLJqRzYE2pPpGL0JYp5du4c1s8 xgLGohlvNgh7bSGdkXcHEpwB0AUdOjLQ0XWhByCBv3dGNlhwLWzDmxmLYLD/gKy7vPnzVWEs8aMg XmBhApB8+MR8BLgrGk5gkoWJgn9MmJyQyRUlDEBGde+8IMBwbMSjgB9LwGDbeRRWSJdlVsygAGBs ACPPfPSMUEImmMgBwhY2HMLBiixyMM4hNjgBghyytILBAFgk8A4ewAQmhAIzWKHDhBYWaaRMvGH2 hnsdIpEPAPhg0AoFIKQoBTMhSCKBBNHs4eUe0UQjgSRrhCAFBzZsIccJNwLwCSQ9NviGAwaMd+Sd eG5kgg5LZLCBj0gcAMAAGlBpAwf6aLkHPBVUEIQHkEJKiQeUBNHoKmBKYuYhamYCThdvcrhBBksM meepqD5U1QoObMiGMPI8/zlAJnJswQEzkizqqAezoDLLr78qscCwJOTQwi96UFoBppqiueann+Ax 3I8RrEBkqthmewwaBvjxQmDxRHLGCBrI4QQHIUgAQQWU6BHGKY2cQ4IeDNSrRzfPFKNvMcgkk0wj p4QxCyUVwBPNGlLYkEgr4ADwTjCBveBHneRlazGe21qRgQCv4nFAFxhQYGsI0azyaBgkJIMMMvo2 oge9L/9SzBE013yEvv2SEMYOlCCyB8JOyHEFPgkUMZwAGViBRsUXN03htkvE0KMQRvAzQCuJHJKu yQxw4g3LZthcDAOXKIFLGKW00cE5zzxjM81m8LtMDsn6HAIHW2DScAqAAf8TwxJLOy24eds280Zn wHwAQAkUOCGFJBAEoYcWKs9cczHn5DHFAlqQkE02C7ghuhtggOFJHudYTrPcdFMCjwTM2CB0FwdY wIYmbzQT+OC8T1b44Wykkk8XV8ihdTQVeMDJMsiEvXoHnoDhxhQdLPD59VrcgAIKijjTgeimd6C6 3C14EMTPHICQCT7+FHB77rv3Ln9cUAOfygE/aAACB2tEfgkRLKvZOdogPTE4gwRa0EI2bsDAG3wu gRBMIAmcIQbSteEcl0MGES7hgddJYQsnGEAC3Ic7wDFtfiicCW8WEYPO3A8frdiCFCSACEq0QGU1 q0f0pnBACH6OCM4whSn/eDCFKYBBiM4gwgMl6IgpuMET9bhcMspXgWgwwwmYECEJY7AIO6XwizFJ UgZ6lIpJwFCGEqiAHlJmuWIQkIc3gCARzjGFNqCgFN2ogjL2qIwqdKMUKKhHHYkAwRs4w4ltaGMy TjGLCuwhdlkcYYcyQDEwWvIjJliBHzgGjHyQIYZSQN4OAOi8DkjPGXHsHB2JwIc+VuGVaoilLF/5 SmXwIXRtQGD2nEE6DB7BDBrUw/lCYIMsfsJ2AvCDtS7JTI0cQwcOgIRhItEFDcgQeaj4Ws2iJwZd ksAU9ciBK9WQhnKW8wvo/II5y6mGWvKhDTxAgQTF0IaaxW0BlzifPrA4/4IDAOYFEdDBCZtJUIfw ZgkKeJURAHAFEMywAqhg3upOCcE21IMPsDwnOqPA0Y56NJ3s1CMf6pHLbOQACvVw3s2Wkc9HbqEV 6AjEcBSwBC8W9KYNMYEBMgAYPPCjBHLgQBr1oM0jnAMMm0sgEXhQij6Sc6MejUIPpkrVHkQVnWlo pzJKwQMiVIERYXCESouxAD1UUQoguAIAkGAYSpoAp3BVyDMd8Kd4HGAAFDjEGhChBwDS7KhT0GXq 2vnUL3S0qlQtRzkQO9WOYrWdVWgEERjBiDQ4whFRvNkCGikBDiSiBPyA2AYcINC4mrYgJrDCG15F zVY4IQQQoAQJkPFXMP90M4GB7eM5DztVYvj2t8AFblU5itVX5qANSmAELsQABl8i4xQ7QMQaDoGJ fg7nDVZ462lPawIYzMA98jgDBhIRyiDccKKB7Zw6cvDKNBiWo1QFrjHmS9/6GkO4jY2COts50jQA AgVGtNwUPQCBEGxBA/TYR4NmIKHtmpYFCDVMPkaQV0lU4BLJsBxSEUgCdWD0qfDtwW/tO4cSm9jE 9f1tfourhPSSwIhwS0Y+o+HZEiSgRzRlgYPhegwY+AEwSACANWHrgQXQ9giecIM8oeDhKoBYqiIm Bn1PPAcVWPnKVKavb6lK3DRUARdgQGDoPLG6BUR3uidAhxEM4wcYDHT/x2A0wSISCoy7BlUCQeDE kU3pDNyKUw3v7a1v52viK185C4g2tApQPN8tW1W/Xs4BDxLIyw7QDBnl2wNaMcAP2ylgEdqFMzOf +V02BDkTr12FHpYxs2LYNoHycnIaQjxoYxTayojOta5zbegSN5oYK/YyFNqQQOa2ehlmlQR1ybDm eMygtKK+pE5X28kBBDUaQTjFkdvgBgTOUbeGFTShq6wCXTPh3OhOt66t7Ov7AvvRX3jlERrROTfU 82aqILA+QICBBNjuDQYIdbS/iIYI/EkeQt5CCFbBgGSErR5g6LMWeKAEEIvb1uRGdLoJwfGOc1zd iV70HNyd36xWgQcI/+RlFM2QjEYq+wRdUPAGIoCGgcdZGhkQhjA+gA8KCDUIWjhyEeN4Dii8F761 zngW0O3xezj96ffoOLpD7mtHO7YUpsheEVeXb00nAhz+0Dk5pCFwm/dOzg9ggwA+gQEQMAMCO2A1 zcSgi2y8+AtBwIBVo0xoXC+dCR2H+iYGP3iof5wJVB+5o+1Qhx58oQPy5CUGzbCMMztBAwBIBRs+ AWqzz+8YdHAAx5BAj1bYwMJhOLIZHAHWNpRiFCkogx162/dy/53jTif84AlAAN1v4ukfp/qv7TAH ANRhFBOY9A3qeOkWBIHGFMDHmlPhgPh5XnA9voAmNPEBCnNgD0VuI/8UKCuGNFACEhMQd4ltD3hC 5H73vI+//Anv9OBngd2N7gEXJrCBCTwegY7gBq1GAjsAAcwAAiXgD9t3AW52fbyjUzHABhbwCSUA AvoAD3rgcDRTD2rACCTwegw1B3YwaOuncbh3D/BHAAGwgizIgrxXeFFHCIh3f1VHDHYwAQzVA4BQ D/VmaSxnVmtweQDgHjEQcHhCDcOQhEq4hEzYhA7GAs1ABWyQDgCQCadXAakHN5PFCPXwBaOwAXFg B6NADIdWbufmfii4CbzXgizYBE3Qgi9YfzKYaCN3X3bABX8ACXagBpOmBWIwBc0XBJ2FCeggA2xA Bc2gYwhxAQXQiI3/qAAJ8QSO+AQK4QCOWAAOIBCXuIkF8AAIIA0JgYRNOIpOeFrb4gCaZwTogAmH gGfadjNtAAjKdQRRsAb+oAJ2oA3GwAR/4AM+wHTvp4It6IaDIAgN0ACD8IYrGIdRd273t2judoNF 4AFpQASExEutdgoeoGlyMACREDzV92YvoHPkKAQJUQDkKAyUeBAOIATpeAECkY7ymI4vsAQIIYqk mI/b9UwX0BrdJwdSAH6NEDbnoGRaQASv5w9lIIIqUAuUAAtYIAu14AO4t3vD6IbGCAdlUAZwIAjK GADMOIc02Gg3OAIj0AN8cA71NnmNsAPwEAL89gmf0WYDJQ3zKAwI/4AQ6JiOOVkQ0rAg7xiPNzmP QtCTBoGP+ViKpnUMOGcY/gAObgcPDUczmqN1amAHkBAHXMAFPvAJG7ABY9APAUCRaSiMK9gEg5CW DQAE7/CVCWAJyeiChRd8+AdsXBAHkMAFagAGCWRvNJMMDFABQXgFZ9AjGSANA6UAN2kBOjmP31AQ QBmU/5COQtCIkSmPRlkQSJmUSrhdmRSB8ZAAV6BwtvALyUAzntABCtQBXzAB6McFWfAIG7APINAH sVAJUYeCa3iWaSkIxggEgfCVk0AKyJiMb9h7T/eLiMcL7jYHcVAE/tcG2aAFHQCIR4AMvyCIh9AK 9MAxMbBMBmEBQ//5mAaxk5SZiQIxjvMIj5NJjgVAEEvwAO5YjvZ4EJvJmZ5pBS4whWegAVeoZzQT cZ3TCGlQBv4wAVwpB/IwAp3QBOKAm2WJlsVojMdoCZYABLlwAPxQA0DQABZqCYIwCCxoCCRqCJVQ C0xgZTY4AYEwAWmwANfoBqvTApQQDeOACV0gD2zgAtllEBeQjuYpDO9ZnjcpBPb4BEPJnkBqEO1I jwlhDdAQpVIapaMoEREwBBLRDC4wBA8wE89WEVD4BGwgAwBwAq0YBDkwM88ABoTUCIAQBVdwBfun BgkgA/xQCMzQB31gCBYpCHdQCEAQqDgwqIR6BzswqL2QC3UwAmX/QJwN0AcNwAsa8AN1sAs14ANZ YA4leQVRAAX0pghu4DbFwAnbyAHRVwRs8ASJaBDqqXOWmI7oSRBBmo4CoJhJKpQ6N6QF8aPleI/X gBBVqhBDMKzE+gBXKhEKQAX1iRAPEAMZoQMv4KwUwQLVoKNF0AWsKAGUsABqapDOAAijEAg74Jwp sAEyIANfCZaD0HsE0ASWkAJj0AD0gAdjUK9GYA9eMAaR4AVYUK/+igevAARj8Ar0OgZfOQYacA/G oA0TcAUnyQdToAUoEKo3Q4DcOALfIg/VoIgDsQTpyJgI4KQFEaTzWaSSuaQHIZ7kyJ4EgYS/ehDB mhAREAFJMAQz/7sEV6oDMxsBBGEAM2sABaEDLqAAEVAqPDsQAWUAQ1u0BrCs/xBQl6GzQOuzReuj QPu0P2tQBad5/YAOPgd+3FoM34MCy5cGdtCi+/cI/GCnG9kPG9AAfEoAg2AJgYBwGxAJonAHvrAP G/AIHxIK8oAErnALNTACX7kD8iAPRlAIncALrcC3NZAFxnCXgWAHUTAFNxA64kNWLskMiTAA7xA8 NFcQD5COkPgPKqtzTvsPQeoAQ/kCpbuyuCqkCNGqOEkQ2DANSfiyBhGzCnGsAnGlL+ACDzAELiAQ CsClW5qZCPACVOCJwCsQNtu8z4sAMdClA2GzEfAAL/ACF4AAxv9bvKebvTEgtLBLBUPAsnKFBqjI BilABocgCfAwSh0AcepAAiTgBlHAolrJBbVQBws6CJ0QCRtgCQGghoNACpFwrv3gBYPqBbSwAZ8g A5MACRsACjhAChcqCggnA0VwD01QCYbQBHWwAb7ABJMbBy0aBSiHAuowBfXQAUTQSGUCDvkAjjVH EKkrDKD4D7Grc9g7EEH6DyErjwIgDT8sDErqnsyajkGMDdyghLxbEL4rs1gavEOQBFgcATNgswJR s1crEM2KxQThxWP8D9dbxjObxf+wBOkrEF3stEMQAzkrEDFABQ1xipqXAgCgAAowArvwDevQDuxA DpmQCeRQAlf/UARxMHI+UMJ1gJbBacC8l8ALXARFcAcO7AVeYAQfIANIIAMfgAOW0ACCcKHyAAl4 EAmWYAi+WAl9sAE/UAuTuwNFcAUYYMiIzA7tsA7fsAsD4McKcAA4TBDfkI540LGU2cOamI7I+7Gg mMRLnKu1a7oCIQJRLMXAqpS/e8VP683/YLMxcLzZq75nHL3hzLNnnMbZu8Z2/AIEEa1l/DdDQLSX Ia0LocdsEAihKwQVMAtEUL9gcL8kAAb7i7bG8MgbEMlNEAhjQMlyq8Dy8ApfiQT8IAq04A7uIAN4 IAO+QMohKghA0A8cHQkNUAlM4AOwvNC0TLlxEAXd1mEwLMMM/xAEbJUK/lDMAyEt5PgAF/DTjMiT surM6alzQoCe0jy7uloQO8yeuruEU0wQVYwQ0YvO4kysxIrPPiytVq3O0srO0uvOaIzVw6rVc/y0 4fACxjsDecy+e4wPIBAC8xu23LZAU/AFZzsBdmAHCl0H4tDQG8AETYDAEu0OoCAKk4AEBosEt8DR Hg0EIFqMQPABeLDKDbAJKV0LsVwHPpDCLfoFU2B39qYvZVUBkmADJUDM1JfDbTyUiznU5DjUsZrU 7UnNPiqPPfzU2gyz3GzFSAvO4ozHSBvGW03GAqEDZvzVwv0PBqC9V5wE8Dzc8/y9AmEA4EvcVLG1 7uu1ARl+Rv+lZFBgCmaLtnwNyYYgDgCwAYWwrgEg0gv8Aa5AqKDgC6mMB6E8yqX8m6ksAyaN2Uyg 2QvtA/PABTsQCKOQBhEbOhjEufBwgDYsuqydxK5NjkY5xAlB2ygLnyUrDMksELqdhNQwpVIqAlN9 EFUN3Gusxf9wAUPA1gNxxm7MnjFgxuGAxS6evGLd3Fz9xuTL4kcLxg1BrdaKrRyAbdx6BM/grW+q kFvpAz+w0OddwqFQnAYsD+fqDzggqF4wwXgwCUXwtpC9lq7Qwf19bj6w2T4wBw17BSgZsRMrqhYr Bd0oTRrLsTs84bbNukTdxLJb27Q7ENKAABsuDLH64aTIDdj/YA29TdXe3NX/AN1DoNaZWdzIS6xU 4AI8y+Jc+g/JO6wu8ARiveJqPayTftbgS6yTnhBhOqb0YKZ4pgVqyqZa0AjZAKdXMAdc+eQ/UAmV cAezGQpwQAplYARWbsG+cAs4IAiwUASQIAPvsAuKmws4EAChwLd3IA+BMAj+feayTAh3CQCJ0Kmf SrGjWqpygA+oqqqKWMQ6JwBA/e79KJkWzuc6N83CUJmNOOg6N77/YOhNiOgCoehL2BEzqwMM4bP2 aAAGH7z1ifBtvPAFUfAKobMB9RCptZ9UaIUWBqBHIKA3QKAGiqBM0K+zXAuGkN4HOwZ4IAobQAuK 7a9jgAQR/7yv/eqvG4AHoSCwKdAEyukDuTAGWMAE+4d+X0AEKJANuiCAxfAMOVCjHECIOsqj2hWk qS4QSEqO0T3vB4HheE6O/N7vSbkNIkAQAp+EnrkCERgMoukEa1ABpkkzMKxAbdCar5kFr4AFr4Cp PhAAd7ALdVAHrxDsdRCojyAKixoLg1oHOQ8EvWD4IxAKhHCMPyAKY6lxtoD3WXCX6KcG9cBA2RAw nLAASqCdJ9CdbPCdb+Wx6cjMBaH65GiPWm8QXI/neBCrA+HvSij2BlH2+9iUQuAPFbhwqHCaR1CV WgAGV5mVXGAHKoB4VsYE91AJAZCWvRmiFarBGvyhx+ih2/8voitoCPfg/BqnAsYwATuQl3vp+S3A AC+TbDagAYXJBofpEghwiUF8EC9wiTkpiY6oEPXviADh4N+/AgUNHnyAQNpAhgynDYMYEeI2EQ0b WoNoUeNGjh09fgQZUuTGYzD8CNH0boAcKXs8LDNz5JwbElqKAeoBINEcO+ZU8JqjIksWH/c2bSIQ gECTAAEGPRUkaFBUQU2aDLLKNMAmo/eYMMmiYk5QY3bi6IzS4tyNbCRw6WEwaxaiEFswJNAkxA+M YyP9/gU88KHEiRU7YgycWPHixMfQOEjFxggZChyiBSFR7EgxMIq0kHCUxgOkCXaIETMWVOhXQveM EkjaNED/Vtpam8I+eo8QIbAqxBo7zSUO6S+NULAlgYrB8h0QpMgB94FNKgdo+jLGnt2vYe3dvSdm 0YwKmzEAWtmQVCFMsphTxGjJBkaNHUhxuIxCnVpoFia7XSONTTYBB8SNq93ACmss4LSZ4BFIuFCD h2zYAmS5uCiJhgMKyJCBDSqaYeE7EUcksUQTLTLBgBjYiCcBDLYIYRVUznnmCCIWmNAZFHIagQvT UBtrv/5aMwrAAQksUDfeevvtNDsmCKSMKKAopi1HcmBAj1n0qEASG1qhJx42YjDAhBPPRDNNNTsq 6QJNUlqpJQ+0aIEBVOC74YY2vuCiiAm46CE/1YYa8j8A/2ETELYklfwqrN+AG4WLHYhroyZn3Kin ES0u2QEefUDA4JM3L+BrTVNPRdU7xyBj44UuTjhEkiDkgiuHbCa8qYczrrDDjkCN0U9I/ww9VNGj cmOUSQWd5CLKKPh474YpptgsmRYw5ECOEfqZrrrrUgU3XHE/MmGRT9gQwEUY4dEyS1xImFBPNXrA QJsoAgVyUP4Kda3IY5FVcklHlyWmBzvmOADCKSzFdLNlGOjyS3oi+2QRM8fFOONxj5GGHGGEUUkO yyiRazlAbs1GRzWiYLkHfFPTl7XdiOy335kFHngOYAvuoeUvADlHC2mp3YwVDyBgBtQEPiZHmos1 hjpqNf/RiGADNvCgRwMb1kCEVj1amEIX+HhIQ400vrj35SD323fIm2/+qtGcd3aZ5S/M5gEKLS6t 5wgzkkElCAk4wASfItjYIAI0pGa88RJTfIMNYPwBhyWXZkFlgWKmoEkLFNpQpgq00z4N2LWHajtu 1eV2VCydgas7ii++qIIGIj5zo40jNjulubquOMMCNt4o03Hjj8fuGB1mEBOSV7dGZAdkNOOsA/ic WUCZ2Vt+GWbf2CY0btSH+l5B4Hi2O40qMtNCCzHc0MyMhwUfh4JtWZxBh2+R57//kMpVgOQ+UYJE tIQSnEjG7jrgBme0zxQkqMLZuFc606nme+Mj3/dc97r/08TuC2lQRil40L5LdWB3xVDF0fSxBQ0A QHgKsJj/ZDhDjpTkJGxwXiucEAJ4eKARmjmCJ9yAAvhMgQ8RHJ3LTpMfmK1Ng+UbCwc72DPZqY8P YNDbAtzgiRMuYAddOoT9uKWXUtHQjGZkwRICKATKiUwCFbgEe3YHhoUV8YgSnCAFKxhFPprvfDyj 4gerwAcW1IQEUwDD7v6mBErsQQqgOgMw2KCAJYTojJeUoQlgwLyrAeAKW2CGSziBjBPS8QZFhCAS uYcvPQLLla/8o8sCObsqlAIMhkQkEJHRgk6FwAYnIMPh4jEDGDwNk8c8ngmsEDmQ4QMTW+vhAkh5 hHqA/0EMp8xGGxQROjymTYlLpCA4lyhLllWxCsogQd4+876+bYYEX5TAOKDzCWEMzwrGRGY+Gac8 B1gtGAmoHAfeOAvN7e4cdKzJ3qagPlWWU5bfBOdDY1dF9aWhDVX6DOfO0UUGBCEaj7wCAASAOAfo T58nbVyKMiAENhTBkyCQQjQqgIplALGaUyDiZ8CQPdGdbXSrlOhE08fQbALilERAZDuLMb89MGML rUAHJNgghAwUD6VXhdox0hhAYaQAHZkA5R6CcImalpKB7UsZGEoROiRur5xvfevsPki7WtaDBIxg RA4uBQYgLlUJR/MlJgbwjnpSkgX7w2piw6W8CLxgqv8HwMcJnBDKsZZ1d21wQwcSmo1itAEFbI1g GnwqV7mK9mxVOKeeUIBXRqSBCFvcncP+CoE1hBEcCWApJEqKWMX2FlUmWIEfRmoBfwzgmSEQa+aQ EZMjdAAMDDzl9cBQDyiAFrWmLRtqUasMQDhiCsW4AS4YUQVA1KMeQDRDMRbAgKPVVg4lCB66/OA0 39YXXFo1QAYkWYAEGNcG+thDBQg6vRNidgpEiO5nnDFdRaCgFGFQRoSV0Y1S3EAR1SxGQrUAiFI4 oh7M9RsySNBR2h7ivQAYg+Sqelj7tvhUWl1EDDTBBv7uAhOTlekOcpAMIFKTc1NwhoZvdYNGNGIK ppj/FpKLzJZstE/BU9BdbKulih0EYQ8hMDEGUMwGTcRgESx2cZjV5JglvGHG/DXuFqQgAUR44BKN WG5s64FZN4hBERp2cp71/BlFvM8N341teheghC9Ggxk2oEAJtqyJNyzBOmKGdJoc0wwz0/gTI2gF CDiwBggEQcc1BXExOsC5P3fAGURAAZ5JgAIiOGPUbih1j9O7DCpTAh4SkMIWMAGOM6SY0c14dKSF faJJV9oCB0DHFeRwCH1Eo82oOAWPQbyZc7SB1LDGdrb/3IZz9NhvxUjGKVDhgQpceRwgaMUAEiC8 Xwd72O8mEZljIEkhpIAeJcDEFjYdYEpAexnTm/bu/57xjHN0wOAdoFGNpHxCZCyDFaioMgQkIQUb yOEK6HgHS4ERA0fzFt4f145jrJCBkQoDCfwYgQYScQgpSAICFfDA1xaQDIAv3OYLTy+4F1AnDwQB AhLQxyFAcAJwAAAS9RRABqzgbpA3vTv49YNj0ZWPLoADEyA4BDMksQdEBMEDqGgBCZZB82KU3exn LzsykrEMErQA4pSowM9DMI4tUAADZPjESFvlBwMw3el/Tx5wI6AAlgpjHwlABwauzvI1ROPlXt8B Kn6hClYswPKXtzwrVPELiO8A7vCIhiSYwYG6a2AEZyhCPYWgAAeswAQeB3zsE2MCHSwhA1aTnBES QP8GDJwgEU7gADPWIIE9wKMCQaCEB3awfOYv3wOUCEIFEAGB0OuDAzYAASauMAIA9EOSiMvAEnSA T9mXXzH4dcAbxMQGC+i+6hqgAAiAL4UQDD8ae9gDBCAAD/5DAP/RkABJCAEpuD4QkINWwAB8OIN+ EB4WeQMHMAAwM78JXIxjoD0rmAHCYwP22wd/AAB8KAENwAQ5kL9D4AAOkAIpYIYVZIYUPMFDsIEt kAMKQMARoIcEKIIGXL0ZsILxgz0KBMKRsEAYWAI/UID1E4ZUMAIPRIcBKIEraAVMoAA5kINEsMJE oEI5wIQT0AAMAAcyAIAE6IdUqCcWUQA/WIJi+sH/IGRDkdAqGFiEGXiDDShDTYgHGYiETzgDeugC fBiBAQCHQASHARgAfEAHejiDBPgAGYiHMhSGDXiDGVgEGJDANrTExtAkA4gAcviEVJixDdQEYBAA eSgCSHiHfEDFfHgHSCgCeRAAYPhELkuFTyAHCPTBS8RFxrBANJCGRXCAC4gBKkgFltrAYjTGY5yq VKCCN7gAB1gEaUCD18vFadRFEzABNIABA2gGB/CDDIgBF3gCeUiFcSRHeXiCfIiBDPADB2gGA4CB aJRGapRHXbRAFkADHYCBFbCCJaiGCHCAf3SACKiGJbCCFYABHUADFni9NZzHhvyLY4BIa2QBe0SD DIqsyIm0RohkSO8ICAA7 ------_=_NextPart_001_01C99E7E.C33FC9BB-- From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: from the normal XP build. XP Embedded is basically a totally modularizable Windows XP distribution, but the lowest layer is never changed. So because SeaBIOS starts normal XP, it will also start XP Embedded. Freeldr was not familiar to anyone in the MS booth, but they did like the prospect of booting kernel really quickly from reset - as always! :) I have never been so convinced that coreboot is potent and worthwhile as I am today. //Peter From bogus@does.not.exist.com Sun Dec 9 17:34:17 2012 From: bogus@does.not.exist.com () Date: Sun, 09 Dec 2012 16:34:17 -0000 Subject: No subject Message-ID: error. OperationRegion(PCFG, SystemMemory, PCBA, 0x01000000) /* Each bus consumes 1MB */ Field(PCFG, ByteAcc, NoLock, Preserve) { /* Byte offsets are computed using the following technique: * ((bus number + 1) * ((device number * 8) * 4096)) + register offset * The 8 comes from 8 functions per device, and 4096 bytes per function config space */ Offset(0x00090024), /* Byte offset to SATA register 24h - Bus 0, Device 18, Function 0 */ STB5, 32, /* Address of SATA_BAR5 */ ... } OperationRegion(SB5, SystemMemory, STB5, 0x1000) /* SATA_BAR5 (ABAR) */ Field(SB5, AnyAcc, NoLock, Preserve) { ... Offset(0x128), /* Port 0 Serial ATA status */ P0DD, 4, /* Port 0 Device Detection (DET) */ , 4, P0IS, 4, /* Port 0 Interface Power Management (IPM) */ Offset(0x12C), /* Port 0 Serial ATA control */ P0DI, 4, Offset(0x130), /* Port 0 Serial ATA error */ , 16, P0PR, 1, The only explanation I can come up with is: P0IS lives at addrof(SB5)+0x129 P0PR lives at addrof(SB5)+0x132 Field SB5 has address STB5. Therefore: P0IS lives at STB5+0x129 P0PR lives at STB5+0x132 The accesses to P0IS happen at 0x100000128. The accesses to P0PR happen at 0x100000131. Subtraction yields: STB5=0xffffffff. That's certainly NOT a valid address of a BAR. The coreboot log says: sata_bar5=fc409000 /proc/iomem says: fc409000-fc4093ff : 0000:00:12.0 fc409000-fc4093ff : ahci lspci says: 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] (prog-if 01 [AHCI 1.0]) Subsystem: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-