summaryrefslogtreecommitdiff
path: root/include/stdio_dev.h
diff options
context:
space:
mode:
authorMarek Vasut <[email protected]>2019-11-20 22:34:31 +0100
committerMarek Vasut <[email protected]>2019-11-25 13:12:56 +0100
commit97a72bc28613733572b9632a51ab9c8680d45406 (patch)
treebf62d976bf67211e3324b6dd9d80a9ef96a70942 /include/stdio_dev.h
parent446cf811c58733c4b68149a0b83f4a258e1719ba (diff)
ARM: socfpga: Purge pending transactions upon enabling bridges on Gen5
On Gen5, when the FPGA is loaded and there was some prior interaction between the HPS and the FPGA via bridges (e.g. Linux was running and using some of the IPs in the FPGA) followed by warm reset, it has been observed that there might be outstanding unfinished transactions. This leads to an obscure misbehavior of the bridge. When the bridge is enabled again in U-Boot and there are outstanding transactions, a read from within the bridge address range would return a result of the previous read instead. Example: => bridge enable ; md 0xff200000 1 ff200000: 1234abcd => bridge enable ; md 0xff200010 1 ff200010: 5678dcba <------- this is in fact a value which is stored in a memory at 0xff200000 => bridge enable ; md 0xff200000 1 ff200000: 90effe09 <------- this is in fact a value which is stored in a memory at 0xff200010 and so it continues. Issuing a write does lock the system up completely. This patch opens the FPGA bridges in 'bridge enable' command, the tears them down again, and then opens them again. This allows these outstanding transactions to complete and makes this misbehavior go away. However, it is not entirely clear whether this is the correct solution. Signed-off-by: Marek Vasut <[email protected]> Cc: Chin Liang See <[email protected]> Cc: Dalon Westergreen <[email protected]> Cc: Dinh Nguyen <[email protected]> Cc: Ley Foon Tan <[email protected]> Cc: Simon Goldschmidt <[email protected]> Cc: Tien Fong Chee <[email protected]> Reviewed-by: Ley Foon Tan <[email protected]>
Diffstat (limited to 'include/stdio_dev.h')
0 files changed, 0 insertions, 0 deletions