Re: [U-Boot] [PATCH v2 0/8] arm: a few steps to reduce the boot time

2015-02-18 Thread Przemyslaw Marczak

Hello Stephen,

On 02/17/2015 11:39 PM, Stephen Warren wrote:

On 02/17/2015 02:43 PM, Stephen Warren wrote:

On 02/16/2015 08:13 AM, Przemyslaw Marczak wrote:

This patchset reduces the boot time for ARM architecture,
Exynos boards, and boards with DFU enabled.


I tested this series on NVIDIA's Jetson TK1 board. It doesn't seem to
introduce any new issues, but I did find a couple have crept in recently:

I'm running the following in U-Boot:

setenv dfu_alt_info /dfu_test.bin ext4 0 1;/dfudummy.bin ext4 0 1
dfu 0 mmc 0

1)

Whenever any file is uploaded through DFU, I see:

#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722729591336 bytes written in 4070 ms (3.9 EiB/s)

Notice that the byte count is way off (that's from a 4KB file). The byte
count is always the same invalid number. I'm not sure if this message
comes from the ext4 or DFU code.


For the record in this thread, this is fixed by:
[PATCH] fs: ext4 write: return file len on success



Thank you for testing. I should add the ext4 fix to this patchset, so it 
will be linked in the next version.


Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 0/8] arm: a few steps to reduce the boot time

2015-02-17 Thread Stephen Warren

On 02/16/2015 08:13 AM, Przemyslaw Marczak wrote:

This patchset reduces the boot time for ARM architecture,
Exynos boards, and boards with DFU enabled.


I tested this series on NVIDIA's Jetson TK1 board. It doesn't seem to 
introduce any new issues, but I did find a couple have crept in recently:


I'm running the following in U-Boot:

setenv dfu_alt_info /dfu_test.bin ext4 0 1;/dfudummy.bin ext4 0 1
dfu 0 mmc 0

1)

Whenever any file is uploaded through DFU, I see:

#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722729591336 bytes written in 4070 ms (3.9 EiB/s)

Notice that the byte count is way off (that's from a 4KB file). The byte 
count is always the same invalid number. I'm not sure if this message 
comes from the ext4 or DFU code.


2)

Both the 4096 and 1048576 DFU tests fail in the read-back stage, with 
the following appearing on the U-Boot console:


#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722734241092 bytes written in 4070 ms (3.9 EiB/s)
DOWNLOAD ... OK
Ctrl+C to exit ...
#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722734241092 bytes written in 4091 ms (3.9 EiB/s)
DOWNLOAD ... OK
Ctrl+C to exit ...
4096 bytes read in 127 ms (31.3 KiB/s)
#
UPLOAD ... done
Ctrl+C to exit ...
4096 bytes read in 126 ms (31.3 KiB/s)
#dfu_read: Wrong sequence number! [1] [3]

The host-side DFU test log ends with:

Opening DFU USB device... ID 0955:701a
Warning: Assuming DFU version 1.0
Run-time device DFU version 0100
Found DFU: [0955:701a] devnum=0, cfg=1, intf=0, alt=0, name=/dfu_test.bin
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 4096
bytes_per_hash=4096
Copying data from DFU device to PC
Starting upload: [###dfu_upload: libusb_control_msg returned -9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 0/8] arm: a few steps to reduce the boot time

2015-02-17 Thread Stephen Warren

On 02/17/2015 02:43 PM, Stephen Warren wrote:

On 02/16/2015 08:13 AM, Przemyslaw Marczak wrote:

This patchset reduces the boot time for ARM architecture,
Exynos boards, and boards with DFU enabled.


I tested this series on NVIDIA's Jetson TK1 board. It doesn't seem to
introduce any new issues, but I did find a couple have crept in recently:

I'm running the following in U-Boot:

setenv dfu_alt_info /dfu_test.bin ext4 0 1;/dfudummy.bin ext4 0 1
dfu 0 mmc 0

1)

Whenever any file is uploaded through DFU, I see:

#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722729591336 bytes written in 4070 ms (3.9 EiB/s)

Notice that the byte count is way off (that's from a 4KB file). The byte
count is always the same invalid number. I'm not sure if this message
comes from the ext4 or DFU code.


For the record in this thread, this is fixed by:
[PATCH] fs: ext4 write: return file len on success
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 0/8] arm: a few steps to reduce the boot time

2015-02-16 Thread Przemyslaw Marczak
This patchset reduces the boot time for ARM architecture,
Exynos boards, and boards with DFU enabled.

For tested Trats2 and Odroid X2 devices, this was done in four steps.

1. Enable the arch memcpy and memset

2. Enable arch memset for .bss clear

3. Reduce the .bss section small as possible by removing the static dfu buffer
   (32MiB in .bss - Trats2), and use the malloc.

4. Skip zeroing the memory reserved for malloc at malloc init.
   For Trats2 it was 80MiB of memory.

The .bss section will grow if we have a lot of static variables.
This section is cleared before jump to the relocated U-Boot,
and it was done word by word. To reduce the time for this step,
we can enable arch memset, which uses multiple ARM registers.

For configs with DFU enabled, we can find the dfu buffer in this section,
which has at least 8MB (32MB for Trats2). This is a lot of useless data,
which is not required for standard boot. So this buffer should be dynamic
allocated.

The next issue was about the malloc reserved memory, which was zeroed
at malloc init in one of early init call. Some boards has more than one MiB
of reserved malloc memory. Zeroing this, adds another boot delay.
Now the memory is zeroed only on calloc call.

So, actually the all was about unnecessary operations on 'big' data.

Przemyslaw Marczak (8):
  exynos: config: enable arch memcpy and arch memset
  arm: relocation: clear .bss section with arch memset if defined
  dfu: mmc: file buffer: remove static allocation
  dlmalloc: add option for skip memset in malloc init
  README: add info about skip memset at malloc init
  kconfig: malloc: add option for skip memset at malloc init
  trats2: defconfig: enable expert and skip memset at malloc init
  odroid: defconfig: enable expert and skip malloc memset

 Kconfig | 26 +++---
 README  |  7 +++
 arch/arm/lib/crt0.S | 10 +-
 common/dlmalloc.c   | 10 +++---
 configs/odroid_defconfig|  2 ++
 configs/trats2_defconfig|  2 ++
 drivers/dfu/dfu_mmc.c   | 25 ++---
 include/configs/exynos-common.h |  3 +++
 8 files changed, 71 insertions(+), 14 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot