On Di, 2019-12-10 at 12:09 +0100, H. Nikolaus Schaller wrote:
Just a quick update:
Fortunately, this didn't turn out as bad as we thought it would!
When aTc first tried it, all his SD Cards stopped the unit from booting, even freshly formatted FAT32 cards.
And that would've been a real issue.
After a bit more testing, aTc found out that this seems to be an issue with gparted: When creating a single partition, gparted fills the beginning of the SD Card with various bytes (we don't know why) whereas sfdisk and others simply fill it with 0.
A fresh card from a manufacturer also is filled with 0.
That's why we thought EVERY card would prevent the system from booting - but the ones filled with 0 work fine.
So as long as the users don't partition the card using gparted, it seems to work fine.
Am 10.12.2019 um 11:40 schrieb Michael Mrozek < EvilDragon@openpandora.org>:
Well, in the issue list, you write "Most likely not a hardware issue".
For me, that means it can be fixed with software.
Well,it seems there is one word missing to be misinterpreted: "Most likely not our hardware issue"...
OMAP5 BootROM (contains ARM firmware) is in my view neither (our) hardware nor (our) software but something in the middle.
So the conclusion is wrong. It may be possible or impossible to fix by software. But I haven't reasoned about that since there was no discussion after finding the issue.
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).
Well, SD1 is the main boot slot as defined by TI. And one reason to keep this boot order is that eMMC may be empty or broken and then you can't boot from SD1.
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
I have not studied the OMAP5 boot process well enough, but it may be possible to use such a method.
or by swapping the interfaces so that eMMC is being tried to boot first out of the box.
This produces other issues with SD card speed and power supply. And, the eMMC interface is not exposed directly to the B2B connector (only through the txs µSD switch). So if you want a complete redesign of the Pyra it may be doable.
Both these sound like hardware changes for me, not software changes.
Well, you are mixing issue and solution. There may be hardware solutions (aka workarounds) for an issue.
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.
Unfortunately I have *no* solution to offer, besides a "social" one: write some instructions into the user manual what one should NOT do with SD card formatting.
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?
Using well formatted SD cards. It seems as if BootROM gets mixed up by an ext3 formatted card. A potential solution could be to have a hidden FAT partition on such cards.
It needs someone who does such experiments and analyes what works and what does not.
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/ < http://projects.goldelico.com/p/dragonfly/issues/818/%3E Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel < http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel%3E
-- 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/ http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt eMail: mrozek@openpandora.org