Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, May 28, 2019 at 05:11:36PM +0200, Helge Deller wrote:
> >
> > My c3750 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
> >
> > [    0.000000] Initialized PDC Console for debugging.
> > [    0.000000] Determining PDC firmware type: System Map.
> > [    0.000000] model 00005dc0 00000481 00000000 00000002 77e45e84 100000f0 00000008 000000b2 000000b2
> > [    0.000000] vers  00000301
> > [    0.000000] CPUID vers 19 rev 11 (0x0000026b)
> > [    0.000000] capabilities 0x7
> 
> Same as Dave: My C3700 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
> [    0.000000] model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 000000b2 000000b2
> [    0.000000] vers  00000301
> [    0.000000] CPUID vers 19 rev 11 (0x0000026b)
> [    0.000000] capabilities 0x7
> [    0.000000] model 9000/785/C3700
> 

Interesting. Now that you mention it i see that my C3750 reports the same. Google
returned the following page https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020

Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware" So maybe
these machines have NP set, and machines "below" (like C3600) don't have it set.

I wonder what happens if you try to flash a 5.0 firmware to such a box.

BTW, i figured out that register 0xf05f1038 bit 0 seems to be the FLASH write
enable. So it's basically just a matter of writing some code to send correct
commands to the flash chip, and being crazy enough to actually erase and reprogram
the flash.

I'm not sure whether that would actually be of help if we know that the NP bit goes
away with a 5.0 firmware on a C3750.

Regards
Sven




[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux