This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.
The 195E boards use ancient versions of u-boot and a slightly mangled
verison of the oft-abused ppcboot header.
There are several variants of the SBC deployed, single/dual
ethernet+serial, and also 4MB/8MB flash variations. In the interest of
having a single kernel image boot on all boards, the cuboot shim detects
the differences and mangles the DTS tree appropriately.
With the exception of the CF interface that was never populated on
production boards, this code/DTS supports all boardpop options.
Signed-off-by: Solomon Peachy <redacted>
diff -Naur linux-2.6.30/arch/powerpc/boot/Makefile linux-2.6.30.hotfoot/arch/powerpc/boot/Makefile
@@ -0,0 +1,142 @@+/*+*OldU-bootcompatibilityforEsteem195EHotfootCPUBoard+*+*Author:SolomonPeachy<solomon@linux-wlan.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseversion2aspublished+*bytheFreeSoftwareFoundation.+*/++#include"ops.h"+#include"stdio.h"+#include"reg.h"+#include"dcr.h"+#include"4xx.h"+#include"cuboot.h"++#define TARGET_4xx+#define TARGET_HOTFOOT++#include"ppcboot.h"++staticbd_tbd;++#define NUM_REGS 3++staticvoidhotfoot_fixups(void)+{+u32uart=mfdcr(DCRN_CPC0_UCR)&0x7f;++dt_fixup_memory(bd.bi_memstart,bd.bi_memsize);++dt_fixup_cpu_clocks(bd.bi_procfreq,bd.bi_procfreq,0);+dt_fixup_clock("/plb",bd.bi_plb_busfreq);+dt_fixup_clock("/plb/opb",bd.bi_opbfreq);+dt_fixup_clock("/plb/ebc",bd.bi_pci_busfreq);+dt_fixup_clock("/plb/opb/serial@ef600300",bd.bi_procfreq/uart);+dt_fixup_clock("/plb/opb/serial@ef600400",bd.bi_procfreq/uart);++dt_fixup_mac_address_by_alias("ethernet0",bd.bi_enetaddr);+dt_fixup_mac_address_by_alias("ethernet1",bd.bi_enet1addr);++/* Is this a single eth/serial board? */+if((bd.bi_enet1addr[0]==0)&&+(bd.bi_enet1addr[1]==0)&&+(bd.bi_enet1addr[2]==0)&&+(bd.bi_enet1addr[3]==0)&&+(bd.bi_enet1addr[4]==0)&&+(bd.bi_enet1addr[5]==0)){+void*devp;++printf("Trimming devtree for single eth board\n");++devp=finddevice("/plb/opb/serial@ef600300");+if(!devp)+fatal("Can't find node for /plb/opb/serial@ef600300");+del_node(devp);++devp=finddevice("/plb/opb/ethernet@ef600900");+if(!devp)+fatal("Can't find node for /plb/opb/ethernet@ef600900");+del_node(devp);+}++ibm4xx_quiesce_eth((u32*)0xef600800,(u32*)0xef600900);++/* Fix up flash size in fdt for 4M boards. */+if(bd.bi_flashsize<0x800000){+u32regs[NUM_REGS];+void*devp=finddevice("/plb/ebc/nor_flash@0");+if(!devp)+fatal("Can't find FDT node for nor_flash!??");++printf("Fixing devtree for 4M Flash\n");++/* First fix up the base addresse */+getprop(devp,"reg",regs,sizeof(regs));+regs[0]=0;+regs[1]=0xffc00000;+regs[2]=0x00400000;+setprop(devp,"reg",regs,sizeof(regs));++/* Then the offsets */+devp=finddevice("/plb/ebc/nor_flash@0/partition@0");+if(!devp)+fatal("Can't find FDT node for partition@0");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++devp=finddevice("/plb/ebc/nor_flash@0/partition@1");+if(!devp)+fatal("Can't find FDT node for partition@1");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++devp=finddevice("/plb/ebc/nor_flash@0/partition@2");+if(!devp)+fatal("Can't find FDT node for partition@2");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++devp=finddevice("/plb/ebc/nor_flash@0/partition@3");+if(!devp)+fatal("Can't find FDT node for partition@3");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++devp=finddevice("/plb/ebc/nor_flash@0/partition@4");+if(!devp)+fatal("Can't find FDT node for partition@4");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++devp=finddevice("/plb/ebc/nor_flash@0/partition@6");+if(!devp)+fatal("Can't find FDT node for partition@6");+getprop(devp,"reg",regs,2*sizeof(u32));+regs[0]-=0x400000;+setprop(devp,"reg",regs,2*sizeof(u32));++/* Delete the FeatFS node */+devp=finddevice("/plb/ebc/nor_flash@0/partition@5");+if(!devp)+fatal("Can't find FDT node for partition@5");+del_node(devp);+}+}++voidplatform_init(unsignedlongr3,unsignedlongr4,unsignedlongr5,+unsignedlongr6,unsignedlongr7)+{+CUBOOT_INIT();+platform_ops.fixups=hotfoot_fixups;+platform_ops.exit=ibm40x_dbcr_reset;+fdt_init(_dtb_start);+serial_console_init();+}
@@ -0,0 +1,299 @@+/*+*DeviceTreeSourceforESTeem195EHotfoot+*+*Copyright2009AbsoluteValueSystems<solomon@linux-wlan.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"without+*anywarrantyofanykind,whetherexpressorimplied.+*/++/dts-v1/;++/{+#address-cells=<1>;+#size-cells=<1>;+model="est,hotfoot";+compatible="est,hotfoot";+dcr-parent=<&{/cpus/cpu@0}>;++aliases{+ethernet0=&EMAC0;+ethernet1=&EMAC1;+serial0=&UART0;+serial1=&UART1;+};++cpus{+#address-cells=<1>;+#size-cells=<0>;++cpu@0{+device_type="cpu";+model="PowerPC,405EP";+reg=<0x00000000>;+clock-frequency=<0>;/* Filled in by zImage */+timebase-frequency=<0>;/* Filled in by zImage */+i-cache-line-size=<0x20>;+d-cache-line-size=<0x20>;+i-cache-size=<0x4000>;+d-cache-size=<0x4000>;+dcr-controller;+dcr-access-method="native";+};+};++memory{+device_type="memory";+reg=<0x000000000x00000000>;/* Filled in by zImage */+};++UIC0:interrupt-controller{+compatible="ibm,uic";+interrupt-controller;+cell-index=<0>;+dcr-reg=<0x0c00x009>;+#address-cells=<0>;+#size-cells=<0>;+#interrupt-cells=<2>;+};++plb{+compatible="ibm,plb3";+#address-cells=<1>;+#size-cells=<1>;+ranges;+clock-frequency=<0>;/* Filled in by zImage */++SDRAM0:memory-controller{+compatible="ibm,sdram-405ep";+dcr-reg=<0x0100x002>;+};++MAL:mcmal{+compatible="ibm,mcmal-405ep","ibm,mcmal";+dcr-reg=<0x1800x062>;+num-tx-chans=<4>;+num-rx-chans=<2>;+interrupt-parent=<&UIC0>;+interrupts=<+0xb0x4/* TXEOB */+0xc0x4/* RXEOB */+0xa0x4/* SERR */+0xd0x4/* TXDE */+0xe0x4/* RXDE */>;+};++POB0:opb{+compatible="ibm,opb-405ep","ibm,opb";+#address-cells=<1>;+#size-cells=<1>;+ranges=<0xef6000000xef6000000x00a00000>;+dcr-reg=<0x0a00x005>;+clock-frequency=<0>;/* Filled in by zImage */++/* Hotfoot has UART0/UART1 swapped */++UART0:serial@ef600400{+device_type="serial";+compatible="ns16550";+reg=<0xef6004000x00000008>;+virtual-reg=<0xef600400>;+clock-frequency=<0>;/* Filled in by zImage */+current-speed=<0x9600>;+interrupt-parent=<&UIC0>;+interrupts=<0x10x4>;+};++UART1:serial@ef600300{+device_type="serial";+compatible="ns16550";+reg=<0xef6003000x00000008>;+virtual-reg=<0xef600300>;+clock-frequency=<0>;/* Filled in by zImage */+current-speed=<0x9600>;+interrupt-parent=<&UIC0>;+interrupts=<0x00x4>;+};+++IIC:i2c@ef600500{+compatible="ibm,iic-405ep","ibm,iic";+reg=<0xef6005000x00000011>;+interrupt-parent=<&UIC0>;+interrupts=<0x20x4>;++rtc@68{+/* Actually a DS1339 */+compatible="dallas,ds1307";+reg=<0x68>;+};++temp@4a{+/* Not present on all boards */+compatible="national,lm75";+reg=<0x4a>;+};+};++GPIO:gpio@ef600700{+#gpio-cells=<2>;+compatible="ibm,ppc4xx-gpio";+reg=<0xef6007000x00000020>;+gpio-controller;+};++gpio-leds{+compatible="gpio-leds";+status{+label="Status";+gpios=<&GPIO10>;+/* linux,default=trigger = ".."; */+};+radiorx{+label="Rx";+gpios=<&GPIO0xe0>;+/* linux,default=trigger = ".."; */+};+};+++EMAC0:ethernet@ef600800{+linux,network-index=<0x0>;+device_type="network";+compatible="ibm,emac-405ep","ibm,emac";+interrupt-parent=<&UIC0>;+interrupts=<+0xf0x4/* Ethernet */+0x90x4/* Ethernet Wake Up */>;+local-mac-address=[000000000000];/* Filled in by zImage */+reg=<0xef6008000x00000070>;+mal-device=<&MAL>;+mal-tx-channel=<0>;+mal-rx-channel=<0>;+cell-index=<0>;+max-frame-size=<0x5dc>;+rx-fifo-size=<0x1000>;+tx-fifo-size=<0x800>;+phy-mode="mii";+phy-map=<0x00000000>;+};++EMAC1:ethernet@ef600900{+linux,network-index=<0x1>;+device_type="network";+compatible="ibm,emac-405ep","ibm,emac";+interrupt-parent=<&UIC0>;+interrupts=<+0x110x4/* Ethernet */+0x90x4/* Ethernet Wake Up */>;+local-mac-address=[000000000000];/* Filled in by zImage */+reg=<0xef6009000x00000070>;+mal-device=<&MAL>;+mal-tx-channel=<2>;+mal-rx-channel=<1>;+cell-index=<1>;+max-frame-size=<0x5dc>;+rx-fifo-size=<0x1000>;+tx-fifo-size=<0x800>;+mdio-device=<&EMAC0>;+phy-mode="mii";+phy-map=<0x0000001>;+};+};++EBC0:ebc{+compatible="ibm,ebc-405ep","ibm,ebc";+dcr-reg=<0x0120x002>;+#address-cells=<2>;+#size-cells=<1>;++/* The ranges property is supplied by the bootwrapper+*andisbasedonthefirmware'sconfigurationofthe+*EBCbridge+*/+clock-frequency=<0>;/* Filled in by zImage */++nor_flash@0{+compatible="cfi-flash";+bank-width=<2>;+reg=<0x00xff8000000x00800000>;+#address-cells=<1>;+#size-cells=<1>;++/* This mapping is for the 8M flash+4Mflashhasallofssets-=4M,+andFeatFSpartitionisnotpresent*/++partition@0{+label="Bootloader";+reg=<0x7c00000x40000>;+/* read-only; */+};+partition@1{+label="Env_and_Config_Primary";+reg=<0x4000000x10000>;+};+partition@2{+label="Kernel";+reg=<0x4200000x100000>;+};+partition@3{+label="Filesystem";+reg=<0x5200000x2a0000>;+};+partition@4{+label="Env_and_Config_Secondary";+reg=<0x4100000x10000>;+};+partition@5{+label="FeatFS";+reg=<0x0000000x400000>;+};+partition@6{+label="Bootloader_Env";+reg=<0x7d00000x10000>;+};+};+};++PCI0:pci@ec000000{+device_type="pci";+#interrupt-cells=<1>;+#size-cells=<2>;+#address-cells=<3>;+compatible="ibm,plb405ep-pci","ibm,plb-pci";+primary;+reg=<0xeec000000x00000008/* Config space access */+0xeed800000x00000004/* IACK */+0xeed800000x00000004/* Special cycle */+0xef4800000x00000040>;/* Internal registers */++/* Outbound ranges, one memory and one IO,+*latercannotbechanged.Chipsupportsasecond+*IOrangebutwedon'tuseitfornow+*/+ranges=<0x020000000x000000000x800000000x800000000x000000000x20000000+0x010000000x000000000x000000000xe80000000x000000000x00010000>;++/* Inbound 2GB range starting at 0 */+dma-ranges=<0x420000000x00x00x00x00x80000000>;++interrupt-parent=<&UIC0>;+interrupt-map-mask=<0xf8000x00x00x7>;+interrupt-map=<+/* IDSEL 3 -- slot1 (optional) 27/29 A/B IRQ2/4 */+0x18000x00x00x1&UIC00x1b0x8+0x18000x00x00x2&UIC00x1d0x8++/* IDSEL 4 -- slot0, 26/28 A/B IRQ1/3 */+0x20000x00x00x1&UIC00x1a0x8+0x20000x00x00x2&UIC00x1c0x8+>;+};+};++chosen{+linux,stdout-path=&UART0;+};+};
On Fri, Jul 24, 2009 at 11:59:48AM -0400, Josh Boyer wrote:
Is this one different from the one you sent out yesterday? I plan to review
this support soon, but now I'm slightly confused :)
Crap, sorry -- I didn't see it show up in the mailing list archives so I
thought it got dropped into the spam bitbucket of the sky. The latter
mailing was sent just after I subscribed to the mailing list.
- Solomon
--
Solomon Peachy solomon@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Fri, Jul 24, 2009 at 12:10:30PM -0400, Solomon Peachy wrote:
On Fri, Jul 24, 2009 at 11:59:48AM -0400, Josh Boyer wrote:
quoted
Is this one different from the one you sent out yesterday? I plan to review
this support soon, but now I'm slightly confused :)
Crap, sorry -- I didn't see it show up in the mailing list archives so I
thought it got dropped into the spam bitbucket of the sky. The latter
mailing was sent just after I subscribed to the mailing list.
No worries. If they aren't different, I'll just pick the latest one to review.
Thanks for sending the patch! More board support is always welcome.
josh
On Fri, Jul 24, 2009 at 11:21:56AM -0400, Solomon Peachy wrote:
This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.
The 195E boards use ancient versions of u-boot and a slightly mangled
verison of the oft-abused ppcboot header.
There are several variants of the SBC deployed, single/dual
ethernet+serial, and also 4MB/8MB flash variations. In the interest of
having a single kernel image boot on all boards, the cuboot shim detects
the differences and mangles the DTS tree appropriately.
With the exception of the CF interface that was never populated on
production boards, this code/DTS supports all boardpop options.
Signed-off-by: Solomon Peachy <redacted>
@@ -0,0 +1,142 @@+/*+*OldU-bootcompatibilityforEsteem195EHotfootCPUBoard+*+*Author:SolomonPeachy<solomon@linux-wlan.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseversion2aspublished+*bytheFreeSoftwareFoundation.+*/++#include"ops.h"+#include"stdio.h"+#include"reg.h"+#include"dcr.h"+#include"4xx.h"+#include"cuboot.h"++#define TARGET_4xx+#define TARGET_HOTFOOT+#include"ppcboot.h"++staticbd_tbd;++#define NUM_REGS 3++staticvoidhotfoot_fixups(void)+{+u32uart=mfdcr(DCRN_CPC0_UCR)&0x7f;++dt_fixup_memory(bd.bi_memstart,bd.bi_memsize);++dt_fixup_cpu_clocks(bd.bi_procfreq,bd.bi_procfreq,0);+dt_fixup_clock("/plb",bd.bi_plb_busfreq);+dt_fixup_clock("/plb/opb",bd.bi_opbfreq);+dt_fixup_clock("/plb/ebc",bd.bi_pci_busfreq);+dt_fixup_clock("/plb/opb/serial@ef600300",bd.bi_procfreq/uart);+dt_fixup_clock("/plb/opb/serial@ef600400",bd.bi_procfreq/uart);++dt_fixup_mac_address_by_alias("ethernet0",bd.bi_enetaddr);+dt_fixup_mac_address_by_alias("ethernet1",bd.bi_enet1addr);++/* Is this a single eth/serial board? */+if((bd.bi_enet1addr[0]==0)&&+(bd.bi_enet1addr[1]==0)&&+(bd.bi_enet1addr[2]==0)&&+(bd.bi_enet1addr[3]==0)&&+(bd.bi_enet1addr[4]==0)&&+(bd.bi_enet1addr[5]==0)){+void*devp;++printf("Trimming devtree for single eth board\n");++devp=finddevice("/plb/opb/serial@ef600300");+if(!devp)+fatal("Can't find node for /plb/opb/serial@ef600300");+del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
@@ -0,0 +1,299 @@+/*+*DeviceTreeSourceforESTeem195EHotfoot+*+*Copyright2009AbsoluteValueSystems<solomon@linux-wlan.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"without+*anywarrantyofanykind,whetherexpressorimplied.+*/++/dts-v1/;++/{+#address-cells=<1>;+#size-cells=<1>;+model="est,hotfoot";+compatible="est,hotfoot";+dcr-parent=<&{/cpus/cpu@0}>;++aliases{+ethernet0=&EMAC0;+ethernet1=&EMAC1;+serial0=&UART0;+serial1=&UART1;+};++cpus{+#address-cells=<1>;+#size-cells=<0>;++cpu@0{+device_type="cpu";+model="PowerPC,405EP";+reg=<0x00000000>;+clock-frequency=<0>;/* Filled in by zImage */+timebase-frequency=<0>;/* Filled in by zImage */+i-cache-line-size=<0x20>;+d-cache-line-size=<0x20>;+i-cache-size=<0x4000>;+d-cache-size=<0x4000>;+dcr-controller;+dcr-access-method="native";+};+};++memory{+device_type="memory";+reg=<0x000000000x00000000>;/* Filled in by zImage */+};++UIC0:interrupt-controller{+compatible="ibm,uic";+interrupt-controller;+cell-index=<0>;+dcr-reg=<0x0c00x009>;+#address-cells=<0>;+#size-cells=<0>;+#interrupt-cells=<2>;+};++plb{+compatible="ibm,plb3";+#address-cells=<1>;+#size-cells=<1>;+ranges;+clock-frequency=<0>;/* Filled in by zImage */++SDRAM0:memory-controller{+compatible="ibm,sdram-405ep";+dcr-reg=<0x0100x002>;+};++MAL:mcmal{+compatible="ibm,mcmal-405ep","ibm,mcmal";+dcr-reg=<0x1800x062>;+num-tx-chans=<4>;+num-rx-chans=<2>;+interrupt-parent=<&UIC0>;+interrupts=<+0xb0x4/* TXEOB */+0xc0x4/* RXEOB */+0xa0x4/* SERR */+0xd0x4/* TXDE */+0xe0x4/* RXDE */>;+};++POB0:opb{+compatible="ibm,opb-405ep","ibm,opb";+#address-cells=<1>;+#size-cells=<1>;+ranges=<0xef6000000xef6000000x00a00000>;+dcr-reg=<0x0a00x005>;+clock-frequency=<0>;/* Filled in by zImage */++/* Hotfoot has UART0/UART1 swapped */++UART0:serial@ef600400{+device_type="serial";+compatible="ns16550";+reg=<0xef6004000x00000008>;+virtual-reg=<0xef600400>;+clock-frequency=<0>;/* Filled in by zImage */+current-speed=<0x9600>;
Just a question, but is the baud supposed to be 38400 or 9600? At first glance
it almost seems like a typo :).
unsigned long bi_bootflags; /* boot / reboot flag (for LynxOS) */
unsigned long bi_ip_addr; /* IP Address */
unsigned char bi_enetaddr[6]; /* Ethernet address */
+#if defined(TARGET_HOTFOOT)
+ /* second onboard ethernet port */
+ unsigned char bi_enet1addr[6];
+#define HAVE_ENET1ADDR
+#endif /* TARGET_HOOTFOOT */
unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in MHz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
@@ -74,6 +79,9 @@
unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
#endif
+#if defined(TARGET_HOTFOOT)
+ unsigned int bi_pllouta_freq; /* PLL OUTA speed, in Hz */
+#endif
#if defined(TARGET_HYMOD)
hymod_conf_t bi_hymod_conf; /* hymod configuration information */
#endif
@@ -94,6 +102,10 @@
unsigned char bi_enet3addr[6];
#define HAVE_ENET3ADDR
#endif
+#if defined(TARGET_HOTFOOT)
+ int bi_phynum[2]; /* Determines phy mapping */
+ int bi_phymode[2]; /* Determines phy mode */
+#endif
#if defined(TARGET_4xx)
unsigned int bi_opbfreq; /* OB clock in Hz */
int bi_iic_fast[2]; /* Use fast i2c mode */
Ok. So I'm not really all that thrilled with changes to ppcboot.h. We try to
keep this file as much in-sync with U-Boot as we can. Did your HOTFOOT changes
get pulled into upstream U-Boot?
josh
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
quoted
+ devp = finddevice("/plb/opb/serial@ef600300");
+ if (!devp)
+ fatal("Can't find node for /plb/opb/serial@ef600300");
+ del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
(The PPC405EP's serial boards aren't created equally; the first is a
dumb tx/rx-only port while the second has a full set of signals.
The hotfoot is wired such that the second, full-featured port is the
primary/console/boot port)
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
Ok. So I'm not really all that thrilled with changes to ppcboot.h.
We try to keep this file as much in-sync with U-Boot as we can. Did
your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the "standard" 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
- Solomon
--
Solomon Peachy solomon@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
quoted
quoted
+ devp = finddevice("/plb/opb/serial@ef600300");
+ if (!devp)
+ fatal("Can't find node for /plb/opb/serial@ef600300");
+ del_node(devp);
Slightly confused here. You delete the first serial node in the single eth
case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
Maybe a brief comment in the code explaining that would help. Also, I did
notice the DTS had them in the order you mention, and I forgot to come back
and correct my question there.
Shouldn't you do the quiesce conditionally if the other eth port doesn't
exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
OK. If it's not needed just yank it.
quoted
Ok. So I'm not really all that thrilled with changes to ppcboot.h.
We try to keep this file as much in-sync with U-Boot as we can. Did
your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the "standard" 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
josh
Just a question, but is the baud supposed to be 38400 or 9600? At first glance
it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
Cool. Just checking.
Um.. except, surely it's clearer to just list 38400 in decimal, rather
than 0x9600 which people are very likely to misread as 9600.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
quoted
quoted
Ok. So I'm not really all that thrilled with changes to ppcboot.h.
We try to keep this file as much in-sync with U-Boot as we can. Did
your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the "standard" 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
Solomon, any update on this? As far as I'm concerned, the ppcboot.h issue is
the only thing that really needs to be reworked before we bring this patch
in.
josh
On Mon, Aug 17, 2009 at 11:13:59AM -0400, Josh Boyer wrote:
quoted
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
Solomon, any update on this? As far as I'm concerned, the ppcboot.h issue is
the only thing that really needs to be reworked before we bring this patch
in.
Should I call the new version 'hotfoot.h' or 'ppcboot-hotfoot.h'?
- Solomon
--
Solomon Peachy solomon@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Thu, Aug 20, 2009 at 01:45:19PM -0400, Solomon Peachy wrote:
On Mon, Aug 17, 2009 at 11:13:59AM -0400, Josh Boyer wrote:
quoted
quoted
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
Solomon, any update on this? As far as I'm concerned, the ppcboot.h issue is
the only thing that really needs to be reworked before we bring this patch
in.
Should I call the new version 'hotfoot.h' or 'ppcboot-hotfoot.h'?