public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bodonoghue@codehermit.ie>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 1/1] Supplemental USB patch to previous 14 patches.
Date: Tue, 30 May 2006 22:50:53 +0100	[thread overview]
Message-ID: <20060530225053.7575ab34@localhost.localdomain> (raw)
In-Reply-To: <17532.35399.950069.322353@astp0002.localdomain>

On Tue, 30 May 2006 21:09:11 +0300
Yuli Barcohen <yuli@arabellasw.com> wrote:

>     Bryan> -CROSS_COMPILE = powerpc-linux-
>     Bryan> +CROSS_COMPILE = ppc_8xx-
> 
Blink. How the hell did that get in there ?

> I didn't mean to add entirely new board target. I think a new target
> should be added to the existing Adder targets which would add a #define
> for USB console just like "#define CONFIG_MPC852T" is added for
> AdderII. 

Actually I think that makes more sense then adding AdderUSB as the supplemental
patch does. I concur, this is definitely the more generic/portable way
to do this. I'll generate another supplemental patch in lieu of the previous
patch, which implements the above.

> Conditional on this #define, BoardName.h can include
> usbd_vendor.h which we decided to create. In the current version of your
> patch, it's exactly opposite: usbd_vendor.h (AdderUSB.h in our case)
> includes BoardName.h (Adder.h). This means that for every board wishing
> to support USB console you have to create another BoardNameUSB.h (which
> is a clone of AdderUSB.h). What's about creating CodeHermit.h containing
> something like this:
>
>  #define CONFIG_USB_DEVICE		/* Include UDC driver */
>  #define CFG_USB_EXTC_CLK 0x02		/* Oscillator on EXTC_CLK 2 */
>  #define CFG_USB_BRG_CLK	0x04
>  #define CFG_CONSOLE_IS_IN_ENV
>  #define CONFIG_USBD_MANUFACTURER	"CodeHermit.ie"
>  #define CONFIG_USBD_PRODUCT_NAME	"Das U-Boot"
>  #define CONFIG_USBD_VENDORID		0xFFFF 
>  #define CONFIG_USBD_PRODUCTID_GSERIAL 0xFFFF
>  #define CONFIG_USBD_PRODUCTID_CDCACM  0xFFFE

>  adding to Adder.h
> 
>  #ifdef CONFIG_USB_TTY
>  #include <CodeHermit.h>
>  #endif
> 
> "#define CONFIG_USB_TTY" would be added by the configuration target in
> the Makefile. Any other board can then include CodeHermit.h
> unchanged. To allow IDs overwriting, you can even use the following in
> CodeHermit.h:
> 
>  #ifndef CONFIG_USBD_VENDORID
>  #define CONFIG_USBD_VENDORID 0xFFFF
>  #endif

Right. I have a suggestion, which if it is agreeable to you and everybody else
I will generate a new full supplemental patchset based upon.

1: For Adder ports, the Makefile shall be amended to optionally add
CONFIG_USB_TTY to config.h as CONFIG_MPC852T is added by make AdderII_config.
This will provisionally imply an appendation of USB to the config name. Hence
three new values should be added to Makefile AdderUSB_config,
Adder87xUSB_config and AdderIIUSB_config. - Do all these boards have USB
facility ? 

2: include/usbd_vendor.h shall be created. This will look almost exactly like
the following.

#define CONFIG_USB_DEVICE		/* Include UDC driver */
#define CFG_CONSOLE_IS_IN_ENV
/*
 * Include your own Vendor specific defines here if you have been allocated a
 * Vendor ID from the USB Implementors Forum. www.usb.org else DO NOT POLLUTE
 * THE USB NAMESPACE !
 *
 * #define CONFIG_USBD_MANUFACTURER	"CodeHermit.ie"
 * #define CONFIG_USBD_PRODUCT_NAME	"Das U-Boot"
 * #define CONFIG_USBD_VENDORID		 0xFFFF 
 * #define CONFIG_USBD_PRODUCTID_GSERIAL 0xFFFF
 * #define CONFIG_USBD_PRODUCTID_CDCACM  0xFFFE
 */

If at a later date for argument sake, we were to implement RNDIS then the
appropiate thing to do would be to add an optional 
CONFIG_USBD_PRODUCTID_RNDIS entry to usbd_vendor.h, with defaults for RNDIS
values residing in usbrndis.h, thus maintaining the structure established
with usbtty, thus far.

3: Adder.h shall be ammended with the following text in
a rational place.

#ifdef CONFIG_USB_TTY
#include <usbd_vendor.h>

#define CFG_USB_EXTC_CLK 0x02	/* Oscillator on EXTC_CLK 2 */
#define CFG_USB_BRG_CLK	0x04	/* Or optionally on brgc4 */	

#endif

I think CFG_USB_*BLAH* above shoudln't be in usbd_vendor.h for the case
where the USB console is being compiled for a non 8xx port, say the omap1510/SX1
port, hence the two CFG options above should probably be board specific.

4:
usbtty.c shall stay pretty much the same.

usbtty.h - Shall be included in usbtty.c. CONFIG_USBD_VENDORID,
CONFIG_USBD_PRODUCTID_GSERIAL will default to Linux values

config.h - Shall be included subsequent to usbtty.h, thus facilitating
over-riding of default VENDORID/PRODUCTID values from Linux specific values to
Vendor specific values.


I think that with this in place we pretty much do all that needs to be done.
If everybody else is in agreement, I can have these changes made in <= 10
minutes.

Let me know what you think.


Best Regards,
Bryan

  reply	other threads:[~2006-05-30 21:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 22:47 [U-Boot-Users] [PATCH 1/1] Supplemental USB patch to previous 14 patches Bryan O'Donoghue
2006-05-30 18:09 ` Yuli Barcohen
2006-05-30 21:50   ` Bryan O'Donoghue [this message]
2006-05-30 23:59     ` Wolfgang Denk
2006-05-31 10:42       ` Bryan O'Donoghue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060530225053.7575ab34@localhost.localdomain \
    --to=bodonoghue@codehermit.ie \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox