pmezydlo / beaglewire Goto Github PK

Trying a BeagleWire today using the pre-prepared image, I noticed today that echo statement in

$ xxd blink.bin | tail -n 4
00020fa0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00020fb0: 0000 0000 0000 22fb d201 0600 2d65 205c  ......".....-e \
00020fc0: 7830 5c78 305c 7830 5c78 305c 7830 5c78  x0\x0\x0\x0\x0\x
00020fd0: 305c 7830 0a                             0\x0.

I have a PR with a tested fix. idcrook#1

$ xxd blink.bin | tail -n 4
00020f90: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00020fa0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00020fb0: 0000 0000 0000 22fb d201 0600 0000 0000  ......".........
00020fc0: 0000 0000                                ....

I also added a target (.bg-prog) in the shared makefile in same PR to use the fpga upload wrapper that comes with the pre-prepared image, since the .load target did now seem to be working for me.

cd ~/BeagleWire/examples/blink_leds
make
sudo make blink.bw-prog

Should I submit a PR here? I am wanting to make it easier for pre-prepared image/QuickStart to use the examples, etc.

Since I don't have the quick start firmare image due to issue #1, I've tried building the dev environment on a stock debian BBB image. To get to the point of being able to try the fpga-load.ko I had to:

• update to 4.14 to get the fpga manager support and installed kernel headers
• build fpga-mgr.ko and ice-spi.ko as out-of-tree modules and insmod'ed them
• compile the DTS/BW-ICE40CapeV2-00A0.dts into a dtbo and installed it with the cape manager
• fixup the paths in bw-prog.sh

When fpga-load.ko is insmod'ed by the script, it fails with "Cannot find manager node" and exits without loading the bitfile.

I'd like to purchase the LCD for the game, see how it works.
Could you add a README.md in the lcd and lcd_game directories describing where I can purchase the screen?

I've been trying to track down why sdram results are sometimes wrong (issue #7) and think it might be due to gpmc occasionally mis-timing data and address. I modified the examples/sdram/top.v to require the top 8-bits of the commands to have a magic value and log any writes to gpmc address 0 that don't have those bits.

For a while everything is fine, but then a spurious value shows up, usually with some bits of the previous write.

icetime is reporting that we're meeting the 100 MHz timing goal (9.08 ns / 110.08 MHz), so I think it is related to the clock-crossing in gpmc.

These projects seam to have timing issues.? They need to be checked against the icetime utility. Even when using the nextpnr utility, which tries to improve timing by better placement, on a pc, the examples are below the 100Mhz.

The proposed tool set includes archne-pnr. This tool claims to support only the 1K and 8K lattice parts of the iCE40 family. The beaglewire uses the 4K device. Can you please clarify.
Thanks

The quick start image at https://github.com/pmezydlo/BeagleWire/blob/master/load_fw/image.tar.xz is unavailable due to insufficient LFS credits.

Would you add the file as a release instead? Github's guide to working with large files suggests that as a way to distribute large binaries and "We don't limit the total size of your binary release files, nor the bandwidth used to deliver them".

It looks like the sdram_controller can miss read/write commands if they occur when a refresh is happening. It checks for edges on the enable pins only if state == IDLE:

  if (state == IDLE)
     if (rd_enable && !rd_enable_prev)
          begin
          next = READ_ACT;
          command_nxt = CMD_BACT;

but the rd_enable_prev and wr_enable_prev are updated on every clock cycle:

always @ (posedge clk)
   begin

    wr_enable_prev <= wr_enable;
    rd_enable_prev <= rd_enable;

Are the PMOD connectors reversed from the "standard"? The docs for most PMOD look like this, with pin 1 on the right side:

The ones on the BW have pin 1 on the left side and ground/power on the right.

I see no updates in development since april 2018 . So, I suppose there are no new updates or examples (like "how to..") on te BeagleWire.
I tried for weeks to get the Wire working but without any succes. I always end up with: "fpga-load.ko not found".
I believe that when spending so much money on a BeagleBone Black and a BeagleWire it should be up and running within a few hours.

Is the sense of the SDRAM's rd_busy incorrect? In the verilog code the logic is: https://github.com/pmezydlo/BeagleWire/blob/master/components/sdram_controller.v#L161

assign rd_ready = rd_ready_r;
[...]
   if (state == READ_READ)
      begin
      rd_data_r <= data_in_from_buffer;
      rd_ready_r <= 1'b1;
      end
    else
      rd_ready_r <= 1'b0;

Which makes rd_ready an active high signal when the read has data available. However, the sdram.c code calls it rd_busy and appears to spin waiting for it to go back to 0: https://github.com/pmezydlo/BeagleWire/blob/master/bridge_lib/sdram.c#L72 and

Although I just noticed that rd_ready_r is reset after one clk, so I'm updating my test to latch it to be sure that it is noticed by the host interface.

PR #6 adds a check for the value read from the sdram in bridge_lib/sdram.c as well as adds an XOR value so that repeated runs can be distinguished. This shows that it fails some of the time, but a repeated read works most of the time.

debian@arm:~/bridge-cleanup/bridge_lib$ sudo ./sdram 0x55
sdram=0xb6dec000
addr=0xb6dec002 0xb6dec004
rd_data=0xb6dec008
writing....
reading....
try 0 data[b]=5f BAD
try 0 data[17]=17 BAD
try 1 data[17]=17 BAD
try 2 data[17]=17 BAD
try 3 data[17]=17 BAD
try 0 data[2a]=7c BAD
try 0 data[4f]=1b BAD
try 0 data[52]=52 BAD
try 1 data[52]=52 BAD
try 2 data[52]=52 BAD
try 3 data[52]=52 BAD
try 0 data[5b]=f BAD
try 0 data[5d]=5d BAD
try 1 data[5d]=5d BAD
try 2 data[5d]=5d BAD
try 3 data[5d]=5d BAD

Reads where only one try is reported means that the second read worked and the first read was ignored (likely the value returned was stale; note that data[2a] read 0x7c, which is the correct value for the previous read since 0x7C == 0x21 ^ 0x55).

Reads where there are three tries indicate that perhaps the write failed (note that data[17] == 17, which indicates that the previous run with an XOR of 0x00 successfully wrote the value).

I've read much, but am still not sure how write to /dev/mem in the beaglebone to make the arm_blink_leds example work.

Could you include a C program that does the right thing?
I would be happy to write a README.md for that example if I had a program that could flip those bits!