flashing estimate time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. flash alt-f
2. waiting to complete

What is the expected output? What do you see instead?

Flashing the kernel, it takes about 25 seconds: 51
Flashing the ramdisk, it takes about 110 seconds: 174
The new firmware will only be active after a reboot. 

What Alt-F version are you using? Have you flashed it?
trunk r1923

What is the box hardware revision level? A1, B1 or C1? (look at the label
at the box bottom)
C1

What operating system are you using on your computer? Using what browser?
OSX 10.8.2 using Firefox 16.0.1

Please provide any additional information below.

there's a mismatch time between realtime and estimated time
kernel 25-->51
ramdisk 110-->174

Original issue reported on code.google.com by zero1...@gmail.com on 27 Oct 2012 at 2:32

[GoogleCodeExporter]

Trunk is unstable, you should not flash it or use it to flash firmware.

And this is specially true because for RC3 the rootfs will "run" straight from 
the flash device, saving about 6MB of main memory. This means that the kernel 
command line now contains a root=/dev/mtdblockx, and that flashing (after 
flashing RC3) is not possible without rebooting into a special mode where the 
rootfs "runs" from memoty (as it does in RC2 and previous versions).

The changes are only midway done, not sure what is the current status, but it 
is not finished yet.
Also, the firmware creation is different, with 'mkinitramfs.sh' now accepting a 
'sqmtd' argument.

Not all changes are SVN commited or finished, not sure if you have or not 
damage your box :-O

In any case, you can always reboot into a know good firmware after putting a 
kernel image and rootfs of a previous Alt-F version, e.g., RC2, into the 
'/root' folder and rebooting.
You can use the  'dns323-fw -s' command on a firmware .bin image and strip the 
first 64 bytes uBoot header, as in

dns323-fw -s Alt-F-0.1RC2.bin
dd if=kernel of=/root/zImage bs=64 skip=1
dd if=initramfs_file of=/root/rootfs.arm.cpio bs=64 skip=1

You might have to change/adapt /etc/init.d/rcE, look at it near the end.

As for the flash time, it used to be the contrary, it actually took less time 
than announced... I will take a look at that when I first flash RC3, which I 
have never done yet!

Thanks

Original comment by whoami.j...@gmail.com on 30 Oct 2012 at 3:14

[GoogleCodeExporter]

I have not SVN commit the relevant kernel patch and configuration, neither 
/init and /etc/init.d/rcE, nor mkinitramfs.sh/mkfw.sh changes, so you should be 
safe.

Original comment by whoami.j...@gmail.com on 30 Oct 2012 at 6:40

[GoogleCodeExporter]

thanks Joao,
I reverted back to RC2 Firmware
I did 'tryit' first, after that I flash it.

this is the output from my C1-box

Flashing the kernel, it takes about 25 seconds: 51
Flashing the ramdisk, it takes about 110 seconds: 191
The new firmware will only be active after a reboot. 

Original comment by zero1...@gmail.com on 31 Oct 2012 at 3:20

[GoogleCodeExporter]

You can continue using trunk as long as you don't flash it or use it to flash 
firmware.
Just create zImage and rootfs.arm.cpio-sq.lzma as usual, put it in the box 
'/root' folder and reboot. This is what the TryIt button does, and what I do in 
my normal development cycle.

Original comment by whoami.j...@gmail.com on 31 Oct 2012 at 4:31

[GoogleCodeExporter]

Original comment by whoami.j...@gmail.com on 5 Nov 2012 at 6:42

• Changed state: Accepted

[GoogleCodeExporter]

The current svn contains all changes (RC3 testing), so flashing trunk is again 
safe.
The flashing times seems to be OK now, closing.

Original comment by whoami.j...@gmail.com on 16 Mar 2013 at 6:05

• Changed state: Fixed

[GoogleCodeExporter]

RC3 Flashing time C1-box

Flashing the kernel, it takes about 19 seconds: 44
Verifying... OK
Flashing the rootfs, it takes about 86 seconds: 188
Verifying... OK
You can continue using the current firmware,
but the new firmware will only be active after a reboot.

reboot time
Waiting 60 seconds: 93

Original comment by zero1...@gmail.com on 24 Mar 2013 at 2:48

