|
195 | Core | Feature Request | High | Start re-recharge of battery sooner | Closed | |
Task Description
Increase battery LVL_4 and LVL_3 threshold.
After reaching 100%, in some cases the charge circuit enters "battery full" state, stops charging, and begins to discharge. This is not entirely unexpected behavior according to the spec sheet, although I don't fully understand exactly the situations in which it completes charging. Once the battery is full, the battery will begin discharging. The charge circuit automatically restarts the recharge once the voltage has gone below a certain level (crosses below the LVL_3 voltage threshold)
The default LVL_3 voltage threshold is 3.902 volts which is at about 80-85% battery level as recorded by bq27500 chip. In my opinion, this is way too low.
Setting the BCIMFTH2 register to 0xCB increases the voltage threshold to about 4.003 volts which is about 93%.
Setting it to 0xDC may also be worthwhile, which is just over 95%.
By default, if a user leaves their Pandora plugged in overnight, they may wake up to find their Pandora has stopped charging and the capacity has dropped to almost 80%, which can be quite startling to some users who will then report it as a bug.
This change will ensure that it never drops below 93-95%, a much more acceptable level.
Specific code changes suggested, in the /drivers/power/twl4030_bci_battery.c file, somewhere in the twl4030_bci_battery_probe function (or a function called by it), add the lines:
/********************************/
#define KEY_FTH2 0x7F
#define REG_BCIMFTH2 0x017
ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE, KEY_FTH2, REG_BCIMFKEY);
if (ret)
return ret;
ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE, 0xDC, REG_BCIMFTH2);
if (ret)
return ret;
/********************************/
(Move defines to the top, as appropriate) |
|
197 | Core | Bug Report | High | [PATCH] Fix opp if booting with wrong settings in hw | Closed | |
Task Description
Hi,
This should help with cases like this
http://www.gp32x.com/board/index.php?/topic/57303-overclocking-broke-my-pandora/
Patch attached. |
|
214 | Core | Bug Report | High | op_wifi pnd not exiting cleanly, with fix (one characte ... | Closed | |
Task Description
The op_wifi pnd does not exit out cleanly once the encased script executes,
the pndrun_op_wifi.out reports
umount: /mnt/utmp/op_wifi: device is busy.
umount: /mnt/utmp/op_wifi: device is busy.
umount UNION failed, didn't clean up. Process still using this FS :
3197 ? S 0:00 /bin/sh /etc/init.d/wl1251-init start
This op_wifi.sh just calls
/usr/pandora/scripts/op_wifi.sh
for some reason, the init.d/w.... start causes it to hang, I executed all this locally, and it doesn't appear to keep running
Appending " &" to the line which calls this init script, solves the problem. |
|
226 | Core | Feature Request | High | Boot from /dev/sda devices requested | Closed | |
Task Description
Boot from usb hard disk not supported. This should be a rather simple fix of adding the sdx devices and adjust the boot scripts??
I was able to put this autoboot.txt on mmc 0:1
setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K
ext2load sda 0:1 0x80300000 /boot/uImage
bootm 0x80300000
This failed with amongst other things "Block device sda 0 not supported" and something about failing to load kernel
So I then changed the autoboot file to this
setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K
ext2load mmc 0:3 0x80300000 /boot/uImage
bootm 0x80300000
All this did was die after the kernel loaded.
I believe I could much better make use of this device if I could boot from some faster storage, please advise :) |
|
249 | Application | Bug Report | High | File Browser Thunar - After 2 nub double-clicks unreact ... | Closed | |
Task Description
If I navigate via keyboard (KEY UP/DOWN to move in lists, ENTER level down, BACKSPACE level up) I experience no problems at all. I can go many levels up/down, change to other folders, etc. No problems.
But if I navigate with the nubs, and using the right-nub-up-direction to trigger a double click, this only works 1-2 times, and from then on, the files/folders in Thunar cannot be clicked any further. I am stuck then.
A look into dmesg reveals this:
keyboard.c Can't emulate rawcode for keycode 139
The timestamp of that specific keyboard.c error messages exactly correlates with the bug occurrence times. (uptime timestamps matched with dmesg timestamps)
I tried alternative filebrowsers such as emelFM2, and there the problem does not exist, meaning I can trigger as many double clicks I want!
I am using HotFix 5 Alpha 4 on an SD card. The bug already annoyed me on a HF5 on the NAND. |
|
254 | Core | Bug Report | High | Several apps leave graphical artefact overlay (ghost) a ... | Closed | |
Task Description
After quitting some apps, their last graphical output remains on the screen, which covers a large area of the Pandora, and therefore makes it quite unusable, so that only a full restart resolves this issue.
As this happens in many apps (Mednafen-GB, Dark Light Battles, etc) this must be a problem within a shared library (driver, graphics lib, window manager framework, or similar). |
|
259 | Core | Bug Report | High | Hold switch does NOT lock keyboard! Especially crucial ... | Closed | |
Task Description
Apps, which operate with the Pandora in closed lid mode, such as audio players, server processes, etc, in a button-press-probably environment (as i.e. your pocket) still CAN receive the shoulder button L + R key presses, and if they have a meaning in these programs, they could trigger undesired actions.
And also in the current implementation of the Low Power Mode (See: FS#260) key presses may still be received.
Therefore I strongly propose to implement the HOLD switch to en/dis-able a keyboard lock.
IN DETAIL: This shall be global, meaning that the input processing software (however this is implemented on the Pandora: kernel, driver, … ) keeps the lock state (on/off), and if the keyboard state is off,
a) discards all input, or
b) if it makes sense for some reason/applications (any ideas?) just writes them into a queue/buffer, which gets (partially) executed or made accessible to certain software after the keyboard gets unlocked again.
FYI: I have tested the hold switch with the Pandora Input-Tester, and it is recognized. So my report is definitely a software (and not an hardware) issue. |
|
267 | Core | Bug Report | High | HF6-Updater.pnd loses pnd_run.sh | Closed | |
Task Description
Several users have reported that running HF6-Updater.pnd leads to a missing /usr/pandora/scripts/pnd_run.sh
Possibly the file is locked by the Updater itself when installing pandora-libpnd_1.0-r56.5_armv7a.ipk
Forum thread:
http://boards.openpandora.org/index.php?/topic/5652-hotfix-6-final-released/page__view__findpost__p__99313 |
|
108 | Base OS | Feature Request | Critical | TUN/TAN-Driver | Closed | |
Task Description
There is no TUN/TAN Driver installed. This is recommanded for some encrypted wireless lan connections, especially for eduroam, a world wide access point for the education community. Also, a tun-driver is also recommended for vpnc. |
|
208 | Core | Bug Report | Critical | HOTFIX 4 and 5 Slow WIFI | Closed | |
Task Description
I'm getting 5kb/s with bursts up to 10kb/s if I am lucky.
I have attempted every channel on my router.
Tried every encryption even no encryption.
Tested with the router's wifi speed: 300Mbps 154Mbps and 45Mbps
I'm running Hotfix 5 RC2.
Wifi works fine with my android smartphone, and other wireless devices such as a laptop. |
|
263 | Application | Bug Report | Critical | MiniMenu with "Auto discover pnd apps?" set to NO hangs ... | Closed | |
Task Description
BUG DESCRIPTION:
On my SD card with Pandora OS 1.6.4 I changed MiniMenu's setting "Auto discover pnd apps?" to NO, and then the program remained in an endless loop showing "Setting up menu...", crashing, "Setting up menu...", crashing, and so on.
BUG REPRODUCTION:
The variable filesystem.do_pnd_disco set to the value 0 definetely causes the crash, but maybe only in conjunction with some of my other settings?!
Therefore see my attached config file mmpref.conf.
Maybe related to FS#79 , hard to tell, as this is a very minimal report.
Definitely not related to my previously reported MiniMenu bug FS#262
WORKAROUND:
1) If your default GUI is:
a) MiniMenu: Then after rebooting, MiniMenu will still be caught in an endless loop! Therefore boot up from an auxilary/temporary volume rather than your volume with the damaged MiniMenu! If your ruined system is on the NAND boot from an SD card, if the ruined system is on SD card, boot from NAND or another SD card. In doubt read: http://pandorawiki.org/Running_Linux_from_an_SD_card
b) Other than MiniMenu such as XFCE: Then you are lucky. Simply start into XFCE, and continue with the next step.
2) Open ~/.mmpref.conf with a text editor and set the variable filesystem.do_pnd_disco to the value 1.
3) Reboot into your healed volume. |
