| Message ID | 1473437441-938-6-git-send-email-marcel.ziswiler@toradex.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Warren |
| Headers | show |
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? > +#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.
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? 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. > > +#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?
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.
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.
diff --git a/include/configs/colibri_t20.h b/include/configs/colibri_t20.h index c15f0cb..33e1ef5 100644 --- a/include/configs/colibri_t20.h +++ b/include/configs/colibri_t20.h @@ -31,6 +31,9 @@ #define CONFIG_GENERIC_MMC #define CONFIG_TEGRA_MMC +/* USB DFU */ +#define CONFIG_DFU_NAND + /* USB host support */ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_TEGRA @@ -86,7 +89,10 @@ /* Miscellaneous commands */ #define CONFIG_FAT_WRITE +#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" \ "mtdparts=" MTDPARTS_DEFAULT "\0" /* Increase console I/O buffer size */
Enable USB gadget DFU functionality for NAND as well. Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> --- include/configs/colibri_t20.h | 6 ++++++ 1 file changed, 6 insertions(+)