Weekly Progress Report - BeagleWire Software Support

Google Summer of Code
1

After Week 1 (31 May - 7 June)

What is done:

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

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

2

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,

3

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,
4

Week 2 (7 June - 14 June)

What is done:

Issues:
all is well,

Next weak goals:

  • further bridge development
5

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,

6

Week 4 (21 June - 28 June)

What is done:

Issues:

What is next:

  • spi driver, first spi transfer

  • add more information to eBeagleWire wiki page

  • gpio controller

  • start working on sdram controller

7

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

8

Testing spi against a scope or real hardware?

Might not be in meeting later...

9

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

10

Week 8 (19 July - 26 July)

What is done:

Issues:

What is next:

  • GPIO driver is ready (code is completed and tested),
  • further uart development,
11

All sounds good.

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

On question inline

Week 8 (19 July - 26 July)

What is done:
- FIFO component is ready, code is completed and tested, (
BeagleWire/components/fifo.v at develop · pmezydlo/BeagleWire · GitHub)
- SPI driver is up to date and support new SPI core, (4-32bits per
word,
cpol, cpha etc)
(BeagleWire/drivers/spi-ice40.c at develop · pmezydlo/BeagleWire · GitHub)
- 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?

12

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 :slight_smile:

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,
13

Not nearly enough issues :slight_smile:

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

14

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

15

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

16

Week 10 (2 August - 9 August)

What is done:

  • documentation development :slight_smile:
  • 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

17

Week 11 (9 August - 16 August)

What is done:

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.

DS1Z_QuickPrint5.png

What is next:

  • documentation,

  • further uart driver development,

  • i2c driver

  • more tests

18

Week 12 (16 August - 23 August)

What is done:

What is next:

  • documentation
  • work only on fixing the bugs and carrying out tests
  • wiki page

DS1Z_QuickPrint5.png