[GoogleCodeExporter]

Assuming that the elapsed time shown on the web page is correct (have you 
confirmed that?), the only explanation is that the rev-C1 boards (yours) are 
slower then the B1 ones (mine).

Can you please execute and post the output of the following commands (my 
system's output follows)

# dmesg | grep -E 'TCLK|MIPS'
Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976)
Orion ID: MV88F5182-A2. TCLK=166666667.

# dd if=/dev/mtd3 of=/dev/null
12672+0 records in
12672+0 records out
6488064 bytes (6.2MB) copied, 2.291098 seconds, 2.7MB/s

# dd if=/dev/mtd3 of=/tmp/foo
12672+0 records in
12672+0 records out
6488064 bytes (6.2MB) copied, 2.501223 seconds, 2.5MB/s

# rm /tmp/foo

Thanks

Original comment by whoami.j...@gmail.com on 24 Mar 2013 at 2:40

[GoogleCodeExporter]

ah, the reboot time estimate is an ad-hoc value, it is about 45 seconds on my 
box, but it depends on what has to be done to shutdown and reboot the system; 
if ssh/host keys have to be generated it takes longer.

After an initial 20 sec period, the browser queries the box every three seconds 
to see when it is alive again, and then connects to it.

And generating a rsa key is a good test also:

# time /usr/bin/dropbearkey -t rsa -s 2048 -f foo
...
real    0m 27.33s
user    0m 27.30s
sys     0m 0.01s

# rm foo

Original comment by whoami.j...@gmail.com on 24 Mar 2013 at 2:51

[GoogleCodeExporter]

here's the output
# dmesg | grep -E 'TCLK|MIPS'
Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976)
Orion ID: MV88F5182-A2. TCLK=166666667.

# dd if=/dev/mtd3 of=/dev/null
12672+0 records in
12672+0 records out
6488064 bytes (6.2MB) copied, 2.283885 seconds, 2.7MB/s

# dd if=/dev/mtd3 of=/tmp/foo
12672+0 records in
12672+0 records out
6488064 bytes (6.2MB) copied, 2.504779 seconds, 2.5MB/s
# rm /tmp/foo

# time /usr/bin/dropbearkey -t rsa -s 2048 -f foo
Will output 2048 bit rsa secret key to 'foo'
Generating key, this may take a while...
Public key portion is:
ssh-rsa 
AAAAB3NzaC1yc2EAAAADAQABAAABAwCLo8p9F2N4IzG2v0UMfJ0OSg2VHkrJzfqX16yzIYKVoKX1OrI7
VqdDmKolfiWOuO1sIUWrnAsiMv+GSh1s24fV6B6+42STNePsMVdEmEsuZBHdkS6QmeQrwpdeWP5TuvFs
icRo1WnQGq5lPYyXcQnrcezJsgs35A+/7Pyx2GGz0W2PR43Uw6fQKKHynvw9v+qZZtWJnAtKjwk6MXkK
GjahHVGDuVLYx+OVhGlkeLY37qIfAY/+4vxcN0m4zlWC3U2rmWvt5Er1ctmDQvN4pQYqlMgwznbrJAQX
uZYowzagkgsX3c6vAtC1QwER32eRagb0cqeXJPuRY7XU+Q8kefKceLU= root@orion
Fingerprint: md5 40:71:49:46:e7:b7:ed:6e:71:cd:8e:3d:fc:38:95:e0
real    0m 14.31s
user    0m 14.29s
sys 0m 0.00s
# rm foo

Original comment by zero1...@gmail.com on 25 Mar 2013 at 2:51

[GoogleCodeExporter]

Processor speed and flash memory *reading* times are the same on your's and 
mine boxes, the flash writing speed should also be similar (although the rsa 
key generating time is much lower/better on your box)

This only leaves the browser elapsed timer.
During your next reboot can you please check with a stopwatch that the count-up 
time is correct? (you are using Firefox on OSx)

Original comment by whoami.j...@gmail.com on 25 Mar 2013 at 4:18

[GoogleCodeExporter]

using stopwatch:
1st reboot= 57.9 s
2nd reboot= 58.0 s

now it's normal. weird :-/

Original comment by zero1...@gmail.com on 26 Mar 2013 at 12:23