Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build from scratch doesn't work #90

Closed
Eliad127 opened this issue Aug 17, 2021 · 15 comments
Closed

Build from scratch doesn't work #90

Eliad127 opened this issue Aug 17, 2021 · 15 comments

Comments

@Eliad127
Copy link

  1. The bug - When building image from scratch, wgd.sh fails (getting *.ko: Invalid module format)

  2. I tried to build the image from scratch.

  3. With my modification (removing Viterbi license) and without.

  4. Versions

    • OS: Ubuntu 18.04.5 LTS
    • Vivado: Vivado HLx 2018.3: WebPACK
    • openwif repo: commit 2742c72 (HEAD -> master, origin/master, origin/HEAD)
  5. Board/hardware type - Xilinx zed board + FMCOMMS4 (zed_fmcs2)

  6. WiFi channel number - Irrelevant

  7. Steps to reproduce the issue

    • Run the "Build openwifi Linux img from scratch" process (stdout and stderr files attached)
    • On board: Run ./wgd.sh (output attached)
      logs.zip
@JiaoXianjun
Copy link
Member

I think maybe you don't need to build the whole image from scratch.

You only need to generate new FPGA image following openwifi-hw (with your viterbi), and then follow:

https://github.com/open-sdr/openwifi#update-fpga

@Eliad127
Copy link
Author

Tested it, and the results are different but still doesn't work.

When using SD card image (https://users.ugent.be/~xjiao/openwifi-1.2.0-leuven-2-32bit.img.xz) and then replacing the BOOT.BIN the following happens:
- When running wgd.sh the output says all is ok.
- Hostapd process is running.
- No SSID broadcast, means the AP is not really starting (tested with WiFi scanner to make sure).

Before changing the BOOT.BIN the AP was up and stable.
Same thing when using the original openwifi-hw project to build the BOOT.BIN

@JiaoXianjun
Copy link
Member

JiaoXianjun commented Aug 18, 2021

when issue is there:

  1. cat /proc/interrupts
    Execute the "cat ..." command for several times
    You should see the number of interrupts of "sdr,tx_itrpt" (and related dma) grows, because it sends the "openwifi" beacon periodically)

  2. can you also show me the demsg output?

@JiaoXianjun
Copy link
Member

While testing openwifi-hw master FPGA, could you also update onboard software to openwifi master by: https://github.com/open-sdr/openwifi#update-driver

Because the image might be not matched with the latest master.

@Eliad127
Copy link
Author

Sorry for the late response.

Looks like there is a problem with the update-driver part.

First test with the following steps:
- Burn SD card with project image (https://users.ugent.be/~xjiao/openwifi-1.2.0-leuven-2-32bit.img.xz)
- Generate new FPGA image, and replacing BOOT.BIN with new one (https://github.com/open-sdr/openwifi#update-fpga)
- Power Cycle board
- Updating onboard software drivers (https://github.com/open-sdr/openwifi#update-driver)
- On board: Run fosdem-11ag.sh
- Result, failed to start (output of process attached)
fosdem-11ag_output.txt

Second test with the following steps (like I have done before):
- Burn SD card with project image (https://users.ugent.be/~xjiao/openwifi-1.2.0-leuven-2-32bit.img.xz)
- Generate new FPGA image, and replacing BOOT.BIN with new one (https://github.com/open-sdr/openwifi#update-fpga)
- Power Cycle board
- On board: Run fosdem-11ag.sh
- Result, no SSID broadcast, in /proc/interrupts sdr tx/rx are 0 (/proc/interrupts and demsg outputs attached as requested)
interrupts_output.txt
demsg_output.txt

@JiaoXianjun
Copy link
Member

That error means that the rf front-end dac is not ready, so the tx chain is blocked.

Could you share me your FPGA image (without replacing viterbi, leave the fpga source code untouched)? You can pack the directory "openwifi-hw/boards/zed_fmcs2/sdk/" and attach it here, after you run (README of openwifi-hw):

In Vivado:

Open Block Design
Tools --> Report --> Report IP Status
Generate Bitstream
(Will take a while)
File --> Export --> Export Hardware... --> Include bitstream --> OK
File --> Launch SDK --> OK, then close SDK

In Linux:

cd openwifi-hw/boards
./sdk_update.sh board_name

@Eliad127
Copy link
Author

Attached
zed_fmcs2_sdk.zip

@JiaoXianjun
Copy link
Member

I compare your file with the file in master openwifi-hw, they are the same. So you didn't generate your own FPGA image? Have you run:

In Vivado:

Open Block Design
Tools --> Report --> Report IP Status
Generate Bitstream
(Will take a while)
File --> Export --> Export Hardware... --> Include bitstream --> OK
File --> Launch SDK --> OK, then close SDK

In Linux:

cd openwifi-hw/boards
./sdk_update.sh board_name

@Eliad127
Copy link
Author

Sorry, with all of this re-testing I forgot I have moved my own build and cloned again.

Attached my FPGA image with the original source code of openwifi-hw.

zed_fmcs2_sdk.zip

@JiaoXianjun
Copy link
Member

JiaoXianjun commented Aug 19, 2021

I don't have any issue with your .zip. I do like this:

Put your system_top_hw_platform_0 into openwifi-my/openwifi-hw/boards/zed_fmcs2/sdk/ (replace the existing system_top_hw_platform_0)

Run on computer:

cd /directory-to/openwifi-my/user_space/
./boot_bin_gen.sh /directory-to/openwifi-my/ ~/Xilinx/ zed_fmcs2

(Use your own CORRECT directory! Your openwifi-my and Xilinx root directory!)

After above script finishes, the BOOT.BIN is in openwifi-my/kernel_boot/boards/zed_fmcs2/output_boot_bin/

Run on computer:

cd  /directory-to/openwifi-my/kernel_boot/boards/zed_fmcs2/output_boot_bin/
scp ./BOOT.BIN root@192.168.10.122:

Run on board:

mount /dev/mmcblk0p1 /mnt
cp ~/BOOT.BIN /mnt
cd /mnt
sync
cd /
umount /mnt
reboot now

Power cycle the board, do the test and everything is OK.

@Eliad127
Copy link
Author

Ok, so when I run this steps it also works for me!
I'll try the same process with the modified Viterbi replacing code.

Still the build from scratch process doesn't work, but looks like there is a workaround..

@JiaoXianjun
Copy link
Member

Any news from your side?

@Eliad127
Copy link
Author

Eliad127 commented Sep 6, 2021 via email

@JiaoXianjun
Copy link
Member

Are you using some opensource viterbi decoder? Would you please tell me which project are you using?

@JiaoXianjun
Copy link
Member

If no further questions, I will close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants