- flashrom - mail.coreboot.org

Re: [flashrom] [PATCH] Board enable for ASUS P5LP-LE
by Uwe Hermann 24 Aug '11

24 Aug '11

On Wed, Aug 18, 2010 at 06:27:15PM +0200, Michael Karcher wrote: > + * - ASUS P5LP-LE (Epson/HP OEM) OK, this one is going to be interesting. The board is made by ASUS for HP, it seems. HP calls it "Leonite" or "Leonite-GL8E". http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=c008… But that would have been too easy. There are a bunch of other boards on the HP site which are also called P5LP-LE, but have different HP code names. From a quick glance I see at least: P5LP-LE (Leonite) P5LP-LE (Leonite2) P5LP-LE (Lithium) P5LP-LE (Limestone) P5LP-LE (Emery) Fun! I don't know how to differ between them, the dmidecode from Leon Zhang <leoncamel(a)gmail.com> said: DMI string system-manufacturer: "EPSON DIRECT CORP." DMI string system-product-name: "Endeavor MT7700" DMI string system-version: "" DMI string baseboard-manufacturer: "ASUSTek Computer INC." DMI string baseboard-product-name: "P5LP-LE" We don't know if other "P5LP-LE" might have the "Leonite" (or other) HP code name in there or not. Maybe something is printed as silkscreen on the board? An then one of these HP OEM boards is built into the Epson "Endeavor MT7700" system/PC. So it's a bit unclear which vendor/board name we should use in this case. It's probably best to mention all of them for better googling results. Attached is a slightly updated patch for review, let me know what you think. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

3 2

Failed Flashing Intel 3420 Chipset
by Shailendra Sodhi 24 Aug '11

24 Aug '11

Hi, Hi we use flashroom tool to flash our X8DTH and X8DTU Supermicro boards now when we try to flash X8SIE-F Motherboard with Intel 3420 chipset flashrom fails with error. Attached a file(s) detailing error. Please let me know if any further information required to make this work. Regards, Shailendra

2 2

Re: [flashrom] report for Intel QM67 | Winbond W25Q64 - layout patches
by Tadas Slotkus 24 Aug '11

24 Aug '11

> I'm using the 0.9.4 from http://www.flashrom.org/Downloads. > > Isn't this the latest? For developing patches use latest svn revision.

1 0

Re: [flashrom] report for Intel QM67 | Winbond W25Q64 - layout patches
by Stefan Tauner 24 Aug '11

24 Aug '11

On Wed, 24 Aug 2011 15:38:03 +0200 "Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote: > Hi, > > I applied the patches 0001 - 0007, but now flashrom doesn't compile any more... :-( > > flashrom.c: In function verify_flash: > flashrom.c: 1234:3: error: implicit declaration of function msg_gsbg2 > flashrom.c: At top level: > flashrom.c: 1305:5: error: redefinition of write_buf_to_file > flashrom.c: 1281:5: note: previous definition of write_buf_to_file was here > flashrom.c: In function write_buf_to_file: > flashrom.c: 1311:2: error: implicit declaration of function write_dump_to_file > > can you please help here? > hi hm. how did you apply them? the reason i ask is because "msg_gsbg2" should have been "msg_gdbg2" (message general debug2) and it actually is in my posted patches afaics. the patches compile on my machine (on top of r1416 btw, probably other revisions too, but that's the one i compile tested with a few moments ago). which revision did you checkout/extract/fetch before applying the patches? i assume you are using one that is too old. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[RFC] unsignify flashchip and programmer structs
by Stefan Tauner 23 Aug '11

23 Aug '11

