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, or is this part of the "wrong resistor that puts the cpu in debug mode" problem that this older prototype apparently has ?
On Mi, 2019-12-04 at 23:13 +0100, aTc wrote:
Okay, I just checked the OMAP5 datasheet and the Pyra schematics.
The document I'm using is: OMAP543x_ES2.0_NDA_TRM_AF - swpu282af.pdf
According to the OMAP5 datasheet (29.2.4.2 Booting Device Order Selection), there are three ways to control which is the main booting device:
* Setup by software. This has the highest priority and is only used on a warm boot.
* Setup by an EEPROM (which we don't use, AFAIK)
* Setup by sys_boot
So since we're not always warm booting, I guess we need to make sure sys_boot is setup properly. According to the schematics, sys_boot[3:0] is set to "high", which means Table 29-5. Memory Preferred Booting in the datasheet is the one that's valid. The schematics also mention that the system is setup to boot SD > eMMC
USB (which apparently is not how it should work, as the eMMC should
always have the highest priority in the end user system!)
Now, I don't understand how you can set that to different values - but I guess that Nikolaus set it to 0b1010, as then the boot order would be: SD > eMMC > USB
Now for the interesting part: In TIs datasheet, they map SD to MMC1 and eMMC to MMC2. In Nikolaus' datasheet, it's the other way round: eMMC is mapped to MMC1 and SD to MMC2.
This means that the boot order we've setup is probably: eMMC > SD > USB
Which would be good!
Now there are two questions arising:
1. Why does it not boot from eMMC if that's the primary boot device? 2. Why does it even hang? It should loop all devices until it finds a proper bootcode (and 00000 on an SD Card should not be a proper bootcode).
I can imagine that we have an improper software booting setup. The software configuration has highest priority and should be kept in memory until the battery and all other power is removed. So shutting down the system would keep the configuration.
This could very well be! I don't know if the software boot configuration has a different setup than the sys_boot configuration, but there is one very interesting sys_boot-Config:
"When sys_boot[3:0] is tied to 1110, the ROM code boots from eMMC boot partition. If the ROM code fails to retrieve the booting image, it does not try boot from the user area contrary to other eMMC options in the table. This option does not provide the peripheral booting support (for example, USB)."
As we swapped eMMC and SD in our setup, this config would mean that it would try to boot from SD Card - and if there's not bootloader, it won't do anything else!
I'm not sure where the boot configuration is setup in the software (board file, maybe?), but maybe that's the clue.
One thing to try: If you remove the power and battery for 30 seconds thus clearing out the software config and then try to boot from eMMC with the SD Card in, does it still hang?
Because if THAT is the case, then we're having a small problem... as it would probably be confusing for the normal user if he had to remove the SD card whenever the battery runs flat to boot the system.
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, or is this part of the "wrong resistor that puts the cpu in debug mode" problem that this older prototype apparently has ? _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
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.
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
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/ 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
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
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