I have added some photos of the alternate SIM/SD combo slots that we use in the GTA04. They would be nice but * they are too thick (3mm instead of 2mm) * we have no spare SD/MMC driver
So we have 3 samples and I would send 2 to the mechanical designers. And one to ED for looking at it.
IMHO we should move the upper key row a little down - because the mounting pins from the USB Hosts are very close. Especially the Power button in the middle.
BR, Nikolaus
Am Wed, 12 Feb 2014 21:25:13 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
nice, thanks :)
I have added some photos of the alternate SIM/SD combo slots that we use in the GTA04. They would be nice but
- they are too thick (3mm instead of 2mm)
Would that really be an issue? Don't forget: There will be a hole in the case where you open and close it. So the thickness of the case can be added here as well.
- we have no spare SD/MMC driver
That's a reason ;)
IMHO we should move the upper key row a little down - because the mounting pins from the USB Hosts are very close. Especially the Power button in the middle.
That shouldn't be a problem.
BTW: I found a company in Munich who offers silicon keymats. I'll have a meeting with them next Wednesday :)
Hi,
okay, since it seems a larger battery would help, I've now asked Fatih to check back with the case company what can be done here.
I guess with double the thickness (would be about 3mm thicker), we could get double the capacity. Maybe for 1,5mm, we could get 150% of the capacity?
We might also be able to increase the width a bit by maybe moving the Stylus into a bit more into the edge and using a bit more of that empty space.
I know there's the UMTS antenna there, but we still might get a few mm - maybe that helps.
With the PCBs with all important parts on being sent to the case company, I'll ask them if they can find a way to somehow increase the battery compartment as well.
As we all agree that a pluggable module as SoC would be great, we should also try to find out what thickness we would need for that soon.
I'd say if it adds about 1 - 2mm in thickness, it would probably be worth it, as the lid will probably be thinner than with the Pandora.
What do you think?
And even if the module is not pluggable, maybe a reflow-one (similar to the Jorjin module) could be designed, with a very thin PCB.
It still would limit the 8-layer PCB to a very small module size.
What do you guys think?
Okay, so it seems with Linux you can disable a CPU Core using:
echo 0 > /sys/devices/system/cpu/cpu1/online
According to /proc/cpustat and htop, only one core is active and being used by the Linux system.
The power consumption doesn't change though, so it seems the core isn't really disabled in the OMAP when doing this.
Seems like our current Power Management really is pretty simple, missing a few features.
Am 13.02.2014 um 02:37 schrieb Michael Mrozek:
Okay, so it seems with Linux you can disable a CPU Core using:
echo 0 > /sys/devices/system/cpu/cpu1/online
According to /proc/cpustat and htop, only one core is active and being used by the Linux system.
The power consumption doesn't change though, so it seems the core isn't really disabled in the OMAP when doing this.
Seems like our current Power Management really is pretty simple, missing a few features.
Well, we have a 3.8 kernel and at that time it is quite a wonder that the OMAP5 is already supported...
So my hope is that some 3.12 or later kernel could already be a little better.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Thu, Feb 13, 2014 at 3:37 AM, Michael Mrozek EvilDragon@openpandora.org wrote:
Okay, so it seems with Linux you can disable a CPU Core using:
echo 0 > /sys/devices/system/cpu/cpu1/online
According to /proc/cpustat and htop, only one core is active and being used by the Linux system.
The power consumption doesn't change though, so it seems the core isn't really disabled in the OMAP when doing this.
If CPU idle powersaving is working properly, power usage shouldn't actually change much compared to just idle.
Seems like our current Power Management really is pretty simple, missing a few features.
We don't know that.. It might be just SoC parts, not CPU powersaving that's not working, at least on OMAP3 there is whole CPU/MPU power domain which probably contains various support circuitry for the CPU. That part was missing powersaving in pandora's 2.6 kernel, and as you remember the battery drain was pretty bad.
Gražvydas
Am Thu, 13 Feb 2014 19:11:41 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
The power consumption doesn't change though, so it seems the core isn't really disabled in the OMAP when doing this.
If CPU idle powersaving is working properly, power usage shouldn't actually change much compared to just idle.
Oh, is CPU idle powersaving that good that a core doesn't need anything anymore when it's not being used?
Seems like our current Power Management really is pretty simple, missing a few features.
We don't know that.. It might be just SoC parts, not CPU powersaving that's not working, at least on OMAP3 there is whole CPU/MPU power domain which probably contains various support circuitry for the CPU. That part was missing powersaving in pandora's 2.6 kernel, and as you remember the battery drain was pretty bad.
True. Right now, we're on Kernel 3.8 No idea if that patch is even included: http://marc.info/?t=137407980100008&r=1&w=2
Fixes wrong voltage settings for OMAP5...
Is TI mostly working on 3.8 or 3.11/3.12 kernels?
Am 15.02.2014 um 17:19 schrieb Michael Mrozek:
Am Thu, 13 Feb 2014 19:11:41 +0200 hat Grazvydas Ignotas notasas@gmail.com geschrieben:
Hi,
The power consumption doesn't change though, so it seems the core isn't really disabled in the OMAP when doing this.
If CPU idle powersaving is working properly, power usage shouldn't actually change much compared to just idle.
Oh, is CPU idle powersaving that good that a core doesn't need anything anymore when it's not being used?
Seems like our current Power Management really is pretty simple, missing a few features.
We don't know that.. It might be just SoC parts, not CPU powersaving that's not working, at least on OMAP3 there is whole CPU/MPU power domain which probably contains various support circuitry for the CPU. That part was missing powersaving in pandora's 2.6 kernel, and as you remember the battery drain was pretty bad.
True. Right now, we're on Kernel 3.8 No idea if that patch is even included: http://marc.info/?t=137407980100008&r=1&w=2
Fixes wrong voltage settings for OMAP5...
Is TI mostly working on 3.8 or 3.11/3.12 kernels?
Well, we have a TI version of the 3.8 kernel which is much ahead of 3.12 mainline. So that might be a snipped of TI's efforts to get things fixed in mainline as well.
For the GTA04 for example we currently have about 100 deviations from mainline and try hard to get them in. Some are tried with 3.10 and have not yet appeared in 3.14... Quite a difficult business.
Nevertheless we should check if e.g. 3.12 or 3.14 mainline is a better basis for the future than continuing with a TI kernel.
For the moment for my hardware-bring-up the ti-3.8 kernel was the one with the most complete EVM support I could find. So it is always good to have it for reference :)
Maybe we should do the same for the Pyra as I did for the GTA04.
I took the 2.6.32 beagleboard kernel and modified it until I was 100% sure what the problems were and could make all hardware work. This did *not* optimize power.
In parallel Neil Brown had started with a 3.4 kernel and looked at bringing in more and more features incl. better power management. When he did come to 3.7 I ported some of the missing pieces and upgraded constantly so that we currently have a 3.12 kernel with 100% of the features. Unfortunately we lost some power management optimization. But that is planned to be fixed by 3.14 (where the device tree throws us back again...).
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 13.02.2014 um 02:11 schrieb Michael Mrozek:
Hi,
okay, since it seems a larger battery would help, I've now asked Fatih to check back with the case company what can be done here.
I guess with double the thickness (would be about 3mm thicker), we could get double the capacity. Maybe for 1,5mm, we could get 150% of the capacity?
Yes.
We might also be able to increase the width a bit by maybe moving the Stylus into a bit more into the edge and using a bit more of that empty space.
I know there's the UMTS antenna there, but we still might get a few mm
- maybe that helps.
I am not sure if you can get any arbitrary size of batteries. They usually come as cells which are bundled together. And the cells have the dimensions they have. So you can only get multiples of the basic cell size.
Or you find a cell supplier with slightly bigger cells. But I think there are not many different cell suppliers - just zillions of battery pack customizers.
With the PCBs with all important parts on being sent to the case company, I'll ask them if they can find a way to somehow increase the battery compartment as well.
As we all agree that a pluggable module as SoC would be great, we should also try to find out what thickness we would need for that soon.
Yes, I have some ideas that I need to draw and verify.
I'd say if it adds about 1 - 2mm in thickness, it would probably be worth it, as the lid will probably be thinner than with the Pandora.
We need to take care of battery connectors that can handle the bigger distance of the battery from the PCB.
What do you think?
And even if the module is not pluggable, maybe a reflow-one (similar to the Jorjin module) could be designed, with a very thin PCB.
Yes. This is one of the options. One may be a mix - a very thin PCB and some flat connectors to the left and right.
It still would limit the 8-layer PCB to a very small module size.
One issue might be that a really flat 8 layer PCB may be more expensive than making the whole board in 8 layers but 1mm. That is the next multidimensional topic to find an optimum between technology and cost and production :)
What do you guys think?
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 13.02.2014 um 01:43 schrieb Michael Mrozek:
Am Wed, 12 Feb 2014 21:25:13 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
nice, thanks :)
I have added some photos of the alternate SIM/SD combo slots that we use in the GTA04. They would be nice but
- they are too thick (3mm instead of 2mm)
Would that really be an issue? Don't forget: There will be a hole in the case where you open and close it.
Ah, you may be right. It basically depends on the thickness of the plastics above the other 2mm components. Which are the battery connector, the UMTS module and the SD readers.
So we have this stacking (seen from top)
Battery Battery-PCB with gold contacts Battery bay floor thickness (plastics) Components PCB
The critical thing is that the battery connector must reliably connect the battery... If we move the battery upwards, we might need one with more distance of the spring contacts.
So the thickness of the case can be added here as well.
- we have no spare SD/MMC driver
That's a reason ;)
Hm. What about adding it anyways (for the case design) and leave the MicroSD side unconnected. Or connect it to 6 pins of the B2B connectors for the CPU module. Then, a future CPU could use them and the case is prepared.
IMHO we should move the upper key row a little down - because the mounting pins from the USB Hosts are very close. Especially the Power button in the middle.
That shouldn't be a problem.
BTW: I found a company in Munich who offers silicon keymats. I'll have a meeting with them next Wednesday :)
Ah, I remember that I found one some years ago in Gilching? Germering? But it may be a different one. Focus of companies change over the years.
BR, Nikolaus