Has anyone got OpenGL working in their kernel?

[richcole]

It's fun to start with the frame buffer, but I presume going through the opengl library is going to make a bunch of stuff a lot faster. Do you just link the opengl code into your kernel? Does anyone have a link to github where they got it working?

My beaglebone has a usb serial port which makes getting started pretty easy. The serial port looks like a serial port from the ARM side, but it connected over USB and appears on my desktop as serial port in /dev. Are you all doing something similar for your kernels on the pi?

Is there a canonical collection of hobby OS info for the pi out there anywhere. I found lots of links here and there but no "hub" as it were.

regards,

Richard.

[gnif]

I am just about to start investigating the OpenGL path as I want the same thing.

As for debugging, I am using a USB JTAG interface with OpenOCD. I have the older board so I had to patch S5-11 into the P1 header to make it work, but this allows code stepping and is invaluable to bare metal development.

What I did to expose S5-11 on the P1 header was to remove P1-14 (GND), drill out the hole for it to break its connection to the internal ground plane, making sure not to drill out the black plastic on the header, and then glued the pin back into place. Then I brought a wire (wire-wrap) from S5-11 through one of the unpopulated holes on P3 and across to P1-14.

This makes it so that I don't have a hanging wire in the box, and I can easily unplug the JTAG interface adaptor (made out of an old FDD ribbon cable) from P1. So yeah, hacks on hacks, but the solution is very neat and works real well.

[tufty]

My beaglebone has a usb serial port which makes getting started pretty easy. The serial port looks like a serial port from the ARM side, but it connected over USB and appears on my desktop as serial port in /dev. Are you all doing something similar for your kernels on the pi?

Can't vouch for the others, but I'm using a 3v3 USB/serial adaptor in exactly that manner.

Simon

[gnif]

Further research shows that OpenGL is just a library that is calling the lower levels to perform the accelerated functions, in this case, the VideoCore closed binaries. So until someone figures out how to do some 2d accelerated operations without the closed binaries we are stuck with the slow frame buffer.

[DexOS]

My beaglebone has a usb serial port which makes getting started pretty easy. The serial port looks like a serial port from the ARM side, but it connected over USB and appears on my desktop as serial port in /dev. Are you all doing something similar for your kernels on the pi?

Can't vouch for the others, but I'm using a 3v3 USB/serial adaptor in exactly that manner.

Simon

I am also using something similar, for my debugging.

[inder]

@gnif. I'm a total noob and am thinking about using the jtag when my rev.2 board eventually arrives. Shall be grateful if you can post in all the gory detail as to how you created your jtag wiggler cable and other details. Do you hook up the other end to a parallel port on your desktop? Do you use tjtag or any other software? What's the advantage of using jtag versus the usb-serial connection? TIA.

[gnif]

@inder - I will see about posting some pics later, but to answer your other questions

I do not use a wiggler cable anymore, none of my PCs have LPT ports anymore, and also it is quite slow. I spent the $30-$40 for a Olimex ARM-USB-OCD-H which works really nice under Linux and is stacks faster then the wiggler cable.

JTAG allows you to debug the code as if you were working on the local PC with gdb. So you can set breakpoints, inspect variables & register values, step your code, etc. Also you can load the compiled image into the devices ram without having to write to the SD-card and reboot, so you don't even have to touch the RPi to test new code.

The only downside to JTAG on the RPi is that the bootloader does not configure the GPIO pins alternative mode for JTAG, so you have to boot a small kernel to configure the GPIO before JTAG will work, for this I used https://github.com/dwelch67/raspberrypi ... er/armjtag

I have done development on ARM via serial before, and I will NEVER do it again after moving to JTAG, those that are still using serial do not know what they are missing out on.

[richcole]

I ordered one of these:

http://www.amazon.com/gp/product/B006JKNWLE/

My hope is that it will allow me to attach to the serial port. GND1 - GND2, RX1 - TX2, TX1 - RX2 I presume.

