[U-Boot] [PATCH v1 5/5] colibri_t20: enable dfu also for nand

[Stephen Warren]

On 09/14/2016 09:41 AM, Marcel Ziswiler wrote:
> On Mon, 2016-09-12 at 12:24 -0600, Stephen Warren wrote:
>> On 09/09/2016 10:10 AM, Marcel Ziswiler wrote:
>>>
>>> Enable USB gadget DFU functionality for NAND as well.
>>>
>>> diff --git a/include/configs/colibri_t20.h
>>> b/include/configs/colibri_t20.h
>>>
>>> +/* USB DFU */
>>> +#define CONFIG_DFU_NAND
>> Oh, I see this file already includes tegra-common-usb-gadget.h, so
>> USB
>> device-mode is already enabled for this board. Does that make sense
>> given that it doesn't actually work?
>
> Well, it's not like it hurts anything else really isn't it?

Having the feature enabled implies that it works in my opinion. If it 
doesn't, I think this will only confuse users.

> My hopes were that somebody may actually help me looking into it which
> this would ease. However I understand that you NVIDIA people long since
> stopped even having any of them older Tegra 2 and 3 hardware any
> longer. At least Harmony and Ventana currently looks rather broken in
> many aspects which I left for another days exercise.

If someone wants to fix USB device mode on Tegra20, I don't imagine it 
would be hard for them to enable it while working on it.

What's broken on Harmony and Ventana? They both worked when I tested all 
Tegra boards within the last few months. We have a Tegra30 board (but 
admittedly not Tegra20 board) in our automated upstream U-Boot test farm 
(running test/py).

>>> +#define DFU_ALT_NAND_INFO	"u-boot part 0,1;ubi part 0,4"
>>> +
>>>  #define BOARD_EXTRA_ENV_SETTINGS \
>>> +	"dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
>> I would defer this to the user, since people may choose different
>> flash
>> layouts.
>
> Given the DFU NAND syntax being rather delicate at least Google
> returning rather some wrong stuff with respect to now starting with
> zero or one I thought that would at least make it clear. It's not that
> a user could not overwrite it any time if he wishes to do so isn't it?

Certainly a user could over-write it. However, I'm not convinced it's a 
good idea to provide an arbitrary default value that may or may not be 
remotely relevant to the user's actual configuration. Again, this may 
lead users down the wrong path of wondering why they can't get this 
default configuration to work, rather than researching what the correct 
configuration is.