coreboot

coreboot@coreboot.org

10 participants
39710 discussions

Re: Help on epia-m 10000 linuxbios VGA
by Dave Ashley 13 Nov '03

13 Nov '03

> Santi Mirenna >In attach you have the output log .... >Can someone tell me where i wrong? You haven't applied all the patch, specifically the handler for the unsupported bios interrupts. This is the bug where it just gets into an endless loop of bios interrupts, so the program needs to exit the bios somehow. -Dave

1 0

Help on epia-m 10000 linuxbios VGA
by Santi Mirenna 13 Nov '03

13 Nov '03

Hi to all, today i make EPIA-M 10000 rom image. i compile to have VGA and Filo, after apply patch of Dave Ashley and info from Takeshi about RAM ammount VGA now is found by the system but .... In attach you have the output log .... Can someone tell me where i wrong? ********************************************************************************************** Santi Mirenna INGV - Istituto Nazionale di Geofisica e Vulcanologia Sezione di Milano via Bassini 15, 20133 Milano, Italy tel. +39-02-23699278 fax +39-02-23699458 e mail: santi.mirenna(a)mi.ingv.it ********************************************************************************************** Questo messaggio è di carattere riservato ed è indirizzato esclusivamente al destinatario specificato. L'accesso, la divulgazione, la copia o la diffusione sono vietate a chiunquealtro ai sensi delle normative vigenti, e possono costituire una violazione penale. In caso di errore nella ricezione, il ricevente è tenuto a cancel lare immediatamente il messaggio, dandone conferma al mittente a mezzo e-mail. This e-mail is confidential and is for the intended recipient only. Access, disclosure, copying, distribution or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to sender.

1 0

Help on config of "epia-m.config" file
by Santi Mirenna 07 Nov '03

07 Nov '03

Hi to all, yesterday i make my first EPIA-M 10000 rom image. With the help of Eddy i compile to have VGA and Filo. In attach you have the output log .... The problem is : - LinuxBios tell that the RAM is 127Mbye (and i had 256Mbyte) - LinuxBios tell that there is no VGA (and i add the VGA bios image in to) Can someone tell me where i wrong? ********************************************************************************************** Santi Mirenna INGV - Istituto Nazionale di Geofisica e Vulcanologia Sezione di Milano via Bassini 15, 20133 Milano, Italy tel. +39-02-23699278 fax +39-02-23699458 e mail: santi.mirenna(a)mi.ingv.it ********************************************************************************************** Questo messaggio è di carattere riservato ed è indirizzato esclusivamente al destinatario specificato. L'accesso, la divulgazione, la copia o la diffusione sono vietate a chiunquealtro ai sensi delle normative vigenti, e possono costituire una violazione penale. In caso di errore nella ricezione, il ricevente è tenuto a cancel lare immediatamente il messaggio, dandone conferma al mittente a mezzo e-mail. This e-mail is confidential and is for the intended recipient only. Access, disclosure, copying, distribution or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to sender.

4 5

