Kernel Interface

[notaz]

I've started documenting kernel interface:
http://pandorawiki.org/Kernel_interface

Questions and suggestions are welcome. Flaming and off-topic are not (mods, delete if you see any, thanks).

 

[mindlord]

Thanks, Notaz for taking the time to post up his extremely valuable information. Bookmarked for future reference.

 

[Pickle]

Good idea, examples keep them coming. Your input section is good, maybe more info you can bring to the main page the better. For example what are the actual key codes you get when you read the input file?

 

[javaJake]

Wow, this is looking great.

Any news on controlling the battery LED through /proc? I'd like to be able to heavily customize that thing.

 

[Squidge]

There will be a standard library for all this stuff (plus examples of course), so you should end up with almost the exact same code base for PC builds and Pandora builds, just a different library.

 

[cosam]

Nice work. My only comment would be that some of the device names (e.g. "ADS784x Touchscreen") are very specific. If one of the aims is to keep things working after future hardware changes, wouldn't it be more useful to have more generic device names? Or is that abstraction meant for another layer?

 

[notaz]

For example what are the actual key codes you get when you read the input file?

Added.

Any news on controlling the battery LED through /proc? I'd like to be able to heavily customize that thing.

There are already LED drivers, but I haven't hooked them yet, they should have some userspace interface, will check.

There will be a standard library for all this stuff

This stuff is for library writers (and for people doing things like Fenix runtime, etc).

Nice work. My only comment would be that some of the device names (e.g. "ADS784x Touchscreen") are very specific. If one of the aims is to keep things working after future hardware changes, wouldn't it be more useful to have more generic device names? Or is that abstraction meant for another layer?

Hm, this string is what the driver returns. Will think about that.

 

[skeezix]

Lib writers can abstract it out, but thats a very good point.

Could have a config file (/etc/iotemplate.rc or something) to map human readable names to current device names, or use symlinks (/pandora/input/keyboard symlink to /dev/input/eventX or whatever), or have a little kernel module we hack up which does the mapping inside itself, or.. infite options, hmm

jeff

 

[jdh2550]

Many thanks Notaz - this will be a great starting place - much Kudos for doing this.

I hope to do some I2C stuff with the UART on the external connector - I think this will fit in well with this page. Once I get the pandora and a break out cable I can start tinkering and figuring out what's what and I'll be sure to add it to this page.

Unless of course someone beats me to it.

Great job!

EDIT: One question - where is this stuff linked too on the wiki? I tried to navigate to it from the main page and couldn't find it... (I mean I can get there from your direct link above - but where is it "filed" on the wiki?)

 

[Squidge]

Nice work. My only comment would be that some of the device names (e.g. "ADS784x Touchscreen") are very specific. If one of the aims is to keep things working after future hardware changes, wouldn't it be more useful to have more generic device names? Or is that abstraction meant for another layer?

I'd say thats for another layer. The device driver returns the exact identifier (eg. "ADS784x Touchscreen") and the library then knows what that particular touchscreen supports and how to use it. There could be multiple drivers in the library for various touchscreen controllers. The application then uses the more generic library calls, not caring about exactly which touchscreen is installed.

 

[Yamara]

EDIT: One question - where is this stuff linked too on the wiki? I tried to navigate to it from the main page and couldn't find it... (I mean I can get there from your direct link above - but where is it "filed" on the wiki?)

I have linked the Kernel Interface page to the Development Tools page, as an aside for the default libraries. I didn't see anywhere more appropriate to link, and other dev pages seemed to link to the Tools page.

 

[wesbrown18]

Awesome! I honestly hope that most developers will use the SDL libraries rather than tap directly into the Pandora's kernel interfaces like this.

This would make it easier to just plug in a USB gamepad, or just port and develop on other Cortex-A8 based platforms like the Beagle Board.

 

[Squidge]

wesbrown18: Using a library which internally uses the kernel interface isn't going to be much difference (hardly any?) to using SDL from a users point of view (but obviously very different for a developer).

You will still be able to just plug in a USB gamepad, as thats mostly in the kernel, which will of course still be running.

Developing on other Cortex systems and porting will also be possible, as the library could be ported and the Pandora specific routines doing very little or nothing (or just compile the PC version). However, if you did develop and port then you would lose a lot of functionality like the analog nubs, game buttons, key pad and touch screen. I hope developers don't stay away from or minimally use these useful features just to keep there software multi-platform.

 

