AM5726: GPMC hang if gpmc_wait0 is not asserted

David,

Can you confirm if you are looking to protect against an error condition on the FPGA (recover from a bus hang) or if there are scenarios where WAIT may not be de-asserted but the FPGA operation is valid?

For the first scenario, it's possible to reset the interface. For the second, it may be possible to configure different regions use the wait input.

Hi Dave, 

It is the first condition.
Can you describe how we can reset the interface?

Thank you,

David

Hi Dave,

Unfortunately, we cannot predict when the access will fail, and once it has failed, the whole system freezes, so we cannot initiate a reset. Is there a configuration that we can change to prevent the system from freezing?

David

David,

To help with this further, can you elaborate more on the GPMC servicing scheme, and what you are seeing when the system freeze? Is your application accessing the GPMC by direct CPU read/write and by which core(s), or is this through DMA? When the GPMC hangs, what has been attempted?

Likely if you have a CPU that is stalled waiting for the GPMC then that core will not be usable for the reset action and you'll need an alternate mechanism. If you leverage a watchdog to trigger an exception event you should be able to use an alternate mechanism for writing to the GPMC control register to reset.

Best regards,

Dave

Dave, 

We have a kernel driver that does a memory map of the address range and then exposes some of the values via sysfs files.
But I can also reproduce this by reading the memory reqion using tools like memtool.

The FPGA is using Chipselect 0, and mapped to region 0x01000000.

memtool md -w 0x1002000+1
01002000: 000b
memtool md -w 0x1002000+1
01002000: 000b
memtool md -w 0x1002000+1
01002000: 000b
<Disconnect a component on the other side of the FPGA so that FPGA will stop responding>
memtool md -w 0x1002000+1
<memtool never returns, until our watchdog kicks in after a few minutes and reboots>

We are planning to put protection in the FPGA code to make sure the FPGA still responds in this condition, but we also want to make sure we can handle other cases in the future where the FPGA might not respond.


DTB settings:

&gpmc {

status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gpmc_pins>;

ranges = <
0 0 0x01000000 0x01000000 /* minimum GPMC partition = 16MB */
>;

bcsr@0,1000000 {
reg = <0 0x00000000 0x01000000>; /* minimum GPMC partition = 16MB */
compatible = "rx1k5cm_bcsr";

bank-width = <2>;
gpmc,mux-add-data = <2>;
gpmc,sync-read;
gpmc,sync-write;
gpmc,wait-pin = <0>;
gpmc,wait-on-read;
gpmc,wait-on-write;
gpmc,sync-clk-ps = <15000>;
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <116>;
gpmc,cs-wr-off-ns = <60>;
gpmc,adv-on-ns = <15>;
gpmc,adv-rd-off-ns = <30>;
gpmc,adv-wr-off-ns = <30>;
gpmc,we-on-ns = <30>;
gpmc,we-off-ns = <60>;
gpmc,oe-on-ns = <37>;
gpmc,oe-off-ns = <112>;

gpmc,page-burst-access-ns = <0>;
gpmc,access-ns = <37>;
gpmc,rd-cycle-ns = <45>;
gpmc,wr-cycle-ns = <67>;
gpmc,bus-turnaround-ns = <7>;
gpmc,cycle2cycle-delay-ns = <11>;
gpmc,clk-activation-ns = <7>;
gpmc,wr-access-ns = <56>;
gpmc,wr-data-mux-bus-ns = <30>;

gpmc,cycle2cycle-diffcsen;
gpmc,cycle2cycle-samecsen;
};

David,

There looks to be a better option for this. Please see the GPMC Timeout Register in the TRM - http://www.ti.com/lit/ug/spruhz6l/spruhz6l.pdf

Table15-512.GPMC_TIMEOUT_CONTROL

15.4.4.8.4 Error Handling

When an error occurs in the GPMC,the error information is stored in the GPMC_ERR_TYPE register and the address of the illegal access is stored in the GPMC_ERR_ADDRESS register.The GPMC keeps only the first error abort information until the GPMC_ERR_TYPE register is reset. Subsequent accesses that cause errors are not logged until the error is cleared by hardware with the GPMC_ERR_TYPE[0] ERRORVALID bit.• ERRORNOTSUPPADD occurs when an incoming system request address decoding does not match any valid chip-select region,or if two chip-select regions are defined as overlapped,or if a register file access is tried outside the valid address range of 1KiB.• ERRORNOTSUPPMCMD occurs when an unsupported command request is decoded at the L3 interconnect interface.• ERRORTIMEOUT:A time-out mechanism prevents the system from hanging.The start value of the 9-bit time-out counter is defined in the GPMC_TIMEOUT_CONTROL register and enabled with the GPMC_TIMEOUT_CONTROL[0] TIMEOUTENABLE bit. When enabled,the counter starts at start-cycle time until it reaches 0 and data is not responded to from memory,and then a time-out error occurs. When data are sent from memory, this counter is reset to its start value. With multiple accesses (asynchronous page mode or synchronous burst mode),the counter is reset to its start value for each data access within the burst.The GPMC does not generate interrupts on these errors. True abort to the MPU or interrupt generation is handled at interconnect level.

There is some detail on a related thread for the AM335 device regarding this function for reference as well - https://e2e.ti.com/support/processors/f/791/t/651634?Linux-AM3359-GPMC-WAIT-stalls-MPU

Best regards,

Dave