SD card image with Debian 8.0, Red Pitaya web server and SDK

[pavel]

Thank you for all the tests. I still have not tested it myself.

I plan to use the MCPHA application for my tests since it is the one where I actually use the oscilloscope functionality and has a GUI.

I think that the samples are lost because the throughput of the FPGA to RAM interface is probably not enough to transfer the samples at the full sample rate.

[fbalakirev]

I think that the samples are lost because the throughput of the FPGA to RAM interface is probably not enough to transfer the samples at the full sample rate.

I suspect the same. I note though that with your older library and OS we were able to stream large amounts of data (~100Mbyte) into HP port at ~ 1 Gbyte/sec.

[fbalakirev]

I think that the samples are lost because the throughput of the FPGA to RAM interface is probably not enough to transfer the samples at the full sample rate.

I suspect the same. I note though that with your older library and OS we were able to stream large amounts of data (~100Mbyte) into HP port at ~ 1 Gbyte/sec.

I redirected the axis_ram_writer output from ACP to HP0 and now the trigger position is accurately identified in the stream. As a follow up: does axis_ram_writer need any modifications to optimize its performance with HP0? Are there some QoS optimizations to prioritize HP0->DDR to ensure no potential data loss by any chance?

On unrelated note, I am using your pre-compiled Red Pitaya OS, and the console is spammed with;

Code: Select all

systemd-journald[390]: Data hash table of /run/log/journal/47c73d64eaa94b28a29ad                                                             2da07aca1f5/system.journal has a fill level at 75.0 (1691 of 2254 items, 1298432                                                              file size, 767 bytes per hash table item), suggesting rotation.
systemd-journald[390]: /run/log/journal/47c73d64eaa94b28a29ad2da07aca1f5/system.                                                             journal: Journal header limits reached or header out-of-date, rotating.

Is there a way or a need fix it?

[pavel]

It is good to know that the HP0 port has a higher throughput than the ACP port.

I finally did some tests with the MCPHA application. I have a similar effect with samples lost if decimation rate set to 1 (no decimation).

I think this is my only application where there is no decimation. Since the oscilloscope is not the main feature, fixing it is not my top priority.

I do not think you need to change anything in axis_ram_writer to make it work with HP interfaces if it already works.

Priorities are controlled by the SLCR registers DDR_URGENT and DDR_URGENT_SEL. U-Boot sets DDR_URGENT to 0xC, giving higher priority to HP ports. However, I do not use U-Boot in the latest release. It is probably possible to modify these registers from your application.

I have no systemd-journald console messages using the latest version of my SD card image (red-pitaya-alpine-3.18-armv7-20240204.zip). What is the file name of the SD card image that you are using?

[fbalakirev]

I have no systemd-journald console messages using the latest version of my SD card image (red-pitaya-alpine-3.18-armv7-20240204.zip).

Thank you for the suggestion. I downloaded 'red-pitaya-debian-12.4-armhf-20240204' image and that fixed the journal messages.

I did not find uEnv.txt on the new image though, which I used to set cma size. Is there a new method to set cma size?

I also tried to use PL fabric clock FCLK_CLK0, but it does not seems to be running. If that's the case, is there a simple way to re-enable that clock?

[pavel]

These changes are now made in the files in the dts directory.

The CMA memory size is defined in the rootfs.dts file.

For the clock, you will need to add the following lines to common.dts:

Code: Select all

 &clkc {
 	fclk-enable = <0x1>;
 	ps-clk-frequency = <33333333>;
 };

Then you will need to rebuild devicetree.dtb and boot.bin

[fbalakirev]

Thank you for the clarification. Sorry for my ignorance, but does OS image need to be re-buiit to incorporate changes to CMA memory size and/or fclk or there's a less involved method to change devicetree.dtb and boot.bin?

[pavel]

It should be enough to rebuild boot.bin and copy it to an SD card without rebuilding the image.

[fbalakirev]

It should be enough to rebuild boot.bin and copy it to an SD card without rebuilding the image.

Thank you, I'll try that.

In the meantime I merged in your latest master branch and went to re-make led blinker image. The image script failed around line 115 in debian.sh. The last few lines on the console:

Code: Select all

:/# service chrony stop
Stopping time daemon: chronyd.
:/# service ssh stop
Stopping OpenBSD Secure Shell server: sshd.
:/#
:/# history -c
:/#
:/# sync
:/# exit
umount: /tmp/BOOT.MO1OVWjQdp: not mounted.
umount: /tmp/ROOT.AB5dbsCKVh: not mounted.
rmdir: failed to remove '/tmp/BOOT.MO1OVWjQdp': Directory not empty
rmdir: failed to remove '/tmp/ROOT.AB5dbsCKVh': Directory not empty
zerofree: failed to open filesystem /dev/

Do you happen to any hunch how to fix that?

I've been using WSL with Ubuntu 22.04 for red pitaya notes builds if that matters.

[pavel]

Are you using something like the following command to run the script?

Code: Select all

sudo sh scripts/image.sh scripts/debian.sh red-pitaya-debian-12-armhf.img 1024

It seems that the script has a problem accessing the device on which it should create the boot and root filesystems.