Am Tue, 10 Dec 2019 12:09:36 +0100 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
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"...
Ah, yes, that makes some difference.
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.
I didn't spawn a discussion as I thought this to be software fixable if it's not hardware. So yeah, probably a misunderstanding.
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.
Well, you're not fixed to boot from SD1, even if you don't use the EEPROM to setup the boot order, as you can use the sysboot pins to define it.
The only issue I see with the sysboot pins is: TO prefer booting from eMMC, you need to set it to 0b1000, which boots from eMMC and then from USB second, so it can't even boot from SD anymore.
So yes, the only usable setup seems to be what we use, which is 0b1010.
However, I guess the proper way would've been to use an SDIO (via shoulder button or some other button) to change the one sysboot pin, so that it defaults to 0b1000 but can be forced to 0b1010.
Then it would always boot off the eMMC first but you could override it to the first SD Card.
That's how it works on the Pandora as well.
But that's not fixable anymore.
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.
Well, it took me 10 minutes to look that up in the documentation just by searching for "Boot" ;)
Page 7197 lists everything about sysboot including the various setups (29.2.4.2 Booting Device Order Selection) for the sysboot-method.
And setup guides and examples for the EEPROM configurarion on page 7212. (29.3.4.4 Boot Device List Retrieved from EEPROM)
The SAR RAM method is also described just after the EEPROM configs, but it's unclear if that configuration survives a power off or not.
But yeah, all this except for the SAR RAM method will not help us now, as that would mean hardware changes.
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.
As far as I see it, we just didn't setup our own boot configuration but instead simply copied the one from the uEVM.
So I don't see it as an OMAP5 hardware issue but rather of a missing configuration on our PCBs.
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.
Well, best thing we can do is try to use the SAR configuration. If it saves the boot config until the battery is removed, then at least the users don't need to remove the SD Card to boot up the system.
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.
If it does only happen on EXT3-formatted cards, I don't see an issue, as that won't happen to the normal user. That's fine then.
However, as far as I understood aTc, he tried a standard FAT32-formatted fresh card and it lead to the same issue. That's why I'm bringing it up here.
I'll try to find some time to test it with freshly unpacked SD Cards as well.
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/ 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
-- 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