There's definitely some sort of hangups happening in there. I think due to the way the mutex is handled in the usb_detect function (called when IRQ or polling event occurs). The mutex wraps a large amount of logic and I2C transactions and there's a lot of action on the bus IIRC. It could be...
There is a known bug which causes freezes. I’ve encountered it a couple times, it happens randomly and semi-frequently (maybe once every day or 2). daveshah has found it to be related to the power state code. This could be what you’re experiencing, though I’m not sure. I’m pretty sure a symptom...
The OMAP5 is actually running LPAE which is an emulated 64bit mode. It provides extended address space for the extra RAM. This is what allows us to use 4GB. I don’t know if it can support up to 8GB though I haven’t looked into that.
https://elinux.org/images/6/6a/Elce11_marinas.pdf
I mean that’s what it does now so it’s pretty easy :) I haven’t really started to look into the splash screen on the bootloader yet. I think ED said there’s no display driver in uboot for the omap5 so that’s definitely a waste of effort at this point. Kernel should be doable but there’s a number...
whoopsies I’ll keep an eye on that in the future. Thanks for the ffmpeg tip forgot about that tool. I’ll probably need to use it when I get around to working on splash screen.
Sound does work mostly in some builds. It doesn't work on mine for some reason, but I haven't looked into it because my focus at the moment is lower level, power and battery management in the bootloader and kernel. Bluetooth audio does work, I had some fun playing GBA with bluetooth headphones...
I know its GBA and so isn't much but I know how much you guys like candy :). I got @daveshah's OpenGL fixes up and running on my Pyra as well as his retroarch port. I don't have sound (looks like my codec isn't properly configured yet) but its pretty neat to see some actual gameplay on this...
im back in the game and working to get my battery fixes into the current kernel. Sent you a PM so we can hopefully work together and I get on your page with the kernel work/tree. Going to be updating my build system to use the Letux kernel (finally) and hopefully start moving on to some of the...
That explains it :). I just kind of blindly copied this functionality from the old UBoot with only mild testing. I’ll have to do some more testing and repairs here. Good to have some units out in the wild to help us find these issues :)
The reason for sync is because Linux caches bits of the filesystem in RAM temporarily to speed things up. When performing writes on unmounted devices, sync makes sense because that is not a common thing to do and anyone doing it should be aware of the behavior and risk of doing so. When...
So it looks like the kernel is booting just fine. I think there’s something wrong with the first boot wizard service that’s kicking off. Is this booting from the SD card and then the service is trying to flash the eMMC? This is some new software I haven’t used, mine doesn’t do this. What it...
Oof, it’s having a rough time. This is booting from the eMMC? Looks like either a corrupt filesystem or potentially an issue with the eMMC. Have you tried booting this image on the SD card with success?
Is this the special kernel I created for EDs testing? If so, just a quick note about this kernel, clock speed is limited to 1.25GHz on this version. It is a quick fix to help ED test new units faster.
There’s also a WIP software guide that outlines how the Pyra boots, how to build the kernel and bootloader, and how to flash the Pyra.
https://dev.pyra-handheld.com/imagebuild/pyra-docker/wikis/Pyra-Software-User-Guide
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.