Hi,
I've collected all the mainboards I've got together and want to test which ones work (and what doesn't work) so I can prepare prototypes and send them out to devs.
I plan on using our Pyra OS rootfs, as that already has a setup to automatically run scripts on bootup, so I can write the testing scripts (so we can test all hardware features easily and comfortably).
However, as far as I know, the UBoot / Kernel used in our Pyra OS Setup only works if a battery is connected - which is horribly unconvenient if I just want to test bare boards.
Can someone give me a U-Boot which works fine without battery?
And which kernel is the best to use (where can I grab a binary)? I don't care about aufs at the moment, as that's not needed for the testing scripts.
Thanks in advance!
On 06/23/2018 06:21 PM, Michael Mrozek wrote:
Hi,
I've collected all the mainboards I've got together and want to test which ones work (and what doesn't work) so I can prepare prototypes and send them out to devs.
I plan on using our Pyra OS rootfs, as that already has a setup to automatically run scripts on bootup, so I can write the testing scripts (so we can test all hardware features easily and comfortably).
However, as far as I know, the UBoot / Kernel used in our Pyra OS Setup only works if a battery is connected - which is horribly unconvenient if I just want to test bare boards.
Can someone give me a U-Boot which works fine without battery?
I've updated the one in http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz to the latest gta uboot version (with the extlinux config patched in) As usual, it works on mine (booting fine without a battery), no idea if it works on the 4gb versions.
And which kernel is the best to use (where can I grab a binary)? I don't care about aufs at the moment, as that's not needed for th > testing scripts.
All kernels I've built are on the pyra repo, if you do an "apt-cache search linux-image" you'll get the full list of available kernels. The ones ending in -pyra have the aufs patches and a few config changes, the -letux ones are straight compiles from the letux repo. There are far more recent ones than the default kernel I use for the image on there, but they all have their problems (like the fbturbo driver failing on 4.16+ kernels, or not having a working tiler rotation)
On Sa, 2018-06-23 at 22:59 +0200, aTc wrote:
Hi,
thanks, I just installed it and tried it.
Unfortunately, without a battery, it still behaves the same like last time I tried (about a year ago):
The keyboard LEDs flash up brightly for a split second, and that's it.
On serial out, I get nothing except for: U-Boot SPL 2016.11-01334-g2b143578a0-dirty (Jun 23 2018 - 22:23:08) OMAP5432-GP ES2.0
This happens both with 2GB and 4GB RAM boards.
If your PCB boots (you've got one of the very mainboards, AFAIR), then something clearly is different.
@hns: Can you boot the latest board revision that has been produced without a battery?
On 06/23/2018 06:21 PM, Michael Mrozek wrote:
Hi,
I've collected all the mainboards I've got together and want to test which ones work (and what doesn't work) so I can prepare prototypes and send them out to devs.
I plan on using our Pyra OS rootfs, as that already has a setup to automatically run scripts on bootup, so I can write the testing scripts (so we can test all hardware features easily and comfortably).
However, as far as I know, the UBoot / Kernel used in our Pyra OS Setup only works if a battery is connected - which is horribly unconvenient if I just want to test bare boards.
Can someone give me a U-Boot which works fine without battery?
I've updated the one in http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz to the latest gta uboot version (with the extlinux config patched in) As usual, it works on mine (booting fine without a battery), no idea if it works on the 4gb versions.
And which kernel is the best to use (where can I grab a binary)? I don't care about aufs at the moment, as that's not needed for th
testing scripts.
All kernels I've built are on the pyra repo, if you do an "apt-cache search linux-image" you'll get the full list of available kernels. The ones ending in -pyra have the aufs patches and a few config changes, the -letux ones are straight compiles from the letux repo. There are far more recent ones than the default kernel I use for the image on there, but they all have their problems (like the fbturbo driver failing on 4.16+ kernels, or not having a working tiler rotation)
Hi,
Am 24.06.2018 um 13:20 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Sa, 2018-06-23 at 22:59 +0200, aTc wrote:
Hi,
thanks, I just installed it and tried it.
Unfortunately, without a battery, it still behaves the same like last time I tried (about a year ago):
The keyboard LEDs flash up brightly for a split second, and that's it.
On serial out, I get nothing except for: U-Boot SPL 2016.11-01334-g2b143578a0-dirty (Jun 23 2018 - 22:23:08) OMAP5432-GP ES2.0
This happens both with 2GB and 4GB RAM boards.
If your PCB boots (you've got one of the very mainboards, AFAIR), then something clearly is different.
@hns: Can you boot the latest board revision that has been produced without a battery?
No. None of the boards I have can boot w/o battery, at least with my software setup.
IMHO the problem is that MLO (SPL) doesn't enable high power in the bq24297. This is done in U-Boot.
If I remember correctly, some very early boards without any keyboard backlight were able to boot without battery. So it might help to turn off the keyboard backlight (gpio8_230) in MLO (and maybe restart in U-Boot).
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51
#if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
On the other hand the keyboard backlight is the only visual indication of "MLO is starting" if you have no console message for whatever reasons.
Which helps to distinguish between an SD card with broken MLO and starting MLO. Well, if you boot from eMMC and the console works fine, this isn't important.
BR, Nikolaus
On 06/23/2018 06:21 PM, Michael Mrozek wrote:
Hi,
I've collected all the mainboards I've got together and want to test which ones work (and what doesn't work) so I can prepare prototypes and send them out to devs.
I plan on using our Pyra OS rootfs, as that already has a setup to automatically run scripts on bootup, so I can write the testing scripts (so we can test all hardware features easily and comfortably).
However, as far as I know, the UBoot / Kernel used in our Pyra OS Setup only works if a battery is connected - which is horribly unconvenient if I just want to test bare boards.
Can someone give me a U-Boot which works fine without battery?
I've updated the one in http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz to the latest gta uboot version (with the extlinux config patched in) As usual, it works on mine (booting fine without a battery), no idea if it works on the 4gb versions.
And which kernel is the best to use (where can I grab a binary)? I don't care about aufs at the moment, as that's not needed for th
testing scripts.
All kernels I've built are on the pyra repo, if you do an "apt-cache search linux-image" you'll get the full list of available kernels. The ones ending in -pyra have the aufs patches and a few config changes, the -letux ones are straight compiles from the letux repo. There are far more recent ones than the default kernel I use for the image on there, but they all have their problems (like the fbturbo driver failing on 4.16+ kernels, or not having a working tiler rotation)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On So, 2018-06-24 at 13:50 +0200, H. Nikolaus Schaller wrote:
Hi,
@hns: Can you boot the latest board revision that has been produced without a battery?
No. None of the boards I have can boot w/o battery, at least with my software setup. IMHO the problem is that MLO (SPL) doesn't enable high power in the bq24297. This is done in U-Boot. If I remember correctly, some very early boards without any keyboard backlight were able to boot without battery. So it might help to turn off the keyboard backlight (gpio8_230) in MLO (and maybe restart in U-Boot).
That might explain things, especially the reason it switches off as soon as they go to full brightness.
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51
#if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
Or maybe change the brightness of the backlight to lowest?
On 06/23/2018 06:21 PM, Michael Mrozek wrote:
Hi,
I've collected all the mainboards I've got together and want to test which ones work (and what doesn't work) so I can prepare prototypes and send them out to devs.
I plan on using our Pyra OS rootfs, as that already has a setup to automatically run scripts on bootup, so I can write the testing scripts (so we can test all hardware features easily and comfortably).
However, as far as I know, the UBoot / Kernel used in our Pyra OS Setup only works if a battery is connected - which is horribly unconvenient if I just want to test bare boards.
Can someone give me a U-Boot which works fine without battery?
I've updated the one in http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz to the latest gta uboot version (with the extlinux config patched in) As usual, it works on mine (booting fine without a battery), no idea if it works on the 4gb versions.
And which kernel is the best to use (where can I grab a binary)? I don't care about aufs at the moment, as that's not needed for th
testing scripts.
All kernels I've built are on the pyra repo, if you do an "apt- cache search linux-image" you'll get the full list of available kernels. The ones ending in -pyra have the aufs patches and a few config changes, the -letux ones are straight compiles from the letux repo. There are far more recent ones than the default kernel I use for the image on there, but they all have their problems (like the fbturbo driver failing on 4.16+ kernels, or not having a working tiler rotation)
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Sun, Jun 24, 2018 at 4:37 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
On So, 2018-06-24 at 13:50 +0200, H. Nikolaus Schaller wrote:
Hi,
@hns: Can you boot the latest board revision that has been produced without a battery?
No. None of the boards I have can boot w/o battery, at least with my software setup. IMHO the problem is that MLO (SPL) doesn't enable high power in the bq24297. This is done in U-Boot. If I remember correctly, some very early boards without any keyboard backlight were able to boot without battery. So it might help to turn off the keyboard backlight (gpio8_230) in MLO (and maybe restart in U-Boot).
That might explain things, especially the reason it switches off as soon as they go to full brightness.
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51
#if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
Or maybe change the brightness of the backlight to lowest?
Needs working i2c (I guess?) which is not working from MLO.
Gražvydas
On So, 2018-06-24 at 17:01 +0300, Grazvydas Ignotas wrote:
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51 #if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm. Could the CPU power usage be lowered (keep it down at 500MHz with 1 CPU core only, etc.) and upped after the limit has been raised?
Or is there anything else we could do to lower the power usage on startup - I mean, even limited, we've got 5V * 0.5A which is 2.5W... and we only need to keep it lower than that until the limit has been reached.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
I guess adding i2c to MLO is no simple task...
Hi,
ED: your suggestion might be good, but hard to implement.
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
Gražvydas
On Sun, Jun 24, 2018 at 5:46 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
On So, 2018-06-24 at 17:01 +0300, Grazvydas Ignotas wrote:
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51 #if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm. Could the CPU power usage be lowered (keep it down at 500MHz with 1 CPU core only, etc.) and upped after the limit has been raised?
Or is there anything else we could do to lower the power usage on startup - I mean, even limited, we've got 5V * 0.5A which is 2.5W... and we only need to keep it lower than that until the limit has been reached.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
I guess adding i2c to MLO is no simple task...
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
On So, 2018-06-24 at 17:57 +0300, Grazvydas Ignotas wrote:
Hi,
thanks a lot! That's really helpful - I only have 2GB RAM boards here atm, but I can get a 4GB one from Nikolaus.
Unless you could also compile one for 2GB RAM boards, then I could start right away (don't know how complicated that is).
Well, it might be hard to implement, but it shows that it's possible... which is a good thing. A limitation in hardware would be worse.
ED: your suggestion might be good, but hard to implement. Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
Gražvydas
On Sun, Jun 24, 2018 at 5:46 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
On So, 2018-06-24 at 17:01 +0300, Grazvydas Ignotas wrote:
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51 #if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm. Could the CPU power usage be lowered (keep it down at 500MHz with 1 CPU core only, etc.) and upped after the limit has been raised?
Or is there anything else we could do to lower the power usage on startup - I mean, even limited, we've got 5V * 0.5A which is 2.5W... and we only need to keep it lower than that until the limit has been reached.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
I guess adding i2c to MLO is no simple task...
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Hi, fine to hear that it is almost solved.
Am 24.06.2018 um 18:19 schrieb Michael Mrozek EvilDragon@openpandora.org:
On So, 2018-06-24 at 17:57 +0300, Grazvydas Ignotas wrote:
Hi,
thanks a lot! That's really helpful - I only have 2GB RAM boards here atm, but I can get a 4GB one from Nikolaus.
Unless you could also compile one for 2GB RAM boards, then I could start right away (don't know how complicated that is).
Well, it might be hard to implement, but it shows that it's possible... which is a good thing. A limitation in hardware would be worse.
ED: your suggestion might be good, but hard to implement.
That is the reason why I didn't do it :)
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
Yes,that is ok. Since booting without battery isn't the highest priority for non-developer users, we (Patrick) should work on upstreaming the easier things first.
BR, Nikolaus
Gražvydas
On Sun, Jun 24, 2018 at 5:46 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
On So, 2018-06-24 at 17:01 +0300, Grazvydas Ignotas wrote:
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51 #if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm. Could the CPU power usage be lowered (keep it down at 500MHz with 1 CPU core only, etc.) and upped after the limit has been raised?
Or is there anything else we could do to lower the power usage on startup - I mean, even limited, we've got 5V * 0.5A which is 2.5W... and we only need to keep it lower than that until the limit has been reached.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
I guess adding i2c to MLO is no simple task...
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
On 06/24/2018 06:19 PM, Michael Mrozek wrote:
On So, 2018-06-24 at 17:57 +0300, Grazvydas Ignotas wrote:
Hi,
thanks a lot! That's really helpful - I only have 2GB RAM boards here atm, but I can get a 4GB one from Nikolaus.
Unless you could also compile one for 2GB RAM boards, then I could start right away (don't know how complicated that is).
I've compiled both of them, and uploaded them in a new version of http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz
2gb version appears to work, keyboard backlight stays off during uboot, and even boots after having the usb lead unplugged for a minute or so :)
On So, 2018-06-24 at 19:37 +0200, aTc wrote:
Thanks works fine here, this will be really helpful testing all the PCBs (especially the next ones GC will produce).
On 06/24/2018 06:19 PM, Michael Mrozek wrote:
On So, 2018-06-24 at 17:57 +0300, Grazvydas Ignotas wrote:
Hi,
thanks a lot! That's really helpful - I only have 2GB RAM boards here atm, but I can get a 4GB one from Nikolaus.
Unless you could also compile one for 2GB RAM boards, then I could start right away (don't know how complicated that is).
I've compiled both of them, and uploaded them in a new version of http://packages.pyra-handheld.com/images/stretch/pyra-install.tgz
2gb version appears to work, keyboard backlight stays off during uboot, and even boots after having the usb lead unplugged for a minute or so :)
On 24.06.2018 16:57, Grazvydas Ignotas wrote:
Hi,
ED: your suggestion might be good, but hard to implement.
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...).
Did you tried to call bq24297_setup() from board_early_init_f()?
Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
Gražvydas
Patrick
Hi Notaz,
Am 24.06.2018 um 16:57 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
ED: your suggestion might be good, but hard to implement.
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
I have cherry-picked some, but there are also interesting patches which lack a Signed-off line in the commit message. This makes it impossible to work on them or at some time submit upstream (e.g. by Patrick).
Most interesting is "LC15: mask some irqs so that connecting USB doesn't power on"
How can we get them signed-off by the author (sometimes you sometimes Matthijs)?
BR, Nikolaus
Gražvydas
On Sun, Jun 24, 2018 at 5:46 PM, Michael Mrozek EvilDragon@openpandora.org wrote:
On So, 2018-06-24 at 17:01 +0300, Grazvydas Ignotas wrote:
So try to change board/pandora/pyra+lc15/pyra+lc15.c line 51 #if defined(CONFIG_SPL_BUILD) {TIMER8_PWM_EVT, (PTD | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled low */ #else {TIMER8_PWM_EVT, (PTU | IEN | M6)}, /* GPIO8_230: keyboard backlight - pulled high */ #endif
I've tried this, now it loads u-boot successfully but dies before it reaches the point where it reprograms bq24297, just after printing "DRAM: 4 GiB". It seems to be dying in initr_malloc(), no idea why. A wild guess is that code in malloc init utilizes more CPU pipelines and RAM (as it's clearing memory) which uses more power, and that goes over the current limit.
Hm. Could the CPU power usage be lowered (keep it down at 500MHz with 1 CPU core only, etc.) and upped after the limit has been raised?
Or is there anything else we could do to lower the power usage on startup - I mean, even limited, we've got 5V * 0.5A which is 2.5W... and we only need to keep it lower than that until the limit has been reached.
Hm, it it hard to enable high power for the bq24297 in MLO? I mean, if we recompile the MLO anyways, why switch off the backlight instead of enabling high power mode (if that fixes it).
I've tried this too and it doesn't work (i2c errors), probably the needed i2c bus is not properly initialized yet in MLO.
I guess adding i2c to MLO is no simple task...
-- Greetings,
Michael Mrozek
OpenPandora GmbH CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
On Mon, Jul 23, 2018 at 11:22 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Notaz,
Am 24.06.2018 um 16:57 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
ED: your suggestion might be good, but hard to implement.
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
I have cherry-picked some, but there are also interesting patches which lack a Signed-off line in the commit message. This makes it impossible to work on them or at some time submit upstream (e.g. by Patrick).
Most interesting is "LC15: mask some irqs so that connecting USB doesn't power on"
How can we get them signed-off by the author (sometimes you sometimes Matthijs)?
I henceforth explicitly give permission for anyone to add Signed-off-by: Grazvydas Ignotas notasas@gmail.com to any patch authored by me in https://dev.pyra-handheld.com/notaz/pyra-u-boot
I hope that's enough because I don't want to be rebasing that git. Obviously I can't do the same for Matthijs' stuff.
Gražvydas
Hi,
Am 24.07.2018 um 11:09 schrieb Grazvydas Ignotas notasas@gmail.com:
On Mon, Jul 23, 2018 at 11:22 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Notaz,
Am 24.06.2018 um 16:57 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
ED: your suggestion might be good, but hard to implement.
Ok got it to work with some horrible hacks to reprogram bq24297 earlier (good luck to anyone trying to mainline that...). Binaries (for 4GB RAM, includes Tony's fixes): http://notaz.gp2x.de/misc/pyra/u-boot/ Source: https://dev.pyra-handheld.com/notaz/pyra-u-boot (not posting patches to the list unless requested to, as they're hacks, and that git already has more of such pyra-only patches anyway).
I have cherry-picked some, but there are also interesting patches which lack a Signed-off line in the commit message. This makes it impossible to work on them or at some time submit upstream (e.g. by Patrick).
Most interesting is "LC15: mask some irqs so that connecting USB doesn't power on"
How can we get them signed-off by the author (sometimes you sometimes Matthijs)?
I henceforth explicitly give permission for anyone to add Signed-off-by: Grazvydas Ignotas notasas@gmail.com to any patch authored by me in https://dev.pyra-handheld.com/notaz/pyra-u-boot
Thanks!
I hope that's enough because I don't want to be rebasing that git.
No problem, I can simply edit after cherry-picking.
Obviously I can't do the same for Matthijs' stuff.
That is something Matthijs should please do or at least comment on.
BR and thanks, Nikolaus
okay this is probably a silly question, but hand we not hit the bare metal at uboot, just specifically to switch the power management to 11 (out of 10)?
On 06/24/2018 01:20 PM, Michael Mrozek wrote:
On Sa, 2018-06-23 at 22:59 +0200, aTc wrote:
Hi,
thanks, I just installed it and tried it.
Unfortunately, without a battery, it still behaves the same like last time I tried (about a year ago):
The keyboard LEDs flash up brightly for a split second, and that's it.
On serial out, I get nothing except for: U-Boot SPL 2016.11-01334-g2b143578a0-dirty (Jun 23 2018 - 22:23:08) OMAP5432-GP ES2.0
This happens both with 2GB and 4GB RAM boards.
If your PCB boots (you've got one of the very mainboards, AFAIR), then something clearly is different.
What's probably different is that I tried booting it without a battery after having run it for a few hours, and didn't unplug the usb cable. The kernel probably set up the charging stuff in a way that made it work. When trying to boot it from a cold start, it failed in the same way as yours.
On So, 2018-06-24 at 16:58 +0200, aTc wrote:
If your PCB boots (you've got one of the very mainboards, AFAIR), then something clearly is different.
What's probably different is that I tried booting it without a battery after having run it for a few hours, and didn't unplug the usb cable. The kernel probably set up the charging stuff in a way that made it work. When trying to boot it from a cold start, it failed in the same way as yours.
Ah, right. That's normal then. AFAIK, once the limit has been raised, it stays like that until you disconnect it from all power sources for longer than around 30 seconds or so.
That's a normal behaviour then.
-
aTc -
Grazvydas Ignotas -
H. Nikolaus Schaller -
Michael Mrozek -
Mr C Camacho -
patrick