Make loader, library and demo code work with Raspberry Pi 2

[campbellsan]

Raspberry Pi 2 now offers 1GB of RAM, but in order to get this, the memory mapped IO address had to be moved. This breaks the BCM2835 library on which our code is dependent.

We had an issue (#9) to remove dependency on this library anyway, so this gives us the additional motivation to get it done.

[campbellsan]

With latest pushes to the issue32 branch, gzlib is substantially rewritten to eliminate dependence on BCM2835 library. All demo programs have similarly modified to eliminate any dependencies. All programs build without errors.

At this stage, only gz_test has been tested, and only on a Pi2. This exercises the hardware clock interface which many of the cores depend on.

Next up will be to test the SPI interface, with the direct IO following on from that. We will then run all demos against all revisions of Raspberry Pi.

[campbellsan]

Update: core gz_16o8i now tested on Pi 2. Since this exercises the SPI channel, it is highly likely all other demos will Just Work. The only ones that might have an issue are the ones which use direct input or output, that is, the cores with upper case I or O in the name. There is no reason to expect these not to work, just that they use different ways of passing events to and receiving events from the Pi which are so far un-exercised.

Looking good, still not tested for backwards compatibility, but informal testing shows that at least a Pi B+ works.

[campbellsan]

Update: core gz_24o1I now tested on Pi 2. This one did not work as expected. It seems that with a spi width of 3, the spi driver waits to fill up the buffer. When the test switched between patterns on the Pi 2, this caused an ioctl 'Invalid argument' error, due presumably to a different threading pattern. Closing the spi device and sleeping for enough time for the spi buffer to empty solves the problem, but designers should be aware of this issue.

This core proves that direct input works.

[campbellsan]

Correction: The invalid argument errors were not caused by the Pi 2, but by the upgrade to the 3.18 kernel. See the issue discussion here:

http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=97216&start=50 (by oklitz » Thu Jan 29, 2015 9:07 pm)

[campbellsan]

Update: core gz_24i1O now tested on Pi 2. Works as expected. This is the last one that we were expecting possible problems with. It has none. Should be able to fly through the remaining test code now.

[campbellsan]

Update: cores gz16i8o, gz_25o, gz_25i now tested and working. At this point all simple io cores are seen to be working on the Pi 2. Still to be tested are the PWM cores and the specialised cores; gz_led_driver, gz_arduino, gz_lcd_driver and gz_ppm.

The loader has performed flawlessly, so that does not look like a barrier to promotion to master. We just need to finish the Pi 2 tests and perform regression testing on pre-Pi 2 models.

[campbellsan]

Update: PWM cores tested and functional.

[campbellsan]

Update: Last few commits only made cosmetic changes. All IO cores now tested on Pi B+ with Raspbian 3.18.

Still have to test the specialised cores, but that will take a little while to set up the specialised hardware they connect to. We will test these across all Pi revisions one at a time to minimise hardware setup time.

However, at this time, this branch, "issue32" looks safe for all Guzunty users.

We may delay promoting this branch to master while the latest OS settles down. There are several things that need to be addressed by the Raspbian community and changes may break what we have done here.

[campbellsan]

Update: gz_led_driver specialist core passes on both Pi 2 and Pi B+.

We may not be able to test gz_lcd_driver on Raspbian 3.18 immediately due to driver dependencies. This support will almost certainly be forthcoming soon, but a separate issue will be raised to track this to resolution.

[campbellsan]

Update: gz_led_driver and gz_test cores now tested on Pi 2, Pi B+, Pi A+, Pi A and Pi B (early 256MB model).

[campbellsan]

Update: All cores but one have now been tested on all available Pi variants. The outstanding core is gz_lcd. There have been substantial changes to the fbtft drivers; it is now device tree based and in addition has made the step of transitioning into the linux upstreaming process. The result is that configuration is very different and we are in the process of developing a configuration compatible with our test hardware.

I don't think this is a reason to delay updating the Guzunty master.

[campbellsan]

All changes upstreamed to master. Closing this issue.

Testing and configuration of gz_lcd will be tracked under a new issue.