On Wed, Aug 17, 2011 at 06:17:45AM +0200, Stefan Tauner wrote:
> defining all those arrays is not very elegant, but i think it is at least very
> readable this way.
Yep, pretty good solution IMHO, I would have done the same.
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de>
I cross-checked the datasheets and didn't spot any errors (ICH7-10,
NM10, EP*, 5/6 series).
ICH6 and lower, ESB*, and 3100 series and probably others don't have
GCS, thus no need to list/mention them here (which you didn't).
> + case 7:
> + /* EP80579 may need further changes, but this is the least
> + * intrusive way to get correct BOOT Strap printing without
> + * changing the rest of its code path) */
^
Missing full stop here.
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
On Wed, 24 Aug 2011 17:00:43 +0200
"Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote:
> Hi,
>
> sorry, msg_gsbg2 is a typo - it is of course msg_gdbg2.
>
> I'm using the 0.9.4 from http://www.flashrom.org/Downloads.
>
> Isn't this the latest?
>
0.9.4 is the latest *stable* release, but the patches floating around
here usually are to be applied on the latest *development* source code.
please check out the source code with subversion as described on the
download page and retry.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Am Freitag, den 26.08.2011, 09:56 +0800 schrieb QingPei Wang:
> you are right, it's 0x1022. new patch attached~~~
Thank you! Did you test it? Can you attach the output of `flashrom -V`
as Uwe asked you to do?
Thanks,
Paul
Hi,
On Thu, Aug 25, 2011 at 11:06:12PM +0800, QingPei Wang wrote:
> The HUDSON has different vendor & device id than SBx00. The ids are got
> by lspci.
> Signed-off-by: Wang Qing Pei <wangqingpei(a)gmail.com>
Thanks for the patch, we'll merge it soonish, but please see below for
some questions.
> Index: chipset_enable.c
> ===================================================================
> --- chipset_enable.c (revision 1419)
> +++ chipset_enable.c (working copy)
> @@ -1052,6 +1052,7 @@
> + {0x1002, 0x780e, OK, "AMD", "HUDSON", enable_flash_sb600},
Shouldn't this be 0x1022 (AMD instead of ATI ID) here?
Also, did you test the chipset-enable on real hardware? Otherwise we
should probably commit this as "NT" (not tested) instead of "OK".
Please post a log of "./flashrom -V" with the patch applied if you own
some test hardware, thanks!
Uwe.
--
http://hermann-uwe.de | http://sigrok.orghttp://randomprojects.org | http://unmaintained-free-software.org
Hi Mattias,
nice to see you're back, and even more so with a big bang announcement.
Am 27.07.2011 18:20 schrieb Mattias Mattsson:
> I was able to run flashrom under Linux on PPC (big endian) hardware
> with two small modifications in internal.c and processor_enable.c (see
> attached patch). Not sure if this is the right way to do it but it
> seems to work for me.
>
> Note that for Apple hardware you have to use a special power on method
> to make the flash chip accessible (hold power button until beep). On
> some models you have to press and hold an additional button on the
> machine ("programmer's button") or keyboard ("Command").
> http://support.apple.com/kb/HT2322
> http://support.apple.com/kb/DL1284
> http://support.apple.com/kb/DL1126
>
> I have tested this on two pieces of Apple hardware: "Mac Mini" (model
> ID: PowerMac10,1) and "Mac mini (Late 2005)" (model ID: PowerMac10,2):
> http://support.apple.com/kb/ht3476
>
> By taking the hardware apart I can confirm they have the following flash chips:
>
> PowerMac10,1: AMD Am29LV008BB-90EC
> PowerMac10,2: SHARP LH28F008BJT-BTLZ1
>
> Flash chips seem to be mapped top-aligned in the 4GB address space.
> Looking at the Open Firmware forth code inside Apple's own firmware
> updates also suggests this is the case.
>
> I was able to probe, read, write and erase on both machines. Read
> files seem to contain valid data.
>
> Added support for LH28F008BJT-BTLZ1 and marked Am29LV008B as fully tested.
>
> Logs and patches attached.
>
>
> Please tell me if I should test something else!
>
Excellent work!
The LH28F008BJT patch is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
The Am29LV008BB patch is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Can you commit those? I think you still have commit rights with account mhm.
The PPC patch itself needs more work:
- We need to match the chipset/machine somehow to avoid disasters on
untested machines. While that may not be 100% required, I'm wary of
bricked machines on an architecture I don't own.
- A chipset match where buses_supported = BUS_PARALLEL is set.
- A chipset match where you check if the flash chip is accessible...
comparing lspci --xxx between flash enabled and flash disabled boots
might shed some light on this. Then again, maybe that setting isn't
visible in PCI space and such a check is futile.
- Side note: Not your fault, but we really need a way for a chipset
enable function to tell internal_init that it should return an error.
Maybe a special return code for a chipset enable?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/