Unaligned access when trying to reach AXI-LW from U-Boot

[Altera_Forum]

Hello, 

 I have a QSYS system, including some Avalon-MM peripherials connected to the AXI-LW interface of the HPS.  For testing purposes I tried to read their registers from the serial console of the u-boot, which gave me the following error message: SOCFPGA_CYCLONE5# md 0xff200000 ff200000:data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : lr : sp : 3ff4f5c0 ip : 00000083 fp : ff200000 r10: ff200000 r9 : ff200000 r8 : 3ff4ff60 r7 : 00000040 r6 : 00000000 r5 : 00000004 r4 : 00000004 r3 : 3ff4f5cc r2 : 3ffbbb54 r1 : 0000003a r0 : 00000009 Flags: nZCv IRQs on FIQs off Mode SVC_32 Resetting CPU ... resetting ...  What is the issue here? Cannot the Avalon-MM registers be reached from the u-boot console?  thanks  Hannes

[Altera_Forum]

That may not be an unaligned access, just an invalid address. 

You might just need to check the address you should use when running under uboot. I don't know whether uboot runs with the mmu enabled - in which case you need the virtual address the physical one is mapped to.

[Altera_Forum]

--- Quote Start ---  That may not be an unaligned access, just an invalid address. You might just need to check the address you should use when running under uboot. I don't know whether uboot runs with the mmu enabled - in which case you need the virtual address the physical one is mapped to.  --- Quote End ---    Thank you. That is something I completely forgot as I always used a Nios II without MMU. Which would be the correct address? The address I used is the offset from the QSYS system + the matching common address space region from the Cyclone V Handbook.

[Altera_Forum]

Dunno - A nios system wouldn't be able to generate an Avalon address of ff200000 without going through the mmu (because the top bit requests 'cache bypass'). 

Whatever memory uboot is running from has a virtual address ending at 40000000 - might give a hint about whether it runs with the mmu enabled or not. I suspect the arm cpu runs like a 'sick pig' without the i-cache enabled, but it is a long time since I've done anything with an arm cpu and I can't remember whether you have to enable the mmu in order to enable the caches.

[Altera_Forum]

It seems that I have to enable the lwhps2fpga bit in the remap register, to remap the address space. 

 Edit: I still get the same error in uboot.  What I have done:  - mw remap 0x11 to activate the hps2lwfpga - md 0xff200000 to read the register at offset 0x0  Did I forget something?  Edit: Using the address 0xff800000 directly instead of "remap" seems to work. But when I try to read the registers under 0xff200000 everything is blocked. At least it does not reset the whole thing anymore. Do I need to configure anything else to be able to communicate with my peripherals in the FPGA?

[Altera_Forum]

What I do from uboot: 

 run mmcfpga -> to load my rbf  run bridge_enable_handoff -> to enable the bridges  Make sure there is something on register 0 in the FPGA, and start with writes io of reads ( reads hang when there is nothing present, writes are a bit more robust ;p )   Other remarks: - The mapping loaded in uboot seems to be 1 to 1 so there is not need to recalculate addresses there - Use a preloader/uboot generated from the correct handover files

[Altera_Forum]

Thank you for your reply, I did not know run bridge_enable_handoff yet. 

This also leads to a freeze, but it looks already promising :)

[Altera_Forum]

I have now access to everything from the uboot console. But if I try to access the memory from the NIOS II, everything stucks. Can this be related to the ARM "security" feature? Do I have to enable that in QSYS? If yes, for every Avalon-MM master, slave etc? 

 My system's structure in QSYS is: HPS -> f2h_sdram_0_data -> Address span extender -> NIOS II.  Is there anything wrong with that?