Re: [Fwd: NXTV's current linuxbios patch]
by Dave Ashley 06 Nov '03

06 Nov '03

>Hi, >please, now that i get the patch ...can you tell me how to apply it. >Tino. The ability to apply patches is probably a reasonable prerequisite for any hacking with freebios :^). But the posting was answering Ron's request for the patch. The problem with my patch is it is like my own fork off of an older version of freebios than what is available now. My patch would be more for informational purposes, however it could be incorporated into the freebios source in part or whole. I cut a few corners with my approach: 1) Cut and pasted some other spd/smbus code just to be able to view the DDR spd contents. The actual ddr ram configuration is *not* done in this patch, I left the code segments in hoping to study them and figure out how to do it for the epia-m. Basically the code in the smbus.inc is a copy of code that I found elsewhere in freebios. Right now it is just useless bloat. 2) I walk all over the CMOS ram contents just because I wanted a way to carry over a version string from linuxbios to linux. Linuxbios compresses everything so I couldn't easily scan the rom for a version string. There is probably another way to address this problem. I just copied the version string into the upper 128 bytes of the epia-m's cmos memory. I also use byte $0e of cmos as a flag because I do a hard pci bus reset to get the system cleanly setup. I need to keep track of whether I've already reset once so it doesn't just endlessly reset. 3) The config file used to build the epia-m is built as part of an external Makefile--I take the one inside the epia-m's directory and tack on a few extra lines that say where the payload is. The payload is built in another directory, based on etherboot code. This approach is foreign to freebios but served our purposes. There is no toplevel Makefile in the normal freebios tree. The really critical code to consider bringing into freebios/epia-m is A) VGA register init + setup B) VGA bios stuff C) VGA bios lockup fix, if an unacceptable INT is called, vga init is aborted. D) Actual pci reset on startup to reset the pci card to known state. This prevents lockups if the card is requesting an interrupt for example. E) Code to access the smbus/SPD which is a starting point to auto config of DDR F) VGA bios wants certain INT's implemented, these are implemented and seem to be ok. G) The pci firewire device comes up configured to respond to IO at 0 to 7f or so, which means the cmos ram can't be accessed. This part has to be moved out of the way. Normal pci configuration fixes this, but if you need to access some other device at those io ports early on you need to move the pci firewire device out of the way, this is a gotcha I had to get past. H) Audio + usb irq's were not initialized properly. I) The hardware status monitor was not initialized and activated. J) Shadow ram for copying the vga bios over wasn't initialized K) Shadow ram for vga bios wasn't write protected. Could be important. That's about it. I don't know the status of epia-m freebios (not freebios2). I don't know if vga is supported in the current CVS version, or any other details. -Dave

2 1

config -> default
by Stefan Reinauer 06 Nov '03

06 Nov '03

Hi, most of the builds are broken again since "config" in the mainboard config file now has to be renamed to "default". On the one hand I see the reason for most of these changes, even though I am not sure if we want to suggest that some stuff can be overridden in the target config file, like: -option CONFIG_IOAPIC=1 +default CONFIG_IOAPIC=1 Can those changing elementary stuff like this that breaks all builds try to apply some regexps on the Config files so that other builds don't break? Getting further is somewhat hard currently since the code almost instantly breaks after the last fixes are checked in.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development

1 0