i don't like the use of generic "int" qualifiers at all, even more the unsigned version for things like absolute addresses, lengths and sizes. of course negative values make sense in return types to indicate errors and in the case a function returns the length of actually bytes written on success and negative values on errors it makes sense to keep the parameters the same type (else the parameter length might be too big to return it on success). i would also like to change the types to more accurate ones someday (uint32_t etc.) instead, but i think that is not important as signedness. i want to assure myself that no one objects changing the following things to unsigned before i create a patch (which should be straight forward, but of course i will need to change quite many lines and also check that all functions will stay correct...). please speak up now or forever hold your peace etc... :) spi_programmer: int max_data_read; int max_data_write; (start + len parameters of:) int (*read)(struct flashchip *flash, uint8_t *buf, int start, int len); int (*write_256)(struct flashchip *flash, uint8_t *buf, int start, int len); (the return values just indicate success and failure with 0 and 1) struct flashchip: int total_size; (should also be converted to bytes instead of kB... i know this is on the todo already) int page_size; (start + len parameters of:) int (*write) (struct flashchip *flash, uint8_t *buf, int start, int len); int (*read) (struct flashchip *flash, uint8_t *buf, int start, int len); (again, the return value just indicates success, not bytes written) }; -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 1

Re: [flashrom] ASUS P5N-D
by Joshua Roys 23 Aug '11

23 Aug '11

On 08/18/2011 04:17 AM, Guillaume Poirier-Morency wrote: > I've been told, after an unsuccessful flashing, to send you these > outputs about my motherboard. > > My board remained intact! > > If you are interested into enabling it and developing patches to make it > compatible, I do not mind giving you feedback. > > Regards, > > Arteymis > > Hello, Please try the attached patch on top of the latest SVN and let us know how it works (reply with the output from `flashrom -Vw [...]'). For the devs: the board enable was identical to the P5N-E SLI, so I have bundled them together. Josh

3 4

Re: [flashrom] ASUS P5N-D
by Stefan Tauner 23 Aug '11

23 Aug '11

On Tue, 23 Aug 2011 06:13:26 -0400 Guillaume Poirier-Morency <guillaumepoiriermorency(a)gmail.com> wrote: > I have checked my bash history. You were right, I was using 9.2. > > I have then moved to the svn folder and used ./flashrom and curiously, look > at what I have got from the log file... > > The file is slightly different, but it's still showing version 9.2 > > Launching the flashrom executable without any arguments, it tells me I'm > using 9.4 > > I suppose there is version typo in the program itself. Otherwise, maybe the > patch affect the version this way. i seriously doubt that. there is only a single string containing the version in the program and only one place where this single string is printed... i would recommend uninstalling the old version anyway. in this case it was not important, but in other cases it may break stuff. > Anyway, It's really using 9.4 and it works very well! that's the important thing anyway :) i'll make the appropriate changes in our repository, thanks for testing! -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] ASUS P5N-D
by Stefan Tauner 23 Aug '11

23 Aug '11

On Tue, 23 Aug 2011 05:34:28 -0400 Guillaume Poirier-Morency <guillaumepoiriermorency(a)gmail.com> wrote: > I think there will soon be a new supported motherboard on your list! > > Here's the flashrom -Vw [...] output. nice! but what did you do exactly? the log shows version 0.9.2. did you patch that ancient version? why? could it be that you just rewrote with the old version by accident to get the verbose log? NB: the write protection remains disabled until reboot. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
by Stefan Tauner 23 Aug '11

23 Aug '11

On Tue, 23 Aug 2011 08:41:35 +0200 "Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote: > please send me this patch - I first want to read out the flash - and if this works, I will try to write... > > I need this for production test. i have already posted my patches in the (sub)thread named "[PATCH 0/7] every layout handling feature you ever wanted to see but never cared to implement". if you are not subscribed to the list you could also fetch them from http://patchwork.coreboot.org/project/flashrom/list/ (all those with date 2011-08-19). i will mail them to you separately this time. you need at least 1-5 to be able to read. > Will this patch work without a layout file? I fnot, can you tell me how to generate it? no, it will not work without one. there is apparently no way to flash beyond the regions defined by the flash descriptor. the layout file can limit the address range accessed (to make it work). depending on how fine-grained you wanna use it you can define in the layout file ranges for each region as defined by the flash descriptor on your board (from this output of flashrom:) 0x54: 0x00000000 (FREG0: Flash Descriptor) 0x00000000-0x00000fff is read-write 0x58: 0x03ff0200 (FREG1: BIOS) 0x00200000-0x003fffff is read-write 0x5C: 0x01ff0001 (FREG2: Management Engine) 0x00001000-0x001fffff is read-write or just define one range for the whole accessible area (that would be something like 0x0 - 0x003fffff i would say) i think you will probably need to set the read_all_first variable in flashrom.c to 0 (and maybe also use the -w parameter) to be able to write without errors printed, else flashrom will try to read the whole flash before and after writing to verify its contents. i have told you already at least twice to look into our documentation. you know that this is my spare time and i am not here to do your work... if you have concrete questions about layout files or their usage we are happy to answer that, but "how do we do that?" makes me kinda angry, if it is already documented. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[carFl mem] Reduce memory buffers
by Tadas Slotkus 22 Aug '11

