Search results

Yes, it was a long time ago that the hardware video encode/decode was last working. It shouldn't be beyond the realms of possibility to get it working again though.

What's important about the Pyra, imo, is that there is no 'DRM' in the hardware, bootloader or kernel. Even if some userspace program does have some pathetic attempt at DRM, in general there's nothing stopping you from writing a kernel driver that captures and saves the current framebuffer or...

Pretty sure Debian armhf (unlike the older softfloat arch) is already ARMv7. The main improvement for a Pyra-specific build (i.e. ARMv7VE) would be the hardware integer divide. A small - but non-zero - percentage of applications would probably see a noticeable speedup from using that. There are...

Anything that is in the Debian armhf repo and/or provides its own armhf binaries will work. In the latter case, these might be "Raspberry Pi" builds.

The Cortex A15 is actually one of the few ARM32 cores to have hardware virtualisation support. Unfortunately, this was little used and support for it is being removed upstream. Either we will have to maintain it ourselves, or convince the maintainers to reinstate it with a good use case, if we...

Funkeymonkey does run before X11 starts, the problem is that the some of the resulting keycodes it produces are currently only being interpreted correctly by X11; the console keyboard probably needs to be configured correctly to understand these (or funkeymonkey needs to be modified to produce...

I think funkeymonkey should be set up to create a "pyraInput Gamepad" device which maps the game buttons and nubs, including the L2 which is also Fn, like a gamepad; simultaneous to their mappings to keyboard modifiers/keys and mouse movements respectively.

There will almost certainly be some tearing at the left of the screen (the first scanned out lines) due to some Vsync oddities in the X and/or kernel drivers; even if everything else is set up to be supposedly 'tear free'. I plan to investigate this once some more pressing issues like the...

Yes, the SGX544 only supports OpenGLES 2 (with a few extensions). @ptitSeb 's gl4es can be used as a shim to support a large subset of OpenGL 1/2, like on the Pandora. My understanding is that the architecture of mobile GPUs mean not all programs designed for desktop GPUs work well with this though.

While the iMX8M is undoubtedly the SoC of choice if designing something like a Pyra today, I just don't think it is worth upgrading to it today after all the effort that has been put into the OMAP, and the significant costs of fragmenting an already small user base. Hopefully, by the time we...

It is the OMAP5's internal ROM that looks at the left slot - that's not related to fastboot, which is a mechanism for flashing the eMMC over USB that is part of U-boot (in this case)

I would presume so, Toast is working on it so he will know the details.

fastboot is part of U-boot. The OMAP5 has its own internal USB boot with a custom protocol in ROM, but I don't know if anyone has tested it or if the Pyra is wired to use it. The only time fastboot wouldn't be useable would be if U-boot itself got corrupted. In this case, recovery would still...

Yeah, I still need to look at fastboot, it seems like a nice workflow. Usually I rsync/scp stuff across (this is useful for updating modules too) unless it doesn't boot that far.

Tradition PC memory has an EEPROM chip on it (SPD) that contains the size and the timings. That would be overkill for an embedded board like the Pyra. What the Pyra CPU board has is a resistor that can be fitted or not fitted depending on whether the board is 2GB or 4GB. The bootloader should...

Yes, that's just the way it was wired. Note that as the uSD and eMMC are the same boot device from the OMAP5 point of view; at best the alternative would be "uSD over eMMC if uSD inserted" rather than "uSD over eMMC if uSD bootable" But as I said, a suitable U-boot config on the eMMC could...

At a hardware level, fixed in the board wiring and logic, the first-stage boot order is essentially left SD card if available and bootable --> internal uSD if L1 pressed --> eMMC but U-boot on the eMMC can make its own decisions about where to load the kernel and rootfs from. Furthermore the...

I expect that ED is not giving the 2GB people an upgrade out of the sheer kindness of his dragon-heart, more likely a small batch of 2GB boards would be much more expensive than the upgrade cost.

One annoyance at the moment is that to boot from the internal SD card, you need to remember to hold down a button when turning on or restarting. The solution is to have an option where U-boot on eMMC load the kernel from and point the rootfs to the internal microSD card by default unless some...

It's also worth noting that we haven't yet updated the default config yet; so even if we built a new image today it still wouldn't have the new X11/DRI3 packages or configuration by default.