Weekly Progress Report - BeagleWire Software Support

[Patryk Mężydlo]

After Week 1 (31 May - 7 June)

What is done:

- created wiki page and github repository

- created an introduction video

- created pinmap file to BeagleWire (https://github.com/pmezydlo/BeagleWire/blob/master/beaglewire_pinmap.pcf)

- created ICE40 overlay (https://github.com/pmezydlo/BeagleWire/blob/bw_bridge_irq/DTS/ice40-overlay-00A0.dts)

- added first example and makefile for it, (not tested, only synthesized on pc) (https://github.com/pmezydlo/BeagleWire/tree/bw_bridge_irq/example)

Issues: 

I solved the problem regarding compatibility of drivers, in old kernel in dts there

was "compatible = "linux,spidev";" and now it should be "compatible = "spidev";"

On kernel 4.4, loading custom cape works very well but I still have a problem with kernel 4.12.

It seems that uboot is not reading /boot/uEnv.txt file. Do you have any idea on how to solve this problem?

My ftdi output:

U-Boot SPL 2017.03-dirty (May 27 2017 - 13:06:39)

Trying to boot from MMC1

U-Boot 2017.03-dirty (May 27 2017 - 13:06:39 +0200)

CPU  : AM335X-GP rev 2.1

I2C:   ready

DRAM:  512 MiB

Reset Source: Power-on reset has occurred.

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Using default environment

<ethaddr> not set. Validating first E-fuse MAC

BeagleBone Black:

BeagleBone: cape eeprom: i2c_probe: 0x54:

BeagleBone: cape eeprom: i2c_probe: 0x55:

BeagleBone: cape eeprom: i2c_probe: 0x56:

BeagleBone: cape eeprom: i2c_probe: 0x57:

Net:   eth0: MII MODE

cpsw

Press SPACE to abort autoboot in 2 seconds

board_name=[A335BNLT] ...

board_rev=[00C0] ...

switch to partitions #0, OK

mmc0 is current device

SD/MMC found on device 0

** Bad device 0:2 0x82000000 **

** Bad device 0:2 0x82000000 **

switch to partitions #0, OK

mmc0 is current device

Scanning mmc 0:1...

gpio: pin 56 (gpio 56) value is 0

gpio: pin 55 (gpio 55) value is 0

gpio: pin 54 (gpio 54) value is 0

gpio: pin 53 (gpio 53) value is 1

switch to partitions #0, OK

mmc0 is current device

gpio: pin 54 (gpio 54) value is 1

Checking for: /uEnv.txt ...

1358 bytes read in 8 ms (165 KiB/s)

gpio: pin 55 (gpio 55) value is 1

Loaded environment from /uEnv.txt

Importing environment from mmc ...

Checking if uenvcmd is set ...

gpio: pin 56 (gpio 56) value is 1

Running uenvcmd ...

146 bytes read in 18 ms (7.8 KiB/s)

debug: [/boot/vmlinuz-4.12.0-rc2-bone0] ...

8409136 bytes read in 548 ms (14.6 MiB/s)

debug: [/boot/initrd.img-4.12.0-rc2-bone0] ...

5871791 bytes read in 390 ms (14.4 MiB/s)

debug: [/boot/dtbs/4.12.0-rc2-bone0/am335x-boneblack.dtb] ...

55025 bytes read in 50 ms (1 MiB/s)

debug: [console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ...

debug: [bootz 0x82000000 0x88080000:5998af 0x88000000] ...

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Using Device Tree in place at 88000000, end 880106f0

Starting kernel ...

My /boot/uEnv.txt file:

uname_r=4.12.0-rc2-bone0

enable_uboot_overlays=1

uboot_overlay_addr0=/lib/firmware/CUS_SPI-00A0.dtbo

cmdline=coherent_pool=1M net.ifnames=0 quiet

Next weak goals:

- first BeagleWire programming using ice40-mgr

- porting toolchain

Thanks,

Patryk

[Robert Nelson]

it's hitting the old eMMC compatibility path..

sudo rm /uEnv.txt

it would be good to update your version of u-boot: (2017.05 is out
now, with more u-boot overlay fixes)

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Patryk Mężydło]

---------- Forwarded message ----------
From: Patryk Mężydło <mezy...@gmail.com>
Date: 2017-06-07 1:41 GMT+02:00
Subject: Re: [beagleboard-gsoc] Weekly Progress Report - BeagleWire Software Support
To: Robert Nelson <robert...@gmail.com>

Week 1 (31 May - 7 June)

What is done:

- ported ICEStorm toolchain to BBB, (I had a problem with lack of memory but I created swap memory on BBB),

- created script which building and installing required tools and toolchains for BBB or PC,

- travis script,

- fixed ice40-overlay (thanks Michael) I need more information about new way to load fpga firmware, 

Probably it's similar to load firmware to pru. With Michael We'll plan contact fpga subsystem maintainers. 

Issues: 

all is well,

Next weak goals:

- begin work on GPMC configuration(DTS file),

- understand the GPMC signals,

- begin work on bridge module,

[Patryk Mężydło]

Week 2 (7 June - 14 June)

What is done:

- prepared eeprom cape conten 

- loaded cape information to eeprom

- prepared simple memory test application (https://github.com/pmezydlo/BeagleWire/blob/develop/BW_Bridge/mem_test/devmem.c)

- configurated GPMC controller from DTS (https://github.com/pmezydlo/BeagleWire/blob/develop/DTS/BW-ICE40Cape-00A0.dts)

- watched the GPMC signals using oscilloscope (signals look very well and I'm very happy to see that)

- began work on the bridge (simple state machine, latching address, data and nand cmd)

- created uart debug port 

Issues: 

all is well,

Next weak goals:

- further bridge development

[Patryk Mężydło]

Week 3 (14 June - 21 June)

 

What is done:

-  I worked on gpmc communication

-  repository refactoring (new, better sources locations, cleanup code, etc)

-  fix gpmc timings (I noticed a few glitches during transfer)

-  dual-port ram component (easy to use component, We have dual access to fpga memory, We can can use it with gpmc, it allows to use gpmc with other component for example gpio)

- add bridge-library (Since correct use of /dev/mem might be difficult, we could refrain from using it too much. For this reason I want to create only an easy library (init, read, write) for new users.)

 

Issues:

- works are moving a little slowly,

 

What is next:

- still I'm working on gpmc and dual port ram synchronization,

- gpio component with top layer, connect to kernel gpio subsystem,

[Patryk Mężydło]

Week 4 (21 June - 28 June)

 

What is done:

- spi controller is ready

- spi driver is still under development

- pll example

- BeagleWire elinux page: http://elinux.org/BeagleBoard/BeagleWire

- I'm still working on bus multiplexer component

Issues:

What is next:

- spi driver, first spi transfer

- add more information to eBeagleWire wiki page

- gpio controller

- start working on sdram controller

[Patryk Mężydło]

Week 5 (28 June - 5 July)

 

What is done:

- I did first spi transfer but I'm adding additional stuff to spi controller (setting CPOL CPHA, clock speed setting, etc)

- I acquainted with sdram documentation, I understand basic sdram operations and signals. SDRAM refreshing is ready.

- gpio controller is still under development

Issues:

What is next:

- merge spi to master

- merge gpio controller to master 

- simple reading and writing to sdram are ready

- add pwm controller

[Jonathan Cameron]

Testing spi against a scope or real hardware?

Might not be in meeting later...

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Patryk Mężydło]

Week 7 (12 July - 19 July)

 

What is done:

- I began work on uart ip core and kernel driver. This is a very difficult driver. 

- Uart transceiver and uart baud generator components are ready.

- I tested SPI and after cleaning the code drivers timings were wrong.

I fixed it but now I am working on new SPI ip core. I want to do a better

ip core with support for diferent word lengths (4 bits to 32 bits), 

a support for cpol and cpha settings, and support for clock divider etc.

- I rebuilt PWM ip core and now PWM has 64 bits counter with 200 MHz clock. 

Thanks to that we can generate PWM signals which are more precise and longer.

Issues:

What is next:

- merge new SPI ip core to master

- add support for new SPI features to spi driver

- further uart development

[Patryk Mężydło]

Week 8 (19 July - 26 July)

What is done:

- FIFO component is ready, code is completed and tested, (https://github.com/pmezydlo/BeagleWire/blob/develop/components/fifo.v)

- SPI driver is up to date and support new SPI core, (4-32bits per word, cpol, cpha etc)

(https://github.com/pmezydlo/BeagleWire/blob/develop/drivers/spi-ice40.c)

- GPIO driver is still under development, (I begun work on GPIO driver because I want add interrupt controller, mmio-gpio driver isn't supported interrupt from GPIO)

- a few amendments in uart tranceiver ip core (uart tx code is completed and tested using /dev/mem) 

(https://github.com/pmezydlo/BeagleWire/blob/develop/components/uart-tx.v)

- my second evaluation is completed

Issues:

What is next:

- GPIO driver is ready (code is completed and tested),

- further uart development,

[Patryk Mężydło]

Week 8 (26 July - 2 August)

What is done:

-uart transmitter and receiver are completed and tested, uart tx and rx have own fifo it works well. We can only load data to fifo. Uart automatically sends it. Uart ip block support different data width 1-16, parity bit, two stops mode etc, diferent speed. It's very interesting ip block. I think :)

here is memory map: https://github.com/pmezydlo/BeagleWire/blob/master/examples/uart/top.v#L166

Issues:

What is next:

- documentation,

- further uart driver development,

[Patryk Mężydło]

I have quite a lot of issues, but I'm sure each of them can be resolved with time and a lot of coffee.

[Jonathan Cameron]

All sounds good.

If you are after a quick code review feel free to use my work address. Jonathan...@huawei.com

On question inline

On 26 July 2017 16:00:45 BST, "Patryk Mężydło" <mezy...@gmail.com> wrote:
>Week 8 (19 July - 26 July)
>
>What is done:
>- FIFO component is ready, code is completed and tested, (
>https://github.com/pmezydlo/BeagleWire/blob/develop/components/fifo.v)
>- SPI driver is up to date and support new SPI core, (4-32bits per
>word,
>cpol, cpha etc)
>(https://github.com/pmezydlo/BeagleWire/blob/develop/drivers/spi-ice40.c)
>- GPIO driver is still under development, (I begun work on GPIO driver
>because I want add interrupt controller, mmio-gpio driver isn't
>supported
>interrupt from GPIO)

Interesting. Can't extend existing driver?

[Jonathan Cameron]

Not nearly enough issues :)

All going far too well.

I am off to China for a few weeks. No idea if my email will get through the firewall yet so may be hard to get hold of. Sorry about that.

Jonathan

[Jonathan Cameron]

That's exactly what went wrong with my day. Ran out of coffee...

On 2 August 2017 15:50:43 BST, "Patryk Mężydło" <mezy...@gmail.com> wrote:
>I have quite a lot of issues, but I'm sure each of them can be resolved
>with time and a lot of coffee.

[Patryk Mężydło]

Week 10 (2 August - 9 August)

What is done:

- documentation development :)

- a few fixes

- a lot of tests

- begin work on i2c component,

- uart driver development (I still read other uart codes),

Issues:

What is next:

- documentation,

- further uart driver development,

- i2c driver

- i2c component is ready

2017-08-09 16:35 GMT+02:00 Jonathan Cameron <ji...@jic23.retrosnub.co.uk>:

Plans to send drivers upstream?  In China so not waiting up for meeting!

On 9 August 2017 22:34:13 GMT+08:00, "Patryk Mężydło" <mezy...@gmail.com> wrote:
>Week 10 (2 August - 9 August)
>
>What is done:
>- documentation development :)
>- a few fixes
>- a lot of tests
>- begin work on i2c component,
>- uart driver development (I still read other uart codes),

>
>Issues:
>
>
>What is next:
>- documentation,
>- further uart driver development,

>- i2c driver
>- i2c component is ready

>
>2017-08-02 19:59 GMT+02:00 Jonathan Cameron
><ji...@jic23.retrosnub.co.uk>:
>

[Patryk Mężydło]

---------- Forwarded message ----------
From: Patryk Mężydło <mezy...@gmail.com>
Date: 2017-08-16 17:41 GMT+02:00
Subject: Re: [beagleboard-gsoc] Weekly Progress Report - BeagleWire Software Support

To: Jonathan Cameron <ji...@jic23.retrosnub.co.uk>

Week 11 (9 August - 16 August)

What is done:

- i2c component, is ready, https://github.com/pmezydlo/BeagleWire/blob/master/components/i2c-master.v

- i2c driver is ready in 50% (https://github.com/pmezydlo/BeagleWire/blob/master/drivers/i2c-ice40.c)

I2C component is very good but I have to adjust to work with driver. Now I2C component ending transfer always when fifo queue is empty or full. It's not working with long transfer. I want to add additional state "wait" and then driver can reload and load next data. I'm testing i2c with eeprom memory on BeagleWire board.

What is next:

- documentation,

- further uart driver development,

- i2c driver

- more tests

2017-08-10 1:04 GMT+02:00 Patryk Mężydło <mezy...@gmail.com>:

hmmm Those are very strange questions. I really dream about it, it's good code but for now it isn't useful. IP core is generic and it does not require specific platform, should be useful for xilinx, altera and lattice fpgas. I can do more generic drivers, like a gpio-mmio driver but for spi, pwm, i2c. It need more work but really I want to do it. What do you think?

2017-08-09 16:35 GMT+02:00 Jonathan Cameron <ji...@jic23.retrosnub.co.uk>:

Plans to send drivers upstream?  In China so not waiting up for meeting!

On 9 August 2017 22:34:13 GMT+08:00, "Patryk Mężydło" <mezy...@gmail.com> wrote:
>Week 10 (2 August - 9 August)
>
>What is done:
>- documentation development :)
>- a few fixes
>- a lot of tests
>- begin work on i2c component,
>- uart driver development (I still read other uart codes),
>

>Issues:
>
>
>What is next:
>- documentation,
>- further uart driver development,

>- i2c driver
>- i2c component is ready
>

>2017-08-02 19:59 GMT+02:00 Jonathan Cameron
><ji...@jic23.retrosnub.co.uk>:
>

[Patryk Mężydło]

Week 12 (16 August - 23 August)

What is done:

- a lot of work with i2c driver and i2c core, (https://github.com/pmezydlo/BeagleWire/blob/master/drivers/i2c-ice40.c)

- i2c transfer works very well,

- simple app to transfer data via uart (I don't have enough time to work on uart driver but I created simple application)

- a few lines of documentation,

What is next:

- documentation

- work only on fixing the bugs and carrying out tests

- wiki page