ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[El Topo]

Hi guys:

I have ppclinux 2.4.devel (2.4.20) running on my 440gp ebony board
with ppcboot 2.0.0.  Normally I use tftp to get the compressed kernel
image to 440gp and bootm from memory. So far I have these issues:

1. for some reason, linux kernel sees the two eth interfaces but fails
to get the correct MAC addresses, thus when system fully boots up
"ifconfig" shows two eth0/eth1 with MAC addr as ff:ff:ff:ff:ff:ff, because
this is same as brd, many network services won't work.
I checked kernel source code and found that, in include/asm-ppc/ibm440.h,
there's a structure "board_info" holds MAC addresses of the two enet
interfaces. According to this header file: "Ebony firmware stores MAC
addresses in the F/W VPD area. The firmware must store the other dynamic
values in NVRAM like on the previous 40x systems so they  should be
accessible if we really want them."
So, my question is: how can I get ibm440's EMAC info? from NVRAM?
the kernel I am using now does not support NVRAM for ppc yet.

2. to temporarily solve the problem in 1., I modifed
drivers/net/ibm_ocp/ibm_ocp_enet.c:ocp_enet_probe(),
when reading the MAC address, I simply assigned some fake MAC addrs
to dev->dev_addr, and the network part is working now, I can telnet
into my 440gp, also ftp out from it.
I did relatively enough tests using tftp from my server to get the kernel
image loaded to 440gp and bootm to bring the system up, everything
looked fine. Then I decided that I want to copy the memory area of
kernel image to flash and boot from there. the booting seemed OK,
no errors reported, except that after the system fully booted up I found
I could not ping the network from/into 440gp box.
Several minutes later I found if I tftp something, let's see, a 1-byte
file, or even a non-existent file, then bootm from flash would bring
up working network interfaces. It looked like "tftp" does some
initialization
for the network interfaces.
I read ppcboot-2.0.0/common/cmd_net.c:netboot_common(), which
calls net/net.c:NetLoop(), in which I see functions like eth_halt(),
eth_init(bd) get called.
Here's my 2nd question: is it a good idea that I modify ppcboot to
include these network initialization functions just before booting my
kernel image? Maybe this is not necessary but I really could not figure
out why the "tftp" before loading kernel image made the difference
on the network.

Thanks,

El.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[Wolfgang Denk]

In message <000d01c2fe74$83264520$1464a8c0@sjeng3> you wrote:
>
> Here's my 2nd question: is it a good idea that I modify ppcboot to
> include these network initialization functions just before booting my
> kernel image? Maybe this is not necessary but I really could not figure
> out why the "tftp" before loading kernel image made the difference
> on the network.

This is a somewhat philosophical question, and opinions differ.  IMHO
a  Linux  driver  usually should perform all required initializations
himself instead on relying on certain  things  to  be  done  by  some
firmware.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[erik.teose]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

> 1. for some reason, linux kernel sees the two eth interfaces but fails
> to get the correct MAC addresses, thus when system fully boots up
> "ifconfig" shows two eth0/eth1 with MAC addr as ff:ff:ff:ff:ff:ff, because
> this is same as brd, many network services won't work.
> I checked kernel source code and found that, in include/asm-ppc/ibm440.h,
> there's a structure "board_info" holds MAC addresses of the two enet
> interfaces. According to this header file: "Ebony firmware stores MAC
> addresses in the F/W VPD area. The firmware must store the other dynamic
> values in NVRAM like on the previous 40x systems so they  should be
> accessible if we really want them."
> So, my question is: how can I get ibm440's EMAC info? from NVRAM?
> the kernel I am using now does not support NVRAM for ppc yet.

