Download Pyra Debian OS (WIP)


you may want to get all of your conniptions ready for a fit. Just voice of experience with dealing with Ti things.

Edit: Ah didn't read the "not" in your sentence on the first read through.
 
you may want to get all of your conniptions ready for a fit. Just voice of experience with dealing with Ti things.

Edit: Ah didn't read the "not" in your sentence on the first read through.
That's alright. Although if it's all open, I'm not sure why it wouldn't work.
 
As far as I can see the code for everything is available under a custom (but quite open) license. It looks like they are using the M4s to manage IVA-HD, which of course requires some firmware (both available as source code and binaries)

Ah interesting, I hadn't realized that part was open. The big problem however is the HDVICP2 (synonym for IVA-HD) binary codecs package, which is a dependency and every link to it seems dead. See also this thread, and this. Maybe this firmware blob is what we need, but I don't have the energy right now to try to plow through this maze to see if all the necessary ingredients are there and the whole thing can be made to work.
[doublepost=1468613292,1468613037][/doublepost]
That's alright. Although if it's all open, I'm not sure why it wouldn't work.
It is not, and never has been, "all open". The actual codecs are binary, only the loader/management code on the M3/M4 subsystem is available, although the package with binary blobs necessary to compile it has apparently been unavailable since 2012 or so. It may be possible to extract them from the firmware image though, especially since the one I linked to above helpfully includes a linker map.
 
I just browsed https://git.ti.com/ivimm/ipumm and it looks like the codec blobs are actually present in that git repo, the extrel folder contains several .lib files related to codecs that are apparently being linked into the M4s' firmware.
Score! :D

I wonder if anyone at TI even knows what is or isn't publicly released, there are soo many different repositories all over the place. How'd you stumble across this one?
 
I extract etnaviv driver from kernel source and renamed it to viv_gc320, than changed device tree file "omap5-uevm.dts", add a new simple node

gpu-subsystem-2d {
compatible = "viv-gc320-gpu2d";
};


I know, this is not complete, it is just for testing.

Than i replaced from structure dt_match all identifiers with "{ .compatible = "viv-gc320-gpu2d" },".

After compiling the dts and driver, replacing /usr/lib/linux-image-4.7.0-letux-pyra+/omap5-uevm.dtb with new one, rebooting board, and loading new driver viv_gc320 ....
i got a kernel crash :), but this was expected by me.

The "probe" function for plattform driver, etnaviv_pdev_probe, is now called, this was missing before, but calling component_master_add_with_match() at end of this function crashes with invalid pointer.

We need a better device tree node, but at moment, i have no idea what for GC320 is needed.

Thomas
 
Last edited:
Good. I was afraid.

Looking a little arround found this.It speaks of OMAP4 but in other places it says OMAP4+ and I tentatively assume it's the same block in OMAP4 and OMAP 5.
Looks like mixers, filters, resampling and sDMA controllers for audio from diverse sources (like the modem sending audio from a call or a FM tuner).
A little over my head. And not too much time right now
 
Last edited:
Image aTc:

I tried to connect a bluetooth keyboard but this always fails, first with bluetoothctl, then with graphical manager on desktop. The device was visible, trusted, pair code was requested, and in bluetoothctl accepted, connected, but device couldn't added. I used two different bluetooth sticks and two different keyboards, changed my active usb hub, but nothing helps.

I'm trying this Pyra image for the Pandora because I was hoping Bluetooth would be in usable shape (it's a major failing of Pandian).
How did you enable the BT device in the first place?

Thanks... Andy
 
The firefox-esr message following that one seems more serious to me.
 
Man, I would really like to figure out how someone could make a QEMU/VM setup and configuration for testing this rootfs.

Last I checked, someone even made an extremely bare-bones XBOX emulator with QEMU, and there's also one for the Ben NanoNote.

Is anyone using an ARM 32-bit (armhf) dev-board to test out this rootfs? Maybe we could use one based very closely off of the Pyra's hardware.
 
Back
Top