December 2007 - coreboot - mail.coreboot.org

[LinuxBIOS] Add initial support for intel i855gme northbridge
by Jon Dufresne Jan. 20, 2009

Jan. 20, 2009

Add initial support for i855gme. This is a work in progress and I don't expect it to work on all boards, or even any besides mine. This is based heavily on i855pm. Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>

4 4

[LinuxBIOS] A8N5X port
by Robert Millan Nov. 21, 2008

Nov. 21, 2008

This patch includes config files for the asus/a8n5x port. It is the same as asus/a8n_e with a different pnp layout, so I used #include's whenever possible. System boots and is usable with usb keyboard. works: - serial port - vga (old pci card) - memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms in K8. Otherwise you get spurious memory corruption. - ide disk - usb doesn't: - ps/2 keyboard - onboard ethernet - vga pci-e card (??) - any other pci card I tried wasn't tested: - sata - game port - onboard audio (not supported by alsa anyway) - ps/2 mouse -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)

8 27

[LinuxBIOS] flashrom support for AMD Geode CS5536
by Lane Brooks May 16, 2008

May 16, 2008

Attached is a patch that enables AMD Geode CS5536 chipset support. I have tested it successfully on a MSM800 board from digital logic. It does, however, have a few issues that I would like some feedback on. In my discussions with Marc Jones, Geode systems write protect the BIOS via RCONFs (cache settings similar to MTRRs). Unlocking requires changing MSR 0x1808 top byte to 0x22. Reading and writing to the msr, however, requires instrucitons rdmsr/wrmsr, which are ring0 privileged instructions so only the kernel can do the read/write. So my patch uses the msr kernel module to access these instructions from user space using the /dev/cpu/0/msr device. My questions are: - I do not think this is portable beyond linux. Is that an issue? - My code assumes the msr kernel module is already loaded. Is there a way to force a kernel module to load from the C code? My code does die gracefully with a message reminding them to load the kernel module if things fail. - It seems like there should be a way to revert the msr back after flashing is completed to put the bios back in write protect mode. Is there a cleanup mechanism available? Something like disable_flash... Thanks, Lane Brooks

8 17

[LinuxBIOS] [PATCH] TeleVideo TC7020 support (2nd try)
by Kenji Noguchi March 29, 2008

March 29, 2008

Hi Uwe, Thanks for the review. I have updated the patch based on your review. The new patch needs Nikolay's CS5530/CS5536 PIRQ patch. I cannot run superiotool with the factory BIOS because the BIOS is WinCE. WakeOnLan doesn't work out of the box. The original thin-clients manager is able to on/off WOL feature as far as I remember. It's a PC97317 board. Strange, the superiotool r2992 says "No Super I/O found" NIC is soldered on the motherboard, and it resides on pci 15.0. Fixed the config entry. Floppy connector may be available in one of the pin headers but I can't confirm. I leave it off to be conservative. COM2 is a regular DB9 serial. Fixed the comment. irq_tables.c in the previous patch was re-generated by getpir tool, and manually edited. However I had no way of testing it. Linux kernel won't read it unless patched, you know. Anyway I reworked on this file using Nikolay's irq patch. As for MiniPCI slot there are INTA and INTB by definition of the MiniPCI. lspci output had no 14.0 because it's a slot. I installd a WiFi card to the MiniPCI slot(PCI 14.0) for testing. It got IRQ9 and worked great! Regards, Kenji Noguchi

2 2

[LinuxBIOS] [RFC][PATCH] v3: lar header after member support
by Carl-Daniel Hailfinger March 28, 2008

March 28, 2008