[Fwd: NXTV's current linuxbios patch]
by Xavier Pegenaute 06 Nov '03

06 Nov '03

Hi, the patch is this one, is a message from Tue, probably you will have also. If you don't have i'll send you the patch. About the memory, after the patch, in src/mainboard/via/epia-m/smbus.inc, at line 245, there is something i didn't tryed yet but i think is it. I think there is something more else... I saw in your log, i have also epia-m 10000 and ,my VGA is: lspci -n -> 01:00.0 Class 0300: 1106:3122 (rev 03) lspci -> 01:00.0 VGA compatible controller: VIA Technologies, Inc.: Unknown device 3122 (rev 03) Xavi. -----Forwarded Message----- > From: Dave Ashley <linuxbios(a)xdr.com> > To: linuxbios(a)clustermatic.org > Subject: NXTV's current linuxbios patch > Date: 04 Nov 2003 14:00:46 -0800 > > I did a clean cvs checkout of freebios, then updated to 2003/7/5, and > did a diff between what's in our cvs and that, and this is the result. > It appears to be everything I touched. I got rid of all the CVS tree > differences. >

2 1

Add size option and checks to flash_rom
by Peter Fox 06 Nov '03

06 Nov '03

The patch below adds a size option to flash_rom, and also verifies that the bios image being flashed matches the rom size. (Previously, if the rom image was too small, the image would be flashed at the beginning of the rom, so the reset vector would be in the wrong place.) The advantage of this change is that it is no longer necessary to pack the bios image up to the rom size, thus saving programming time. And it is also not necessary to hack the code if you've wired the top bit to a switch as a BIOS saviour. It still doesn't check for an image too big, though that should be taken care of in the build process. Index: flash_rom.c =================================================================== RCS file: /home/fox/freebios-latest/freebios/util/flash_and_burn/flash_rom.c,v retrieving revision 1.23 diff -u -r1.23 flash_rom.c --- flash_rom.c 2003/09/12 22:41:53 1.23 +++ flash_rom.c 2003/11/06 08:41:33 @@ -272,11 +272,12 @@ return 0; } -struct flashchip * probe_flash(struct flashchip * flash) +struct flashchip * probe_flash(struct flashchip * flash, int pretend_size) { int fd_mem; volatile char * bios; unsigned long size; + int total_size; if ((fd_mem = open("/dev/mem", O_RDWR)) < 0) { perror("Can not open /dev/mem"); @@ -288,15 +289,18 @@ flash++; continue; } - printf("Trying %s, %d KB\n", flash->name, flash->total_size); - size = flash->total_size * 1024; + total_size = flash->total_size; + if((pretend_size != -1)&&(pretend_size < total_size)) + total_size = pretend_size; + printf("Trying %s, %d KB\n", flash->name, total_size); + size = total_size * 1024; /* BUG? what happens if getpagesize() > size!? -> ``Error MMAP /dev/mem: Invalid argument'' NIKI */ if(getpagesize() > size) { size = getpagesize(); printf("%s: warning: size: %d -> %ld\n", __FUNCTION__, - flash->total_size * 1024, (unsigned long)size); + total_size * 1024, (unsigned long)size); } bios = mmap (0, size, PROT_WRITE | PROT_READ, MAP_SHARED, fd_mem, (off_t) (0 - size)); @@ -310,6 +314,7 @@ if (flash->probe(flash) == 1) { printf ("%s found at physical address: 0x%lx\n", flash->name, (0 - size)); + flash->total_size = total_size; return flash; } munmap ((void *) bios, size); @@ -441,11 +446,12 @@ void usage(const char *name) { - printf("usage: %s [-rwv] [-c chipname][file]\n", name); + printf("usage: %s [-rwv] [-c chipname] [-s size] [file]\n", name); printf("-r: read flash and save into file\n" "-w: write file into flash (default when file is specified)\n" "-v: verify flash against file\n" "-c: probe only for specified flash chip\n" + "-s: pretend device is smaller, specify the size in k\n" " If no file is specified, then all that happens\n" " is that flash info is dumped\n"); exit(1); @@ -456,6 +462,7 @@ { char * buf; unsigned long size; + int pretend_size = -1; FILE * image; struct flashchip * flash; int opt; @@ -464,7 +471,7 @@ setbuf(stdout, NULL); - while ((opt = getopt(argc, argv, "rwvc:")) != EOF) { + while ((opt = getopt(argc, argv, "rwvc:s:")) != EOF) { switch (opt) { case 'r': read_it = 1; @@ -478,6 +485,9 @@ case 'c': chip_to_probe = strdup(optarg); break; + case 's': + pretend_size = atoi(optarg); + break; default: usage(argv[0]); break; @@ -500,7 +510,7 @@ */ (void) enable_flash_write(); - if ((flash = probe_flash (flashchips)) == NULL) { + if ((flash = probe_flash (flashchips, pretend_size)) == NULL) { printf("EEPROM not found\n"); exit(1); } @@ -527,12 +537,18 @@ fclose(image); printf("done\n"); } else { + unsigned long filesize = 0; if ((image = fopen (filename, "r")) == NULL) { perror(filename); exit(1); } - fread (buf, sizeof(char), size, image); + filesize = fread (buf, sizeof(char), size, image); fclose(image); + if(filesize != size) + { + fprintf(stderr, "File size doesn't match device size\n"); + exit(1); + } } if (write_it || (!read_it && !verify_it)) -- Peter Fox <peter.fox(a)aeroflex.com> Aeroflex Test Solutions Principal Design Engineer Stevenage Any opinions expressed above are http://www.aeroflex.com/ not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200

1 0

Bug in am29f040b.c causes flash device not to be recognised
by Peter Fox 06 Nov '03

06 Nov '03

The following patch needs to be applied to am29f040b.c in the utils/flash_and_burn directory: ---------------------- --- am29f040b-nv.c Wed Nov 5 14:33:34 2003 +++ am29f040b.c Wed Nov 5 14:20:26 2003 @@ -76,8 +76,8 @@ *(bios + 0x2AA) = 0x55; *(bios + 0x555) = 0x90; - id1 = *(unsigned char *) bios; - id2 = *(unsigned char *) (bios + 0x01); + id1 = *(volatile unsigned char *) bios; + id2 = *(volatile unsigned char *) (bios + 0x01); *bios = 0xF0; ---------------------- My C compiler was reordering the writes and reads, so that the flash wasn't ready to give an id when the reads occurred. I notice that all the other flash devices already seem to have this correct. -- Peter Fox <peter.fox(a)aeroflex.com> Aeroflex Test Solutions Principal Design Engineer Stevenage Any opinions expressed above are http://www.aeroflex.com/ not necessarily those of Aeroflex. Tel: + 44 (0) 1438 742200

2 2

LinuxBios in epia m-10000 (freebios2)
by Xavier Pegenaute 05 Nov '03

05 Nov '03

Hi, now i know more things :-) Yes was there some thing printed in serial line, but i was so nervious and i did'nt see it, i'm sorry. The line that is printed is: "Serial controller not found", if i search for this line in the code i find it only in: src/southbridge/via/vt8231/vt8231_early_serial.c, inside this code the lines are: static void enable_vt8231_serial(void) { unsigned long x; uint8_t c; device_t dev; outb(6, 0x80); dev = pci_locate_device(PCI_ID(0x1106,0x8231), 0); if (dev == PCI_DEV_INVALID) { outb(7, 0x80); die("Serial controller not found\r\n"); ... etc. if i'm not wrong, the first problem is the southbridge, the code for epia is looking for vt8231, and i have vt8235 :-) Ok. I saw in "freebios" that there is code for vt8235, then i think that i'm going to try first with the old version, and once that i see how LinuxBios is in live, if i have enough (i hope, at least for curiosity) time i'll port it to the new one if nobody made it before. By the other hand, the northbridge in the manual is CLE266, that axactly i don't know how is named in the standard way (vt8633 may be ?), i don't know if i'll have the same problem (probably i think). ------------------------------------------------------------------ My lspci, is this: 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3123 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant IEEE 1394 Host Controller (rev 80) 00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74) 01:00.0 VGA compatible controller: VIA Technologies, Inc.: Unknown device 3122 (rev 03) ------------------------------------------------------------------ And lspci -n, is this one: 00:00.0 Class 0600: 1106:3123 00:01.0 Class 0604: 1106:b091 00:0d.0 Class 0c00: 1106:3044 (rev 80) 00:10.0 Class 0c03: 1106:3038 (rev 80) 00:10.1 Class 0c03: 1106:3038 (rev 80) 00:10.2 Class 0c03: 1106:3038 (rev 80) 00:10.3 Class 0c03: 1106:3104 (rev 82) 00:11.0 Class 0601: 1106:3177 00:11.1 Class 0101: 1106:0571 (rev 06) 00:11.5 Class 0401: 1106:3059 (rev 50) 00:12.0 Class 0200: 1106:3065 (rev 74) 01:00.0 Class 0300: 1106:3122 (rev 03) ------------------------------------------------------------------ Thanks a lot. Xavi. PD: Sorry by the long text.

5 8

Trying to get a handle on CMOS usage
by ron minnich 05 Nov '03

05 Nov '03

I just found an issue with CMOS usage, and I am trying to figure out what tools use CMOS in which cases. So, can we summarize: - does etherboot do anything to bits in CMOS? If so, what? - what bits in CMOS is linuxbios V2 currently messing with? (yeah, I should know this, but it turns out I don't currently; I'm still looking for the place where linuxbios V2 writes to cmos nowadays) Finally, is the CMOS really 256 bytes nowadays on something like the EPIA, or are we stuck at 128 still? I'm not sure at this point. Any and all information would be nice to have. The problem I've hit is that I'm storing authentication data for Plan 9 in cmos, and it appears that linuxbios/etherboot are storing to bytes at location 0x1f or so, which is bad for me. I need to find 112 bytes that will be unmolested by either linuxbios or etherboot. thanks ron

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot