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

[Marcel Ziswiler]

On Wed, 2016-09-14 at 17:23 +0000, Stephen Warren wrote:
> 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.

Well, as you correctly noticed it is and always was already enabled
anyway.

> > 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.

Sure, as it long since was already enabled.

> 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).

Last I checked a few days ago USB failed at least on Ventana.

> > > > +#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.

Sure, I will just drop this patch. Don't worry.