coreboot October 2007

coreboot@coreboot.org

84 participants
481 discussions

Re: [LinuxBIOS] : Disable OFW
by Stefan Reinauer 06 Oct '07

06 Oct '07

Jordan Crouse wrote: > On 04/10/07 08:10 +0200, Stefan Reinauer wrote: > >> * Jordan Crouse <jordan.crouse(a)amd.com> [071002 22:13]: >> >>> Okay, now that everybody has recovered from the last patch, here's the >>> last one - disable OFW for the short term in buildrom. Reason being, >>> that it only worked for OLPC, and the previous patch removed OLPC. I >>> discussed the matter briefly with Stefan and Segher, and they tell me >>> that there are ongoing efforts to make OFW or a OpenFirmware clone of >>> some sort usable on a generic x86. I support that 100%, I think OFW >>> is a vital payload for this project. I just don't know enough about >>> OpenFirmware to get the job done. So I am submitting a patch to >>> disable, but not to remove the OFW scripts, so that those who do know >>> what they are doing can port the code easily. When everything works, >>> revert this patch, and we're off to the races. >>> >> ok Acked-by: Stefan Reinauer <stepan(a)coresystems.de> -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

1 0

[LinuxBIOS] r39 - trunk/filo-0.5/main
by svn＠openbios.org 06 Oct '07

06 Oct '07

