Re: [flashrom] flashrom on PowerPC

[Carl-Daniel Hailfinger]

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

The Am29LV008BB patch is
Acked-by: Carl-Daniel Hailfinger

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

flashrom on PowerPC

[Stefan Tauner]

On Sun, 14 Aug 2011 02:50:38 +0200
Carl-Daniel Hailfinger  wrote:
> 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?

the infrastructure is all there and the call stacks for all board
enables has internal_init as ancestor, so using a return value to
communicate makes sense yes...
the handling of return codes in chipset_flash_enable is already quite
convoluted and should be better standardized before. which brings
back some memories of that thing name libflashrom... ;)

flashrom on PowerPC

[Uwe Hermann]

Hi,

On Sun, Aug 14, 2011 at 02:50:38AM +0200, Carl-Daniel Hailfinger wrote:
> Excellent work!
>
> The LH28F008BJT patch is
> Acked-by: Carl-Daniel Hailfinger

This was r1420.
> The Am29LV008BB patch is
> Acked-by: Carl-Daniel Hailfinger

This was r1421.
> 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?

Mattias, can you take a look at the issues above? Is it possible to do
such chipset matches etc.?

Thanks, Uwe.

flashrom on PowerPC

[Andrew Morgan]

On 25/08/11 23:56, Uwe Hermann wrote:
> > 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?
>
> Mattias, can you take a look at the issues above? Is it possible to do
> such chipset matches etc.?

As I have a PowerPC Mac I thought I'd run 'sudo lspci -vvvnnxxx' on it 
with the flash enabled and disabled (hold power button for a few seconds 
until it beeps to enable flash on this machine). Results attached, along 
with the contents of /proc/cpuinfo, which looks to me like a pretty good 
match for the machine type.