u-boot.git/cmd, branch v2016.03-rc3 Unnamed repository; edit this file 'description' to name the repository. trace: Fix compiler warnings in trace 2016-02-26T15:53:10+00:00 Simon Glass sjg@chromium.org 2016-02-24T16:14:45+00:00 5eca977935bf58f4227b2681e612a452a0da0286 With min() we must use the same type for each parameter. Fix two problems in trace.c which produce compiler warnings. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
With min() we must use the same type for each parameter. Fix two problems
in trace.c which produce compiler warnings.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Merge branch 'master' of git://git.denx.de/u-boot-usb 2016-02-24T23:44:17+00:00 Tom Rini trini@konsulko.com 2016-02-24T19:26:20+00:00 fec26e7270ad31e4179d1bd189e5cd8ab93ccba3 






cmd: mem: Show 64bit addresses which are tested
2016-02-24T23:44:14+00:00

Michal Simek
michal.simek@xilinx.com

2016-02-24T07:36:02+00:00

dfe461d6b5a196c6f13ab0b4ccbeb1b16aa22cf5

Fix print message to show full 64bit addresses.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>





Fix print message to show full 64bit addresses.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>







booti: Help text rework.
2016-02-24T23:44:12+00:00

Karsten Merker
merker@debian.org

2016-02-22T19:59:08+00:00

6f6051fac360cf6ca88cfcfa3cb377778ef5742c

Fix spelling errors in the "booti" help text and bring it more
in line with the bootm/bootz help texts.

Signed-off-by: Karsten Merker <merker@debian.org>





Fix spelling errors in the "booti" help text and bring it more
in line with the bootm/bootz help texts.

Signed-off-by: Karsten Merker <merker@debian.org>







dfu: usb: f_dfu: Set deferred call for dfu_flush() function
2016-02-24T18:12:32+00:00

Lukasz Majewski
l.majewski@samsung.com

2016-01-28T15:14:49+00:00

fc18f8d170ecc7e15269ad5312ec643addb42491

This patch fixes situation when one would like to write large file into
medium with the file system (fat, ext4, etc).
This change sets file size limitation to the DFU internal buffer size.

Since u-boot is not supporting interrupts and seek on file systems, it
becomes challenging to store large file appropriately.

To reproduce this error - create large file (around 26 MiB) and sent it
to the target board.

Lets examine the flow of USB transactions:

0. DFU uses EP0 with 64B MPS [Max Packet Size]

1. Send file - OUT (PC->target) - dat_26MiB.img is sent with 4096 B transactions

2. Get status - OUT (PC->target) - wait for DFU_STATE_dfuDNLOAD_IDLE (0x05) sent
				   from target board - IN transaction
				   (target->PC)

3. The whole file content is sent to target - OUT (PC->target) with ZLP [Zero
					      Length Packet]

Now the interesting part starts:

4. OUT (PC->target) Setup transaction (request to share DFU state)

