If you (notaz) are pushed for time, I don't expect you'll be too interested in getting the latest stable mainline kernel working on the Pandora...
I've a need for this - with Debian and I also suspect that the wifi driver in the mainline kernel is probably worth trying ;)
I wonder if you can briefly outline the minimum required to get the kernel booting on the Pandora, I see in the mainline kernel there seems to be omap2/3 stuff from TI but I'm guessing there are some other things need to be done to make the kernel actually boot on the Pandora...
any clues from yourself or anyone else on here would be most welcome!
Best Chris
On 27/04/11 16:34, Grazvydas Ignotas wrote:
On Wed, Apr 27, 2011 at 6:27 PM, Chrisc.camacho@ntlworld.com wrote:
Can you confirm you will be enabling alarm irq in next firmware?
I'll email you directly with the source code to my little executable that prevents the Pandora switching on when connected to mains (this disables AC charging even if the unit is not charged btw) you need to be on to charge!
Thanks, I can't guarantee I'll really do it but I'll try to allocate some time for it.
Mainline already has pandora support, not everything but I'd consider most things to be there: http://pandorawiki.org/Kernel_status
git.openpandora.org also has newer kernels with additional patches (none of them are feature complete though).
On Wed, Apr 27, 2011 at 6:46 PM, Chris c.camacho@ntlworld.com wrote:
If you (notaz) are pushed for time, I don't expect you'll be too interested in getting the latest stable mainline kernel working on the Pandora...
I've a need for this - with Debian and I also suspect that the wifi driver in the mainline kernel is probably worth trying ;)
I wonder if you can briefly outline the minimum required to get the kernel booting on the Pandora, I see in the mainline kernel there seems to be omap2/3 stuff from TI but I'm guessing there are some other things need to be done to make the kernel actually boot on the Pandora...
any clues from yourself or anyone else on here would be most welcome!
Best Chris
On 27/04/11 16:34, Grazvydas Ignotas wrote:
On Wed, Apr 27, 2011 at 6:27 PM, Chrisc.camacho@ntlworld.com wrote:
Can you confirm you will be enabling alarm irq in next firmware?
I'll email you directly with the source code to my little executable that prevents the Pandora switching on when connected to mains (this disables AC charging even if the unit is not charged btw) you need to be on to charge!
Thanks, I can't guarantee I'll really do it but I'll try to allocate some time for it.
--
Disclaimer: By sending an email to ANY of my addresses you are agreeing that:
1. I am by definition, "the intended recipient"
2. All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please.
3. I may take the contents as representing the views of your company.
4. This overrides any disclaimer or statement of confidentiality that may be included on your message.
Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On 04/27/2011 06:09 PM, Grazvydas Ignotas wrote:
Mainline already has pandora support, not everything but I'd consider most things to be there: http://pandorawiki.org/Kernel_status
git.openpandora.org also has newer kernels with additional patches (none of them are feature complete though).
Which one of those is the most complete to be used as the next official kernel ?
.37/38/39 ?
good question there seem a number of things up there on git and its a bit confusing dare I say inaccessible, maybe a gitmap.txt is in order...
On 27/04/11 18:10, aTc wrote:
On 04/27/2011 06:09 PM, Grazvydas Ignotas wrote:
Mainline already has pandora support, not everything but I'd consider most things to be there: http://pandorawiki.org/Kernel_status
git.openpandora.org also has newer kernels with additional patches (none of them are feature complete though).
Which one of those is the most complete to be used as the next official kernel ?
.37/38/39 ? _______________________________________________ Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Hi,
well, since I now catched up a bit with normal day-job work, Pandora work and emails and stuff, I'll try to work a bit more on HF6. Here are my ideas, let me know what you think of them.
1. WizardStans improved charger should be included 2. Latest WiFi Driver from notaz (incl. AdHoc support) since I didn't hear any problems from it so far. 3. Chris' Wake up on time as well as shutdown if charged (optional) sounds good 4. More consumer-friendly-charging (I'll explain in my next mail) 5. New kernel (if it makes sense?)
1. and 2. should be pretty straightforward, 3. needs some configuration stuff, but that's something I also can do using Zenity scripts (if someone tells me what commands to use here).
Power off after fully charged (if that really does work) could have two configurations:
a) If enabled and the user hasn't touched the unit for a certain amount of time, it could shutdown and switch off when fully charged.
b) If disabled, the user should be able to run it manually through the menu.
5. New kernel: It was planned for the next OS version, but I don't know how far that is (care to shed any light on that, John? :))
If it works and can be easily implemented into our current OS, we could do that. If it's not that easy, we won't do it :)
What do you guys think?
Power off after fully charged (if that really does work) could have two configurations:
How many more people are going to assume this is a fake! try it yourself if you doubt my word its been available on my website for some time and has a good number of happy users! Heck you could even read the datasheet ...
a) If enabled and the user hasn't touched the unit for a certain amount of time, it could shutdown and switch off when fully charged.
I don't think it should be automatic at all, it should only shutdown if the *current* session has specifically been instructed to shut down after full charge is reached, what if its playing media while charging or some other task that doesn't require user interaction?
b) If disabled, the user should be able to run it manually through the menu.
it should be disabled all the time unless specifically requested by the user.
- New kernel:
It was planned for the next OS version, but I don't know how far that is (care to shed any light on that, John? :))
Isn't the latest stable kernel likely to have a more upto date wifi driver ?
On Sun, May 1, 2011 at 11:56 AM, Chris c.camacho@ntlworld.com wrote:
- New kernel:
It was planned for the next OS version, but I don't know how far that is (care to shed any light on that, John? :))
Isn't the latest stable kernel likely to have a more upto date wifi driver ?
We are already using a backport from the latest kernels, which is regularly synced..
- Chris' Wake up on time as well as shutdown if charged (optional)
sounds good
This needs to be integrated into kernel first. Current method of i2cset hack-around is unsafe and I don't recommend doing it like this in official firmware.
- New kernel (if it makes sense?)
Somebody needs to fix various regressions first. For example, NAND isn't working any more, OSS emulation is broken (which means half of emus will not work). Also a new BT solution is needed.
On Sun, 1 May 2011, Michael Mrozek wrote:
# well, since I now catched up a bit with normal day-job work, Pandora # work and emails and stuff, I'll try to work a bit more on HF6. # Here are my ideas, let me know what you think of them.
Somewhere along the line, somethign changed so now when a pnd is unmounted, it triggers an inotify event that causes a pnd autodiscovery from pndnotifyd; which is fine, it all works, but means after you finish running an app, your SD/CPU chug for a few seconds. A shame.
I'll do a short patch to libpnd to not trigger auto-discovery after an unmount, or whatever is needed to fix it; so a minor libpnd patch fior HF6.
--
If you want to roll 'links' or some other pure-texdt webbrowser right into the firmware (there are a few pnds around, not hard a port), then I can build a 'info' viewer right into minimenu so it can skip launching arora/midori to view the pnd internal docs.
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
As mentioned in my previous eMail, I'd love to include a more consumer-friendly charging.
A lot of new users are confused that the unit doesn't switch off when being charged, I even had one guy who sent it back for RMA (without asking if that's normal)...
Therefore, I'd love to improe that.
Basically, we can't switch off the unit while it's charging, but we could make a similar behaviour.
The ideal behaviour would be the following:
In case the unit is switched off and connected to AC: Start booting but don't boot into the full OS but show a screen that the unit is charging (along with percentage, approx. time left, etc.) Power LED should be switched off. Flick the switch to continue booting.
In case the unit is switched on, connected to AC and user shuts down: It should log out, display the charging screen and behave the same as above.
In case the unit is switched on, connected to AC and user reboots: It should reboot without showing the charging screen.
To accomplish that, the following needs to be checked:
* Can we find out if the unit has been powered on by the power switch OR by connecting the AC?
* How do we know if the user reboots or shuts down? I think reboot and shutdown trigger different runlevels, right?
* Someone needs to code the program that displays the battery level and charging info :)
* Where do we put the program into the boot process? Is it possible to interrupt the bootprocess and continue it later? If not, I think it should be possible to load it instead of XFCE4 or MiniMenu. That could be included in the X-Startup-Script. That's probably the best area to include it, as this script starts BEFORE a GUI is run and as soon as you quit the GUI, it continues, so both the startup and reboot / shutdown could be triggered here. And if the user flips the power switch, the program would just have to set the normal GUI to load and quit to continue booting.
What do you think?
I would take care of the implementation of that small charging program into the script and make sure shutdown, reboot and starting the normal GUI would work, but I'd need someone to code that GUI and help me how to find out how the unit has been booted up.
Also, how do you find out the runlevel you're in? :)
I've briefly glanced through that section of the spec and I believe it is theoretically possible to know how it was started (switch, power, or interrupt) but it needs i2c to communicate and I'm not sure how early in the boot process that would be available. I wonder if it could be handled in the uBoot, before it even gets to the kernel.
On Sun, May 1, 2011 at 6:58 AM, David Goldsmith wizard.stan@gmail.com wrote:
I've briefly glanced through that section of the spec and I believe it is theoretically possible to know how it was started (switch, power, or interrupt) but it needs i2c to communicate and I'm not sure how early in the boot process that would be available.
Are you sure about that? There is a register that tells about watchdog resets and thermal shutdown, but not much else..
I wonder if it could be handled in the uBoot, before it even gets to the kernel.
Yes it could, u-boot can access TWL but I'm not sure you can find the boot reason.
Section 5.4.2.4.1 talks about numbered starting events, and page 267 (bottom of section 5.5.1) describes the restart flow, with step 1 being "Check the starting origin". That was the "quick glance" I mentioned before. Looking deeper now, seems it should be possible, not directly but at least indirectly. It looks like it would require checking a few interrupts. I know it's possible to tell whether it was booted via AC power or alarm wakeup simply because those interrupts will be set and waiting assuming they were cleared last time they were triggered (which they should be, unless something is wrong); I don't know about a similar interrupt for hitting the power switch, but I think we can reasonably use process of elimination.
We could use a more custom approach to the run levels rather than the traditional
1 reserved 2 charging mode 3 command line mode 4 xwindows mode 5 reserved
The default runlevel would *always* be 2, this is a runlevel that would have almost nothing running, just enough to show the battery level and offer flicking the power switch to goto runlevel 4 (it would also show %age and eta)
runlevel 2 would automatically initiate runlevel 4 if either
a) charge is 100% (unless in runlevel2 user has requested shutdown on charge - as nothing of the users is running we could default to this unless the user changes it)
b) the ac supply is not present
runlevel 3 should only be entered if specifically requested by the user (via normal means) should be tested and working with the power management (ie not loose the console after blanking) - there are no end of uses for this run level for the "power" user
if the user reboots with a full battery but no AC power runlevel 2 should just automatically initiate runlevel 4 without the user being aware this is happening...
oh and if you want to know what runlevel you're in use the runlevel command! :D
I'd reckon that the runlevel 2 application should directly use the framebuffer, it should absolutely not be and xwindows application, it need only run in "low power" mode and should do screen blanking and completely shutdown the display subsystem then the lid is closed. I'd suggest a slow dim flashing that gradually becomes solid dim
I'd could probably be persuaded to volunteer to write this is no one else does...
On 01/05/11 02:23, Michael Mrozek wrote:
As mentioned in my previous eMail, I'd love to include a more consumer-friendly charging.
A lot of new users are confused that the unit doesn't switch off when being charged, I even had one guy who sent it back for RMA (without asking if that's normal)...
Therefore, I'd love to improe that.
Basically, we can't switch off the unit while it's charging, but we could make a similar behaviour.
The ideal behaviour would be the following:
In case the unit is switched off and connected to AC: Start booting but don't boot into the full OS but show a screen that the unit is charging (along with percentage, approx. time left, etc.) Power LED should be switched off. Flick the switch to continue booting.
In case the unit is switched on, connected to AC and user shuts down: It should log out, display the charging screen and behave the same as above.
In case the unit is switched on, connected to AC and user reboots: It should reboot without showing the charging screen.
To accomplish that, the following needs to be checked:
Can we find out if the unit has been powered on by the power switch OR by connecting the AC?
How do we know if the user reboots or shuts down? I think reboot and shutdown trigger different runlevels, right?
Someone needs to code the program that displays the battery level and charging info :)
Where do we put the program into the boot process? Is it possible to interrupt the bootprocess and continue it later? If not, I think it should be possible to load it instead of XFCE4 or MiniMenu. That could be included in the X-Startup-Script. That's probably the best area to include it, as this script starts BEFORE a GUI is run and as soon as you quit the GUI, it continues, so both the startup and reboot / shutdown could be triggered here. And if the user flips the power switch, the program would just have to set the normal GUI to load and quit to continue booting.
What do you think?
I would take care of the implementation of that small charging program into the script and make sure shutdown, reboot and starting the normal GUI would work, but I'd need someone to code that GUI and help me how to find out how the unit has been booted up.
Also, how do you find out the runlevel you're in? :)
On Wed, Apr 27, 2011 at 8:10 PM, aTc aTc@k-n-p.org wrote:
On 04/27/2011 06:09 PM, Grazvydas Ignotas wrote:
Mainline already has pandora support, not everything but I'd consider most things to be there: http://pandorawiki.org/Kernel_status
git.openpandora.org also has newer kernels with additional patches (none of them are feature complete though).
Which one of those is the most complete to be used as the next official kernel ?
.37/38/39 ?
Whatever works best when ED starts pushing for new firmware harder, with preference to newer stuff. Might even end up being .40+, who knows.
Am Thu, 28 Apr 2011 00:52:53 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
I need to push? :D
Well, John is approaching it slowly, so I'm only waiting for him :) I'm ready for testing new firmwares anytime now.
Had a lot of work lately, but slowly catched up with everything and want to start working on HF6 and / or on the new firmware :)
Hope you guys are doing well, I really missed all the IRC developing stuff... it's much more enjoyable than just building units :D
On Wed, Apr 27, 2011 at 8:10 PM, aTc aTc@k-n-p.org wrote:
On 04/27/2011 06:09 PM, Grazvydas Ignotas wrote:
Mainline already has pandora support, not everything but I'd consider most things to be there: http://pandorawiki.org/Kernel_status
git.openpandora.org also has newer kernels with additional patches (none of them are feature complete though).
Which one of those is the most complete to be used as the next official kernel ?
.37/38/39 ?
Whatever works best when ED starts pushing for new firmware harder, with preference to newer stuff. Might even end up being .40+, who knows. _______________________________________________ Firmware-dev mailing list Firmware-dev@openpandora.org http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
On 04/28/2011 12:19 AM, Michael Mrozek wrote:
Am Thu, 28 Apr 2011 00:52:53 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
I need to push? :D
Well, John is approaching it slowly, so I'm only waiting for him :) I'm ready for testing new firmwares anytime now.
Had a lot of work lately, but slowly catched up with everything and want to start working on HF6 and / or on the new firmware :)
If everyone is waiting for each other we'll never get anything done.
What we need is a not too ancient kernel that will support as much of the pandora hardware as possible, and fix/decide the points mentioned on the Kernel_status page on the wiki.
Then find some magical point in the latest OE git where everything actually worked, decide which pandora recipes are needed, fix them if necessary, throw in the kernel, and done is your new firmware.
After that it's just a matter of keeping things up to date so it doesn't get into the outdated state it is today again.
(and of course make full use of all the nice features OE has regarding SDKs and repos)
It all sounds so simple :)
On Thu, Apr 28, 2011 at 3:48 AM, aTc atc@k-n-p.org wrote:
On 04/28/2011 12:19 AM, Michael Mrozek wrote:
Am Thu, 28 Apr 2011 00:52:53 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
I need to push? :D
Well, John is approaching it slowly, so I'm only waiting for him :) I'm ready for testing new firmwares anytime now.
Had a lot of work lately, but slowly catched up with everything and want to start working on HF6 and / or on the new firmware :)
If everyone is waiting for each other we'll never get anything done.
What we need is a not too ancient kernel that will support as much of the pandora hardware as possible, and fix/decide the points mentioned on the Kernel_status page on the wiki.
Then start with pandora-37 git branch, it should be "good enough" and I don't think anyone has to wait for the kernel.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 28.04.2011 11:50, schrieb Grazvydas Ignotas:
On Thu, Apr 28, 2011 at 3:48 AM, aTc atc@k-n-p.org wrote:
On 04/28/2011 12:19 AM, Michael Mrozek wrote:
Am Thu, 28 Apr 2011 00:52:53 +0300 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
I need to push? :D
Well, John is approaching it slowly, so I'm only waiting for him :) I'm ready for testing new firmwares anytime now.
Had a lot of work lately, but slowly catched up with everything and want to start working on HF6 and / or on the new firmware :)
If everyone is waiting for each other we'll never get anything done.
What we need is a not too ancient kernel that will support as much of the pandora hardware as possible, and fix/decide the points mentioned on the Kernel_status page on the wiki.
Then start with pandora-37 git branch, it should be "good enough" and I don't think anyone has to wait for the kernel.
I don't know how severe the "power usage problems" that phoronix wrote about lately [1] are for non x86 based architectures (yes, on my laptop I got an increase in power usage of about 15% when going from .37 to .38!). Just because of those it might make sense to stay with .37 for the moment, at least if they also effect arm based systems. Cheers, Nils Kneuper aka Ivanovic
[1] http://www.phoronix.com/scan.php?page=article&item=linux_kernel_regress2...