Open networkimprov opened 8 years ago
i2c2 bus isn't accessible from u-boot. Likely an pinmuxing issue, will check into this.
Check these commits, our previous working u-boot branch.
https://github.com/networkimprov/u-boot/commits/anvl-v2014.10
Figured out the issue was the fuel gauge doesn't even enumerate if the battery is disconnected... So that is one check we have to do in u-boot as well, or alway have a bench supply connected.
Anyway since the result from the fuel gauge is big endian, and u-boot doesn't have a sane way to convert endian types. Need to figure a way to convert it, and per @tmlind we may just need to add a simple command to u-boot instead.
@networkimprov Do you want this battery check to loop and check every 5 seconds or so inside the bootcmd?
Check bq24190 stat registers first to find out if battery connected. Then get voltage from gauge. Charger driver does that here: https://github.com/networkimprov/linux/blob/anvl-v4.7/drivers/power/bq24190_charger.c#L933
If comparing a register value with a constant int, can you write the constant as a big-endian value? e.g. 0x1000000 vs 1?
Maybe check every 3s.
Actually was incorrect about endian. Here is an initial rev of functions that check battery connection, and voltage.
Also need to test bq24190 for USB charging port. I believe boot can proceed if it's present, regardless of battery state.
Detect charging port with reg8[7:6] (aka vbus_stat) == BIT(1)
Yes it can will update today.
Ok resubmitted with vbus check
Edited to normal link - lb
Why the \& ? Two kinds of & ?
Add a comment with the decimal value of e74, and units "min_voltage" would be easier to read :-) The usb function should go first in the group The whole group should go before loadramdisk=
On Tue, Sep 13, 2016 at 8:13 PM, Liam notifications@github.com wrote:
Why the \& ? Two kinds of & ?
You have to escape the & statement in u-boot or the hush shell will think you are doing a bitwise operation. And the extra \ is to escape the \ on the mkenvimage compilation :).
Add a comment with the decimal value of e74, and units "min_voltage" would be easier to read :-) The usb function should go first in the group The whole group should go before loadramdisk=
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.
Revised patchset above.. also found an issue with the u-boot test command that didn't like >8 bit hex digits unless prepended with 0x
The min voltage must be lower than 3.7? That's what the battery's rated when fully charged.
@networkimprov Ah good point but fuel gauge is reporting the following with "udevadm monitor --kernel --property". Not sure why
POWER_SUPPLY_CAPACITY=84 POWER_SUPPLY_VOLTAGE_NOW=3966000
Edit: Actually it is 3.9v when I measure with a multimeter. Not a battery expert but I think the discharging curve is like this -> http://www.all-battery.com/productimages/li-ion/18650-2200mAh-discharge-curve.jpg
So maybe we should make the cutoff 3.650 or 3.6 ?
Prob 3.4 to 3.5? We need to work out at what V we're going to poweroff and set it slightly over that. I'll ask EE...
We need a revision to bootcmd to call your check functions and sleep/retry on fail. Probably with a way to let user exit the loop and get the u-boot prompt.
I don't see the part about sleep/retry in recent commit?
Doesn't loop but errors out.
Tony thought we should loop, as we are probably charging if test fails.
Additional patchset to loop till condition passes https://github.com/networkimprov/omap3-usb-boot-install/commit/6d2d4fe06793b98566a898b2e0fc7593289161a4
Shouldn't it do battery_state_check before voltage_check?
Is there a way to let user stop loop before sleep? If so, indicate how to do that where it echos "No USB or battery too low to boot".
@networkimprov Basically I didn't do battery_state_check to make the logic simpler, and simple fact is the usb cable check fails we must be running off battery. Thoughts?
You should be able to Control-C out of the dialog during sleep command.
Added some items to this issue; see description.
@networkimprov Confirmed the LED is getting set in u-boot. Will look into code
Check for fault before booting. Fault register should be read twice to handle transient errors.
Loop if voltage low. Indicate charging or fault with LED. On kernel start, set amber LED.
Tony: For the u-boot battery voltage detection, the board file should just read the bq chip status to see if there's a battery and refuse to boot further until the voltage is safe for eMMC.