22 Aug '11

Hi all, Sending initial patches, which reduce memory usage for flashrom in coreboot. Look 0-9 patches. To get some laugh at my stupidity look for 10-21 :) Thanks, Tadas

1 1

[PATCH] spi25: get rid of unneccessary line breaks (on failed probes)
by Stefan Tauner 22 Aug '11

22 Aug '11

--- not sure if this is correct for all execution paths, but it fixes the output of a probe on my thinkpad. i have looked a bit around to find examples of code that this patch would break and found none though. without this patch: Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x3017 Probing for SST SST25LF040A, 512 kB: Invalid OPCODE 0xab, will not execute. Probing for SST SST25LF080A, 1024 kB: Invalid OPCODE 0xab, will not execute. Probing for SST SST25VF010.REMS, 128 kB: Invalid OPCODE 0x90, will not execute. Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x3017 with this patch: Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x3017 Probing for SST SST25LF040A, 512 kB: Invalid OPCODE 0xab, will not execute. Probing for SST SST25LF080A, 1024 kB: Invalid OPCODE 0xab, will not execute. Probing for SST SST25VF010.REMS, 128 kB: Invalid OPCODE 0x90, will not execute. Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0xef, id2 0x3017 Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- spi25.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/spi25.c b/spi25.c index 937ee5d..c9fe9ec 100644 --- a/spi25.c +++ b/spi25.c @@ -120,7 +120,6 @@ static int probe_spi_rdid_generic(struct flashchip *flash, int bytes) uint32_t id2; if (spi_rdid(readarr, bytes)) { - msg_cdbg("\n"); return 0; } @@ -201,7 +200,6 @@ int probe_spi_rems(struct flashchip *flash) uint32_t id1, id2; if (spi_rems(readarr)) { - msg_cdbg("\n"); return 0; } @@ -259,7 +257,6 @@ int probe_spi_res1(struct flashchip *flash) } if (spi_res(readarr, 1)) { - msg_cdbg("\n"); return 0; } @@ -283,7 +280,6 @@ int probe_spi_res2(struct flashchip *flash) uint32_t id1, id2; if (spi_res(readarr, 2)) { - msg_cdbg("\n"); return 0; } -- 1.7.1

1 0

[PATCH] dmi: add "Sealed-case PC" to the list of non-laptop chassis
by Stefan Tauner 22 Aug '11

22 Aug '11

--- not sure though if all other computers with that chassis type are "in all likelihood not a laptop". Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- dmi.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/dmi.c b/dmi.c index 8f78376..5f64b94 100644 --- a/dmi.c +++ b/dmi.c @@ -81,6 +81,7 @@ static const struct { {0x0e, 1, "Sub Notebook"}, {0x11, 0, "Main Server Chassis"}, {0x17, 0, "Rack Mount Chassis"}, + {0x18, 0, "Sealed-case PC"}, /* used by Supermicro (X8SIE) */ }; #define DMI_COMMAND_LEN_MAX 260 -- 1.7.1

1 0

Re: [flashrom] flashrom accepts its command line parameters as a file name to read to
by Stefan Tauner 22 Aug '11

22 Aug '11