[wesbrown18]

Developing on other Cortex systems and porting will also be possible, as the library could be ported and the Pandora specific routines doing very little or nothing (or just compile the PC version). However, if you did develop and port then you would lose a lot of functionality like the analog nubs, game buttons, key pad and touch screen. I hope developers don't stay away from or minimally use these useful features just to keep there software multi-platform.

I agree about hoping that developers don't avoid the unique Pandora features. It's my perspective that for the most part, Pandora functionality can be duplicated using a USB joypad, such as the analog nubs. I had envisioned using my Beagle Board as a development and test platform for things such as emulators, because it's well, at my desk, and has DVI out which means it can hook up to my monitor.

But the touch screen functionality will indeed be hard to duplicate, especially if we use the 16 levels of capacitance. I certainly hope that we see unique and interesting games that use the combination of input methods that the Pandora offers.

 

[Squidge]

I had envisioned using my Beagle Board as a development and test platform for things such as emulators, because it's well, at my desk, and has DVI out which means it can hook up to my monitor.
Thats a good idea, but will of course come with some restrictions. For example, the current version of beagle has half the ram of the Pandora, and the fact that it has DVI output can mean creating something that is completely unplayable or unusable on the Pandora due to display sizes. Plus of course the OTG port can only do one side at a time, so it can either be a usb host to your joystick, or be a usb device to your PC. If it's the former, it restricts how you get files over to it, as you don't have Wifi or ethernet, so you'll need another USB dongle to do Wifi/BT/ethernet and a USB hub (along with a USB OTG -> USB Host converter cable).

Since the Pandora is a clam shell, it may be easier to just sit that next to your PC instead with the lid open, dc jack in, and your current development directory nfs mounted across Wifi/USB to avoid the need of having to copy files across. You can then test your apps using the same controls as most people will be using.

 

[javaJake]

The gentoo-arm-pandora project has reached a point where we'll be building drivers and whatnot necessary for the Pandora, and so we have a couple questions:

• Is ACPI supported, or is that an x86-specific "feature"?
• evdev is used for all inputs, but there's also a driver called evtouch. Are the Pandora developers aware of and/or using this driver?

Edit:

Any news on controlling the battery LED through /proc? I'd like to be able to heavily customize that thing.

There are already LED drivers, but I haven't hooked them yet, they should have some userspace interface, will check.

By the way, have you had a chance to look into the LED driver yet?

 

[notaz]

Is ACPI supported, or is that an x86-specific "feature"?

Looks like PC/x86 specific feature to me.

evdev is used for all inputs, but there's also a driver called evtouch. Are the Pandora developers aware of and/or using this driver?

evtouch? Can't find such thing in kernel. Google shows a driver for X, but it's not kernel related. Maybe you meant tsdev? This one is deprecated and removed from current kernels.

By the way, have you had a chance to look into the LED driver yet?

Yep, they are using LED class, see kernel Documentation/leds-class.txt.
[root@pandora leds]# pwd
/sys/class/leds
[root@pandora leds]# ls
pandora::bluetooth pandora::lcd_bl pandora::sd2
pandora::charger pandora:ower pandora::wifi
pandora::keypad_bl pandora::sd1

Note that pandora::lcd_bl is expected to move to /sys/class/backlight/

 

[javaJake]

OK, thanks notaz for your answers! I see now that evtouch is a driver that interprets touchscreen input on /dev/input/ devices. Whether or not that will work, or even will be necessary, remains to be seen.


Edit:

Yep, they are using LED class, see kernel Documentation/leds-class.txt.
[root@pandora leds]# pwd
/sys/class/leds
[root@pandora leds]# ls
pandora::bluetooth pandora::lcd_bl pandora::sd2
pandora::charger pandora:ower pandora::wifi
pandora::keypad_bl pandora::sd1

Note that pandora::lcd_bl is expected to move to /sys/class/backlight/
Beauty! Thanks again!

Another Edit: Added to wiki.

 

[MilanC]

/proc/pandora/cpu_mhz_max

What about some control through standard cpufreq interface?
/sys/devices/system/cpu/cpu0/cpufreq/

 

[notaz]

/proc/pandora/cpu_mhz_max

What about some control through standard cpufreq interface?
/sys/devices/system/cpu/cpu0/cpufreq/

Yeah we might eventually use that. cpufreq was not working when /proc/pandora stuff was written.