Preparing for a Prototype


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?
 
/usr/share/pyra/bin/pyra_test_inputs

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

They're all based on the same rootfs.
 
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.
 
Sure. It's a Debian after all
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.
 
  • Like
Reactions: rSl
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 :)
 
  • Like
Reactions: rSl
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:

grench@Marble:~/Desktop$ sudo su
[sudo] password for grench:
root@Marble:/home/grench/Desktop# fdisk -l
Disk /dev/ram0: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 16 MiB, 16777216 bytes, 32768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


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#
 
Last edited:
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.

We'll see if this idea works.
Post automatically merged:

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?

Yeah, I'm already off road a bit.
Post automatically merged:

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?
 
Last edited:
I mounted on an SD card in the left slot then did the dd if=/dev/zero of=/dev/mmcblk0. It completed after about 15 minutes.

I then mounted off of the OS to eMMC installer and let it install the OS to the eMMC. At the end it prompts to hit any key to power off. I did so, it powered down. For about the next two hours I could not get the unit to respond. After pulling the battery and letting it sit for about 20 mins, then reassembling, connecting it to power for 30 minutes, removing the battery, putting it back - now it came back on. For a bit there I was in fear that I had bricked it.

Booting off of the eMMC.
First bit of the first time welcome program ran - got name, password and name of the device. Then it went into a long series of input/output errors.
Failed to write entry
Failed to rotate
Repeating in a long long loop.
Tried again after removing the battery for a minute.
This is the first time that answering 'yes' to calibrate touch screen actually took me to the screen calibration tool.
After asking me for my user name, this time it just froze at the dp logo. During name input, the shift shoulder button wasn't working again. I can move the mouse x around the screen, but it's otherwise frozen.
It is doing the whole 'won't respond' thing again now.
But, from the above experiences, it is my judgement that the eMMC isn't retaining or returning the information that it would need to for ongoing operations. I will be looking to ED or aTc or other on the project team to give me some instructions on how to test the eMMC further.

My next step is to switch over to booting from my modified microSDXC card for both partitions to be ext4 with it mounted in the left SDXC slot via an adapter. This is an experiment of mine to see if it really I can get it up and running on an SDXC card with both partitions in my preferred ext4 format instead of ext4 / f2fs. But - now I'm stuck in the 'won't respond' thing again after the eMMC experiments. I'm wondering if the eMMC sets something/charges a capacitor/holds something that it isn't setting right for the read/write errors and that something has a long 'cool down' before the unit can get past it to boot again. I don't have much else to theorize on this behavior.

To summarize my day of it:
I haven't been able to install and run a stable OS on the eMMC.
I have been able to install and run a stable OS on the left SDXC slot.
I have been able to install and run a stable OS on the internal microSDXC slot.

In the above cases 'stable' is a very low bar. It amounts to booting through the setup wizard, connecting to my wireless network, downloading and installing at least one application through synaptic and being able to connect FireFox to these boards. The original OS that ED shipped on the eMMC -was- working and did these things, but started to flake out about an hour in. Right now I really suspect that I may have either a bad eMMC or a flaky connection or voltage regulation to the eMMC or it got too much heat. Hard to tell. I haven't cracked open the case yet. I was rather in hopes that I wouldn't have to until a month or so from now when the new display boards come in. The display flickering is occasionally noticeable, but not so bad as to get in the way of these explorations.

I just tried to get it to power on again. It is late enough to be getting early. I'm going to pull the battery and call it a night.
 
Back
Top