On Thu, 18 Aug 2011 17:57:59 +0200 Idwer Vollering <vidwer(a)gmail.com> wrote: > 2011/8/18 Christophe Poncy <cp(a)canaxis.org>: > > Hi, > > > > ... > > > # ./flashrom -r -L > > This shouldn't be allowed. hm. actually i think this is normal behavior (for getopt-using applications). one arbitrary example: grep [OPTIONS] [-e PATTERN | -f FILE] [FILE...] # grep -e -f cli_classic.c this uses "-f" as a search pattern to look for in cli_classic.c i do agree though, that it might be unexpected, especially for windows users. and even if it is expected behavior no one would miss it, if we prohibit it. > What about disallowing the creation of files that have a name listed > in cli_classic.c's optstring[] and/or long_options[] ? or prohibiting any option parameters to be started with "-" (this includes all the file names, but also: - chip names (not an issue so far) - mainboard names (ditto) - layout file names and region names (probably tolerable too) - programmer parameters (also not an issue i presume) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] Update of Gigabyte GA-MA78GM-S2HP motherboard firmware switch
by Stefan Tauner 21 Aug '11

21 Aug '11

On Sun, 21 Aug 2011 08:40:54 -0600 Donovan Lavinder <drmario2007(a)gmail.com> wrote: > > here's the log: > > ;root@sysresccd /root % flashrom > ;flashrom v0.9.3-r1205 on Linux 2.6.38-std230-i586 (i686), built with libpci > 3.1. > ;7, GCC 4.4.5, little endian > ;flashrom is free software, get the source code at http://www.flashrom.org > ; > ; > ;Calibrating delay loop... OK. > ;coreboot table found at 0x6fffe000. > ;Found ITE Super I/O, ID 0x8718. > ;Found Chipset "AMD SB700/SB710/SB750", enabling flash write... OK. > ;This chipset supports the following protocols: LPC,FWH,SPI. > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ;4 byte RDID not supported on this SPI controller > ; > > After that, that's it.... > a verbose one (with -V or even -VVV) please i am not familiar with the it87xx code, but i would say it hangs in the while loop at the end of it8716f_spi_send_command. it would be easy to add a timeout there, but the question is why it does hang there (now). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] MSI H55-GD65 (MS-7637) (H55, locked ME region, FLOCKDN=0(!))
by Bernd Blaauw 21 Aug '11

21 Aug '11

Op 21-8-2011 3:40, Donovan Lavinder schreef: > to use Linux Live CD mentioned in flashrom download page, as FreeDOS > have managed to brick all of the firmware image I have been trying to > flash. Fed up, I went to get the live CD, it works now. I used > SystemRescueCd distro (you need to figure out how to mount the hard > drive or jump drive to be able to have flashrom to download the firmware > ROM - for example: mount /dev/sda1 /mnt/disk0 ), so far, this distro is > quite nice to have! I thought ramdisks make fine temporary storage? No need to mount harddisk then. It seems a bit strange to claim FreeDOS (or DJGPP-compiled flashrom) ruined your flash image. I guess file hashes would give a definitive answer to what's the issue. I have to admit though that sometimes that FreeDOS kernel has had some FAT-related issues, no guarantee they're all solved. goodluck with CoreBoot as well! So far the Asrock E350 board seems best to experiment with, though I'd like the fanless/passive Asus E350 board instead.

1 0

Re: [flashrom] Update of Gigabyte GA-MA78GM-S2HP motherboard firmware switch
by Donovan Lavinder 21 Aug '11

21 Aug '11

