Search results

According to EvilDragon, it is possible to set up the pin mux so JTAG is present on the left SD slot, and an adaptor has been made that breaks that out. I don't have this adaptor yet though. I am using an XDS100v2 clone with the uEVM (around £40) and it seems to work well with CCS.

Annoyingly, think there might actually be two lockup bugs. The first, probably more commonly observed on the Pyra, is probably indeed charge driver related. I did notice a bit of a correlation too early on between lockups and charger events but I'm not 100% sure. There is also the power state...

No, it's very useful to have this stuff beta tested before 100s of people are playing with it! Minicom is probably going to be needed (as the wireless seems to be working, if you know the IP address it should also be possible to ssh into it.) To find out why X11 isn't working, the output of...

Definitely! Thank you very much for reporting and helping to test.

@aTc does the image building side of things, but there is probably no rush in updating things as there are still some outstanding U-boot issues and patches.

It is from the main pyra branch, from just after my USB hub fix was merged.

I just tried that image now. Indeed, the shoulder button does cause dodgy behaviour when using that image as-is. When using my newer build of U-boot, though, it is fine.

I haven't tried that exact image yet - but the biggest difference might be U-boot version and it seems like you tried the exact same build as me that I linked already. Which device are you booting from when you say 'boot SD card'? It is possible something is ropey with booting off the internal...

Does indeed seem a device tree problem (not so much the keypad controller as the eMMC/SD control not being set to SW mode), but a 4.19 dtb will not boot at all with the 5.6 kernel from experience and I don't think there have been any changes within the 5.6 versions.

Do you see anything in dmesg when you press the shoulder button?

The theoretical limit of the OMAP5 is indeed 8GB, and the LC15 board is wired so it should be able to be built as 8GB with the right chips. But I think there may be kernel code that expects DRAM addresses to be 32 bits - and as discussed many programs would only be able to use 3-4GB each on...

If you want to try updating U-Boot, I have attached the version I am currently testing with. 1. Make a backup of any precious data on the SD card due to the risk of accidental corruption 2. Extract the files somewhere 3. Run the following commands to update your boot SD card, replacing <sdcard>...

Tried with an internal uSD too (incidentally is it really hard to open the socket the first time on all units or was mine dodgy?), still not seen any issues pressing L1.

Not seen this behaviour here - although I haven't been using the eMMC or internal SD much; I tested that eMMC access at least was still OK with the button pressed. I think the bootloader was supposed to set this up and the kernel leave it alone. Are you sure it is a kernel change, and not a...

The RPi 4 has more CPU power, and less in the way of thermal constraints. It is also 64-bit, which means that one process could easily access all 8GB if needed, whereas on the 32-bit OMAP5 in general each process is limited to 3GB each.

Not really sure what the point of that would be. I am not sure if anyone has ever successfully used an OMAP5 with 8GB of RAM, and indeed I saw some code in the TILER driver that I know would break going above 4GB RAM. The other question is what use case would actually benefit from this...

The newer display boards use a much faster PWM frequency (8.3kHz). Based on the backlight driver chip (TPS61169DCK) datasheet, there is essentially a low pass filter inside so this gives true-analog backlight control by changing the setpoint current rather than actually turning the LEDs on and off.

Or you could just add mem=2048M to the kernel command line for those units xD

There are plenty of places that dodgy code or functionality could be snuck into the OMAP5 if someone wanted to. Not least the boot ROM and the "secure monitor" that isn't really used in non-secure-boot OMAPs other than for L2 management, but is still something that exists. Of course, the Linux...

The Pyra should have that, working in the same way as any Linux laptop, there are two problems. This is more than just freezing processes as it also puts devices into low power mode (eg turning off the screen). I am not sure how easy it is to make some stuff still run in the background like a...