We had that patch in a larger package about 7 weeks ago, but most parts of the package have been merged since then, reducing the clutter in the patch to zero. For your reference: Message-ID: <470EA5CF.2020409(a)gmx.net> Date: Fri, 12 Oct 2007 00:38:07 +0200 AFAIK not all architectures start executing code at the top of ROM, some start at the bottom (low address). In that case, we can't start the archive with a LAR header, but we can end it with one or postfix the first archive member with a LAR header. To achieve that, the patch redefines offset as signed instead of unsigned and allows the lar header after the boot block to point to the boot block at the beginning. That way, even bottom boot architectures can use the existing header format unless the first LAR member is bigger than 2 GB. This patch also introduces a 2 GB limit for file names in LARchives and a 2 GB limit for unused space between header and data. There is no new restriction for member lengths or archive length. Current LAR archives look like this: Hn=header n -=padding Dn=data n H0D0D0D0H1D1----H2D2D2 where the last bytes of D2 are executed after poweron. The patch (together with signed offset) makes archives like the below one possible: D0D0D0H0H1D1----H2D2D2 (header after boot block points to boot block) The new archive format possibility allows placing a boot block at the beginning without sacrificing the goal of one common archive format. However, there are two potential problems: - Endless loops if we aren't careful when walking the LAR. I think I got all corner cases right. - "Nobody will need more than 640kB", in our case it would be 2GB boot blocks. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: LinuxBIOSv3-larheaderaftermember/include/lar.h =================================================================== --- LinuxBIOSv3-larheaderaftermember/include/lar.h (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/include/lar.h (Arbeitskopie) @@ -61,7 +61,15 @@ u32 reallen; u32 checksum; u32 compchecksum; - u32 offset; + /* The offset is signed to allow header after data for the first member + * of the LAR. This is needed if code execution starts at bottom of + * flash instead of at top of flash (x86). Please note that a + * header-after-data LAR member can't be larger than 2^31 bytes. + * Right now, we are about five orders of magnitude away from such a + * beast. + * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + * "Nobody will ever need more than 640k" */ + s32 offset; /* Compression: * 0 = no compression * 1 = lzma Index: LinuxBIOSv3-larheaderaftermember/lib/lar.c =================================================================== --- LinuxBIOSv3-larheaderaftermember/lib/lar.c (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/lib/lar.c (Arbeitskopie) @@ -116,7 +116,9 @@ if (strcmp(fullname, filename) == 0) { printk(BIOS_SPEW, "LAR: CHECK %s @ %p\n", fullname, header); - result->start = walk + ntohl(header->offset); + /* In the header-before-member case offset is at least + * sizeof(header) + strlen(filename) + 1 */ + result->start = walk + (s32)ntohl(header->offset); result->len = ntohl(header->len); result->reallen = ntohl(header->reallen); result->compression = ntohl(header->compression); @@ -137,9 +139,30 @@ * In the case of consecutive archive members with header- * before-member structure, the next iteration of the loop will * start exactly at the beginning of the next header. - */ + * In the case of header-after-member (e.g. for bottom boot + * architectures) the calculation below will effectively cause + * walk < header. To elaborate a bit more, in this case + * (header->offset + header->len - 1) will evaluate to a value + * between -1 (header directly after file), -16 (file, 15 bytes + * pad, header), and even smaller values if there is 16 bytes + * or more of padding between member and header. The outer + * expression will usually evaluate to 0xfffffff0, cause the + * expected overflow with unsigned arithmetic and result in a + * decrease of walk. That condition can be checked. */ +#warning FIXME: This loop will explode if this code is ever compiled in 64bit mode +#warning because of the hardcoded 0xfffffff0. walk += (ntohl(header->offset) + ntohl(header->len) - 1) & 0xfffffff0; + /* If we have header-after-member, walk < header is true. + * Go forward instead by starting at header, adding header size + * and strlen(fullname). The result of this calculation is the + * position of the terminating \0 of fullname. Round that + * address down to the next 16 byte boundary. */ + if (walk < (char *)header) { + walk = (char *)header; + walk += (sizeof(struct lar_header) + strlen(fullname)) + & 0xfffffff0; + } } printk(BIOS_SPEW, "LAR: File not found!\n"); return 1; Index: LinuxBIOSv3-larheaderaftermember/util/lar/lar.h =================================================================== --- LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Revision 539) +++ LinuxBIOSv3-larheaderaftermember/util/lar/lar.h (Arbeitskopie) @@ -60,6 +60,7 @@ typedef uint64_t u64; typedef uint32_t u32; typedef uint8_t u8; +typedef int32_t s32; /* NOTE -- This and the user-mode lar.h may NOT be in sync. Be careful. */ struct lar_header { @@ -68,9 +69,15 @@ u32 reallen; u32 checksum; u32 compchecksum; - /* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + /* The offset is signed to allow header after data for the first member + * of the LAR. This is needed if code execution starts at bottom of + * flash instead of at top of flash (x86). Please note that a + * header-after-data LAR member can't be larger than 2^31 bytes. + * Right now, we are about five orders of magnitude away from such a + * beast. + * Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. * "Nobody will ever need more than 640k" */ - u32 offset; + s32 offset; /* Compression: * 0 = no compression * 1 = lzma

2 3

[LinuxBIOS] Request for superiotool dump support: SMSC LPC47M192
by Corey Osgood March 9, 2008

March 9, 2008

Hey guys, I've been looking through the datasheet on this chip, and I've got no idea where the values you use come from. I know some of you have been adding dump support to various chips just for the sake of having them (which is a good thing, and I'm glad you're doing it), so I was hoping you might be able to do this one while you're at it. Thanks, Corey

4 10

[LinuxBIOS] W39V040BPZ or vt8237. Flashing problems.
by Adam Talbot March 3, 2008

March 3, 2008

Have three motherboards running cn700, VT8237 chips set. All three boards have W39V040BPZ bios chips. I can not program them with flashrom. Flashrom see the chip as W39V040B. Flashrom start on the flash and just sits there. When flashed with the -V option I can see the memory address is not changing. But, big problem is the fact that the chip does get a bit flashed, as, I can no longer boot. So there is something happening. Looking at the data sheet for the W39V040B, all the PZ gives me is the PLCC package and lead free. So, is this a problem with the vt8237 south bridge? Where should I go to start debugging? -Adam

6 19

[LinuxBIOS] starting ACPI implementation for m57sli
by Andreas B. Mundt Feb. 25, 2008

Feb. 25, 2008

Hi everybody! Following http://linuxbios.org/ACPI_in_LinuxBIOS I tried to implement some basic ACPI functionality for the ga-m57sli. It compiles now, but linux doesn't boot anymore, I guess there is some irq routing wrong (I took all from the a8v-e_se; thanks to Rudolf Marek). I'm an absolute newcomer to the field, so please do not expect to much from the patch. Perhaps someone else can be motivated, and/or use it as starting point for a thorough implementation. (Or, of course, give a hint what's going wrong). Thanks, Andi

6 7

Re: [LinuxBIOS] Intel microcode revision code
by ron minnich Feb. 20, 2008

Feb. 20, 2008

On Dec 12, 2007 12:28 AM, <Martin.Karlsson(a)emerson.com> wrote: > > > > Hello, > > Yesterday I wrote some code for the Syslinux boot loader that is meant to > boot different images based on which revision of the CPU microcode that is > currently loaded in the CPU (yes, this is a bit strange but we have a very > good reason for it). I then compared my implementation with a few others an > ran across yours, in > http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/cpu/intel/microcode/mi… > > Question to you guys: why is the first wrmsr instruction there? From my > understanding, by not properly initialising ECX, EAX and EDX this will > overwrite whatever is in the MSR pointed to by ECX?! > > BTW I tried out your code on our target hardware (Intel Celeron M, 600 MHz) > and with that first wrmsr line in place it hangs and without it, it runs > just fine. > Thanks Martin. That looks like quite a nice bug catch you've done :-) We'll have to figure out if this code was ever (a) used and (b) worked :-) Thanks again, this is great! ron

5 7

[LinuxBIOS] [PATCH] fix port 0 on sata controller 0 for ck804 based boards
by Ward Vandewege Feb. 20, 2008

Feb. 20, 2008

Hi all, There is a problem with the ck804 code in the tree when it comes to SATA support. I've observed this on a tyan s2891, and it has been confirmed by folks with a sun ultra40. This patch changes the southbridge/nvidia/ck804/ck804_early_setup.c file and enables one extra SATA port. I've tested this on real hardware (tyan s2891). There is a very similar file called southbridge/nvidia/ck804/ck804_early_setup_car.c which seems to be used by tyan/s2895 sunw/ultra40 I don't have access to a s2895, but YH thinks that all sata ports should work on that board. It would be great if someone could verify that. I'm not 100% sure why both the ck804_early_setup.c and the ck804_early_setup_car.c file are included in the mainboards/sunw/ultra40/ tree; probably only one of those files is actually used. I've spent quite a bit of time with 'dumpio' and tried to match register values between the proprietary BIOS and LinuxBIOS, but to no avail. If someone has ideas to get port 1 working on both sata controllers, that would be great. Thanks, Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior System Administrator

5 8