Forum Replies Created
You have to connect the ahblite interface from the MIPS core to the AHBLite to AXI brigde.
Its a bus and has a different icon. Hence, it is easy to miss.
I’ve attached an image.
ZubairLK26th July 2017 at 11:24 am in reply to: Runing Linux on MIPSfpga+ and Altera's FPGA-based board #64425
Very good work indeed!
Regarding the ahb-lite uart + ahb-lite sdram wrapper. AFAICT, they are written in Verilog. Is it ‘technically’ easy to port to an equivalent Xilinx FPGA based board? Is there a board with 32/64Mbyte SDRAM with an easy interface to hook up to.
MIPSfpga-SOC (not mipsfpga-plus) is based on Xilinx only and uses an AHB-lite -> AXI bridge to use Xilinx IP blocks.
Some history from memory…
While developing MIPSfpga SoC, I found that Ethernet would sometimes glitch.
A packet lost here and there. A TCP connection dropped. I tried debugging it in detail a few times but couldn’t trace the source of the problem (I was looking from a SW/Linux angle. And not RTL). If I’m not mistaken, I thought I documented this in some appendix/faq.
As MIPSfpga SoC wasn’t intended as a production platform but a teaching resource. Despite the occasional glitch, the Ethernet part of MIPSfpga SoC was sufficient to showcase how a complex IP -> AXI -> AHB-Lite -> MIPS -> Linux Kernel -> Linux Userspace path worked.
There were some timing constraint issues on the MIPSfpga SoC project_linux. When I stared at them, I found them to be with areset wires which I ignored and then subsequently forgot about. Could they be linked with occasional Ethernet glitch. Possibly. Not sure.
Nice work! Debugging this and getting it working is a big job itself. But documenting it so well is truly amazing work indeed.
Just a minor point.
Could you please update your pdf on github with the exact link to the aliexpress part you purchased and managed to get working. Sometimes there can be subtle differences in modules based around the same chip depending on the vendor on aliexpress. This would potentially help a person not as keen as yourself on debugging a subtly different module.
ZubairLK2nd June 2017 at 11:48 am in reply to: Problem for Linux AXI Ethernet driver with SGMII mode #64435
First of all. I commend you on such an ambitious project.
I would recommend simplifying the design as much as possible and then incrementally adding complexity.
e.g. Remove the DMA controller if possible. Remove interrupts if possible to run the device in polling mode. Start with the minimum RTL addition needed.
In this case, we are not entirely sure if the issue is in software or the RTL.
Hence, debugging this can take a tremendous amount of skill and time.
To start with, I don’t see how we can be certain that Tx packets are working and Rx packets are not? The Tx count reported by ifconfig might not be working.
Are Tx packets actually being sent out on the Ethernet wires?
Ping a target IP address. Check if actual Tx packets are going out on the Ethernet interface.
This can be debugged in HW by connecting a logic probe at the Tx lines.
If that is working then good.
Is the Rx packet from ping coming back? If it is coming back then excellent.
Then trace the Rx packet back to SGMII lines.
If the Ethernet IP core is receiving the packet.
Then excellent. Use openocd. Pause the MIPS core. Check physical registers of the SGMII block and read them to see if the Rx packet is in the Fifo. If it is, then start tracing in software in the kernel.
I’d recommend a systematic approach and tracing the whole data path from Hardware to RTL to Software and back.
Yes they should work.
The BRAM is used for program memory and isn’t written to much (if at all).
If I remember correctly, it was something to do with addressing of memory.
There is also a note in the appendix document 6.3 which explains a bit about addressing.
You could try enabling it and see what happens.
And/or see if a store byte instruction works with/without.
Just to double check.
Do these devices (uio/gpio/i2c/ethernet) work OK with your 2016.2 RTL/bitstream and the older provided vmlinux file?
Also, have you followed steps to rebuild vmlinux/buildroot? Or did you directly go for Yocto?
Congratulations on getting so many things working.
Could you try enabling the following options in the Kernel configuration.
Ideally, these should be in the defconfig but I may have missed something accidentally in the Yocto configuration file or in the upstreamed defconfig on kernel.org. Probably because of booting with the additional kernel boot argument. “devtmpfs.mount=1”
ZubairLK29th March 2017 at 5:17 am in reply to: Building the MIPSfpga SoC "project_linux" from scratch #64454
IIRC, I have seen this before. The exact solution escapes my memory.
I think when the Axi interconnect is created, it defaults to 100MHz for whatever reason.
And we connect the clock afterwards, which causes this. Ideally, it should derive the clock for the block from the source clock.
The work around is when to click the axi interconnect block, check the properties. There is a freq_hz property of the block (or the clock line). The clock parameter needs to be set to 50MHz. Or whatever your system clock is.
And I think I also tried simply deleting the axi interconnect block and putting it again.
Glad you managed to get it working.
Thanks for the feedback
If I remember correctly, there were some warnings due to a bit width mismatch in the block ram. Those can be ignored safely. The project in the workspace/project_linux folder should synthesize to the point of generating a bitstream file despite those warnings.
Could you please share the warnings/error messages you see?
Are you synthesizing the provided project in the workspace folder? Or have you followed the documentation and created your own project?
Could you perhaps share which Debian version you are running and which image is flashed on the Ci20?
The Bluetooth hardware is a bit of a black box basically. The kernel loads the firmware for the chip. And then the interface to the bluetooth chip from the JZ4780 and kernel perspective is a simple UART tx/rx wire. I’m not aware of any kernel configuration options required for Bluetooth audio.
The rest of the Bluetooth stack is in userspace as far as I know. You could check your BlueZ version perhaps. If you are using pulse-audio, perhaps you would need to install pulseaudio-module-bluetooth ?
Those steps do look sound.
Do you happen to have a serial connection to the board and then look at the log to try to identify where the slowdown happens.
In my experience,
e.g. uboot should appear very quickly.
And tftp kernel should happen quickly as well.
Kernel boot should happen ok as well.
All of the above should take less than 2 minutes.
Initializing a rootfs can take some time and depends on how many services are being initialized and how fast the link is. 10/100 Mbps etc.
What rootfs are you trying to load?
ZubairLK1st February 2017 at 8:36 am in reply to: UBIFS error : ubifs_mount: cannot open "ubi0:boot" #63706
Is everything else use-able and just ssh showing that error?
There could be some corruption in the NAND filesystem.
If you have an SD card handily available, you could reflash the latest Debian image http://www.elinux.org/CI20_Distros#Debian_8_2016-02-02_Beta