Are you using kernel code supplied by MontaVista (MV)? I had the same
problem;
we are using MontaVista 3.0 for the Ebony board, and I had trouble with
the interface from u-boot 0.2.0 to the MV kernel. The MV code is very
specific to the bootrom supplied by IBM; that bootrom is "custom" to each
unique Ebony board, because the 2 MAC addresses are stored at the end of the
bootrom (that's the "VPD" area). I had to modify 3 MV files to get the MAC
address passed in from u-boot to be used by the MV kernel
(kernel/arch/ppc/platforms/ebony.c,
kernel/include/asm-ppc/ibm440.h, and kernel/include/asm-ppc/ibm4xx.h). I
have attached
my patches for these files.

After I got the MAC address to transfer over from u-boot, I had trouble with
nfs mounting
the root filesystem (I did not want to use bootp/dhcp in the nfs mounting
process). I had to
modify kernel/net/ipv4/ipconfig.c to get this to work (I've attached this
patch as well).

Hope this helps.

Erik Teose
erik.teose@tek.com


[-- Attachment #2: ebony.c.patch --]
[-- Type: application/octet-stream, Size: 2816 bytes --]

--- ebony.c.orig	Thu Mar 27 17:07:13 2003
+++ ebony.c	Fri Mar 28 09:06:53 2003
@@ -125,6 +125,7 @@ extern void abort(void);
 
 /* Global Variables */
 unsigned char __res[sizeof (bd_t)];
+unsigned char __res_uboot[sizeof (bd_uboot_t)];
 
 static void __init
 ebony_calibrate_decr(void)
@@ -325,7 +326,7 @@ static void __init
 ebony_setup_arch(void)
 {
 	bd_t *bip = (bd_t *)__res;
-	unsigned char * vpd_base;
+	bd_uboot_t *bi_uboot_p = (bd_uboot_t *) __res_uboot;
 
 #if !defined(CONFIG_BDI_SWITCH)
 	/*
@@ -336,9 +337,16 @@ ebony_setup_arch(void)
 #endif
 
 	/* Retrieve MAC addresses */
+#if 0
 	vpd_base = ioremap64(EBONY_VPD_BASE, EBONY_VPD_SIZE);
 	memcpy(bip->bi_enetaddr[0],EBONY_NA0_ADDR(vpd_base),6);
 	memcpy(bip->bi_enetaddr[1],EBONY_NA1_ADDR(vpd_base),6);
+#endif
+	memcpy(bip->bi_enetaddr[0], bi_uboot_p->bi_enetaddr, 6);
+	memcpy(bip->bi_enetaddr[1], bi_uboot_p->bi_enetaddr, 6);
+	bip->bi_enetaddr[1][5]++;	/* mac addr of second enet port is one more
+								 * than first one's
+								 */
 
 	/* Setup TODC access */
 	TODC_INIT(TODC_TYPE_DS1743,
@@ -468,10 +476,51 @@ ebony_init_irq(void)
 		irq_desc[i].handler = ppc4xx_pic;
 }
 
-void __init platform_init(unsigned long r3, unsigned long r4,
+/*
+ * Input(s):
+ *   r3 - Optional pointer to a board information structure.
+ *   r4 - Optional pointer to the physical starting address of the init RAM
+ *        disk.
+ *   r5 - Optional pointer to the physical ending address of the init RAM
+ *        disk.
+ *   r6 - Optional pointer to the physical starting address of any kernel
+ *        command-line parameters.
+ *   r7 - Optional pointer to the physical ending address of any kernel
+ *        command-line parameters.
+ */
+void __init 
+platform_init(unsigned long r3, unsigned long r4,
 		unsigned long r5, unsigned long r6, unsigned long r7)
 {
+#if 0
 	parse_bootinfo((struct bi_record *) (r3 + KERNELBASE));
+#endif
+
+    /*
+     * If we were passed in board information, copy it into the
+     * residual data area.
+     */
+    if (r3) {
+        memcpy((void *) __res_uboot, (void *) (r3 + KERNELBASE),
+               sizeof (bd_uboot_t));
+
+    }
+#if defined(CONFIG_BLK_DEV_INITRD)
+    /*
+     * If the init RAM disk has been configured in, and there's a valid
+     * starting address for it, set it up.
+     */
+    if (r4) {
+        initrd_start = r4 + KERNELBASE;
+        initrd_end   = r5 + KERNELBASE;
+    }
+#endif /* CONFIG_BLK_DEV_INITRD */
+
+    /* Copy the kernel command line arguments to a safe place. */
+    if (r6) {
+        *(char *) (r7 + KERNELBASE) = 0;
+        strcpy(cmd_line, (char *) (r6 + KERNELBASE));
+    }
 
 	ppc_md.setup_arch = ebony_setup_arch;
 	ppc_md.show_cpuinfo = ebony_show_cpuinfo;

[-- Attachment #3: ibm440.h.patch --]
[-- Type: application/octet-stream, Size: 2627 bytes --]

--- ibm440.h.orig	Thu Mar 27 16:56:20 2003
+++ ibm440.h	Fri Mar 28 08:47:40 2003
@@ -44,6 +44,58 @@
 typedef struct board_info {
 	unsigned char	 bi_enetaddr[2][6];	/* EMAC addresses */
 } bd_t;
+
+typedef struct bd_info {
+    unsigned long   bi_memstart;    /* start of DRAM memory */
+    unsigned long   bi_memsize; /* size  of DRAM memory in bytes */
+    unsigned long   bi_flashstart;  /* start of FLASH memory */
+    unsigned long   bi_flashsize;   /* size  of FLASH memory */
+    unsigned long   bi_flashoffset; /* reserved area for startup monitor */
+    unsigned long   bi_sramstart;   /* start of SRAM memory */
+    unsigned long   bi_sramsize;    /* size  of SRAM memory */
+#if defined(CONFIG_8xx) || defined(CONFIG_8260)
+    unsigned long   bi_immr_base;   /* base of IMMR register */
+#endif
+    unsigned long   bi_bootflags;   /* boot / reboot flag (for LynxOS) */
+    unsigned long   bi_ip_addr; /* IP Address */
+    unsigned char   bi_enetaddr[6]; /* Ethernet adress */
+    unsigned short  bi_ethspeed;    /* Ethernet speed in Mbps */
+    unsigned long   bi_intfreq; /* Internal Freq, in MHz */
+    unsigned long   bi_busfreq; /* Bus Freq, in MHz */
+#if defined(CONFIG_8260)
+    unsigned long   bi_cpmfreq; /* CPM_CLK Freq, in MHz */
+    unsigned long   bi_brgfreq; /* BRG_CLK Freq, in MHz */
+    unsigned long   bi_sccfreq; /* SCC_CLK Freq, in MHz */
+    unsigned long   bi_vco;     /* VCO Out from PLL, in MHz */
+#endif
+    unsigned long   bi_baudrate;    /* Console Baudrate */
+#if defined(CONFIG_405GP) || \
+    defined(CONFIG_405CR) || \
+    defined(CONFIG_440)   || \
+    defined(CONFIG_405)
+    unsigned char   bi_s_version[4];    /* Version of this structure */
+    unsigned char   bi_r_version[32];   /* Version of the ROM (IBM) */
+    unsigned int    bi_procfreq;    /* CPU (Internal) Freq, in Hz */
+    unsigned int    bi_plb_busfreq; /* PLB Bus speed, in Hz */
+    unsigned int    bi_pci_busfreq; /* PCI Bus speed, in Hz */
+    unsigned char   bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
+#endif
+#if defined(CONFIG_HYMOD)
+    hymod_conf_t    bi_hymod_conf;  /* hymod configuration information */
+#endif
+#if defined(CONFIG_EVB64260) || defined(CONFIG_PN62)
+    /* second onboard ethernet port */
+    unsigned char   bi_enet1addr[6];
+#endif
+#if defined(CONFIG_EVB64260)
+    /* third onboard ethernet port */
+    unsigned char   bi_enet2addr[6];
+#endif
+#if defined(CONFIG_NX823)
+    unsigned char   bi_sernum[8];
+#endif
+} bd_uboot_t;
+
 #endif /* __ASSEMBLY__ */
 
 #ifndef NR_BOARD_IRQS

[-- Attachment #4: ibm4xx.h.patch --]
[-- Type: application/octet-stream, Size: 272 bytes --]

--- ibm4xx.h.orig	Thu Mar 27 17:28:08 2003
+++ ibm4xx.h	Thu Mar 27 17:28:25 2003
@@ -22,6 +22,7 @@
  */
 #ifndef __ASSEMBLY__
 extern unsigned char __res[];
+extern unsigned char __res_uboot[];
 
 /* Device Control Registers */
 #define stringify(s)	tostring(s)

[-- Attachment #5: ipconfig.c.patch --]
[-- Type: application/octet-stream, Size: 422 bytes --]

--- ipconfig.c.orig	Wed Apr  2 14:38:21 2003
+++ ipconfig.c	Thu Apr  3 10:36:18 2003
@@ -1149,7 +1149,8 @@ static int __init ip_auto_config(void)
 	     && root_server_addr == INADDR_NONE
 	     && ic_servaddr == INADDR_NONE) ||
 #endif
-	    ic_first_dev->next) {
+		/* erikt: '!' needed so u-boot will work with this code */
+	    !ic_first_dev->next) {
 #ifdef IPCONFIG_DYNAMIC
 
 		if (ic_dynamic() < 0) {

Re: ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[El Topo]

> This is a somewhat philosophical question, and opinions differ.  IMHO
> a  Linux  driver  usually should perform all required initializations
> himself instead on relying on certain  things  to  be  done  by  some
> firmware.
>
>
> Wolfgang Denk

Thanks Wolfgang for the input.

El.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[El Topo]

> Are you using kernel code supplied by MontaVista (MV)? I had the same
> problem;
> we are using MontaVista 3.0 for the Ebony board, and I had trouble with
> the interface from u-boot 0.2.0 to the MV kernel. The MV code is very
> specific to the bootrom supplied by IBM; that bootrom is "custom" to each
> unique Ebony board, because the 2 MAC addresses are stored at the end of
the
> bootrom (that's the "VPD" area). I had to modify 3 MV files to get the MAC
> address passed in from u-boot to be used by the MV kernel
> (kernel/arch/ppc/platforms/ebony.c,
> kernel/include/asm-ppc/ibm440.h, and kernel/include/asm-ppc/ibm4xx.h). I
> have attached
> my patches for these files.
>
> After I got the MAC address to transfer over from u-boot, I had trouble
with
> nfs mounting
> the root filesystem (I did not want to use bootp/dhcp in the nfs mounting
> process). I had to
> modify kernel/net/ipv4/ipconfig.c to get this to work (I've attached this
> patch as well).
>
> Hope this helps.
>
> Erik Teose
> erik.teose@tek.com

Thank you Erik, I will try your patchs today.

El.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ppcboot 2.0.0 + ppclinux2.4.devel, network weirdo

[Wolfgang Denk]

In message <BA0E4392AD99D040885C414D992C24BE03615100@us-bv-m11> you wrote:
>
> Are you using kernel code supplied by MontaVista (MV)? I had the same
> problem;
> we are using MontaVista 3.0 for the Ebony board, and I had trouble with
> the interface from u-boot 0.2.0 to the MV kernel. The MV code is very
> specific to the bootrom supplied by IBM; that bootrom is "custom" to each
> unique Ebony board, because the 2 MAC addresses are stored at the end of the
> bootrom (that's the "VPD" area). I had to modify 3 MV files to get the MAC
> address passed in from u-boot to be used by the MV kernel
> (kernel/arch/ppc/platforms/ebony.c,
> kernel/include/asm-ppc/ibm440.h, and kernel/include/asm-ppc/ibm4xx.h). I
> have attached
> my patches for these files.

You have always the option to completely ignore such dfaults and  use
the  mechanisms  available  in  U-Boot,  for example just storing the
addresses in U-Boot environment variables (like  95%  of  all  boards
do).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
1000 pains                                              = 1 Megahertz

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/