I guess that's a side effect of the -nobat kernel. If there were no battery inserted, it would make sense to power on as soon as it's put on power.
I suppose it could be made to actually check if there is a battery inserted and not boot up if there is a battery in there in actuality, or it could be changed to require a press of the power button even if you haven't got a battery in there. But for now the default is basically the same as the old Pandora.
Hm, you're ecountering some weird issues there, no idea what's happening.
One thing to note: make sure the battery is not too empty. The system doesn't check that yet and this can lead to weird crashes - and especially sudden freezes.
About the auto-restart:
Either U-Boot or the kernel configures the Palmas chip. Per default, it is set to autostart whenever power is connected.
It can be that the new kernel you installed doesn't change that.
Quick tip about the webbrowser:
Download Vivaldi. It's a lot faster than FireFox
It typing loads of "+" in the username prompt for the first-run-wizard seems to happen sometimes, I haven't found out where that comes from yet, it never does it when you're probing the input devices to see which one causes it .
You can just backspace/delete them and everything works fine after that.
The first run wizard is a bit crap (by design, so someone would write a proper one), so it doesn't clean up after itself when things go wrong.
And anything related to charging/battery/power still needs a bit of work, obviously.
I am going to reflash to the non-nob at version ED notated above and see what changes/fixes.
I wonder... the shoulder button and brightness were working for me before I reflashed. @EvilDragon, can I have a copy of the image used to flash this? I want to see if those work again if I revert.
Is there a buttons diagnostics program like we had for the Pandora yet?
but it's not really meant to run with Xorg and the pyra input daemon active.
You can also run it by selecting a kernel with the (hwtest) option in the boot menu.
That script stil needs a lot of work, so a lot of tests fail, or take a really long time.
The image ED used is the one from https://packages.pyra-handheld.com/images/buster/ , and that's the only one available.
install-nobat.img.zip is the one that creates an sd card that writes everything to emmc
pyra-debian-buster-mate.img.xz is an sd card image that will just boot into pyraos
You can also try to run evtest in normal X console to see which inputs work.
The mapping for the shoulderbuttons and brightness buttons are both software mapped - maybe a too low battery during first boot setup caused that issue?
Maybe reinstalling the corresponding packages with a config file reset will work as well.
It was compiled for the Raspberry Pi, though, so it might be missing things like NEON optimizations - the first RPi had an ARMv6 CPU while Debian armhf already targets ARMv7. It's closed source after all.
They don't seem to provide any kind of minimum requirements, literally the only official information I could find was "it runs on the Raspberry Pi!"
I reflashed again from the image to eMMC. This time I did it entirely plugged into a 2A source - there should have been plenty of juice.
I'm getting even weirder things now. Shutdown selection menu is nothing but symbols for the text and filling the three selection rectangles instead of text. Shutting down I get more 'failure to rotate errors'. I'm starting to think that there might be something sideways with the eMMC. I'm in the process now of creating what I hope will be a bootable SD card image.
Well, this is promising. I have it booted using the SD card image, made it through the setup, opened up LibreOffice Writer and - now my shoulder button works, the brightness button works, etc. So, what this tells me is that the rest of the hardware I have seems to be working fine, but the eMMC or maybe the flashing process is somewhat in question.
To create the bootable SD card I used an old 32GB full sized SD card and:
/Desktop/Pyra/PyraOS/SD_Card_image# dd if=./pyra-debian-buster-mate.img of=/dev/sdj bs=1M; sync
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 516.853 s, 16.6 MB/s
I notice that this creates two partitions. The first is a 256MB 'boot' partition. The second is a rootfs partition consuming the rest of the card.
What is the functionality status of the internal microSDXC slot? If I make one of these on a 64GB EVO microSDXC card, boot the first time off of it using an adapter in the left SD slot to prepare it - then insert it into the internal microSDXC slot, would that work the way I envision? I seem to recall that the microSDXC card presence might get used to trip the boot to it from the eMMC - I don't remember if that was the way it went or if it was just an interesting idea.
But - I'm up and mostly running now that I'm going around the eMMC. Is there a utility that I can fire up from the SD booted Pyra to test/check the eMMC functionality?
But - I'm up and mostly running now that I'm going around the eMMC. Is there a utility that I can fire up from the SD booted Pyra to test/check the eMMC functionality?
e2fsck -c /dev/*emmcdevicename*
Tests for bad blocks, assuming it's ext formatted and not currently in use.
Might be good to have checksums for the images to verify download as well.
Nice investigation/debugging @Grench ! I had some nasty storage media bugs on one of my recent x86 installs and identifying the file system as the problem took a good while. Too bad that you might need to avoid using the eMMC for now, but maybe it is good that it is encouraging you to attempt booting from microSD, as I’m sure a bunch of us will be wanting to do that.
Well, this is promising. I have it booted using the SD card image, made it through the setup, opened up LibreOffice Writer and - now my shoulder button works, the brightness button works, etc. So, what this tells me is that the rest of the hardware I have seems to be working fine, but the eMMC or maybe the flashing process is somewhat in question.
To create the bootable SD card I used an old 32GB full sized SD card and:
/Desktop/Pyra/PyraOS/SD_Card_image# dd if=./pyra-debian-buster-mate.img of=/dev/sdj bs=1M; sync
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 516.853 s, 16.6 MB/s
I notice that this creates two partitions. The first is a 256MB 'boot' partition. The second is a rootfs partition consuming the rest of the card.
What is the functionality status of the internal microSDXC slot? If I make one of these on a 64GB EVO microSDXC card, boot the first time off of it using an adapter in the left SD slot to prepare it - then insert it into the internal microSDXC slot, would that work the way I envision? I seem to recall that the microSDXC card presence might get used to trip the boot to it from the eMMC - I don't remember if that was the way it went or if it was just an interesting idea.
But - I'm up and mostly running now that I'm going around the eMMC. Is there a utility that I can fire up from the SD booted Pyra to test/check the eMMC functionality?
Good to see you are making progress Grench
I am debating whether to take the Pyra with me abroad for work on Monday
Had similar issues with firefox and the battery meter registering 2 batterys .
Tomorrow i will finally have some time to properly experiment....Spent time with family today
Just thinking about the flashing process , could it be the speed of the sd card when writing to the eMMC ? Could that make a difference ?
Wish i had the brains of some of the other members on the board here to help ya
Any other Prototype Chaps out there received there bundle of Joy
Booting from the SD card image I'm now only seeing the one battery - and plugged in via the wide microUSB 3.0 port it shows a single line of -charging- 2 hours to full.
I'm fiddling around with a 64GB EVO microSDXC card. I have it booting from it now and am going to try it in the internal slot soon.
It was compiled for the Raspberry Pi, though, so it might be missing things like NEON optimizations - the first RPi had an ARMv6 CPU while Debian armhf already targets ARMv7. It's closed source after all.
They don't seem to provide any kind of minimum requirements, literally the only official information I could find was "it runs on the Raspberry Pi!"
When you try to download the deb ARM build, you'll see it says "armhf" in the filename. Probably doesn't run on the first Pi, but iunno.
It does run nicely, though. Used it on Askarus' Pyra at Gamescom before.
Alright - I'm running on the interior microSDXC card.
First time reboot after placing it in the holder, it booted to the corrupted eMMC image.
This time I booted it up while holding all four shoulder buttons - likely only one of them matters for it, but by holding all four it booted from the microSDXC. I will need to figure out which one made the difference so I don't have to do the full Vulcan death grip on it when booting.
It seems to be running okay this way, but I'm getting the most bizare fdisk-l results I have ever seen. I'll try to post up from the Pyra so I can cut and paste it in.
Post automatically merged:
Connecting up and logging in went smooth. This post is on my Pyra.
here is that funky fdisk -l report while booted from an inside mounted microSDXC card:
Disk /dev/mmcblk0: 59.6 GiB, 64021856256 bytes, 125042688 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf23ef208
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 526335 524288 256M 83 Linux
/dev/mmcblk0p2 526336 16777215 16250880 7.8G 83 Linux
root@Marble:/home/grench/Desktop#
Well, mmcblk0 is the eMMC, so you could check it there.
I don't think that the eMMC has issues though - but I'm not sure how the flasher exactly works.
The eMMC is 32GB and the flasher file is only 1.2GB... maybe some old stuff remains on the eMMC when you reflash.
You could dd the mmcblk0 with zeros when you've booted from SD card and the reflash, maybe that fixes things.
I have gone down a bit of a rabbit hole. My microSDXC card clearly has two partitions on it. Pulling it up in Gparted on my main workstation, there is a boot ext4 partition and a rootfs f2fs partition. I don't have the patience or tools to deal with f2fs and I cannot seem to resize it. So - I'm going offroad a bit.
By my logic, the boot ext4 partition is going to be the picky one so I'm leaving that one untouched. I am, however, copying the contents out of the f2fs partition. My plan is to create a new ext4 partition for 'the rest of the card' and copy those files back into it and see if I can then see/use the entirety of the card within the OS.
I don't know what the deal is with it creating the pile of ramdisks, but first things first, I want some space so I can install stuff on this, and if I'm going to be diving into partitions, they may as well be ext4.
Well, mmcblk0 is the eMMC, so you could check it there.
I don't think that the eMMC has issues though - but I'm not sure how the flasher exactly works.
The eMMC is 32GB and the flasher file is only 1.2GB... maybe some old stuff remains on the eMMC when you reflash.
You could dd the mmcblk0 with zeros when you've booted from SD card and the reflash, maybe that fixes things.
In the above report mmcblk0 is the 64GB microSDXC card that I have mounted internally and booted from. Note that it is showing the device as 59.6GB. Doing this hijacks the name and lines off of the eMMC, right?
Well, mmcblk0 is the eMMC, so you could check it there.
I don't think that the eMMC has issues though - but I'm not sure how the flasher exactly works.
The eMMC is 32GB and the flasher file is only 1.2GB... maybe some old stuff remains on the eMMC when you reflash.
You could dd the mmcblk0 with zeros when you've booted from SD card and the reflash, maybe that fixes things.
Something I might try - if I get an SDXC card to 'just how I want it', boot from a -different- SDXC card, mount the 'source OS' card in the right SD slot, boot from the left SDXC slot, then I should be able to dd from the 'source OS' card into the eMMC as neither would be mounted. I'll have to give that a shot.
What command would you suggest for the dd to mmcblk0 for zeros? I have used dd before, but for that I'm normally writing a partition/structure to a target not trying to wipe it. Anyone got that syntax handy?
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.
symbols for the text and filling the three selection rectangles instead of text. Shutting down I get more 'failure to rotate errors'. I'm starting to think that there might be something sideways with the eMMC. I'm in the process now of creating what I hope will be a bootable SD card image.