> here's the log: ;root@sysresccd /root % flashrom ;flashrom v0.9.3-r1205 on Linux 2.6.38-std230-i586 (i686), built with libpci 3.1. ;7, GCC 4.4.5, little endian ;flashrom is free software, get the source code at http://www.flashrom.org ; ; ;Calibrating delay loop... OK. ;coreboot table found at 0x6fffe000. ;Found ITE Super I/O, ID 0x8718. ;Found Chipset "AMD SB700/SB710/SB750", enabling flash write... OK. ;This chipset supports the following protocols: LPC,FWH,SPI. ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ;4 byte RDID not supported on this SPI controller ; After that, that's it.... On Sun, Aug 21, 2011 at 8:26 AM, Donovan Lavinder <drmario2007(a)gmail.com>wrote: > The flashrom is the only program that froze when looking for the flash > chip. I have tried cold reboot - same thing happened. That here, was a > head-scratcher since it is not even supposed to happen. Probably it could be > because the firmware unmounted itself (shouldn't happen). The whole OS ran > fine otherwise (I could close the frozen flashrom program with ease). I am > wondering how could SuperIO refuse the handshake between the flashrom - I > left it alone for a while, no change in the behavior (as far as the verbose > terminal emulator was concerned). > > > On Sun, Aug 21, 2011 at 8:05 AM, Stefan Tauner < > stefan.tauner(a)student.tuwien.ac.at> wrote: > >> On Sun, 21 Aug 2011 07:27:02 -0600 >> Donovan Lavinder <drmario2007(a)gmail.com> wrote: >> >> > That's strange. I have tried rewriting the firmware so I COULD provide >> you >> > the text file... It froze after couple complaints of 4-byte RDID not >> found >> > (it just ignored that before), and I tried just "flashrom", same thing. >> Now >> > that's a can of worm. It was 100% successful - verified and signed. Now >> I am >> > somewhat confused. I may have to wait for a while (thankfully I still >> have a >> > Windows laptop so I could write up the report on progresses of the >> firmware >> > ROM.) >> >> the 4 byte RDID warnings should not matter. the chip you have does not >> need it. it is just printed for other chips that are probed for by >> flashrom. you can use the -c <chipname> parameter to probe for the >> correct chip only. regarding the lockup i can't say much without a log, >> but that it should not happen. :) does it reliably happen while probing >> for the same chip or is it (seemingly) random? could you also please >> define "froze" precisely? is it flashrom alone or the whole OS etc? >> >> -- >> Kind regards/Mit freundlichen Grüßen, Stefan Tauner >> > > > > -- > "Mamma-mia, there's Koopa troopa in Mushroom Kingdom!" > -- "Mamma-mia, there's Koopa troopa in Mushroom Kingdom!"

1 0

Re: [flashrom] Update of Gigabyte GA-MA78GM-S2HP motherboard firmware switch
by Stefan Tauner 21 Aug '11

21 Aug '11

On Sun, 21 Aug 2011 07:27:02 -0600 Donovan Lavinder <drmario2007(a)gmail.com> wrote: > That's strange. I have tried rewriting the firmware so I COULD provide you > the text file... It froze after couple complaints of 4-byte RDID not found > (it just ignored that before), and I tried just "flashrom", same thing. Now > that's a can of worm. It was 100% successful - verified and signed. Now I am > somewhat confused. I may have to wait for a while (thankfully I still have a > Windows laptop so I could write up the report on progresses of the firmware > ROM.) the 4 byte RDID warnings should not matter. the chip you have does not need it. it is just printed for other chips that are probed for by flashrom. you can use the -c <chipname> parameter to probe for the correct chip only. regarding the lockup i can't say much without a log, but that it should not happen. :) does it reliably happen while probing for the same chip or is it (seemingly) random? could you also please define "froze" precisely? is it flashrom alone or the whole OS etc? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] Update of Gigabyte GA-MA78GM-S2HP motherboard firmware switch
by Stefan Tauner 21 Aug '11

21 Aug '11

On Sat, 20 Aug 2011 18:57:26 -0600 Donovan Lavinder <drmario2007(a)gmail.com> wrote: > After a day of struggling with bricked firmwares.... I finally ditched > FreeDOS. I went with SystemRescueCd distro and burnt coreboot precompiled > firmware under the folder /gigabyte_ma78gm/ and the firmware WORKED! But now > I am stuck with funny firmware quirks (Windows XP crashing when booting > halfway, almost to the point the video card driver is loaded, right after > "GIVEIO.SYS" driver is being loaded), even though it loaded Linux CD fine. I > guess I should try and ditch PS/2 mouse as it may probably be the cause of > strange behavior - I will be using USB mouse / keyboard as well. I am happy > with this firmware otherwise. And, the backup BIOS didn't even try to > intercept the Linux kernel in the firmware from loading. Thankfully. I will > eventually decide to recompile or "submit" the additional payloads such as > EFI and memtest86+ as those software will be needed in the future, after I > learn more of its capabilities. > > And, thanks for such a wonderful firmware! That thing's so fast! > congratulations :) this mail probably should have been sent to coreboot(a)coreboot.org though (too). btw could you provide a log of a successful flashrom write please? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] MSI H55-GD65 (MS-7637) (H55, locked ME region, FLOCKDN=0(!))
by Stefan Tauner 21 Aug '11

