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