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
next prev parent 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