If you could post instructions for how you got your jtag development environment up and running that would be a great next step.

[tufty]

My hope is that it will allow me to attach to the serial port. GND1 - GND2, RX1 - TX2, TX1 - RX2 I presume.

That looks a lot like mine. Yep, cross over the txd/rxd connections, and you should be good to go. You might want to connect 3v3 as well as ground (you'll power the cp102 from the Pi's GPIO rather than the serial adaptor's USB that way) which *explicitly* signals to the device that you want 3v3 signalling. It should be smart enough to work this out for itself, but it doesn't hurt to be sure...

[gnif]

@richcole - I have the EXACT same device here, works well except for one flaw... the CTS and RTS signals are not connected... It would receive data, but refused to send. I had to bridge those tiny little pins on the chip (5 & 6 and 8 & 9) before I could use it to communicate with a router.

Edit: Sorry, on a second look, it is a very very similar device, so ignore what I said

[dwelch67]

depending on what software you are using you could tell it there is no hardware flow control (using minicom you have to save the settings and exit minicom then enter minicom again with that saved config for hardware flow control to actually turn off, dont know why). Windows, hyperterm, etc, just select no flow control, dont have to exit...

[dwelch67]

As pointed out see my raspberrypi/armjtag directory at github I have a bootloader (rename the .bin file to kernel.img and put on your sd card, if the led blinks then the bootloader started) that is required to change the gpio pins to the correct alternate function settings to allow the jtag through to the arm core. From there you have to have the jtag wired up right, including for the time being a signal that is not on the P1 connector so solder a wire onto the board or hack up a cable to get at a wire with that signal.

I have a number of the sub $100 jtag devices, and other solutions that are slow for under $20. I have a $28 board on its way that is supposedly supported out of the box with openocd, will see how that goes and if it works I will post the results.

As to HOW I got all of that working is in part prior experience with jtag itself and later openocd on arm devices. Then reading the bcm manual, specifically gpio and finding a set of gpio pins to get all the signals out to connectors and then a minimal bootloader to select the alternate function and turn off the pull up or pull down. I use jtag on a daily basis with my day job with arm devices. Although I have access to and could use the $3000 jtag units I prefer the ft2232 (inexpensive) ones supported by openocd (amontec jtag tiny in particular but the shipping to the usa is prohibitive). More than fast enough for my day to day needs. Depending on your target you may have I/O speed issues anyway so the expensive ones may not buy you much, also depending on your target you might use say a sealevel high speed serial port and make a serial bootloader instead of jtag and its overhead (run your serial port at 1.5mbps or something like that if your uart and I/O can handle it). To get your feet wet with openocd jtag based debugging and arm I recommend the stm32f0 discovery board from st about $10 plus shipping, flash is not yet supported by openocd, but that is not needed (esp for parallel experience with the raspberry pi), you can do ram based development and that stlink interface is supported by openocd. (I may have a flash solution before long, I did with the stmvl discovery board, internals are about the same).

Another experiment I hope to do some day is I have already shown how to use one raspberry pi as a bare metal development environment since the native compiler is for arm. And then use that host raspberry pi serial port (sorry, uart) to connect to a second bare metal raspberry pi. I want to try taking more gpio lines on the host raspi and using those to bit bang jtag to the bare metal raspi and see how fast it is since it is not going through usb like an ft232rl solution). In part I am waiting for the rev2 boards to hit the streets so that the requirement to solder or hack a cable to get at jtag goes away. When that happens maybe we petition the tincantools folks (or raspberry pi foundation, sparkfun, etc) to make a board that plugs right on to the p1 connector and gives us ft2232 based uart and jtag access to the raspberry pi (for under $50).

David

[gnif]

@dwelch67 - The stm32f103 is supported for openocd flash, I also develop on this board, and the Olimex ARM-USB-OCD-H can be had for < $40 from ebay, and works with openocd out of the box also, it is USB and as such has no serial port speed issues.

[dwelch67]

