Information regarding development for the Pyra

[slaeshjag]

No... debug port isn't usb. It is serial like old modem stuff.

Debug port is USB. The OMAP has an UART, but it's connected to a UART<->USB bridge.

 

[valhalla]

You can install a crosscompiling environment on Debian using multiarch:

https://wiki.debian.org/CrossToolchains

Some of it is only available in stretch (testing) however.

 

[stevenc99]

What might be ideal then, are backported *cross* gcc-5, binutils etc. packaged up in a jessie chroot, so that ":armhf" versions of build dependencies (the same versions as those on the Pyra) can be installed using multiarch. I'll have some free time in a couple of weeks to attempt this and will be happy to put together some instructions and share the result.

 

[Yoyobuae]

No... debug port isn't usb. It is serial like old modem stuff.

It's an USB slave (ie. device, not computer) port. Just like the USB/charging port on a cellphone is a slave which is meant to be connected to a PC on the other side via a micro B USB plug:
https://en.wikipedia.org/wiki/File:MicroB_USB_Plug.jpg

When connected to a a USB host then it (the internal UART<--->USB bridge) presents itself as an RS232 serial adapter (from wikipedia):

Class   Usage       Description     Examples, or exception
00h     Device      Unspecified[45] Device class is unspecified, interface descriptors
                                    are used to determine needed drivers
01h     Interface   Audio           Speaker, microphone, sound card, MIDI
02h     Both        Communications  Modem, Ethernet adapter, Wi-Fi adapter,
                    and CDC Control RS232 serial adapter. Used together with class 0Ah (below)

So that in the computer you could open use a terminal to see/interact with the Pyra via the serial interface.

In theory it would be possible to use one micro-B to A USB cable to connect the debug port of one Pyra to the fullsize USB host port on another Pyra.

Then another cable would be required for the back connection. And then both pyras would try to charge each other endlessly (wasting power instead).

TL DR; It's actually Serial over USB, not a pure RS232 serial port.

 

[D32_bobjob]

Ok, was easier than expected to get at least a "Hello World!\n" build(have to wait for HW to test it ...*freu*).

Installed on debian every thing according to https://wiki.debian.org/CrossToolchains#For_jessie_.28Debian_8.29 and the used arm-linux-gnueabihf-gcc to compile the main.c. The result is a file that should run on a ARM device according to 'file a.out'. For more serious stuff, e.g. compiling kernel and stuff I'll have to play around a bit. If that works I'll try a newer GCC version or LLVM/CLang.

Hm ... I can try to compile for mi RaspPi and see if it works there and if so, only the compiler has to be changed..., but not today.

 

[Orbstheorem]

if it works on a raspberry pi, It's almost sure It'll work on the pyra.

If you want to go into linux kernel development I'd advise you to read "understanding the linux kernel" from O'reilly. then you may read "Device Drivers".

 

[sulu]

You could test your compiled binaries in a Qemu VM. Among others, Qemu can emulate a Cortex A15, which will be used in the Pyra. This would be much closer in terms of CPU features than running it natively on a Raspberry Pi (1st gen.).
Qemu comes with a huge performance penalty though, when emulating foreign architectures. So I wouldn't recommend to compile in the VM directly. And you shouldn't make performance judgements based on what you see in the VM.

 

[Orbstheorem]

You could also try an ODROID XU4 aswell, it has very similar architecture (Although it was 4 A15 instead of 2 and 4 extra A7).