Well, in the issue list, you write "Most likely not a hardware issue".

For me, that means it can be fixed with software. However, I can't see any way to confiigure this with software if the software - as the software doesn't even boot if it tries to load the MLO off the SD Card.

The only way I can see to fix this is by changing the boot priority configuration, so that it does always boot from eMMC first (unless it's forced to boot from SD Slot 1 with some SDIO signal - that should be the proper way).

If I understand it correctly, the only way to change the boot priority for a cold boot in our case would either be by having an EEPROM with a boot configuration on the PCB or by swapping the interfaces so that eMMC is being tried to boot first out of the box.

Both these sound like hardware changes for me, not software changes.
If you can think of a way how to fix that issue using a software workaround, please let us know so we can look into it.

It looks this is the first known bug of production units then, as we can't change it.

Does anyone know how we can at least prevent that from happening as long as the user doesn't remove the battery from the system?
For example, by setting a boot configuration that's held in memory until the battery is empty or removed?

Is that even possible? TI mentions that a changed software boot config is only possible for a warm boot. A cold boot always uses the default config (or the one in the EEPROM). I just don't know if they mean 'completely without power' with cold boot or already a simple 'power off'.

On 10 December 2019 09:52:40 CET, "H. Nikolaus Schaller" <hns@goldelico.com> wrote:

Am 04.12.2019 um 23:13 schrieb aTc <atc@k-n-p.org>:

I ran into a fun problem where my pyra doesn't seem to boot when there's an sd card in slot 1 that doesn't have a bootloader.

(dd'ed 50mb of zeros onto the card first, then created a fat32 partition)


I installed uboot on the emmc, and that boots when the card is removed (after having pressed power for 8 seconds to shut it down completely, then power again to start it. it seems to get stuck. It does pull 0.5A from the usb socket).


Is this an issue on the other prototypes as well,

yes. It is known for > 2 years [1] and likely an effect of the BootROM. AFAIR also on OMAP5EVM.

or is this part of the "wrong resistor that puts the cpu in debug mode" problem that this older prototype apparently has ?

It may be nothing we can "fix" by hardware, u-boot or kernel. Just by a warning in the user manual.

[1] http://projects.goldelico.com/p/dragonfly/issues/818/
Kernel mailing list
Kernel@pyra-handheld.com
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel


--
Mit freundlichen Grüßen / Greetings,

Michael Mrozek
OpenPandora GmbH
Geschäftsführer / CEO: Michael Mrozek

Schäffbräustr. 11
85049 Ingolstadt
Deutschland / Germany
Tel.: +49 841 / 990 5548
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org