Here is what I was talking about:

All I/O pads on parts have some speed limits including the jtag I/O pads. the difference between the sub $50 FT2232 and MPSSE supported parts and the $1000 on up jtag debuggers is in part that the higher end can transfer much higher rates than the FT2232 and other even slower bit banged wigglers (like the old parallel port ones). So, if your FT2232 or other FTDI mpsse based jtag debugger is not fast enough for you, instead of a few hundred for a jlink or going well above that into the other options, for $80 or so you can get a usb to I think 1.5mbps serial port from sealink, at least that is what mine cost (if I remember right). If your uart can support higher rates and your I/O pads for the uart are capable of it, you can try a serial bootloader (something you write yourself for example, load the small bootloader using jtag then your real program using serial) at that rate and 80% of the data (10 bit cells per byte with 8N1 at speed) can be loaded right into memory so you can run your program (if the size of the program is the reason you want a faster debugger). (the 80% at 1.5mbps would be compared to whatever jtag overhead at the jtag clock rate).

(the olimex usb based ones are in this ftdi ft2232 category I am talking about)

For personal use jlink has an educational version for $60 which is quite a bit faster than the amontek, olimex, flyswatter, etc (ftdi MPSSE based), commercial versions of the same are roughly in the $200 and up range. The BDI3000 and others are in the few thousand range.

the olimex solution is widely available and works just fine, if you were for example starting to get into loading a whole linux kernel and root file system, that kind of thing is where you would quickly find these usb ftdi based jtag debuggers become painful. Was just trying to point out limitations once you move over into that world. If you are using the jtag to debug, stop, single step, etc instead of loading programs, the ftdi based solutions are more than adequate...

David

[richcole]

Thanks for the help. I got going with the USB uart (which finally arrived)

https://github.com/richcole/RaspberryPi/

Small steps I know, but very exiting for me For now I have a power switch between the power supply and the wall socket that I toggle to reboot the pi. Primitive, yes, but it saves the poor power supply connector on the pi board that I'm sure would wear out otherwise.

Since my programs sit in little loops poking memory my hope is that the on-off won't impact the SD card. It will be years before I'm sophisticated enough to be able to write a driver for that.

I think I'll buy a jtag and try follow some of the instructions posted. I'm pretty nervous about anything that involves making a mod to the board because unlike in a text editor, there's no undo.

regards,

Richard.

[DexOS]

Thanks for the help. I got going with the USB uart (which finally arrived)

https://github.com/richcole/RaspberryPi/

Small steps I know, but very exiting for me For now I have a power switch between the power supply and the wall socket that I toggle to reboot the pi. Primitive, yes, but it saves the poor power supply connector on the pi board that I'm sure would wear out otherwise.

Since my programs sit in little loops poking memory my hope is that the on-off won't impact the SD card. It will be years before I'm sophisticated enough to be able to write a driver for that.

I think I'll buy a jtag and try follow some of the instructions posted. I'm pretty nervous about anything that involves making a mod to the board because unlike in a text editor, there's no undo.

regards,

Richard.

This may help you set it up: http://www.dex-os.com/DexBasic/Lesson2.htm

[dwelch67]

Understand that venturing into bare metal, you can do non-recoverable damage with that text editor. Even in other programming spaces but the closer you get to the hardware, the closer you get to mistakes that can do damage. check and double check your work. Perhaps break the problem into steps test each step if possible, etc...

David

[richcole]

Do you guys have any links on how to setup the interrupt vector table? I started getting lost trying to find out where they are:

http://infocenter.arm.com/help/index.js ... baedb.html

It seems they can be mapped in different places. I guess I'm looking for something simple that will jump to a c function.

[richcole]

I found https://github.com/dwelch67/raspberrypi ... /blinker05 which is great resource for getting to understand interrupts.

I couldn't get it to work with the mini uart yet. Is the UART data ready interrupt going to come through as a IRQ or and FIRQ?

regards,

Richard.