Hi, I modified the flash_rom program a little and it might be useful for others. - Add "enable" for VIA VT8231 (southbridge of EPIA board) This does same thing as what is in src/mainboard/via/epia/README. (Btw, I downloaded the datasheet for VT8231 from here: http://www.google.com/search?q=vt8231+application%2Fpdf It's publically online ;-) - Fixed segfault when no "enable" is defined for a board. - Fixed delay calibration so it really finishes in a second (original code takes up to 100 seconds theoretically, >10 seconds on my box) - Support for -r (read), -w (write), and -v (verify). Writing is not really tested since I don't have my BIOS Savior yet. Looking forward to trying out LinuxBIOS on my box. Thanks for the great work. -- Takeshi Index: flash_rom.c =================================================================== RCS file: /cvsroot/freebios/freebios/util/flash_and_burn/flash_rom.c,v retrieving revision 1.16 diff -u -r1.16 flash_rom.c --- flash_rom.c 28 Feb 2003 17:21:37 -0000 1.16 +++ flash_rom.c 12 Mar 2003 14:03:11 -0000 @@ -136,6 +136,9 @@ new = old | 1; + if (new == old) + return 0; + ok = pci_write_byte(dev, 0x4e, new); if (ok != new) { @@ -146,6 +149,28 @@ return 0; } +int +enable_flash_vt8231(struct pci_dev *dev, char *name) { + unsigned char old, new; + int ok; + + old = pci_read_byte(dev, 0x40); + + new = old | 0x10; + + if (new == old) + return 0; + + ok = pci_write_byte(dev, 0x40, new); + + if (ok != 0) { + printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n", + old, new, name); + return -1; + } + return 0; +} + struct flashchip * probe_flash(struct flashchip * flash) { int fd_mem; @@ -227,8 +252,8 @@ timeusec = 1000000 * (end.tv_sec - start.tv_sec ) + (end.tv_usec - start.tv_usec); fprintf(stderr, "timeusec is %d\n", timeusec); - count *= 100; - if (timeusec < 1000000) + count *= 2; + if (timeusec < 1000000/3) continue; ok = 1; } @@ -260,6 +285,7 @@ {0x1, 0x1, "sis630 -- what's the ID?", enable_flash_sis630}, {0x8086, 0x2480, "E7500", enable_flash_e7500}, + {0x1106, 0x8231, "VT8231", enable_flash_vt8231}, }; int @@ -291,10 +317,25 @@ } /* now do the deed. */ - enable->doit(dev, enable->name); + if (enable) { + printf("Enabling flash write on %s...", enable->name); + if (enable->doit(dev, enable->name) == 0) + printf("OK\n"); + } return 0; } +void usage(const char *name) +{ + printf("usage: %s [-rwv] [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" + " If no file is specified, then all that happens\n" + " is that flash info is dumped\n"); + exit(1); +} + int main (int argc, char * argv[]) { @@ -302,12 +343,36 @@ unsigned long size; FILE * image; struct flashchip * flash; - - if (argc > 2){ - printf("usage: %s [romimage]\n", argv[0]); - printf(" If no romimage is specified, then all that happens\n"); - printf(" is that flash info is dumped\n"); + int opt; + int read_it = 0, write_it = 0, verify_it = 0; + char *filename = NULL; + while ((opt = getopt(argc, argv, "rwv")) != EOF) { + switch (opt) { + case 'r': + read_it = 1; + break; + case 'w': + write_it = 1; + break; + case 'v': + verify_it = 1; + break; + default: + usage(argv[0]); + break; + } } + if (read_it && write_it) { + printf("-r and -w are mutually exclusive\n"); + usage(argv[0]); + } + + if (optind < argc) + filename = argv[optind++]; + + printf("Calibrating timer since microsleep sucks ... takes a second\n"); + myusec_calibrate_delay(); + printf("OK, calibrated, now do the deed\n"); /* try to enable it. Failure IS an option, since not all motherboards * really need this to be done, etc., etc. It sucks. @@ -320,25 +385,35 @@ } printf("Part is %s\n", flash->name); - if (argc < 2){ + if (!filename){ printf("OK, only ENABLING flash write, but NOT FLASHING\n"); return 0; } size = flash->total_size * 1024; - - if ((image = fopen (argv[1], "r")) == NULL) { - perror("Error opening image file"); - exit(1); - } - buf = (char *) calloc (size, sizeof(char)); - fread (buf, sizeof(char), size, image); - printf("Calibrating timer since microsleep sucks ... takes a second\n"); - myusec_calibrate_delay(); - printf("OK, calibrated, now do the deed\n"); + if (read_it) { + if ((image = fopen (filename, "w")) == NULL) { + perror("Error opening image file"); + exit(1); + } + printf("Reading Flash..."); + memcpy(buf, (const char *) flash->virt_addr, size); + fwrite(buf, sizeof(char), size, image); + fclose(image); + printf("done\n"); + } else { + if ((image = fopen (filename, "r")) == NULL) { + perror("Error opening image file"); + exit(1); + } + fread (buf, sizeof(char), size, image); + fclose(image); + } - flash->write (flash, buf); - verify_flash (flash, buf, /* verbose = */ 0); + if (write_it) + flash->write (flash, buf); + if (verify_it) + verify_flash (flash, buf, /* verbose = */ 0); return 0; }
thanks very much. If anyone would like to put code in to support reading/writing different segments of flash, we could use it. ron
Greetings, You have good timing. I was just finishing up a 'universal' flash tool that can do that and handle payload tags as well (for use with bootselect). It also supports block locking/unlocking for devices having that feature. It has a seperate flash_on utility. It should be fairly easy to merge in devices from flash_rom. I'll get that posted soon. G'day, sjames On Wed, 12 Mar 2003, Ronald G. Minnich wrote:
thanks very much.
If anyone would like to put code in to support reading/writing different segments of flash, we could use it.
ron
_______________________________________________ Linuxbios mailing list Linuxbios@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 -----------------------------------------------------------------------
steve can you just integrate flash_on into the tool, as I started to do in flash_rom? ron
Greetings, Sure, it's done. Just a matter of linking. G'day, sjames On Wed, 12 Mar 2003, Ronald G. Minnich wrote:
steve can you just integrate flash_on into the tool, as I started to do in flash_rom?
ron
_______________________________________________ Linuxbios mailing list Linuxbios@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 -----------------------------------------------------------------------
Hello guys! Yesterday I spent the day fighting the flash_rom on my pcchips m787cl+ board (SiS630). It just won't work. It mmaps correctly and I can read the BIOS (i created a flash_save tool based on the flash_rom.c code), but the chip identification just doesn't work. My assumption is that it doesn't disable Shadow memory before sending the SoftID sequence to the flash. Btw, the 'flash_and_burn' thing simply doesn't compile complaining on the absence of the 'pci/pci.h' file. So I use flash_rom.c from the 'sis630' directory. But that was just a preface. What I was going to say here is after I gave up fighting with the flash_rom.c, I started searching the Internet for universal flash writers. And you know what? I found a marvelous tool - Uniflash! It can flash almost any flash part on almost any motherboard with any file you say. The tool is written in Pascal for DOS and is open source. I think those of you here who are into the development of the flash_rom.c can use that source to make flash_rom.c way more compatible than it is now. For now I prefer using Uniflash from DOS. It made my m787cl+ boot LinixBIOS in less than a minute after I spent the day fighting the flash_rom.c :)))) Here is the link: http://www.krizovakomunikacia.sk/rainbow/programs.html#UniFlash With best regards, Alexander mailto:spirit@reactor.ru Reactor Critical - 3D Hardware reviews http://www.reactor.ru - in Russian http://www.reactorcritical.com - in English --8<--just-a-cookie---------------------------------------------- Those who contemn Real Programmers are contemned by them more than those who contemn them contemn them. If you understood that then you're a Real Programmer. --8<-------------------------------------------------------------
I wonder if it doesn't make more sense to use the Linux MTD framework. I have begun porting devbios to it. I have refactored devbios into two halves, devbios and a flash library/map library. The MTD chip driver which uses the library is about half done. Perhaps then the LinuxBIOS flash tool can be split into a map driver (the shadow control stuff) and a chip driver for the individual flash chips, then included into MTD. Regards, Jeremy PS - I've used Uniflash, it's very old code with lots of nice global variables and such, but it did help me get an Atmel flash chip working. On Thu, 2003-03-13 at 05:42, Alexander Amelkin wrote:
Hello guys!
Yesterday I spent the day fighting the flash_rom on my pcchips m787cl+ board (SiS630). It just won't work. It mmaps correctly and I can read the BIOS (i created a flash_save tool based on the flash_rom.c code), but the chip identification just doesn't work. My assumption is that it doesn't disable Shadow memory before sending the SoftID sequence to the flash. Btw, the 'flash_and_burn' thing simply doesn't compile complaining on the absence of the 'pci/pci.h' file. So I use flash_rom.c from the 'sis630' directory.
But that was just a preface. What I was going to say here is after I gave up fighting with the flash_rom.c, I started searching the Internet for universal flash writers. And you know what? I found a marvelous tool - Uniflash! It can flash almost any flash part on almost any motherboard with any file you say. The tool is written in Pascal for DOS and is open source. I think those of you here who are into the development of the flash_rom.c can use that source to make flash_rom.c way more compatible than it is now.
For now I prefer using Uniflash from DOS. It made my m787cl+ boot LinixBIOS in less than a minute after I spent the day fighting the flash_rom.c :))))
Here is the link: http://www.krizovakomunikacia.sk/rainbow/programs.html#UniFlash
With best regards, Alexander mailto:spirit@reactor.ru Reactor Critical - 3D Hardware reviews http://www.reactor.ru - in Russian http://www.reactorcritical.com - in English
--8<--just-a-cookie---------------------------------------------- Those who contemn Real Programmers are contemned by them more than those who contemn them contemn them. If you understood that then you're a Real Programmer. --8<-------------------------------------------------------------
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
long term, if I can ever get MTD to work reliably for me, it's the way to go. I've just had lots of boards that I couldn't get it working on. ron
Jeremy Jackson <jerj@coplanar.net> writes:
I wonder if it doesn't make more sense to use the Linux MTD framework. I have begun porting devbios to it. I have refactored devbios into two halves, devbios and a flash library/map library. The MTD chip driver which uses the library is about half done.
I have been using the mtd drivers. The usual mtd split is. - Map driver - probe driver - cmdset. And right now the MTD code has only 2 command sets that are every really used. The AMD and the Intel. I guess there is a third command set in the tree now. And jedec_probe seems to go a good job of probing. I think getting the /dev/bios code merged with the mtd code is a good way to go.
Perhaps then the LinuxBIOS flash tool can be split into a map driver (the shadow control stuff) and a chip driver for the individual flash chips, then included into MTD.
If we continue to maintain a user space tool, it should definitely be factored into map/probe/and command set drivers like the mtd kernel code. Eric
On Thu, 13 Mar 2003, Alexander Amelkin wrote:
Yesterday I spent the day fighting the flash_rom on my pcchips m787cl+ board (SiS630). It just won't work. It mmaps correctly and I can read the BIOS (i created a flash_save tool based on the flash_rom.c code), but the chip identification just doesn't work. My assumption is that it doesn't disable Shadow memory before sending the SoftID sequence to the flash. Btw, the 'flash_and_burn' thing simply doesn't compile complaining on the absence of the 'pci/pci.h' file. So I use flash_rom.c from the 'sis630' directory.
ok, that's the first time I've seen it not compile. New CVS? Who changed it?
http://www.krizovakomunikacia.sk/rainbow/programs.html#UniFlash
Thanks much for the link, I will try to take alook. ron
* Ronald G. Minnich <rminnich@lanl.gov> [030313 15:22]:
simply doesn't compile complaining on the absence of the 'pci/pci.h' file. So I use flash_rom.c from the 'sis630' directory.
ok, that's the first time I've seen it not compile. New CVS? Who changed it?
Sounds rather like it's trying to use the includes provided by pciutils (Package is called pciutils-devel on SuSE, most probably the same on other distributions) Stefan -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra
Hello Stefan, Thursday, March 13, 2003, 5:37:13 PM, you wrote: SR> * Ronald G. Minnich <rminnich@lanl.gov> [030313 15:22]:
simply doesn't compile complaining on the absence of the 'pci/pci.h' file. So I use flash_rom.c from the 'sis630' directory.
ok, that's the first time I've seen it not compile. New CVS? Who changed it?
SR> Sounds rather like it's trying to use the includes provided by pciutils SR> (Package is called pciutils-devel on SuSE, most probably the same on SR> other distributions) Thanks for the hint. It's a pity the LinuxBIOS project lacks the documentation so badly. It really required the pciutils-devel. It would be nice to have that mentioned in the README or elsewhere. However, the flash_and_burn version of flash_rom.c doesn't work for me either. First of all it coredumps because it can't detect the chipset of my motherboard (although it's sis630e) and thus tries to call an NULL function pointer. An small if statement fixes that, but the tool still can't detect the installed flash part properly. The part is JEDEC-compliant, but probe_jedec doesn't return correct id's for it, no matter if I run flash_on or not. So I still prefer uniflash. Someone here called it an old code... well, may be the code style isn't very good (after all it's pascal...), but the project itself is very fresh. The last update is something like January 2003. -- Best regards, Spirit mailto:spirit@reactor.ru
On Thu, 2003-03-13 at 19:14, Spirit wrote:
an NULL function pointer. An small if statement fixes that, but the tool still can't detect the installed flash part properly. The part is JEDEC-compliant, but probe_jedec doesn't return correct id's for it,
I think a lot of these devices operate differently from what the manufacturer's datasheet says. Then there are different revisions, which may not be documented.
no matter if I run flash_on or not. So I still prefer uniflash. Someone here called it an old code... well, may be the code style isn't very good (after all it's pascal...), but the project itself is very fresh. The last update is something like January 2003.
Yes thanks for stating it that way. When I commented about Uniflash, I meant to say the coding style was old. But it works! It is mature code, and like devbios, it contains working code dealing with hardware quirks. I beat my head against the wall trying to get an Atmel AT29C040 to ID, using their datasheet. Then I looked at Uniflash and devbios, did what they did, and it worked, just nowhere near how the spec said. It would be nice however to have both working, and modern code. Ron, can you elaborate more on the problems you have with MTD? Jeremy
On 14 Mar 2003, Jeremy Jackson wrote:
It would be nice however to have both working, and modern code. Ron, can you elaborate more on the problems you have with MTD?
I do the build with the modules, I insmode the modules, and most of the time the part is never IDed and/or writeable. This may have gotten better. Overall MTD has been a headache with bproc nodes due to the large number of modules you have to load. Some sort of auto-loader for MTD modules would be nice. ron
Greetings, My experiance is that each chip has it's little quirks. Sometimes it's undocumented, sometimes it's technically within JEDEC but weird, sometimes both. It doesn't help that some documents assume if it's not in the docs, JEDEC applies while in others, if it's not in the docs, it's not there at all. The good news is that the quirks are usually fairly minor. I do prefer a userspace tool since that makes these things much easier to debug, and some chips have features that don't map well to the MTD interfaces such as block locking or top block swap. G'day, sjames On 14 Mar 2003, Jeremy Jackson wrote:
On Thu, 2003-03-13 at 19:14, Spirit wrote:
an NULL function pointer. An small if statement fixes that, but the tool still can't detect the installed flash part properly. The part is JEDEC-compliant, but probe_jedec doesn't return correct id's for it,
I think a lot of these devices operate differently from what the manufacturer's datasheet says. Then there are different revisions, which may not be documented.
no matter if I run flash_on or not. So I still prefer uniflash. Someone here called it an old code... well, may be the code style isn't very good (after all it's pascal...), but the project itself is very fresh. The last update is something like January 2003.
Yes thanks for stating it that way. When I commented about Uniflash, I meant to say the coding style was old. But it works! It is mature code, and like devbios, it contains working code dealing with hardware quirks. I beat my head against the wall trying to get an Atmel AT29C040 to ID, using their datasheet. Then I looked at Uniflash and devbios, did what they did, and it worked, just nowhere near how the spec said.
It would be nice however to have both working, and modern code. Ron, can you elaborate more on the problems you have with MTD?
Jeremy
_______________________________________________ Linuxbios mailing list Linuxbios@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 -----------------------------------------------------------------------
On Fri, 14 Mar 2003, steven james wrote:
The good news is that the quirks are usually fairly minor. I do prefer a userspace tool since that makes these things much easier to debug, and some chips have features that don't map well to the MTD interfaces such as block locking or top block swap.
yes, I guess in the end we have seen that MTD is nice, but that the userspace tool gives us flexibility we like. ron
Maybe it's time for a payload FAQ? I know we have over 5 payloads in common use and maybe a faq or a table on linuxbios.org could show the features of each? Off the top of my head, we have: Linux Kernel regular - use as your OS kernel Linux Kernel Kexec bootloader - boots another linux kernel from a device supported by linux (I don't know where this payload stands as a formal package) Memtest86 - great memory tester Plan9 - Plan9 OS (can it boot Linux yet?) ADLO + Bochs BIOS - Interrupt support, boots BSDs and Win2k Etherboot standard - kernel over ethernet Etherboot devel branch - kernel over ethernet and raw disk i/o Etherboot 5.0.6 polled ide patch - kernel over ethernet and buggy file system support Etherboot SIS patch - kernel over ethernet, file system support, and booting WinCE I think (but I don't know if SIS has let this out formally) RedBoot - could read the file system but never had the elf support to make it really usefull Steven James ELF finder - I think this was written as payload? Anyway, it lets you choose from payloads in your rom. And I'm sure there are probably many more which have good uses too. Please, add on to the thread if you know of more.
On Fri, 14 Mar 2003, Adam Agnew wrote:
Plan9 - Plan9 OS (can it boot Linux yet?)
no, there are no plans to do that. It's arguable that if you're booting Plan 9 you have no interest in booting Linux :-) also, we can boot 9load ron
Hello! Friday, March 14, 2003, 9:21:19 PM, Adam Agnew wrote: AA> ADLO + Bochs BIOS - Interrupt support, boots BSDs and Win2k Can anyone explain how to use that on a pcchips m787cl+? Now it uses something like kexec or etherboot-devel and I experience troubles with interrupts for add-on cards. For instance, my Cisco Aironet 4800 card doesn't get an interrupt assigned to it and the airo.o driver module doesn't find the card. I would really like to also have some means for disabling chipset built-in devices that consume interrupts. On SiS630e I have absolutely useless extra things like AC97 modem and sound. There is also an fdd controller and a secondary IDE controller that I don't need either. Is there a way to disable those? With best regards, Alexander mailto:spirit@reactor.ru
"Ronald G. Minnich" <rminnich@lanl.gov> writes:
On Fri, 14 Mar 2003, steven james wrote:
The good news is that the quirks are usually fairly minor. I do prefer a userspace tool since that makes these things much easier to debug, and some chips have features that don't map well to the MTD interfaces such as block locking or top block swap.
yes, I guess in the end we have seen that MTD is nice, but that the userspace tool gives us flexibility we like.
So far from what I have seen user space is good for quick hacks, and the mtd code base looks a lot better for long term maintenance. Eric
steven james <pyro@linuxlabs.com> writes:
Greetings,
My experiance is that each chip has it's little quirks. Sometimes it's undocumented, sometimes it's technically within JEDEC but weird, sometimes both.
It doesn't help that some documents assume if it's not in the docs, JEDEC applies while in others, if it's not in the docs, it's not there at all.
The good news is that the quirks are usually fairly minor. I do prefer a userspace tool since that makes these things much easier to debug, and some chips have features that don't map well to the MTD interfaces such as block locking or top block swap.
Block locking maps well to the mtd interface. There is not currently a way to do the top block swap but that should be a minor addition. So far I prefer to achieve the same effect in software, so that has not been an issue. Generally I prefer the mtd driver for end users (not developers). 1) MTD has the cleanest infrastructure I have seen. 2) The test to see if everything is working properly is easy. 3) I can separate out policy from the code that actually talks to the chips. And I have not seen chips so buggy they are impossible to work with the mtd interface. My only problem with the mtd code is that it takes a while to flush through to being in the mainstream kernel. And if someone reminds me I will get my linuxbios flashing tools posted that use the mtd interface. Eric
participants (9)
-
Adam Agnew -
Alexander Amelkin -
ebiederman＠lnxi.com -
Jeremy Jackson -
Ronald G. Minnich -
SONE Takeshi -
Spirit
-
Stefan Reinauer -
steven james