Parallella Community

From reading the u-boot code, it seems to be done this way for the RAM because the ram is actually auto-detected (with the #define just being the maximum detect range).

The only things that seems to be patched in create_fdt() in arch/arm/lib/bootm.c are the memory node and the ethernet mac address.

OK. Thanks for following me down this rabbit hole with a lamp. That was fun!
I was expecting that shared memory could be more easilly and flexibly configured. But not so sure that this is productive now:-
- The U-Boot config controls the allocation of shared memory allocation of 32MB.
- To change that amount involves recompiling the whole bootloader.
- I'm in favour of minimal change to U-Boot board config to minimise the U-Boot Git hassle.
- The "memory" allocation in the device tree should be tidied/removed to avoid confusion (- or recognised by U-Boot which I can't see happening).
- Will update the thread on 'increased shared memory', maybe skin the cat another way.

tery

fyi..the u-boot/kernel shared memory hack was just a temporary solution, we are now working on something more flexible and way coooler.
Andreas

I was reading this blog: http://www.parallella.org/2014/05/13/fp ... expansion/ and it says "The FPGA projects are built using the PlanAhead tool and the free-of-charge ISE WebPACK Design Software is sufficient.". The article doesn't mention XPS and I could even change the GPIO implementation. But for more complex implementation beyond a blinking LED on a GPIO pin, I need XPS.

So I started XPS from PlanAhead with a double click to "Project Manager->Sources->Libraries->Design Sources->Embedded Design Sources->system" (these multiple nested panels are confusing). I tried a simpler tutorial ( http://www.zedboard.org/content/creatin ... peripheral ) and I could create my own VHDL module. "Design Rule Check" worked, I closed XPS, but how do I update the parallella_z7_top.v file? Looks like it has some auto generated signals in the "AUTOWIRE" section. I guess I can do it by hand, but this is error prone (especially in Verilog ) when I add and remove more peripherals.

Thanks, the Emacs feature sounds interesting.

Finally I managed to add a simple register based entity (with an AXI lite interface) and I wote a Linux kernel driver to map the register memory with request_mem_region and ioremap_nocache. I can write and read the registers, so XPS and PlanAhead works. When I use the non-modified bitstream, the driver aborts with an "imprecise abort" (I guess it detects somehow that there is no acknowledge from the AXI bus), so this is a proof that the entity was indeed synthesized in my design.

But I don't like the Xilinx tools. Sometimes PlanAhead crashes with an access violation and when I restart it, it can't generate the bitstream anymore, because it left read-only files from the last run. Or sometimes the netlist is not updated and I have to do it manually in XPS. The Altera tools with NIOS etc. look more stable and are easier to use. Well, the Zynq is still a nice chip, so I have to live with it. I guess Vivado will be all new and better, with many novel bugs

frank,
I created a simple register with an AXI lite interface as well. Then I have successfully reprogrammed my fpga design. However I'm having some issues to access my register, I was trying to do it mapping the physical address of my register to the virtual address through the mmap, however every time that I tried to access it, it freezes my parallella. Can you give me a little help on how you have written your driver, since my approach doesn't seem to work?
thank you