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

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 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.

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.

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?

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

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 :)

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?