21 Aug '11

On Sat, 20 Aug 2011 19:40:55 -0600 Donovan Lavinder <drmario2007(a)gmail.com> wrote: > You guys can also use flashrom utility to be able to write the firmware if > the utility you are using is being stubborn (happens to me too), hi donovan, we are talking about flashrom explicitly here.. because it is the mailing list of flashrom (and not coreboot). to be precise, we are talking about implementing a new feature to flashrom. this has almost nothing to do with coreboot. > […] -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] MSI H55-GD65 (MS-7637) (H55, locked ME region, FLOCKDN=0(!))
by Stefan Tauner 20 Aug '11

20 Aug '11

On Sat, 20 Aug 2011 23:03:16 +0100 (BST) Luzipher McLeod <luziphermcleod(a)yahoo.ie> wrote: > Thanks for your mails ! Good to know that there is something going on (even though you indicate that it'll take quite some time). If I can do anything to help, just let me know. if you are good at REing you could help a lot (because i am a n00b regarding x86 asm, and therefor quite unmotivated to stare at disassembly - especially when i see how fluently others are able to read this :). > That said, it really seems to be a messed up situation. As far as I understood, there are several "units" involved in accessing the flash (or at least granting rights to access the flash). yes. the firmware for the ME, the GbE controller and the host (=BIOS/EFI) are on the same flash chip and all of them can access it via the southbridge. they do also write to it (the ME logs some stuff at least). access restrictions are enforced by the southbridge which acts as a gatekeeper. > Am I right that the major missing thing is support for the embedded controller (ME) ? exactly. usually that is the only real problem. the flash descriptor region is most often read-only, but that's not really an issue (it does not need to be updated normally). i *think* to know how the ME can be told to give us access superficially (using HECI/MEI), but i don't know the exact details. i have a patch already that implements MEI communication in flashrom... the question is just what to send (and what to expect to receive :) > I also do have a flashing utility that works from DOS if that'd be any help (reverse engineering) ? there are various of those and RE is the way to go probably (because intel won't tell us probably). having access to the binary is not the problem though. > > PS: Wir können auch deutsch schreiben, ich hab's mal in Englisch verfasst, weil du erwähnt hast, das das ganze evtl auch der Dokumentation für etwaige Nachfolgerwahnsinnige dient :-) if it is not too hard for you, english is the way to go because it is the least common denominator of those involved. i think i should write together what i know about unlocking the ME. probably a wiki page would be best... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Update of Gigabyte GA-MA78GM-S2HP motherboard firmware switch
by Donovan Lavinder 20 Aug '11

20 Aug '11

After a day of struggling with bricked firmwares.... I finally ditched FreeDOS. I went with SystemRescueCd distro and burnt coreboot precompiled firmware under the folder /gigabyte_ma78gm/ and the firmware WORKED! But now I am stuck with funny firmware quirks (Windows XP crashing when booting halfway, almost to the point the video card driver is loaded, right after "GIVEIO.SYS" driver is being loaded), even though it loaded Linux CD fine. I guess I should try and ditch PS/2 mouse as it may probably be the cause of strange behavior - I will be using USB mouse / keyboard as well. I am happy with this firmware otherwise. And, the backup BIOS didn't even try to intercept the Linux kernel in the firmware from loading. Thankfully. I will eventually decide to recompile or "submit" the additional payloads such as EFI and memtest86+ as those software will be needed in the future, after I learn more of its capabilities. And, thanks for such a wonderful firmware! That thing's so fast! -- "Mamma-mia, there's Koopa troopa in Mushroom Kingdom!"

1 0

Coreboot failure on GA-MA78GM-S2HP Rev. 2.0 motherboard
by Donovan Lavinder 20 Aug '11

20 Aug '11

I originally wanted EFI and other features that will allow me to use my motherboard for few years out. So, I downloaded archived coreboot firmware package, and I found one "baked" firmware ROM under folder MA78GM as the motherboards under this family seems to be having the same chipsets, so I went to burn my own coreboot in FreeDOS using flashrom. Now, it first exclaimed that it found MXIC MX25L8005 chipset, but it tried 4-bytes RDID and failed, however, I was able to erase the BIOS chip fine. Next, I wrote the firmware - after it said "done", it froze - I reset it, it kept reverting back to oh-so-annoying Award BIOS... No wonder my motherboard is SO picky! Here, I wrote up on the paper: flashrom Ver. 0.9.3 - r1205 (on Freedos boot CD - all I have had, no floppy disk and it won't boot from USB disk.... I may try spare hard drive if needed...) - 4-byte RDID refusal (although erasure was successful) Motherboard: Vendor - Gigabyte / Model - GA-MA78GM-S2HP CPU: AMD Phenom II X940 Black Series 3.0GHz quad-core (Deneb) CPU RAM: Crucial Ballistix DDR-II 800MHz 1GB x2 (2GB) on dual-channel memory bus Video card: Vendor - Gigabyte / Model - GV-R467ZL-1GI - FW Ver. - F12 / VPU - AMD Radeon HD 4670 with 1GB 800MHz GDDR3 on 128-bit bus * I removed my hard drive (with my personal documents and Windows XP) during the firmware flash to ensure the data aren't touched in a way. I would like to know how I can get my motherboard to quit being all so picky - otherwise any other methods known to work perfectly on the GA-MA78GM-S2HP motherboard any of you may have up and running the coreboot firmware. Thanks for your help! -- "Mamma-mia, there's Koopa troopa in Mushroom Kingdom!"

1 0

[PATCH] Makefile: Fix MinGW build, improve output with bogus CC
by Uwe Hermann 20 Aug '11

20 Aug '11

See patch. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

2 2

[commit] r1418 - trunk
by repository service 20 Aug '11

20 Aug '11

Author: uwe Date: Sat Aug 20 16:16:00 2011 New Revision: 1418 URL: http://flashrom.org/trac/flashrom/changeset/1418 Log: Makefile: Fix MinGW build, improve output with bogus CC. As per IRC discussion, the "ARCH :=" line should be moved after any lines which set CC, as it uses CC itself. This fixes the MinGW build. Also, add a "2>/dev/null" in the "ARCH :=" as per suggestion from Stefan Tauner to improve the output in the case CC is bogus: Before: $ make CC=foo /bin/sh: foo: not found Checking for a C compiler... not found. make: *** [compiler] Error 1 After: $ make CC=foo Checking for a C compiler... not found. make: *** [compiler] Error 1 Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Modified: trunk/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Sat Aug 20 16:14:22 2011 (r1417) +++ trunk/Makefile Sat Aug 20 16:16:00 2011 (r1418) @@ -37,9 +37,6 @@ CFLAGS += -Werror endif -# Determine the destination processor architecture -override ARCH := $(strip $(shell LC_ALL=C $(CC) -E arch.h|grep -v '^\#')) - # FIXME We have to differentiate between host and target OS architecture. OS_ARCH ?= $(shell uname) ifneq ($(OS_ARCH), SunOS) @@ -202,6 +199,12 @@ endif endif +# Determine the destination processor architecture. +# IMPORTANT: The following line must be placed before ARCH is ever used +# (of course), but should come after any lines setting CC because the line +# below uses CC itself. In some cases we set CC based on OS_ARCH, see above. +override ARCH := $(strip $(shell LC_ALL=C $(CC) -E arch.h 2>/dev/null | grep -v '^\#')) + ifeq ($(ARCH), "ppc") # There's no PCI port I/O support on PPC/PowerPC, yet. ifeq ($(CONFIG_NIC3COM), yes)

1 0

[PATCH] Move the main() function from flashrom.c to cli_classic.c
by Uwe Hermann 20 Aug '11

20 Aug '11

See patch. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom