Hi,
I have redirected this discussion to the ML, because it might be of greater interest.
Am 15.02.2017 um 11:30 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 15 February 2017 at 10:59, H. Nikolaus Schaller hns@goldelico.com wrote:
Neither have I, but it's easy to detect when ROM is trying to boot through USB since it will conspicuously show up as USB device.
It could have something to do with the general effect that the USB3 dwc3 does not work
But it does! I've used it for USB mass storage mode from u-boot without problems.
Oh, ok. This is important info that it works in u-boot. So we just have to look into the kernel.
Except it apparently also doesn't work in the ROM bootloader (on pyra, it does on uEVM).
I have done a quick test: * console connected * no SD cards inserted * battery inserted * plug in µUSB cable on USB3 port * powered on (so that BootROM starts searching for an OS)
Result is that my host reports a device called "OMAP5430".
Product-ID: 0xd011 Vendor-ID: 0x0451 (Texas Instruments) Speed: up to 480 MBit/s Current (mA): 1000
Interesting is also the last one - they assume that we need a high-current port for booting over USB...
Anyways, on my unit it seems to respond. What is different to yours? Well, the VBUS/VBATT fixes are installed. And what we have not verified is if the connector is soldered equally well.
Then, I am not sure if the BootROM assumes that there is a Palmas chip at all! Or does it?
If it does, it will likely check the VBUS voltage level to see if USB is plugged in.
In that case we probably have to swap your main board with a fixed one.
A final idea.
Boot order is: leftSD > µSD/eMMC > USB
So if there is something (broken) in eMMC it might not even try USB. That is why pressing the shoulder button long enough (or permanently) to switch to the empty µSD slot might be necessary. Boot-ROM seems to try for several seconds until it times out and tries the next interface. But I have not as much experience with the OMAP5 BootROM as with the OMAP3 so that I don't know all if its behaviour.
I also tried "ums 0 mmc 1:0" in u-boot but I have not yet cherry-picked all your patches so this command is missing.
BR, Nikolaus
On 15 February 2017 at 13:07, H. Nikolaus Schaller hns@goldelico.com wrote:
I have done a quick test:
- console connected
- no SD cards inserted
- battery inserted
- plug in µUSB cable on USB3 port
- powered on (so that BootROM starts searching for an OS)
Result is that my host reports a device called "OMAP5430".
And now I can get it to work too, and I even managed to boot from eMMC sometimes.
What does and doesn't work seems heavily dependent on what is connected, the configuration/state of charger (and perhaps palmas), probably the state of charge of the battery...
Also, I just powered on with no SD card inserted and holding down LSH-TOP to bypass eMMC boot... except it booted from eMMC anyway!
Weird stuff is going on. Will need to explore more...
Then, I am not sure if the BootROM assumes that there is a Palmas chip at all!
No, it does not interact with the PMIC on the omap5.
So if there is something (broken) in eMMC it might not even try USB.
And as I showed above, the shoulder button doesn't seem to work?
Also, USB is not considered a "permanent boot device", which means it is *only* considered at cold boot and ignored at warm boot. I forgot about this, and probably tried to get it to boot a few times by resetting or rebooting.
Asking palmas to power-cycle the system (i2c mw 48 a0 3) does work of course.
Matthijs
Hi Mattijs,
Am 17.02.2017 um 02:51 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 15 February 2017 at 13:07, H. Nikolaus Schaller hns@goldelico.com wrote: I have done a quick test:
- console connected
- no SD cards inserted
- battery inserted
- plug in µUSB cable on USB3 port
- powered on (so that BootROM starts searching for an OS)
Result is that my host reports a device called "OMAP5430".
And now I can get it to work too,
great!
and I even managed to boot from eMMC sometimes.
What does and doesn't work seems heavily dependent on what is connected, the configuration/state of charger (and perhaps palmas), probably the state of charge of the battery...
I had also tried with booting from µSD (with empty eMMC) and also did not yet find a pattern when it works and when it doesn't.
Maybe the RTC or the barometer chip also has an influence.
Also, I just powered on with no SD card inserted and holding down LSH-TOP to bypass eMMC boot... except it booted from eMMC anyway!
Oops. Hm. Only the 4 lower bits are switched and the eMMC is 8 bit. Well, ECC is probably not that good to read the eMMC correctly in this case...
And manually throwing the switch in u-boot and doing a mmc info shows only either one.
Weird stuff is going on. Will need to explore more...
Indeed. It is one of the last mysterious things.
Another one is that the board version detection sometimes reports V5.5 for my mainboard in MLO which then makes the gpio numbers setup for the µSD/eMMC switch fail.
This is difficult to explain. It just reads out some gpios...
Maybe a timing issue? Do we have to add a delay after switching pinmux before we read the gpio values?
Then, I am not sure if the BootROM assumes that there is a Palmas chip at all!
No, it does not interact with the PMIC on the omap5.
Ok, good to know. This means it is doing USB-boot without any assumptions about VBUS.
So if there is something (broken) in eMMC it might not even try USB.
And as I showed above, the shoulder button doesn't seem to work?
Also, USB is not considered a "permanent boot device", which means it is *only* considered at cold boot and ignored at warm boot.
Interesting to know!
Is the shoulder button not working for card selection a similar issue? Did you do a warm reset or cold reset?
Maybe the OMAP5 keeps the switch state of the last attempt during a warm reset. This completely disables the shoulder button for card selection completely until we do a cold reset.
I forgot about this, and probably tried to get it to boot a few times by resetting or rebooting.
Asking palmas to power-cycle the system (i2c mw 48 a0 3) does work of course.
For the GTA04 we have a poweroff command doing a similar thing for the twl4030.
Afaik there could also be some generic u-boot command, or not? Anyways an u-boot command to completely power off from the u-boot command line would be nice.
Additionally I have cherry-picked some more of your patches and manually picked some defconfig changes. Now, I can also use the ums command.
I hope my patches do not raise too many rebase conflicts.
BR and thanks, Nikolaus
Also, USB is not considered a "permanent boot device", which means it is
*only* considered at cold boot and ignored at warm boot.
Interesting to know!
Is the shoulder button not working for card selection a similar issue?
I don't kow if the gpio controllers are warm-reset-insensitive, I'd need to check.
Did you do a warm reset or cold reset?
I've done all sorts of stuff. I still have nothing resembling a mental model of what's going on.
Maybe the OMAP5 keeps the switch state of the last attempt during a warm reset. This completely disables the shoulder button for card selection completely until we do a cold reset.
Easy to check, but I don't dare rebooting my pyra now since I've just hooked it up to JTAG again for some testing.
Asking palmas to power-cycle the system (i2c mw 48 a0 3) does work of course.
For the GTA04 we have a poweroff command doing a similar thing for the twl4030.
Yes it would be nice to be able to type "poweroff" instead of that command above ;-)
Additionally I have cherry-picked some more of your patches and manually picked some defconfig changes. Now, I can also use the ums command.
I can also recommend CONFIG_DM_I2C btw, it has the benefit of tracking "current bus" state separately for the CLI, which means you no longer run the risk of getting palmas regulator errors while using the 'mmc' command because you typed "i2c dev 1" earlier. (I was a bit surprised when that happened...)
I also made life more convenient by allowing stateless use of the i2c command in the CLI: https://github.com/mvduin/u-boot/commit/11ee63376e521f574c584c81dc0df9d33078...
Matthijs
Am 17.02.2017 um 17:22 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
Also, USB is not considered a "permanent boot device", which means it is *only* considered at cold boot and ignored at warm boot.
Interesting to know!
Is the shoulder button not working for card selection a similar issue?
I don't kow if the gpio controllers are warm-reset-insensitive, I'd need to check.
Did you do a warm reset or cold reset?
I've done all sorts of stuff. I still have nothing resembling a mental model of what's going on.
I also have no such model...
I found a tiny piece of new information while checking the Palmas bits for poweroff. There are things like a battery debouncing detector. And auto-warm-start or however it was called. And, most importantly, in my register data sheet, the initial settings are not documented and referred to the OTG setup. That is something I don't know. So maybe we should read out the Palmas once in MLO and note what the initial state is (except those bits which are already modified by MLO).
Maybe this gives us some hints. Also to a subtle bug ED has noticed several times when unplugging the USB cables that the OMAP5 simply freezes with panel and omapdss being still on. But with overlay of some moiré pattern.
I suspect that the battery did momentarily loose contact - but the Palmas didn't switch off so that the OMAP5 lost memory or CPU state.
All this has no direct relation to the µSD/eMMC switch because it is controlled by OMAP5 gpios, but it may have an influence if the OMAP gets a warm/cold reset etc.
Maybe the OMAP5 keeps the switch state of the last attempt during a warm reset. This completely disables the shoulder button for card selection completely until we do a cold reset.
Easy to check, but I don't dare rebooting my pyra now since I've just hooked it up to JTAG again for some testing.
No problem, please do JTAG first! That is something which I can't help with.
Asking palmas to power-cycle the system (i2c mw 48 a0 3) does work of course.
For the GTA04 we have a poweroff command doing a similar thing for the twl4030.
Yes it would be nice to be able to type "poweroff" instead of that command above ;-)
Have added this!
Fortunately, someone already added the poweroff command option to cmd/boot.c which calls do_poweroff(). Enabling needs to #define CONFIG_CMD_POWEROFF in old style include file.
But the do_poweroff isn't defined anywhere - except in our private gta04 commands...
So I had to write a new poweroff i2c command to the palmas.c driver.
Here it is:
http://git.goldelico.com/?p=gta04-uboot.git;a=shortlog;h=refs/heads/letux-20...
Additionally I have cherry-picked some more of your patches and manually picked some defconfig changes. Now, I can also use the ums command.
I can also recommend CONFIG_DM_I2C btw, it has the benefit of tracking "current bus" state separately for the CLI, which means you no longer run the risk of getting palmas regulator errors while using the 'mmc' command because you typed "i2c dev 1" earlier. (I was a bit surprised when that happened...)
Ok, I see!
I also made life more convenient by allowing stateless use of the i2c command in the CLI: https://github.com/mvduin/u-boot/commit/11ee63376e521f574c584c81dc0df9d33078...
I am not sure if we should add too many such private extensions to u-boot core code. On one hand they are very useful, on the other hand we should tink about upstreaming them... So I will review them a little.
BR, Nikolaus
On 17 February 2017 at 19:52, H. Nikolaus Schaller hns@goldelico.com wrote:
in my register data sheet, the initial settings are not documented and referred to the OTG setup.
OTP yes, i.e. there can be a many variants of Palmas depending on which settings have been fused into it by TI. The old TRM I have (SWCS055J) lists the ordering codes PTWL6035BxxYFF and PTWL6037BxxRVL for the WCSP and QFN packaged versions respectively, where "xx is OTP designator". (Hmm, PTWL? Prototype?)
It also mentions later "OTP configuration defined for TWL6035 and TWL6037 in each specific platform is described in a separate Application Note."
That is something I don't know. So maybe we should read out the Palmas once
in MLO and note what the initial state is (except those bits which are already modified by MLO).
Should be easy enough to grab a copy before any change is made at all.
Interestingly SWCS055J indicates that there's an "OTP" page on slave address 0x4b, though no info on its contents. I can dump it on the pyra no problem, but the Palmas on my uevm doesn't seem to respond to reads from that slave address.
I also noticed something funny: it seems that if you read a non-existent register, you get the data from the previous read. This is fairly easy to detect hence allows mapping which registers are unused (or perhaps write-only). Note that dumping all registers will clear any pending irqs, but
I also made life more convenient by allowing stateless use of the i2c command in the CLI: https://github.com/mvduin/u-boot/commit/ 11ee63376e521f574c584c81dc0df9d3307819dc
I am not sure if we should add too many such private extensions to u-boot core code. On one hand they are very useful, on the other hand we should tink about upstreaming them... So I will review them a little.
Well regardless of what upstream thinks, as long as I'm still using i2c transfers in u-boot with some regularity I'm keeping something like this patch in ;) The stateful bus switching stuff sucked
And yes, I abstractly support the concept of sending the non-hacky patches upstream. It seems like a headache I don't want to deal with myself right now though :-)
Matthijs
-
H. Nikolaus Schaller -
Matthijs van Duin