5. IN (target->PC) - reply the current DFU state
	- In the UDC driver the req->completion (with dfu_flush) is called
	  after successful IN transfer.
	- The dfu_flush() (called from req->completion callback) saves the
	  whole file at once (u-boot doesn't support seek on fs).
	  Such operation takes considerable time. When the file
	  is large - e.g. 26MiB - this time may be more than 5 seconds.

6. OUT (PC->target) - ZLP, is send in the same time when dfu_flush()
 writes data to eMMC memory.
 The dfu-util application has hard coded timeout on USB transaction
 completion set to 5 seconds (it uses libusb calls).

When the file to store is large (e.g. 26 MiB) the time needed to write it
may excess the dfu-util timeout and following error message will be displayed:
"unable to read DFU status" on the HOST PC console.

This change is supposed to leverage DFU's part responsible for storing files
on file systems. Other DFU operations - i.e. raw/partition write to NAND and
eMMC should work as before.

The only functional change is the error reporting. When dfu_flush() fails
the u-boot prompt will exit with error information and dfu-util application
exits afterwards as well.

Test HW:
- Odroid XU3 (Exynos5433) - test with large file
- Trats (Exynos4210) - test for regression - eMMC, raw,

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Reported-by: Alex Gdalevich <agdalevich@axion-biosystems.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Heiko Schocher <hs@denx.de>





This patch fixes situation when one would like to write large file into
medium with the file system (fat, ext4, etc).
This change sets file size limitation to the DFU internal buffer size.

Since u-boot is not supporting interrupts and seek on file systems, it
becomes challenging to store large file appropriately.

To reproduce this error - create large file (around 26 MiB) and sent it
to the target board.

Lets examine the flow of USB transactions:

0. DFU uses EP0 with 64B MPS [Max Packet Size]

1. Send file - OUT (PC->target) - dat_26MiB.img is sent with 4096 B transactions

2. Get status - OUT (PC->target) - wait for DFU_STATE_dfuDNLOAD_IDLE (0x05) sent
				   from target board - IN transaction
				   (target->PC)

3. The whole file content is sent to target - OUT (PC->target) with ZLP [Zero
					      Length Packet]

Now the interesting part starts:

4. OUT (PC->target) Setup transaction (request to share DFU state)

5. IN (target->PC) - reply the current DFU state
	- In the UDC driver the req->completion (with dfu_flush) is called
	  after successful IN transfer.
	- The dfu_flush() (called from req->completion callback) saves the
	  whole file at once (u-boot doesn't support seek on fs).
	  Such operation takes considerable time. When the file
	  is large - e.g. 26MiB - this time may be more than 5 seconds.

6. OUT (PC->target) - ZLP, is send in the same time when dfu_flush()
 writes data to eMMC memory.
 The dfu-util application has hard coded timeout on USB transaction
 completion set to 5 seconds (it uses libusb calls).

When the file to store is large (e.g. 26 MiB) the time needed to write it
may excess the dfu-util timeout and following error message will be displayed:
"unable to read DFU status" on the HOST PC console.

This change is supposed to leverage DFU's part responsible for storing files
on file systems. Other DFU operations - i.e. raw/partition write to NAND and
eMMC should work as before.

The only functional change is the error reporting. When dfu_flush() fails
the u-boot prompt will exit with error information and dfu-util application
exits afterwards as well.

Test HW:
- Odroid XU3 (Exynos5433) - test with large file
- Trats (Exynos4210) - test for regression - eMMC, raw,

Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Reported-by: Alex Gdalevich <agdalevich@axion-biosystems.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Heiko Schocher <hs@denx.de>







i2c: spd: Extend SPD memory types
2016-02-22T15:21:12+00:00

Michal Simek
michal.simek@xilinx.com

2016-02-15T10:58:37+00:00

18c4e7f71c3ab7298a5453c492e0a9c46cd38c23

Decode DDR, DDR3 and DDR4 memories.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>





Decode DDR, DDR3 and DDR4 memories.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>







gpio: Correct handling of 'gpio status'
2016-02-15T20:58:25+00:00

Simon Glass
sjg@chromium.org

2016-02-14T23:28:59+00:00

4c80c53c00ac6583f22938fc98e4df688acdf4ce

This is broken - we need to look at the first two characters to distinguish
'gpio status' from 'gpio set'.

Fixes: 0ffe6ab5 (gpio: Allow 's' as an abbreviation for 'status')
Reported-by: Soeren Moch <smoch@web.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Soeren Moch <smoch@web.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>





This is broken - we need to look at the first two characters to distinguish
'gpio status' from 'gpio set'.

Fixes: 0ffe6ab5 (gpio: Allow 's' as an abbreviation for 'status')
Reported-by: Soeren Moch <smoch@web.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Soeren Moch <smoch@web.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>







itest: allow map_physmem to return 0 in limited cases
2016-02-09T22:41:19+00:00

Stephen Warren
swarren@nvidia.com

2016-01-29T23:10:04+00:00

986fe378172fa4bd5be1432ab2f8f7c2b1c43bae

On some systems, RAM starts at address 0. If the user executes itest
against address 0 on such a system, it will call map_physmem(0, ...)
which will return 0 back; mapping only changes the address on sandbox.
This causes itest to believe map_physmem() has failed, and hence fails
the comparison.

Fix itest so that it allows map_physmem() to return 0 /if/ the orignal
address passed to it was also 0.

This fixes "tegra-uboot-flasher flash" on Tegra20.

This has the disadvantage that on sandbox, failed mapping attempts for
address 0 are not detected. Instead, should the code only call
map_physmem() on sandbox? Or, should map_physmem() return its error status
some other way. Or, should the special case only be allowed on systems
where the base of RAM is 0 somehow?

Fixes: 7861204c9af7 ("itest: make memory access work under sandbox")
Signed-off-by: Stephen Warren <swarren@nvidia.com>





On some systems, RAM starts at address 0. If the user executes itest
against address 0 on such a system, it will call map_physmem(0, ...)
which will return 0 back; mapping only changes the address on sandbox.
This causes itest to believe map_physmem() has failed, and hence fails
the comparison.

Fix itest so that it allows map_physmem() to return 0 /if/ the orignal
address passed to it was also 0.

This fixes "tegra-uboot-flasher flash" on Tegra20.

This has the disadvantage that on sandbox, failed mapping attempts for
address 0 are not detected. Instead, should the code only call
map_physmem() on sandbox? Or, should map_physmem() return its error status
some other way. Or, should the special case only be allowed on systems
where the base of RAM is 0 somehow?

Fixes: 7861204c9af7 ("itest: make memory access work under sandbox")
Signed-off-by: Stephen Warren <swarren@nvidia.com>







Remove unused CONFIG_CMD_HWFLOW option and associated dead code.
2016-02-08T15:22:44+00:00

David Müller (ELSOFT AG)
d.mueller@elsoft.ch

2016-02-06T06:57:26+00:00

b7fbdc60abaf3224e9fca62d0c4759072bdc60ad

Signed-off-by: David Müller <d.mueller@elsoft.ch>





Signed-off-by: David Müller <d.mueller@elsoft.ch>







cmd: Fix control bmp_display()
2016-02-06T12:53:09+00:00

Simon Glass
sjg@chromium.org

2016-01-30T22:45:15+00:00

e517db73a61376b940a9b352eb717f703f6b25df

All paths should share the same return.

Reported-by: Coverity (CID:134903)

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>





All paths should share the same return.

Reported-by: Coverity (CID:134903)

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>