If I shut down my Android A20-4GB using the UI (press power button for ~2 secs, select "Power off", untick "Quick Boot Mode next time", click "OK") and disconnect the power (12V into the barrel connector), then when I reconnect the power the board often doesn't boot straight away - I have to press the power button for 2 seconds to get it to go. I get the same problem if I shut down the tablet using "reboot -p" from the command shell.
I don't get consistent behaviour - sometimes the board boots when power is applied, sometimes it doesn't. I want to use the A20 for an unattended embedded application, so is there a way to guarantee consistently that it does boot on power-up?
Thanks
Kevin
PS I've seen the bit in the A20 user manual about Android entering battery save mode if "Quick Boot" isn't selected. Is that likely to be the problem, as I don't have a battery connected.
Also, I have tried setting "Quick Boot next time", but when I've done that the A20 often comes up with Airplane mode switched on.
This is something I am working on too but I will have the battery and so far there is no consistency either.
As you are on external power only, have you checked to see what SCRIPT.BIN is set for in the [target] settings.
At the end after the clock and voltage settings there is a power_start setting. On my board this was set for 0 so this stopped it powering up on applying DC power.
[target]
boot_clock = 912
dcdc2_vol = 1400
dcdc3_vol = 1250
ldo2_vol = 3000
ldo3_vol = 2800
ldo4_vol = 2800
power_start = 0
You'll need to mount the nanda partition to get access to and change this. You'll also need something to convert the binary file to fex format.
You'll need to get a script to bin and bin to script tool. Sunxi tools have these.
I use a read.bat file with the following to mount the partition and then pull down the file with adb (I assume you have the Android development system on your PC?)
adb shell mkdir /mnt/sdcard/kernel
adb shell mount -t vfat /dev/block/nanda /mnt/sdcard/kernel
adb pull /mnt/sdcard/kernel/script.bin
After I convert and edit and convert back, I use this write.bat file to push it back to the device.
adb push script.bin /mnt/sdcard/kernel
adb shell sync
adb shell umount /mnt/sdcard/kernel
Might be worth a test to see if this works for you.
Post back and let me know if this idea works.
That's fantastic! Thanks for the prompt response. I've had a hack with script.bin files before, so I know about remounting the nanda partition, and I've built fex2bin and bin2fex already. I'll give it a try and let you know how I get on.
I tried changing power_start as you suggested but it didn't help - I still have to press the power button after plugging in the DC power supply.
Before I made the change to script.bin I noticed that the A20 does boot immediately on restoration of DC power if I do a forced shutdown by pressing and holding the power button, or by unceremoniously yanking out the power cable while the board is running (yep - I know this can corrupt the filesystem!)
It must be in the Android code and if I can get the damn source to compile and run, I will track this down.
I too want to use this in a remote location and need it to auto power up. I am currently experimenting with using either a small microcontroller to control the power button on the board or doing this in software.
I have battery backup and after allowing the battery to deplete down to zero the system auto powers off when the battery gets too low. It won't normally happen in real life as I will monitor for this and in the event of lost power, I will send a message to the server to indicate this, wait for a preset time and if still no power, I will tell the system to power down.
The issue is that on re-applying the power is that it does not switch back on. Well, it does sort of as the 3V3 and 5V rails are present but Android is in a dormant state. I am working on code to see if I can detect this as I have an application that gets started on boot up and if this detects the system is off, it powers it back up using wake locks.
That might be an idea for your application? Are you developing the software for the system?
Have a look at the android.permission.RECEIVE_BOOT_COMPLETED permission. When this fires, you can tell it to run and intent that can check for power off? Not sure yet if this works. It's something I am working on.
I think that, especially because you have a battery in play (which I want too!) that you'll have to do something with a microcontroller to "press" the power button. We currently have 2 previous projects based on android tablets, and in each case we've had to do something with a microcontroller that closes a relay for a couple of seconds on detection of the external DC power source in order to "press the button". I was hoping to avoid it this time :-(
How are you planning to incorporate the microcontroller? Will you have to remove the POWER button from the A20 board, or are there some handy pins that you can connect to so you avoid taking a soldering iron to it?
There is no external connection :( so it will have to be soldered. It's the only soldering needed and just one wire as I already have a motherboard that this sits on top of to handle the analog and digital IO on.
If the test I do next week (away tomorrow for a business trip) works with the BOOTCOMPLETE code, I'll let you know what I did to make it work.
Am I right in saying the one-wire solder is to connect the relay to the R70 side of PWR_BUT - and connect the other side of the relay to GND elsewhere on your addon board?
@dave-at-axon have you seen this ... https://www.olimex.com/forum/index.php?topic=1091.msg6448
which mentions this ... https://www.olimex.com/forum/index.php?topic=868.msg5585#msg5585
The latter post is talking about 4.1.1 on A13, and says
Quote
In fex file when power_start is 0 to start android you have to hold power button. Also when you try to reboot the system it instead shuts down. And when battery is plugged adapter power doesn't start android.
But when power_start option is 1 reboot works ok and also it doesn't matter if there is battery, adapter power always start android.
So power_start = 1 reportedly works on 4.1.1, and I've seen reports saying it works on 4.0.3 too. Maybe you have to have it set before doing the shutdown in order for it to take effect on powerup.
Are you using an A20 with NAND or SD card? I have a sneaking suspicion that script.bin works differently on NAND devices, though I haven't found anyone to confirm that suspicion one way of the other. If you are using NAND, why not try setting up an SD card instead? I'll have a go later.
Thanks for the information.
I have tried this and with 4.2 is still won't boot up using NAND.
I'll try the SD idea later today and see if that works.
I did some testing last night with my A20 with NAND...
I disconnect the battery, pressed the PWR_BUT for a couple is seconds, selected Shutdown from the popup menu and set Quick Boot Mode before OKaying the shutdown, then removed DC power when shutdown had completed. When I reapplied DC power the A20 consistently booted fully straight away as far as the lock screen. However, more often than not Airplane Mode was enabled, and on a couple of occasions so was Silent Mode.
With Quick Boot Mode disabled on powerdown, and no battery connected, the same powerdown/restart sequence always left the A20 needing the power button to be pressed to complete boot.
With the battery connected and Quick Boot Mode enabled, the same shutdown/restart sequence consistently left the A20 booting as far as "charging" - a short press of the power button brought up the green battery icon and a long press caused boot up to complete.
The setting of power_start in script.bin had no effect on any of this behaviour.
I've been looking at the script.bin issue. I am convinced that the system only ever reads this on the first boot after you re-flash the device and then creates another file to use to boot the system with. This would certainly fit the case of no changes to the script.bin file making any difference to the system.
I am going through the source now to find out where script.bin is processed.
That sounds like a way forward if it's true - though it sounds like a bit of a chore - we'd have to chop a modified script.bin into the IMG file prior to flashing. Or do it properly and build our own IMG file from the SDK. Less painful than soldering a relay to a few hundred boards though!
Have you discovered http://linux-sunxi.org/A31_EVB - it's a well-documented script.fex for the A31 - interestingly it puts power_start in the [pmu_para] section rather than [target].
I tried that last night and it made no difference :-)
Quote from: kbro on February 10, 2014, 01:24:45 PM
Less painful than soldering a relay to a few hundred boards though!
You don't need a relay. A simple NPN transistor and 1 resistor on the base will do the job. Much cheaper than a relay. I'll put a second resistor on the base though to ensure that the transistor is off as the processor powers up.
Doing a little testing tonight and I see on the serial output the following when I plug in power whilst on battery. I had done a shutdown but no quick boot. In fact it's the same for quick boot.
power_start=0x00000000
power trigger
power start detect
power enter detect
.
.
.
enter standby
That first entry is curious. This indicates that the entry in the script.bin is not being read as we have set to 1.
The code that reads this is in lichee/linux-3.4/drivers/power/axp_power/axp-mfd.c at line 345
This would confirm our suspicions that the change to the script.bin is not being accepted. :(
Last night I also noticed that the board would fully boot on DC power up if I left the USB-OTG cable to my Macbook plugged in after the power down.
I thought I'd cracked the problem until is spotted that :-)
I'm glad I am already bald headed !! ;D
Digging through the code I found where it reads the power_start flag and displays this on the debug output.
line 165 of this file
lichee/boot/boot1/appps/Boot_Android/Board/fel_detect/fel_detect.c
As you can see, this is where it displays the value found in the script file. This is the line of code that reads this.
if(wBoot_script_parser_fetch("target", "power_start", &power_start, 1))
I also noticed that the script.bin I put in the nanda partition is not being read as the min and max recovery_key values are 40 and 4 as per the original image. My script.bin is 44 and 4
There has to be another copy of the script.bin that we can't see that is causing this.
You want the good news?
power_start=1 does work.
I decided to try my kernel and Android build again, even though it crashes on starting Android it does go into power down with the battery connected by holding down the power button.
With power-start=1 in my script.bin it does the full boot up from DC application even with the battery connected. :)
So this means that if we can somehow get the pesky board to take our modified script.bin, it will work the way we want it to.
Time for bed and a fresh start tomorrow.
Dave...
I've been testing with an SD card image. There's good news and bad...
The good news is that the script.bin file (which is on /dev/block/mmcblk0p2) already has power_start = 1 and this has the desired effect on powerup booting with one exception - if you power down with "Quick Boot Mode next time" enabled and a battery in place, then when you apply DC power the board stops at Charging and you have to press the power button to get it to complete. All other combinations of with/without battery and Quick Mode yes/no or "reboot -p" result in the A20 booting fully when DC power is re-applied.
The bad news is that changing script.bin in the SD card has no effect - repeating the test with power_start = 0 gives identical results.
So to my mind, the SD version suffers from the same problem as the NAND version - It doesn't read the script.bin after the first boot.
But at least we know we're on the right track with power_start.
Sorry, Dave, didn't notice your post until I'd done mine. So we're in agreement that power_start = 1 will have the desired effect, we just need to know how to get a modified script.bin to have an effect!
We sure do.
It's all very strange. I mounted the nanda partition last night, pulled the file, made changes then rebooted the board. After it re-started I could read back the modified script.bin file so it appears to be writing the modified version but the boot sequence shows that it is not reading it as power_start is still zero.
I even have changes to add UART3 and UART4 and these are not working either.
I got an email from Allwinner before so I am going to take the chance and fire off a new one to them today about this and see if we can get some ideas why this is not working.
Here's a (daft) idea...
1. Flash a clean NAND image but do NOT reboot.
2. Boot from SD card instead.
3. Use the SD-booted image to mount the NANDA partition and tweak script.bin - therefore doing it BEOFRE the first boot
4. Boot from NAND
This ought to show whether script.bin is used first-time-only.
You could repeat the operation the other way round to modify a never-booted SD card.
I'll give it a try later today if you haven't beaten me to it - I have other stuff I'm supposed to be doing :-)
The daft idea didn't work. I guess the SD image doesn't have the necessary stuff to define the /dev/block/nandX partitions. I only see /dev/block/nanda, and attempts to mount that result in "invalid argument". Looks like I need to start looking at how to build my own Android image.
Good day. I even posted on the sunxi Google group and so far have had no replies to my posting.
I've been trying to get a build to work for days now. I can build no problem (I'll document it in the next couple of days what I found) but none of the source will run on the machine. It crashes with a segment fault in the surfaceflinger.
I'd be interested to see how you get on with building the source. Just follow the information at the bottom of this page (I assume you have a Linux machine to build this on and if not, I build on a virtual machine under Windows 7 and it works fine)
https://www.olimex.com/wiki/A20-OLinuXino-MICRO
Once you have the make -j4 completed, you need to run PACK but this will fail because it can't find the board and the tar files don't include these file.
Go into lichee/tools/pack/chips/sun7i/configs/android and create a directory called olinuxino-a20
Then download this tar and copy the sys_config.fex and sys_partition.fex into that directory.
http://www.axoninstruments.biz/download/olinuxino-a20.tar.gz
pack should now run and you will have the img to put on the device. It is configured for NAND but easy to change to the SD by changing the setting in the sys_config.fex file to storage_type=1 and run pack again.
That's the settings I have been trying to use with the 7" LCD and I'd be interested to see how you get on with this and if it will run for you.
So far Olimex have not been able to provide the exact fex files for the source. Not sure why they are missing either. :)
Right, I've posted about the build process in my new blog! :)
http://axonjakarta.wordpress.com/olimex-a20-android-building/
I'll see if I can get Olimex to add this to the A20 wiki page.
OK.I've switched to the SDCARD version for now as it actually has the power_start=1 setting and it is working as expected. Applying power with battery plugged in boots up the board as long as you don't set the quick boot option.
I let the battery run down until it switched itself off and then applied DC power again and it rebooted.
This is exactly as we need it, only we need it to be working from NAND. :(
This I can work with in the mean time but I really do want to have a custom build so I can leave out stuff I don't need and set some things to default.
One thing I did notice with the SD image is that the brightness control is now in the correct direction. On the NAND version, max brightness was with the slider all the way to left. With SD it's to the normal right.
*cries*
This is very weird. I unpacked the image file using imgRePacker and I changed the sys_config.fex file to power_start=1
I then used MagicISO to open the bootloader.fex.iso file and edit the script.bin
I then repacked the img (which was now a different size) and flashed to nand... Nothing, still same power_start=0 :'(
I am running out of time with this and unless someone can get me going with the source build, I am for now going to run with the SDCARD option, albeit with a slightly slower system.
Good day.
I thought that you might like to know that I got it to work now and after some work with on the Kernel config and the Android configuration, I now have auto boot and touch working.
Olimex claim that the source files on the website are the ones used to build the image but I can tell you from all the work I had to do to add touch and the calibration alone that this is not the case. It seems to be configured for capacitive panel (I've got one coming so I will be migrating to this soon myself)
I've also now added the Mms/SMS code to my system and I can send SMS. I am still trying to get SMS receive to work but nothing yet but I am pleased with the progress so far this week. I've learned a lot about how Android is put together! :)
It's quite a lot of work to do this but I will try and get around to documenting this on my blog.
If you are interested I can upload the Android and Linux kernel for you to download if you send me a PM with your email address. I don't have enough bandwidth for all to download so I may upload to Google Drive if anyone else is interested.
You can change it easily to run from SD or NAND. I am using SD for development and once I have it where I want it, I will move to nand.
Have you come across anything in your build investigations that would suggest you have the wherewithal to create an Android image for the A10 LIME? The official one is supposedly out Real Soon Now but it's not here yet :-)
Not without the binaries for it, no, not really possible unless the hardware is close to an existing design. Allwinner have a number of no source binaries in there that would make it impossible without a lot of rework.
For example, I am trying to get SMS receiving to work and they only have a binary for the RIL so I am trying to port a Huawei generic RIL that someone else created to the board. With luck I will get SMS fully working soon. :)