<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.14.1">
</HEAD>
<BODY>
I am working on a patch to add DM355 SoC support to u-boot git tree. I am following the steps listed at http://www.denx.de/wiki/UBoot/DevelopmentProcess. Since the DM355 has an ARM9 processor, I am creating a patch for the u-boot-arm git tree.<BR>
<BR>
Since one of the steps is to verify MAKEALL builds cleanly, I first ran MAKEALL before applying my patch to make sure all is well. Since I am focusing on ARM9, I only did a MAKEALL for ARM9 (I don't have a PCC toolchain). Specifically, I did:<BR>
<BR>
git clone git://www.denx.de/git/u-boot-arm.git u-boot-arm<BR>
cd u-boot-arm<BR>
CROSS_COMPILE=arm-linux- BUILD_DIR=/tmp/build MAKEALL_LOGDIR=/tmp/log ./MAKEALL ARM9<BR>
<BR>
Much to my surprise, I not only got warnings, I got errors. The main error being:<BR>
<BR>
mpc8xxx_spi.c:26:29: error: asm/mpc8xxx_spi.h: No such file or directory. I see a patch to fix this error has been submitted.<BR>
<BR>
The second error I got relates to PUEN() / __REG2() macros. I am not sure if that is a real error or caused by the toolchain I am using. I looked at the code, but got lost with the use of __builtin_constant_p() in asm-arm/arch-pxa/hardware.h where __REG2 is defined as<BR>
<BR>
# define __REG2(x,y) \<BR>
( __builtin_constant_p(y) ? (__REG((x) + (y))) \<BR>
: (*(volatile u32 *)((u32)&__REG(x) + (y))) )<BR>
<BR>
I have no way to check that any change I propose works so I don't feel comfortable providing a patch, (plus the above code reinforces my believe that accessing hardware should be made obvious using inl() outl() type API). Does anyone else see this error when using MAKEALL for ARM9?<BR>
<BR>
Questions:<BR>
<BR>
1) Did I do something wrong on how I invoked MAKEALL or maybe have a toolchain issue? Should MAKEALL ARM9 build cleanly?<BR>
<BR>
2) I am looking at providing two patchs. One to add DM355 SoC support and a second to add DFU USB functionality to the u-boot git tree. Should I post the USB patch based on u-boot-arm git tree or the u-boot-usb git tree. I have to have DM355 SoC support in order to test the DFU USB functionality so I would rather have the patches apply to the same git tree. The USB code in both git trees is nearly identical. Any suggestions?<BR>
<BR>
3) There are common USB UDC API definitions in usbdcore_omap1510.h and usbdcore_mpc8xx.h (and they don't agree on the API). I am adding usbdcore_musb.h that supports the same API. Should I pull out this common code in a separate patch or as part of the USB UDC support for DM355 patch?<BR>
<BR>
The API I found to be common includes:<BR>
<BR>
int udc_init(void);<BR>
void udc_irq(void);<BR>
int udc_endpoint_write(struct usb_endpoint_instance *endpoint);<BR>
void udc_setup_ep(struct usb_device_instance *device, unsigned int ep,<BR>
struct usb_endpoint_instance *endpoint);<BR>
void udc_connect(void);<BR>
void udc_disconnect(void);<BR>
void udc_enable(struct usb_device_instance *device);<BR>
void udc_disable(void);<BR>
void udc_startup_events(struct usb_device_instance *device);<BR>
void udc_set_nak(int epid);<BR>
void udc_unset_nak (int epid);<BR>
<BR>
Note that omap has udc_endpoint_write() not returning a value, but drivers/serial/usbtty.c expects udc_endpoint_write() to return a result code.<BR>
<BR>
Basically I am confused on how to submit patches when one patch requires another patch and the patches could be applied to different git custodian trees.<BR>
<BR>
Thanks,<BR>
<BR>
Todd<BR>
<BR>
</BODY>
</HTML>