HPT360/HPT370 ATA controller flash interface

[Michael Karcher]

Hello flashrom developers,

(obtained from reversing the vendor update tool)

Supported IDs (names stolen from pci.ids, the double 372N is not my
fault):
  1103:0004 HPT366/368/370/370A/372/372N
  1103:0005 HPT372A/372N
  1103:0006 HPT302/302N

Flash enable at 58L.24 (setpci syntax), set to enable flash writing
Flash interface select at 70B, 1 = mmapped in ROM addr space,
                               0 = io mapped

IO-mapped access:
  (BAR4)+0x90 -> DWORD Address
  (BAR4)+0x94 -> BYTE/WORD/DWORD data access.

memmapped chip access was not shown in the tool, but the flash disable
code disables the extension ROM BAR. So probably its just mmapped
read/write in that area. Maximum Chip size supported by the vendor tool:
128K

Regards,
  Michael Karcher

[Uwe Hermann]

On Wed, Jan 13, 2010 at 06:40:57PM +0100, Michael Karcher wrote:
> Hello flashrom developers,
>
> (obtained from reversing the vendor update tool)
>
> Supported IDs (names stolen from pci.ids, the double 372N is not my
> fault):
>   1103:0004 HPT366/368/370/370A/372/372N
>   1103:0005 HPT372A/372N
>   1103:0006 HPT302/302N
>
> Flash enable at 58L.24 (setpci syntax), set to enable flash writing
> Flash interface select at 70B, 1 = mmapped in ROM addr space,
>                                0 = io mapped
>
> IO-mapped access:
>   (BAR4)+0x90 -> DWORD Address
>   (BAR4)+0x94 -> BYTE/WORD/DWORD data access.
>
> memmapped chip access was not shown in the tool, but the flash disable
> code disables the extension ROM BAR. So probably its just mmapped
> read/write in that area. Maximum Chip size supported by the vendor tool:
> 128K

Great, thanks!

I'll post a patch tomorrow or so and test on my HPT370A.

Uwe.

[Uwe Hermann]

On Thu, Jan 14, 2010 at 02:09:51AM +0100, Uwe Hermann wrote:
> I'll post a patch tomorrow or so and test on my HPT370A.

Here's the first draft. It does not yet work, the chip cannot be
detected, all reads return 0x00 so far.

Attached is the patch, an lspci -xxxnnnvvv after a fresh boot and before
any flashrom runs, and the output of 'flashrom -p atahpt -V'.

I desoldered the SST39SF512 chip and soldered on a PLCC socket onto the
HPT card for easier testing. I already posted a patch for the
SST39SF512, which I tested in a supported mainboard and it works fine.

Note that the WE# pin is at 3.3V while the HPT card is powered, thus
writes are _dis_abled, unless I'm mistaken. The WE# pin is connected to
some pin of the HPT370A chip (probably a GPIO), so it can in theory
toggle the WE# pin.

The PCI registers suggest that the flash access is enabled per default,
and the IO-vs-MMIO bit is set to I/O per default.

HTH, Uwe.

[Carl-Daniel Hailfinger]

On 17.01.2010 01:55, Uwe Hermann wrote:
> Here's the first draft. It does not yet work, the chip cannot be
> detected, all reads return 0x00 so far.
>
> Note that the WE# pin is at 3.3V while the HPT card is powered, thus
> writes are _dis_abled, unless I'm mistaken. The WE# pin is connected to
> some pin of the HPT370A chip (probably a GPIO), so it can in theory
> toggle the WE# pin.

That would explain why you don't get any probe response. An interesting
experiment would be to write some random image to the chip with a known
good programmer (your mainboard?), then force read the chip in the
HPT360. If that works, you only have to handle WE#. If it doesn't, there
are deeper issues that need to be fixed.
> Index: Makefile
>
> --- Makefile	(revision 862)
> +++ Makefile	(working copy)
> @@ -84,6 +84,9 @@
>  # Always enable SiI SATA controllers for now.
>  CONFIG_SATASII ?= yes
>
> +# Always enable Highpoint (HPT) ATA/RAID controllers for now.
> +CONFIG_ATAHPT ?= yes
>
> # Always enable FT2232 SPI dongles for now.
>  CONFIG_FT2232SPI ?= yes

Following the policy of merging code early as long as users won't trip
over it, change CONFIG_ATAHPT to default to no, and the patch is
Acked-by: Carl-Daniel Hailfinger

If you merge the current tree with your patch, a conflict will arise in
flashrom.c. Suggested resolution:

#if NIC3COM_SUPPORT+GFXNVIDIA_SUPPORT+DRKAISER_SUPPORT+SATASII_SUPPORT+ATAHPT_SUPPORT+FT2232_SPI_SUPPORT+SERPROG_SUPPORT+BUSPIRATE_SPI_SUPPORT+DEDIPROG_SUPPORT > 1

Regards,
Carl-Daniel

[Uwe Hermann]

On Thu, Feb 04, 2010 at 01:49:48AM +0100, Carl-Daniel Hailfinger wrote:
> On 17.01.2010 01:55, Uwe Hermann wrote:
> > Here's the first draft. It does not yet work, the chip cannot be
> > detected, all reads return 0x00 so far.
> >
> > Note that the WE# pin is at 3.3V while the HPT card is powered, thus
> > writes are _dis_abled, unless I'm mistaken. The WE# pin is connected to
> > some pin of the HPT370A chip (probably a GPIO), so it can in theory
> > toggle the WE# pin.
>
> That would explain why you don't get any probe response. An interesting
> experiment would be to write some random image to the chip with a known
> good programmer (your mainboard?), then force read the chip in the
> HPT360. If that works, you only have to handle WE#. If it doesn't, there
> are deeper issues that need to be fixed.

Will check as soon as I find some spare time.
> Following the policy of merging code early as long as users won't trip
> over it, change CONFIG_ATAHPT to default to no, and the patch is
> Acked-by: Carl-Daniel Hailfinger

Thanks, r908. The code is disabled by default in the Makefile.

Uwe.