Release Pandora System Info

[_wb_]

@ekianjo: I'm booting from an SD card and install whatever I want on that, without having to worry about space. Booting itself is slower this way, but since I never power off, that doesn't matter too much.


@Atamos: thanks for the info! That percentage doesn't seem too bad! Anyone have a lower percentage?

 

[ekianjo]

@ekianjo: I'm booting from an SD card and install whatever I want on that, without having to worry about space. Booting itself is slower this way, but since I never power off, that doesn't matter too much.

you mean your whole OS is on the SD card?

 

[_wb_]

Yes, you can use this tool to prepare an SD card to boot from: http://repo.openpandora.org/?page=detail&app=sd-install-2011-03-10

 

[ekianjo]

Yes, you can use this tool to prepare an SD card to boot from: http://repo.openpand...tall-2011-03-10

So basically you can install as many things in the OS as you like in this case? No specific limitations whatsoever?

 

[_wb_]

Yes. Only limit is the size of the partition you create on the SD card.

 

[Letalis Sonus]

Does it give the actual free space? (this would correspond to the pessimistic (but true for average but atypical data) assumption that no compression can be achieved for the data you're going to write) Or does it assume some small compression factor to compute the remaining free space?


I didn't even know the NAND was using a compressed fs, I nearly never use it anyway.

I kinda took it from the UBIFS website, I'm still waiting for my device. I do know that compression is enabled, but I have no idea whether it's LZO or zlib.

Traditional file systems like ext2 can easily calculate amount of free space. The calculation is usually quite precise and users are accustomed to this. However, the situation is very different in UBIFS - it cannot really report precise amount of free space which confuses users. Instead, it reports minimum amount of free space, which usually less than the real amount. Sometimes the mistake may be very high. For example, UBIFS may report (via the statfs() system call) that there is no free space, but one would still be able to write quite a lot.


To put it differently, UBIFS is often lying about the amount of free space it has. As a rule, it may fit considerably more bytes than it reports. However, it never reports more free space than it has. It reports less, and very rarely it may report the exact amount. And this is not because UBIFS authors are jerks, there are fundamental reasons for this, which are discussed below. [...]

 

[Null]

89.4340% after 1 recharge cycles, wtf the battery's been charged/discharged quite a few more times than that.

 

[Zero3K]

The info for my battery is: 86.6509% after 224 recharge cycles

 

[A2000]

Thank you for the program. I love this kind of apps. Very nice storage view!


My battery is 91,1557% with 45 cycles.

 

[pmprog]

Where are the cycles taken from? I've had my Pandora for over a year (I think), and it says 4 cycles - however, my Panda went for repair not too long ago, and ended up with a new board.

 

[_wb_]

They are taken from /sys/class/power_supply/bq27500-0/cycle_count, I suppose this is what the battery reports. I don't know how the battery keeps track of this or how it defines what a cycle is.

 

[Linux-SWAT]

A cycle is when the end reaches the start.

 

[notaz]

It's all in the manual:

... the number of cycles the battery has experienced. One cycle occurs when accumulated discharge ≥ CC Threshold.

I don't know what MWeston set CC Threshold to, default value is 900mAh.

 

[_wb_]

A full charge is 4200mAh, so does that mean that one full discharge corresponds to 4 cycles? That seems strange... or does there have to be charging in between?

 

[EvilDragon]

Hmmm, that would be nice as charging indicator for a minimal kernel...


notaz: I forgot, is it possible to find out whether the Pandora booted up from the power switch or from connecting the AC adaptor?


Would be nice to show the battery dialogue when you connect the AC adaptor while the Pandora is off and then continue to boot when the user flicks the power switch.

 

[notaz]

Nope, not possible (one of main reasons this was never implemented).

 

[_wb_]

Well, you could just read out the charging status during boot time (as soon as the battery info becomes available in /sys), and show the battery info if the battery is charging. I don't know how early in the booting process you could do this.


This is not exactly the same as figuring out the reason why the Pandora booted, but it might be "close enough". If you would switch it on manually, then quickly connect the AC adapter, it may give you the battery info if it's already charging by the time the boot process reaches the point where it checks. Or if you reboot while charging. So there are some "false positives", but if you can just skip the info (let's say by pressing any key) and move on, that is probably not a big problem.

 

[notaz]

There is also an issue when you use pandora over remote (which I do most of the time) and reboot it, if it then enters that charging mode I would lose my access.

 

[_wb_]

Good point. It would make sense to keep booting in the background while the charging info is shown so 1) services like sshd get started, and 2) when you exit the info screen, you don't have to wait too much longer before your desktop appears.


Also it would not be hard to save a "don't show charging screen" file at (planned) reboot, which overrides the standard behavior.

 

[EvilDragon]

That could work - instead of login, keep showing the battery info.


Also, there are different runlevels for reboot and poweroff.


The poweroff runlevel could create a file. If that file exists, show the battery meter while booting the system and removing the file.


If th file doesn't exist, boot normally.