tftp booting the panda board

Hi,

I am trying to tftpboot the panda board, this basically works, but I still have some issues.

The panda board uses an SMSC95xx chip, and so requires USB2.0

Using the u-boot git head, we have support for network adapters over USB, and the patches from Simon Glass, we get support for the ethernet chip. So, the only missing piece of the puzzle is USB EHCI for OMAP4/Panda.

I tried to implement it, the patches will follow shortly, but have several remaining issues:
- the EHCI stop routine, implemented as in the Linux kernel driver, has timeouts when trying to wait for the UHH reset;
- the SMSC95XX is unstable, if I start USB, stop USB, then start again, the SMSC95XX initialization hangs, this does not happen without this driver
- if I launch bootp, and say, the server does not answer to the bootp protocol, the smsc95xx driver does not seem to be able to recover from the first timeout, any further attempt causes a timeout.

Regards.

                                                                Gilles.

Copied from omap3.

---
 arch/arm/cpu/armv7/omap4/Makefile      |    1 +
 arch/arm/cpu/armv7/omap4/gpio.c        |  169 ++++++++++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/gpio.h |   93 +++++++++++++++++
 3 files changed, 263 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap4/gpio.c
 create mode 100644 arch/arm/include/asm/arch-omap4/gpio.h

index 987dc9d..c39693a 100644
@@ -29,6 +29,7 @@ SOBJS	+= lowlevel_init.o
 
 COBJS	+= board.o
 COBJS	+= mem.o
+COBJS	+= gpio.o
 COBJS	+= sys_info.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)

1.7.2.5

I have not looked at the code but if it truly is a copy (other than some base addresses) is there a way to share with omap3?

--john

Yes, probably. The linux code is full of switch/cases, but that is because it has to support compiling one kernel for all omaps. We can do something simple with a header defining the same defines to different values depending on the actual processor.

                                                                Gilles.

I am going to fix this and resend another round of patches. But, it this the only thing I should fix?

For instance, in part of the patch, I used hardcoded hardware addresses, in other part, I put some #define for register addresses in the .c file, in other part, the #define are in a common header. What is the policy in u-boot for this particular point?

                                                                Gilles.

My comment was not a complete review only a comment about sharing.

I got that, I am just trying to get more comments before I send another round of patches, in order to avoid having to send 10 rounds of patches.

Maybe the patches were sent to the wrong person?

                                                                Gilles.

As board may need some specific support, implement inner functions to be called by the boards implementaions of ehci_hcd_start, ehci_hcd_stop.

---
 arch/arm/include/asm/arch-omap4/ehci.h |    8 +
 drivers/usb/host/Makefile              |    1 +
 drivers/usb/host/ehci-omap4.c          |  268 ++++++++++++++++++++++++++++++++
 3 files changed, 277 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h
 create mode 100644 drivers/usb/host/ehci-omap4.c

new file mode 100644
index 0000000..fc84f6a
@@ -0,0 +1,8 @@
+#ifndef EHCI_H
+#define EHCI_H
+
+int omap4_ehci_hcd_init(void);
+
+int omap4_ehci_hcd_stop(void);
+
+#endif /* EHCI_H */

index 51b2494..5a5b971 100644
@@ -46,6 +46,7 @@ COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
 COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
 COBJS-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
 COBJS-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
+COBJS-$(CONFIG_USB_EHCI_OMAP4) += ehci-omap4.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)

1.7.2.5

I am far from an expert. But I saw a previous post for EHCI on omap3 saying "this file is sufficiently specific to be specific for each board". So, I started writing a panda specific board, but found that there was not really much code specific to panda, and most of the code was specific to omap4.

This said, there is more than one way to do it on omap4, the processor can be configured different ways to get EHCI support (as far as I understood the processor even has two different EHCI controllers). So maybe a panda-only file was not a bad idea after all...

                                                                Gilles.

Dear Gilles Chanteperdrix,

...

Can you please provide exact reference? Please see
http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign
bullet # 4

Thanks.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q: Why do PCs have a reset button on the front?
A: Because they are expected to run Microsoft operating systems.

---
 board/ti/panda/Makefile     |    4 ++-
 board/ti/panda/ehci-panda.c |   59 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+), 1 deletions(-)
 create mode 100644 board/ti/panda/ehci-panda.c

index 2186403..253567c 100644
@@ -25,7 +25,9 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(BOARD).o
 
-COBJS	:= panda.o
+COBJS-$(CONFIG_USB_EHCI) += ehci-panda.o
+
+COBJS	:= $(COBJS-y) panda.o
 
 SRCS	:= $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))

1.7.2.5

This is a bug in USB net I think, rather than just this driver. I have not looked at it yet but patches are welcome!

This may or may not be related - again I have seen this and it also happens with Asix.

Regards,
Simon