Author: stepan Date: 2007-10-06 21:06:52 +0200 (Sat, 06 Oct 2007) New Revision: 39 Modified: trunk/filo-0.5/main/malloc.c Log: This patch makes qemu work again on v3. FILO was depending on bss being zero, which is not all that safe in embedded. It's better to zero things you are depending on being zero. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/filo-0.5/main/malloc.c =================================================================== --- trunk/filo-0.5/main/malloc.c 2007-10-04 06:12:32 UTC (rev 38) +++ trunk/filo-0.5/main/malloc.c 2007-10-06 19:06:52 UTC (rev 39) @@ -43,8 +43,10 @@ static unsigned long total_free, total_alloc; static unsigned int count_free, count_alloc; +/* FILO should not count on bss being zero. That's dangerous */ static void malloc_init(void) { + memset(&_heap, 0, heap_end - heap_start); head = (struct block_header *) ALIGN(heap_start); head->prev_size = INUSE; head->size = ((heap_end & ~(ALIGNMENT-1)) - ALIGN(heap_start)) @@ -70,9 +72,11 @@ { struct block_header *p, *new_space; unsigned long required, largest, remainder; - - if (!head) + static int firsttime = 1; + if (firsttime) { malloc_init(); + firsttime = 0; + } #ifdef DEBUG malloc_check();

1 0

[LinuxBIOS] Normal vs. fallback images and CMOS
by Jonathan Sturges 06 Oct '07

06 Oct '07

Question. If an embedded board has no battery backup, it should have no (usable) CMOS. Therefore, is a "Normal" image required on such a system? My understanding is that CMOS settings are required to force the Fallback image to boot, except in cases of an missing or corrupt Normal image. I'm thinking I can pack in a bigger LB payload, if there's only need for one image. Are there any considerations I'm missing? Thanks, Jonathan ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

2 1

[LinuxBIOS] lbrelocs - LinuxBIOSv3 re-linking tool
by Jordan Crouse 06 Oct '07

06 Oct '07

Okay - based on my previous e-mail, attached is the custom tool that I wrote to change the relative addresses of the initram binary so that it can be placed at an arbitrary place in the ROM and still work. To start with, we ask LD to emit the relocation info for the segment into the ELF. The relocation tables list everywhere in the binary where a symbol reference is made. Using that information, we can easily walk the table and adjust each all the relative offsets so that they will work from a base address specified on the command line. This tool just changes the code - a more complete solution would probably rewrite the entire ELF file so the offset was correct - I think thats as easy as re-writing the sh_addr for the sections, but I don't know for sure. I had to take a crash course in how relocs worked (thanks a million to Eric Biderman for arch/i386/boot/compressed/relocs.c in the Linux kernel - it taught me much, and I borrowed some of the functions for this utility too). So, I put this out there as food for thought, and end with some instructions on how to see it in action (I used the amd/norwich/ mainboard): Modify the $(LD) command in mainboards/amd/norwich/Makefile to this: $(Q)$(LD) -R$(obj)/stage0.o --emit-relocs -Ttext 0x0 $(INITRAM_OBJ) --entry=main -o $(obj)/linuxbios.initram.o This moves the text to 0x0 (makes the math easier for me to verify), and emit the relocation tables. Build the LinuxBIOS image. Compile the tool, and run it: lbrelocs -b <base address> linuxbios.initram.o This command will adjust all the references in the code to the base address. It will overwrite linuxbios.initram.o, so I recommend saving it off first if you are going to play around. Because we're not changing the actual offsets of the sections, the disassembly will get confused, but you can still do the math yourself to verify that the calls are correct. If you are brave and have a geode, you can figure out the right address to adjust the segment too, copy it to a binary, and rebuild it into a LAR and see it boot. I'm rambling, so I'm going to leave you here. Comments especially welcome, if I can do something smarter or better, I'm very interested to hear about it. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. /* LinuxBIOS post-link fixup script for segments * Copyright (C) 2007, Advanced Micro Devices, Inc. * * Techniques for reading the ELF file was borrowed from * arch/i386/boot/compressed/relocs.c * Mainly by Eric Biderman, but also others too. 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* What is happening here? * * LinuxBIOSv3 functionality is divided into a series of independent segments, * each of which serves a different purpose and are linked independently of * each other. LinuxBIOS also has a number of common symbols that are to * be shared by each segment (such as printk). The code for these will live * in the bootblock (at a known location), but need to be resolved for each * block. This is easily done with the -R command line option for GNU ld. * * This is not a problem for segments that are compiled to run in memory, * since they will be loaded to whatever memory address they were linked for, * and all the relative function calls just work. * * This *is* a problem for segments that need to be executed in place from * the ROM (for the segments that run before memory is initialized). These * ROMs are not located at a set location, they may be located anywhere on * the ROM (at the option of the LAR tool). * * This utility takes an XIP module and adjusts it to run at a specified * location. Thus the final location of the code need not be known at link * time. * * How does this work? * * When the ELF is linked, we ask it to emit a series of tables known as * relocation tables, which point at all the locations in the the code * where we refer to symbols (like calls to functions). Based on these * relocation tables, we can adjust each relative symbol reference to * match the new execution address. */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/stat.h> #include <fcntl.h> #include <stdarg.h> #include <sys/mman.h> #include <elf.h> #include <ctype.h> /* We shouldn't see ELF headers with more then 64 sections - the most I've seen to date is 12 */ #define MAXSHDRS 64 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) /* We use this structure to carry around the information for a given ELF file, including the mmap variables. This is a little overkill when we read a single ELF file, but it gives us the flexiblity to read multiple ELF files if we need to */ struct elffile { int fd; unsigned char *ptr; int size; Elf32_Ehdr *header; Elf32_Shdr *sects[MAXSHDRS]; Elf32_Rel *relocs[MAXSHDRS]; Elf32_Sym *symtab[MAXSHDRS]; char *strtab[MAXSHDRS]; }; /* A verbose flag to increase the blather from printfs() */ static int verbose; /* Borrowed from relocs.c - I liked the idea - print an error message and exit with an error. */ static void die(char *fmt, ...) { va_list ap; va_start(ap, fmt); vfprintf(stderr, fmt, ap); va_end(ap); exit(1); } /* Borrowed from relocs.c - return name of a section */ static const char *secname(struct elffile *file, unsigned int index) { const char *stab; const char *name = "<noname>"; /* Get the string table for the section headers */ stab = file->strtab[file->header->e_shstrndx]; /* If the index matches a real section in the ELF file, then use sh_name to index into the string table above. table. Otherwise, its a standard section type, and we a standard name */ if (index < file->header->e_shnum) name = stab + file->sects[index]->sh_name; else if (index == SHN_ABS) name = "ABSOLUTE"; else if (index == SHN_COMMON) name = "COMMON"; return name; } /* Borrowed from relocs.c - return name of a symbol */ static const char *getname(struct elffile *file, const char *strtab, Elf32_Sym *sym) { const char *name = "<noname>"; /* If st_name is non zero, then it is an index into the string table passed into the function. If st_name is not set, then we need to look up the section name instead */ if (sym->st_name) name = strtab + sym->st_name; else name = secname(file, file->sects[sym->st_shndx]->sh_name); return name; } /* Parse the ELF header */ static void getheader(struct elffile *file) { file->header = (Elf32_Ehdr *) file->ptr; if (memcmp(file->header->e_ident, ELFMAG, 4)) die("File is not an ELF\n"); if (file->header->e_ident[EI_CLASS] != ELFCLASS32) die("Not a 32 bit executable\n"); if (file->header->e_ident[EI_DATA] != ELFDATA2LSB) die("Not a LSB ELF executable\n"); if (file->header->e_ident[EI_VERSION] != EV_CURRENT) die("Unknown ELF version\n"); /* We assume that we are on a LSB system for simplicity now, but this is a stupid assumption and should be fixed */ } /* Get the list of sections, and the individual tables from the ELF */ static void getsections(struct elffile *file) { int i; int count = file->header->e_shnum; int offset = file->header->e_shoff; if (count > MAXSHDRS) die("Too many headers\n"); /* We assume that we are on a LSB system for simplicity now, but this is a stupid assumption and should be fixed */ for(i = 0; i < count; i++) { file->sects[i] = (Elf32_Shdr *) (file->ptr + offset); offset += sizeof(Elf32_Shdr); /* We need to individually index the string tables, the symbol tables, and the star of the show, the relocation tables - so when we encounter those, we set up the array pointers accordingly. The mmap()ed file makes this very easy. */ switch(file->sects[i]->sh_type) { case SHT_STRTAB: file->strtab[i] = (char *) (file->ptr + file->sects[i]->sh_offset); break; case SHT_SYMTAB: file->symtab[i] = (Elf32_Sym *) (file->ptr + file->sects[i]->sh_offset); break; case SHT_REL: file->relocs[i] = (Elf32_Rel *) (file->ptr + file->sects[i]->sh_offset); break; } } } /* These are the most important function - this is where we walk the reloc tables, and fixup the symbol references. By the time this function ends, the incoming binary should be completely ready to go */ static void fixupsection(struct elffile *file, int base, int index) { int i; int section = file->sects[index]->sh_link; Elf32_Sym *table = file->symtab[section]; /* Get the base address of the symbol table */ unsigned int symbase = file->sects[file->sects[index]->sh_info]->sh_addr; /* Get the file offset of the section */ unsigned int foffset = file->sects[file->sects[index]->sh_info]->sh_offset; Elf32_Rel *rel = file->relocs[index]; /* Walk the relocation table */ for(i = 0; i < file->sects[index]->sh_size / sizeof(*rel); i++) { /* This is the relative offset of the reloc */ unsigned int roffset = rel[i].r_offset - symbase; /* This is the actual location in the file where the reference is */ unsigned int *fpos = (unsigned int *) (file->ptr + foffset + roffset); if (ELF32_R_TYPE(rel[i].r_info) == R_386_32) { /* For absolute values, we just update the value in place */ *fpos = (*fpos - symbase) + base; } else if (ELF32_R_TYPE(rel[i].r_info) == R_386_PC32) { unsigned int offset; /* Get the actual symbol this entry indexes to */ Elf32_Sym *sym = &table[ELF32_R_SYM(rel[i].r_info)]; /* we only worry about the absolute values ("external functions") everything else should have the right offsets already */ if (sym->st_shndx != SHN_ABS) continue; /* calculate the new relative offset of the symbol */ offset = sym->st_value - (base + roffset); /* Update the value in the file */ *fpos = 0xfffffffc + offset; } } } static void fixuprelocs(struct elffile *file, int base) { int index; /* Go through the entire list of sections */ for(index = 0; index < file->header->e_shnum; index++) { /* We only care about the relocation tables */ if (file->sects[index]->sh_type != SHT_REL) continue; fixupsection(file, base, index); } } /* Borrowed from reloc.c - pretty print the relocation type */ static const char *reltype(unsigned type) { static const char *type_name[] = { #define REL_TYPE(X) [X] = #X REL_TYPE(R_386_NONE), REL_TYPE(R_386_32), REL_TYPE(R_386_PC32), REL_TYPE(R_386_GOT32), REL_TYPE(R_386_PLT32), REL_TYPE(R_386_COPY), REL_TYPE(R_386_GLOB_DAT), REL_TYPE(R_386_JMP_SLOT), REL_TYPE(R_386_RELATIVE), REL_TYPE(R_386_GOTOFF), REL_TYPE(R_386_GOTPC), #undef REL_TYPE }; const char *name = "UNKNOWN"; if (type < ARRAY_SIZE(type_name)) { name = type_name[type]; } return name; } /* This function shows the list of relocations - not useful in normal usage, but its good for debugging issues */ static void showrelocs(struct elffile *file) { int i, j; for(i = 0; i < file->header->e_shnum; i++) { char *sh_strtab; Elf32_Sym *sh_symtab; unsigned int sec_symtab; /* We only care about the relocation tables */ if (file->sects[i]->sh_type != SHT_REL) continue; /* Get the symbol table index */ sec_symtab = file->sects[i]->sh_link; if (!(file->sects[file->sects[i]->sh_info]->sh_flags & SHF_ALLOC)) continue; /* Get the symbol table and string table */ sh_symtab = file->symtab[sec_symtab]; sh_strtab = file->strtab[file->sects[sec_symtab]->sh_link]; for(j = 0; j < file->sects[i]->sh_size / sizeof(file->relocs[0][0]); j++) { Elf32_Rel *rel; Elf32_Sym *sym; const char *name; rel = &file->relocs[i][j]; sym = &sh_symtab[ELF32_R_SYM(rel->r_info)]; /* Get the name of the symbol */ name = getname(file, sh_strtab, sym); /* Show it */ printf("%d: %08x %08x %10s %08x %s\n", sym->st_shndx, rel->r_offset, rel->r_info, reltype(ELF32_R_TYPE(rel->r_info)), sym->st_value, name); } } } /* This function opens an elf file, mmaps it, and parses the structures */ static int openelf(const char *filename, struct elffile *file) { struct stat s; /* Open the file */ file->fd = open(filename, O_RDWR); /* Get the size */ if (fstat(file->fd, &s)) { fprintf(stderr, "Couldn't stat %s: %m\n", filename); close(file->fd); return -1; } file->size = s.st_size; /* Map the file */ file->ptr = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, file->fd, 0); if (file->ptr == MAP_FAILED) { fprintf(stderr, "Unable to map the file: %m\n"); close(file->fd); return -1; } /* Parse the ELF bits */ getheader(file); getsections(file); return 0; } /* This function closes the ELF file (writing back any changes) */ static void closeelf(struct elffile *file) { if (file->fd > 0) { munmap(file->ptr, file->size); close(file->fd); } file->fd = 0; } struct elffile relocs; int main(int argc, char **argv) { int frelocs = 0; unsigned int base = 0; /* Options: -S - specify the symbols table to use when fixing up the relocations -v - be verbose -r - Show the relocation tables in the image - for debugging -b - Specify the base address for the initram (as a hex value) */ while(1) { signed char ch = getopt(argc, argv, "S:vrlb:"); if (ch == -1) break; switch(ch) { case 'b': base = strtoul(optarg, 0, 0); case 'v': verbose = 1; break; case 'r': frelocs=1; break; } } if (optind >= argc) { printf("Error - you must specify an object file to fixup\n"); return -1; } if (openelf(argv[optind], &relocs)) return -1; else if (frelocs) showrelocs(&relocs); else { if (verbose) printf("Fixing up the object file %s (using base %x)\n", argv[optind], base); fixuprelocs(&relocs, base); } closeelf(&relocs); return 0; }

2 3

[LinuxBIOS] Initram+XIP
by Jordan Crouse 05 Oct '07

05 Oct '07

(This is a long e-mail. I apologize, but I feel this is important to cover). This week I've been working with LinuxBIOSv3 to try to get over the XIP initram problem. For those that tuning in late, here's the recap: There are some symbols that we use that we want to define once, and use in different segments (such as printk). This is very easy to do for segments that are loaded and run at a particular location in memory, by passing in the symbol list from stage0 to LD through the -R command line option, from which LD figures the right relative offsets. The problem is, this is only easy if you know where your code is executing, and pass the appropriate fu into LD. For most systems, we need to run at least the initram segment in place on the ROM which are not always located at a known location - there can be multiple initram blocks, and LAR can put them anywhere it wishes. Needless to say, this breaks things badly when we try to call functions in the bootblock with a relative offset that walks into the weeds. So my quest this week was to try to find a list of solutions that we can consider as a group. The only criteria I had for a solution is that it needed to maintain the independence of the individual segments (i.e. - I couldn't just cheat and link the bootblock and initram together). Any other legitimate solution was on the table, though obviously, the more simple and obvious the better. Here's what I came up with: ----------------------------------------- Solution 1 - fixed locations the -R trick to LD works for the XIP modules too, assuming that you link it at the right address where it will execute in the ROM. The very simplest way to do this would be to define fixed locations for the initram(s) and feed those in to to LD (through a platform configuration). This would be remotely similar to v2. PROS: Easy CONS: Completely breaks the LAR model, wastes ROM space, and really breaks the whole v3 concept. Solution 2 - relink the image Like above, we use -R to pass in the symbols from stage0. we link the image at an arbitrary address (say, 0x0), and build it into the LAR. We can then ask LAR where it put the segment, and then relink the segment at that address, and replace it in the LAR. There may be other things we can do with LAR to make this easier - perhaps just pass in the sizes of the segments to LAR and have it return the offsets without actually constructing an archive, perhaps? PROS: Fits in the v3 model CONS: Complex, and relies on some scripts to do the right thing with LAR. Also, its confusing to relink twice. Solution 3 - postlinker Again, we use -R to pass in the symbols from stage0 and link the segment to 0x0. But instead of re-linking when we learn the address, we run a special utility that will read the relocation tables in the ELF and update the addresses in the ELF. This should be somewhat more lightweight then re-linking. The same problems with LAR still exist here - the key is finding out the address we need to link to. PROS: Fits into the v3 model, less complex then relinking CONS: Finding the address from LAR will be a challenge. Plus its another custom utility to maintain. Solution 3.5 - postlinker + symbol table One CON for all of these is that each solution requires us to have the stage0.o ELF file laying around. To me, that sort of defeats the purpose of independence. So the 4th option is similar to the 3rd (and suffers from the same problems), but instead of using -R to pass the symbols to LD during the link stage, we leave the shared symbols undefined. Then, we grab a list of shared symbols from stage0.o (which could easily be a "published" list, and feed that into the custom script from above, which could fill in the undefined shared symbols. PROS: One could build an initram completely separate from stage0 (which is the goal). CONS: An extra stage of abstraction to get the symbol table. It would be difficult to ensure that the symbol table matches the current bootblock. Finding the address from the LAR remains a challenge. Custom utility. ----------------------------------------- I vote for #3 and possibly #4. I've spent some time writing the very custom app described above, and I used it with a little manual trickery to make the Geode boot through the initram stage (I'll send it out in a separate e-mail). Figuring out the right address from LAR will be the tricky part - for that i really don't have a good idea (I build the lar with the un-modified initram, listed the lar, figured out the address, ran my tool, and re-lared the new initram. I don't recommend that method - too much possibility for failure). So, why am I telling you this? Because I think the time is ripe for a discussion - we know what needs to be done code wise, and we have a list of options at our disposal, but the most important thing we need is consensus. I don't want this to be some crazy scheme cooked up late at night and snuck into the code base when nobody is looking. Thoughts? Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.

2 1

Re: [LinuxBIOS] flashrom support for AMD Geode CS5536
by Jordan Crouse 05 Oct '07

05 Oct '07

Sigh - I hit 'r' instead of 'g'. I blame mutt... :) On 05/10/07 11:35 -0600, Jordan Crouse wrote: > On 05/10/07 10:16 -0600, Marc Jones wrote: > > > > > > Lane Brooks wrote: > > > Here it is again with the patch actually attached. > > > > > > Lane Brooks wrote: > > >> Here is the patch again with an updated comment regarding SMP and a > > >> signed-off-by line. > > >> > > >> Signed-off-by: Lane Brooks <lbrooks(a)mit.edu> > > >> > > >> ron minnich wrote: > > >>> On 10/2/07, Lane Brooks <lbrooks(a)mit.edu> wrote: > > >>>> 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? > > >>> it's not, but it is not really an issue at present. > > >>>> - 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 is possible I think to have udev help with this, but I am not sure. > > >>> Graceful failure is certainly a good start. > > >>> > > >>>> - 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... > > >>> I thought that was in the structure of flashrom. Now that I look, it > > >>> seems like we lost it! > > >>> I propose this at the end of flashrom: > > >>> board_flash_disable(lb_vendor, lb_part); > > >>> chipset_flash_disable(chipset); > > >>> > > >>> but we'll need to change some things to make this all work. We need a > > >>> penable struct * to use for the disable; no point in searching each > > >>> time we touch a chip. or not? > > >>> > > >>> one comment on your patch: you use /dev/cpu/0/msr. This is great for a > > >>> single-cpu machine, and will always be fine on geode. Lots of times, > > >>> people use one piece of flashrom to write another. Imagine some future > > >>> hacker, in a year or two, who has copied your code for some SMP > > >>> system, not understanding why sometimes flashrom fails (i.e. they set > > >>> CPU0 msr but end up running on cpu1). We had this very problem when we > > >>> were getting graphics going (and, earlier, SMP going). I suggest a > > >>> comment as to why the /dev/cpu/0/msr is always safe on geode, but > > >>> future hackers beware on SMP. Or something like that. > > >>> > > >>> That's up to you, however :-) > > >>> > > >>> If you had a signed-off-by line, I would ack and commit for you :-) > > >>> > > >>> ron > > >>> > > >>> ron > > >> > > > > Did anyone ack and commit this last version? > > I think ron Acked it, but I'll ack again. > > Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> > > > Marc > > > > > > > > -- > > Marc Jones > > Senior Firmware Engineer > > (970) 226-9684 Office > > mailto:Marc.Jones@amd.com > > http://www.amd.com/embeddedprocessors > > > > > > > > -- > > linuxbios mailing list > > linuxbios(a)linuxbios.org > > http://www.linuxbios.org/mailman/listinfo/linuxbios > > > > > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.

2 1

[LinuxBIOS] r2828 build service
by LinuxBIOS information 05 Oct '07

05 Oct '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2828 to the LinuxBIOS source repository and caused the following changes: Change Log: Add dump support for the Winbond W83627HF/F/HG/G. Signed-off-by: Rasmus Wiman <rasmus(a)wiman.org> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=hdama&vendor=… Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=e325&vendor=i… Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=e326&vendor=i… Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=juki-511p&ven… Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=dk8s2&vendor=… Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=dk8x&vendor=i… Compilation of newisys:khepri is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2828&device=khepri&vendor… If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system

1 0

[LinuxBIOS] Tyan Thunder n3600R (S2912) support status?
by niko 05 Oct '07

05 Oct '07

Hello there, I'm in the midst of an upgrade for my server, but I want the entire thing to run 100% Free Software, including LinuxBIOS. The Tyan S2912 seems to be a perfect match feature/specifications wise for what I am searching for. I need a dual Socket F board with built in SAS and SATA2 with RAID-5 support on the latter, and ideally two gigabit NICs to boot. This Tyan board largely fits this description more than any other board on the LinuxBIOS supported motherboard compatibility list. The problem is that on the list it is still marked "WIP" with a yellow box instead of a green one. What is the current status of LinuxBIOS support for this board? Will it work at all or maybe partially? What is/isn't working? I need these certain features on my next motherboard, but I also need stability with LinuxBIOS on the board. Is this too much to ask for a dual Socket F board such as this Tyan? I should also note that I'm not particularly attached to this board. If LinuxBIOS works better with another dual Socket F board, I would love to know about it. I just need the SAS and SATA2, really. I would sincerely love it if someone could help me understand the current state of LinuxBIOS support for this class of motherboards... ..here's hoping the compatibility list is out of date! Thank you, ©Niko

5 7

[LinuxBIOS] r2828 - trunk/util/superiotool
by svn＠openbios.org 05 Oct '07

05 Oct '07

Author: uwe Date: 2007-10-05 23:58:03 +0200 (Fri, 05 Oct 2007) New Revision: 2828 Modified: trunk/util/superiotool/winbond.c Log: Add dump support for the Winbond W83627HF/F/HG/G. Signed-off-by: Rasmus Wiman <rasmus(a)wiman.org> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/winbond.c =================================================================== --- trunk/util/superiotool/winbond.c 2007-10-05 21:00:10 UTC (rev 2827) +++ trunk/util/superiotool/winbond.c 2007-10-05 21:58:03 UTC (rev 2828) @@ -2,6 +2,7 @@ * This file is part of the superiotool project. * * Copyright (C) 2007 Uwe Hermann <uwe(a)hermann-uwe.de> + * Copyright (C) 2007 Rasmus Wiman <rasmus(a)wiman.org> * * 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 @@ -164,6 +165,48 @@ /* ID only */ {0x52, "W83627HF/F/HG/G", { + {NOLDN, NULL, + {0x02,0x07,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x28, + 0x29,0x2a,0x2b,0x2c,0x2e,0x2f,EOT}, + {0x00,NANA,0x52,NANA,0xff,0x00,MISC,0x00,0x00,0x00, + 0x00,0x7c,0xc0,0x00,0x00,0x00,EOT}}, + {0x0, "Floppy", + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4, + 0xf5,EOT}, + {0x01,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00, + 0x00,EOT}}, + {0x1, "Parallel port", + {0x30,0x60,0x61,0x70,0x74,0xf0,EOT}, + {0x01,0x03,0x78,0x07,0x04,0x3f,EOT}}, + {0x2, "COM1", + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x01,0x03,0xf8,0x04,0x00,EOT}}, + {0x3, "COM2", + {0x30,0x60,0x61,0x70,0xf0,0xf1,EOT}, + {0x01,0x02,0xf8,0x03,0x00,0x00,EOT}}, + {0x5, "Keyboard", + {0x30,0x60,0x61,0x62,0x63,0x70,0x72,0xf0,EOT}, + {0x01,0x00,0x60,0x00,0x64,0x01,0x0c,0x80,EOT}}, + {0x6, "Consumer IR", + {0x30,0x60,0x61,0x70,EOT}, + {0x00,0x00,0x00,0x00,EOT}}, + {0x7, "Game port, MIDI port, GPIO 1", + {0x30,0x60,0x61,0x62,0x63,0x70,0xf0,0xf1,0xf2,EOT}, + {0x00,0x02,0x01,0x03,0x30,0x09,0xff,0x00,0x00,EOT}}, + {0x8, "GPIO 2, Watchdog timer", + {0x30,0xf0,0xf1,0xf2,0xf3,0xf5,0xf6,0xf6,0xf7,EOT}, + {0x00,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}}, + {0x9, "GPIO 3", + {0x30,0xf0,0xf1,0xf2,0xf3,EOT}, + {0x00,0xff,0x00,0x00,0x00,EOT}}, + {0xa, "ACPI", + {0x30,0x70,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7, + 0xf0,0xf1,0xf3,0xf4,0xf6,0xf7,0xf9,0xfe,0xff,EOT}, + {0x00,0x00,0x00,0x00,NANA,NANA,0x00,0x00,0x00,0x00, + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}}, + {0xb, "Hardware monitor", + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x00,0x00,0x00,0x00,EOT}}, {EOT}}}, /* ID[3..0] */

1 0

[LinuxBIOS] r2827 build service
by LinuxBIOS information 05 Oct '07

05 Oct '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "rminnich" checked in revision 2827 to the LinuxBIOS source repository and caused the following changes: Change Log: This patch will add support for the Geode GX1/CS5530 VGA feature. It's able to set up one of five screen resolutions (sorry no autodetection at runtime, resolution is selected at buildtime) and displays a graphic in the right bottom corner (splash screen). Signed-off-by: Juergen Beisert <juergen127(a)kreuzholzen.de> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=hdama&vendor=… Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=e325&vendor=i… Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=e326&vendor=i… Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=juki-511p&ven… Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=dk8s2&vendor=… Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=dk8x&vendor=i… Compilation of newisys:khepri is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2827&device=khepri&vendor… If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system

1 0

← Newer
1
...
38
39
40
41
42
43
44
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2007