Preparing for a Prototype

[erico]

@Grench , the vulkan death grip....

 

[Grench]

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.

 

[Djoga'Ro]

@Grench Suppose you've put an sd-card into the internal slot and do the flashing, would then the sd-card get written on instead of the mmc? If so maybe try that? If this gives you the same misbehaviour, it'd be either a faulty flashing routine or whatever emmc and internal sd-slut share hardware-wise could be at fault. But if it works, it would narrow it down to something more emmc-specific?

I haven't cracked open the case yet.

Ypu should rather use a screwdriver.

 

[Grench]

@Grench Suppose you've put an sd-card into the internal slot and do the flashing, would then the sd-card get written on instead of the mmc? If so maybe try that? If this gives you the same misbehaviour, it'd be either a faulty flashing routine or whatever emmc and internal sd-slut share hardware-wise could be at fault. But if it works, it would narrow it down to something more emmc-specific?

I don't know if that is even possible. The flash write program does not give a chance to change the target.

 

[pimaster]

Not exactly. The OMAPs have their own bootloader code (called MLO).
When you start the processor, the OMAP checks all devices in a given order for the MLO signature starting on sector 0 (USB, MMC, etc.) and once it finds it, it loads the next few sectors and runs that code.

The MLO sets up the basic information about the system and the OMAP runs the code.

These days, you often combine the MLO with U-Boot, but basically all the OMAP does is look for the MLO signature and runs that.

It does not know about partitions, etc. You just dd it to the first sectors of the used medium

I only have the OMAP Development Board and not a Pyra but thought I should chime in because after reading the whole TRM, I want to feel useful.

28.3.7.6.4 Read Sector Procedure
The contents of an eMMC or SD card may be formatted as raw binary (referred to as Raw(UDA) or within
a FAT file system. The ROM Code reads out sectors from raw image or the booting file within the file
system and boots from it.
• Raw mode
In Raw(UDA) mode, an image can be at one of the four consecutive locations in the main area: offset
0x0 (0 KiB)/0x20000 (128 KiB)/0x40000 (256 KiB)/0x60000 (384 KiB). For this reason, the size of a
booting image must not exceed 128 KiB. However, a device with an image greater than 128 KiB can
be flash starting at one of the aforementioned locations. Therefore, the ROM code does not check the
image size. The only drawback is that the image crosses the subsequent image boundary. Raw mode
is detected by reading sectors 0, 256, 512, and 768. The content of these sectors is verified for the
presence of a TOC structure. For a GP device, a GP header must be located at the beginning of the
booting image, as described in Section 28.3.8.2, Configuration Header. Image data is read directly
from continuous sectors of a card. If raw mode is not detected, file system mode is assumed.
File system handling
The read sector procedure uses the standard SD/eMMC read data procedure. The sector address is
generated based on the booting memory file map collected during initialization. Thus, the ROM code
can freely address sectors in the booting file space.
28.3.7.6.5 File System Handling
The eMMC / SD cards can hold a file system that the ROM code reads. The image used by the booting
procedure is taken from a booting file named MLO. This file must be in the root directory on an active
primary partition of type FAT12/16 or FAT32.

So yes, a file can be flashed to the start of a disk to get a working boot process. OMAP should be able to read simple FAT partitions as well. I found this method much easier to work on whilst I was trying to get up to speed.
This might help Grench feel less lost with the difference between 1 and 2 partition setups.

 

[Djoga'Ro]

I don't know if that is even possible. The flash write program does not give a chance to change the target.

Isn't it, that one can only use either the emmc or an internal sd-card at any given time and there's only one reference two address them? The question would be then, on which conditions, where, and when the decision is made, which of the two gets made accessible to the system. ?

 

[EvilDragon]

To switch between internal emmc or sdcard, there's a script installed in the OS that can do that.
For booting, holding one of the shoulder buttons while powering on switches to the internal SD Card.
But it could be the kernel switches back to the eMMC - which would be an issue.
The switch has only been tested for functionality, we haven't dived further into it.

@Grench Hmm, it really could be a bad eMMC you have here.
Please use badblocks when booted from the sd card to test the eMMC.

 

[EvilDragon]

Oh, and also try fsck (probably fsck.f2fs in this case) to check the eMMC filesystem.

 

[matzesu]

When I get my Pyra 28, I will probably never touch the OS, only to update..

But on the other side: isn’t fiddle around whit the OS also a part of the Fun??
IA perfect OS would be boring ^^

 

[Letalis Sonus]

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.

armhf refers to an ABI, just because Debian decided to target ARMv7 with this ABI does not imply that it is exclusive to that architecture, the VFPv2 FPU in the RPi 1 is compatible with the hard float ABI and other Debian forks may choose to use it while targeting an older ARM architecture.

They do provide an official install script for other distributions, you are free to install it onto a RPi 1 with a distro that targets only ARMv6 using the hard float ABI, it will only crash when it tries to execute NEON, VFPv3, or ARMv7 specific instructions.

 

[aTc]

To switch between internal emmc or sdcard, there's a script installed in the OS that can do that.
For booting, holding one of the shoulder buttons while powering on switches to the internal SD Card.
But it could be the kernel switches back to the eMMC - which would be an issue.
The switch has only been tested for functionality, we haven't dived further into it.

@Grench Hmm, it really could be a bad eMMC you have here.
Please use badblocks when booted from the sd card to test the eMMC.

The initramfs runs a script at boot that detects if there's a microsd card inserted, and switches to that if one is there.

initramfs/pyra-emmc-switch · master · packages / pyra-config · GitLab

DragonBox Pyra - GIT Repositories

dev.pyra-handheld.com

It will disable the emmc, so the installer sd card probably won't work if there's a microsd card too.

The installer itself is just a simple script that creates the two partitions, dumps uboot in the space before it, and extracts the rootfs.tgz to them.
It's in the pyra-install package, the script itself end up in /usr/share/pyra/scripts/pyra-install.sh , also at https://dev.pyra-handheld.com/atc/pyra-install
I haven't had the time yet to clean up all the stuff and update it, so it has slightly outdated uboot files. (also need to get all the initramfs installer stuff in there too) (and check/fix all the other known problems, we really need more people helping with this)

 

[levi]

If the initramfs runs before the installer sd card, and the microsd appears in the same place in the OS (I think it should, since it's a physical line swap as I understand it) then there's reasonable to fair odds the installer will just write to the microsd card provided it's not to sniffy about the physical size I'd hope.

 

[ToastBucket]

reflashing it won't actually help with the two batteries thing, you need to install the other kernel package that has the battery fixes in it.

apt update
apt install linux-image-4.19.60-letux-lpae-pyra
or
apt install linux-image-4.19.60-letux-lpae-pyra-nobat ( modified kernel that can boot the pyra without a battery inserted (does need the charger connected though ) )

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.

 

[aTc]

yes

 

[Grench]

The initramfs runs a script at boot that detects if there's a microsd card inserted, and switches to that if one is there.

initramfs/pyra-emmc-switch · master · packages / pyra-config · GitLab

DragonBox Pyra - GIT Repositories

dev.pyra-handheld.com

It will disable the emmc, so the installer sd card probably won't work if there's a microsd card too.

The installer itself is just a simple script that creates the two partitions, dumps uboot in the space before it, and extracts the rootfs.tgz to them.
It's in the pyra-install package, the script itself end up in /usr/share/pyra/scripts/pyra-install.sh , also at https://dev.pyra-handheld.com/atc/pyra-install
I haven't had the time yet to clean up all the stuff and update it, so it has slightly outdated uboot files. (also need to get all the initramfs installer stuff in there too) (and check/fix all the other known problems, we really need more people helping with this)

Where does intramfs live? Right now my Pyra isn't booting at all. If intramfs lives on the eMMC and my eMMC is garbled - what then?

Right now I have some very conditional responses from my Pyra. The following test cases were done and recorded in order. It feels like one test type can change what the unit response is to the next test type.

* No cards installed, battery installed, press power button - no response. When last checked battery had 80% charge. Tried with a 2nd battery, same response.

* No card installed, battery removed, connected to power via microUSB 3.0 wide port (power button glows red, unit draws 0.3A), unit attempts to power on (draws 1.8A), a few hundred lines of tiny script fly by and screen blanks, keyboard backlight is on. Good = something happens. Bad = doesn't make it through boot from the eMMC.

* OS boot card (32GB Lexar SDXC - has worked before) installed left SD port, battery removed, connected to power via microUSB 3.0 wide port (power button flashes red, unit draws 0.15A), no boot progress. Pressing power button has no visible effect - red flashing power button continues to flash.

* Alternate/other OS boot card installed left SD port (64GB Samsung EVO - has worked before in left SD port with adapter and internally mounted), battery removed, connected to power via microUSB 3.0 wide port (power button flashes red, unit draws 0.15A), no boot progress. Pressing power button causes keyboard backlight to flash one time, then back to the power button flashing.

* OS loader / flash card installed left SD port (8GB Patriot microSDHC card in adapter - has worked before to load OS to eMMC), battery removed, connected to power via microUSB 3.0 wide port (power button flashes red, unit draws 0.15A), no boot progress. Pressing power button causes keyboard backlight to flash then unit boots from card and installs rootfs to the eMMC. Good = unit appears alive and this is kind of the objective - to get a working OS on the eMMC again. Pulls ~1A through the process. Syncing, prompts to poweroff (completes). Unit goes to flashing red power button.

* No card installed, first boot after OS loader / flash complete, battery removed, connected to power via microUSB 3.0 wide port. Unplugged unit from power, plugged back in. Flashing power button for 5 seconds then solid then keyboard backlight comes on and - there is a grey line left to right at the bottom edge of the display like zillions of characters flying by too fast for the eye to resolve. Press and hold power button 9 seconds unti resets to flashing power button, stays that way no further activity. Pressing power button once results in solid power button seconds later, keyboard backlight comes on, screen scrolls a few hundred lines of text then that same grey line - this time through the whole screen of characters flying by too quick to resolve. Press and hold power button 9 seconds to exit the loop.

* 32GB OS card installed left SD slot. No battery. Plugged into microUSB 3.0 wide for power. Power button flashes red, keyboard backlight flashes once, power button continues red. Pressing power button flashes keyboard backlight once, then goes back to just the power button flashing. Unit is drawing 0.01A, barely registering on my meter.

* Remove the 32GB OS card, plug unit back into the microUSB 3.0 wide for power, draws 0.3A and boots from the corrupted eMMC again. Press/hold power button, unit shuts down to flashing power button, insert OS boot SD, unit powers on and loads the eMMC image, not the SD card one - lines of nothing but flying characters again. Power button glowing purple, left light green, right light red.

* Unplugged, put the battery in, lights came on before I could flip it over. systemd-journal error No space left on device. Press power button once, system powers down completely. Press power button = nothing happens.

* Switch to microSDXC OS card in adapter in left slot. Add battery. System unresponsive.

* Remove card, reinsert battery, system boots automatically from eMMC to dp logo (no button press). Welcome screen displayed. Answer yes to calibrate touchscreen - it skips it anyway - Please enter full name - fills with +++++++++++++++++++... - Wait 30 seconds then press/hold backspace button. No good - can't get rid of the +++++s. I'm not sure how big that buffer is, but it seems to be tens of thousands of bytes. Use cancel button to recycle it. Please try again [OK], Please enter your full name. Left shoulder shift is not working to create a capital letter. Right keyboard shift does fine. Enter 'Grench', goes to dp logo screen with working x mouse pointer at 15:17 local time. Waiting. 15:20 still stuck on the same dp dark red on black logo with x mouse pointer. Calling it locked. Press power button once, no response. Press and hold 9 seconds unit powers down completely.

* Battery removed, 64GB OS microSDXC card placed internally, battery inserted, no light, no response to power button. Connect unit to microUSB 3.0 wide power supply, unit draws 1.87 A, boots to Welcome screen to configure what seems to be the eMMC OS. Yes to touchscreen calibration - it skips it - ++++++++ filled user name box, wait, Cancel, OK, ++++++++++ filled user name box, wait, Cancel, OK, ++++++++++ filled user name box, Cancel, OK, ++++++++++ filled user name box, wait, Cancel, OK, ++++++++++++ filled user name box, wait, run nubs in all directions fully in case picking up some noise from centering, Cancel, OK, +++++++++ filled user name box, Cancel, OK, ++++++++++ filled user name box, Click in box, press and hold backspace for 30+ seconds and it begins to clear, using backspace and delete clear box. Try to use lower left shoulder button to shift for G character and get g. Use right keyboard shift to input Grench, click OK. dp dark red logo on black background, movable x mouse pointer. Stuck.

* Working on a theory. One of the shoulder buttons is relevant in booting from internal microSDXC, but which one? I was able to get it to boot from it before by holding all four and pressing power, but now the unit will not power on from battery but powers on instantly from mains.

* Disconnected from microUSB 3.0 wide cable and immediately pressing both right shoulder buttons and power button. Back to a Welcome! screen, not sure if it is internal card or eMMC. Start - Calibrate=yes, system skipped, +++++++++ filled user name box, rinse repeat, catch it quick to get backspace and delete for the +s, left shoulder shift fails, input Grench, dp dark red logo on black screen - I'm pretty sure this is the eMMC again. Press/hold power button to get out of stuck. Takes 13 seconds.

* Tried cycling power with shoulder buttons pressed. Red power light came on, otherwise unreesponsive. Removed / placed battery. unresponsive.

The above took a two and a quarter hours. Hopefully there is something in there for ED, aTc or other devs to inspire ideas for me to try.

Things to do:
1. Dig through my old microSD and SD card collection to find another one to use for the eMMC OS flasher. Maybe that card I am using to flash the OS is the issue? I will make a new/different one for flashing the OS.
2. Re-create my OS SD cards. Maybe I have corrupted them. I will create a new set.

Other suggestions?

 

[levi]

Traditionally, Pandora special booting is trigger by the right shoulder button, but on the Pyra that leads to a question; which one?

No other suggestions from here, really, but I would like to thank you Grench for this exhaustive test which I feel may be getting a little frustrating already. Awesome work there!

 

[Djoga'Ro]

@Grench is there some serial console functionality you could use to gather some more information on a connected desktop pc?

 

[rSl]

I would like to thank you Grench for this exhaustive test which I feel may be getting a little frustrating already. Awesome work there!

+1
and much zen powers to you. don't forget to have a good cup of tea between debugging sessions!

 

[Grench]

I have figured out a bit about the battery charge cycles. When it wants to charge it pulls 1.8A. Later in the cycle it seems to pull 1.07A. When full the unit pulls 0.3A or less. Right now it is connected to the microUSB 3.0 wide port on a 2A charger. How am I getting these Amp draw numbers?

https://www.amazon.com/Eversame-Multimeter-Voltmeter-Indicator-DC3-6-30V/dp/B07JYVPLLJ

I'm back to it a bit, though there won't be much going on to report about. I'm going to make myself a new eMMC loader/flash tool.

Post automatically merged: Dec 29, 2019

+1
and much zen powers to you. don't forget to have a good cup of tea between debugging sessions!

I just got done taking a break, during which I restrung and tuned a cello. Fixit Dad is never done.

 

[Djoga'Ro]

When it wants to charge it pulls 1.8A. Later in the cycle it seems to pull 1.07A.

For whoever cares: The charge control regulates the voltage to maintain a set charging current, until the voltage reaches a preset limit (usually 4.2 V) and then keeps it there. Since the battery's resistence goes up as the charge does, the current gradually goes down in this second stage. (I'm talking about LiIon batteries, but I'd say it's the same for LiPos - maybe a slightly different (per cell) target voltage.)