Information regarding development for the Pyra

[D32_bobjob]

Hi,

I (pre-)ordered one of this nice little boxes, but now I'm looking for information on how to setup a development environment.

What I want to do:
- learn to do linux kernel stuff(I'm a software developer, but I have not much experience beside x86)
- improve driver for the pyra if I need them
- write games, libs, ... whatever I want to do
- in general I want to write code I enjoy writing in addition to my day job that brings in the money

What do I need to know:
- is there a prefered linux distribution(I expect Debian)?
- is there a documentation somewhere to use as a template for similar targets that need only little adjustment(like for the BeagleBoard)

-> I found some documentation about that, but I want to avoid reading stuff that does not help
-> simple notes, in bad english/german are good enough for me. I'm used to this​

Thanks,
Jörg

 

[lukey]

Here's an pretty good Guide on Linux Drivers/Modules: http://www.tldp.org/LDP/lkmpg/2.6/html/ .There are many Co-Processors/Peripherals (Hardware Face Detection to give one example) in the OMAP5 that need Drivers.

 

[D32_bobjob]

The link looks good for general kernel development. But the more important thing I need to know is, how to setup the development environment for this platform*. You know, the stuff that is a pain in the a?? to figure out because you have to setup adresses and stuff before a make produces a workable binary. So fare I always had something like this setup for me and I never hat to compile for a different platform(I know C#/C++ for windows[under windows] and C/C++ for bare metal x86 [under windows], both mostly at work).

Jörg

PS: (*) the 'Pyra'

 

[TrashyMG]

It's shipping with standard Debian, all the build tools and libraries can just be installed from the repository like it can on an x86 platform.

just install the build-essential package to get all the compiling tools.

I typically use a light weight editor called Geany, but Code::Blocks or even netbeans should work alright on the Pyra.

 

[D32_bobjob]

Yeah, but I want to develop on my PC, it is much more powerfull and I really do not want to compile on the Pyra. As good as a platform for my usecases it is(ultra mobile PC), low level hardware development is not part of that.

Jörg

 

[TrashyMG]

Yeah, but I want to develop on my PC, it is much more powerfull and I really do not want to compile on the Pyra. As good as a platform for my usecases it is(ultra mobile PC), low level hardware development is not part of that.

Jörg

Honestly dealing with the OMAP5 devboard I found compiling fairly quick, especially when accustomed to compiling on the Pandora directly.

So in your case you would need a cross-compiler, I've had fairly good experience with them running in an x86 Linux environment, but haven't used them in a Windows environment. In the past for the Pandora we've had a community member assemble a virtualbox image that has a Linux install with all the cross-compiler tools and libraries pre-installed.

 

[D32_bobjob]

No no no, I do not want to develop under windows, I'm used to it(@work), but I know that linux(I'm linux user if it works) is better suited for this task. At the end I will compile the final version on the pandora before that, e.g. as long as I do not have the actuall hardware and to compile my code if I do not have the HW available I want an environment that works anyway.

 

[lukey]

Yeah, but I want to develop on my PC, it is much more powerfull and I really do not want to compile on the Pyra. As good as a platform for my usecases it is(ultra mobile PC), low level hardware development is not part of that.

Jörg

Well the Linux kernel doesn't depend on libraries and Stuff so Crosscompiling Drivers/Modules isn't that hard. You'll need an ARM Crosscompiler like this one. Setting up Debian Jessie in an VM makes things easier. With an Proper Makefile its just an matter of invoking "PATH=$PATH:/path/to/toolchain/bin make make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- LINUX_SRC=/path/to/kernel-src". For Application Development i suggest you to write your stuff so that it runs in your Debian VM (libsdl1/2 are a good starting point) and compile/test it there. Later you can compile and Package it on the Pyra.

 

[D32_bobjob]

Ok. So only for kernel development a cross compile environment is a sensible way and because the rest uses standard libs, cross compile is just a waste of time? If so, I can live with that(I'm used to more problems ... ).

Jörg

 

[notaz]

Depending on your distro you might be able to install the cross compiler directly from your package manager. For example on Ubuntu, there is gcc-arm-linux-gnueabihf package for that.

It all should look something like that:

sudo apt-get install make gcc-arm-linux-gnueabihf u-boot-tools
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make omap2plus_defconfig
make
make uImage LOADADDR=0x80008000

And this should give you a kernel image that boots on Pyra. That's all there is to it really.

You might need some more tools along the way, but it shouldn't be hard to figure out from the error messages.

 

[D32_bobjob]

- Simple notes -- check
- it works this way -- we'll see
- Bad english -- you screwed that on up, for sure

I'll try this on the weekend and report back, maybe I'll use some more words in describing the problems I stepped into and how to get rid of em.

Jörg

PS: it will look like this and will give :
- install Windows 10
- install Hyper-V
- install debian
- do what notaz said
- tbd

But one thing is clear: SledgeHammers are involved.

 

[Grench]

Unless you're hard determined to get started -now-, you might want to just wait for your Pyra to arrive then develop and compile on it directly.

If you're concerned about working on a device with a 5" display and thumb keyboard, it has an HDMI output and you should be able to plug a keyboard and mouse directly into the USB ports on the back. At that point the difference between working on it (slightly longer compile times) and working on your X86 (with cross-compile headaches) should be pretty moot.

Don't let it's diminutive physical size fool you. Part of the point of Pyra's magic is a full desktop environment. No sledgehammers required?

- do what notaz said

That is a common theme and could become an ongoing meme - he knows his stuff.

 

[D32_bobjob]

Well, I want to setup the environment now(this will take a while, esp. the COM ports). From experience @work I know that it is a bad/frustrating way to work on the system that you are fixing/improving. Doing that remotly opens up a lot of possibilities(using google while staring at hardware error codes for example). For user space stuff I will develop on a debian system, but the kernel stuff will be done remotly most of the time. I'll only have to figure out how to setup TFTP(I'll need to start a IPXE client on the Pyra for that - help?) and enable remote debugging(e.g. the GDB server that can be build into the linux kernel, for that I'll have to find a serial port where I can add some wires and to them a MAX232).

Jörg

 

[Neelix]

Are you talking about using an OMAP5 devboard or building a serial interface for the pyra? I'm not sure if your aware that the charging port on the Pyra doubles as a debug serial port.

-Neelix

 

[D32_bobjob]

The second option would do if it allows debugging via GDB(no soldering is always good). But the information I got across so far, are not really helping in telling me what the hardware can do for me. Is this a simple serial port that is a attached to an ftdi serial-to-USB chip or is it something else? Again, I can speculate, but an USB port that doubles as serial debugging port could be anything, even a port that has a TI specific custum serial protocol only usable at full moon and after you sacrified a black and brown stripped goat ...

Sorry, as long as I do not know which datasheet to read exactly and then verifing it with real hardware I can get a little bit ?dramatic?. Even Intel, NVidia and AMD do not publish completly usable specs, so ... yeah ...


Jörg

 

[notaz]

It's connected to one of OMAP5's UARTs through usb-to-serial converter, yeah. You get Linux kernel messages there and a shell after the system boots.

 

[Grench]

It's connected to one of OMAP5's UARTs through usb-to-serial converter, yeah. You get Linux kernel messages there and a shell after the system boots.

To the point of silly...
If I hypothetically had two Pyras, would I be able to put in an RS232C (cross over) equivalently wired microUSB male <-> microUSB male cable, would I be able to use the shell on one Pyra from the OS/interface of the other? (I suspect so...)

No, I don't need the pin-out diagram for that cable... at least not today.

 

[Silent-Hunter]

To the point of silly...
If I hypothetically had two Pyras, would I be able to put in an RS232C (cross over) equivalently wired microUSB male <-> microUSB male cable, would I be able to use the shell on one Pyra from the OS/interface of the other? (I suspect so...)

No, I don't need the pin-out diagram for that cable... at least not today.

Just plug one's debug port into the other's host port?

 

[Grench]

Just plug one's debug port into the other's host port?

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

 

[Silent-Hunter]

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

I thought it was serial internally, but converted to USB so you can plug it into your PC to debug it?