Ypu should rather use a screwdriver.I haven't cracked open the case yet.
I don't know if that is even possible. The flash write program does not give a chance to change the target.@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 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.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
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.22.214.171.124.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 126.96.36.199, 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.
188.8.131.52.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.
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. ?I don't know if that is even possible. The flash write program does not give a chance to change the target.
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.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.
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.
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 install linux-image-4.19.60-letux-lpae-pyra
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 ) )
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?The initramfs runs a script at boot that detects if there's a microsd card inserted, and switches to that if one is there.
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)
I just got done taking a break, during which I restrung and tuned a cello. Fixit Dad is never done.+1
and much zen powers to you. don't forget to have a good cup of tea between debugging sessions!
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.)When it wants to charge it pulls 1.8A. Later in the cycle it seems to pull 1.07A.