BDI2000 PTEs
Thanks a lot, Dan, It is working now. The only thing you omitted is allocation of abatro_pteptrs variable. In same file following has to be added as well: After lines cmd_line: .space 512 Add following: /* Room for two PTE table poiners, usually the kernel and current user * pointer to their respective root page table (pgdir). */ abatron_pteptrs: .space 8 Rudolf -Original Message- From: Dan Malek To: Rudolf Ladyzhenskii Cc: 'linuxppc-embedded at lists.linuxppc.org' Sent: 11/28/01 5:19 PM Subject: Re: BDI2000 PTEs Rudolf Ladyzhenskii wrote: All I need for kernel debugging is BAT only translation. I cleared it according to BDI2000 manual. UmmmI think you need more than that for debugging loadable modules. The BAT translation won't work for loadable modules, you have to find all of their code and data through page tables. I looked at 2.4.14 kernel. It only has BDI2000 support in file /arch/ppc/kernel/head_8xx.S Well hellI wonder why they were never updated in 2.4.14. Take a look at the PowerPC development kernels, then. Which lines do I have to add? Add this right after the 'bl load_up_mmu': /* Add helper information for the Abatron bdiGDB debugger. * We do this here because we know the mmu is disabled, and * will be enabled for real in just a few instructions. */ lis r5, abatron_pteptrs at h ori r5, r5, abatron_pteptrs at l stw r5, 0xf0(r0)/* This much match your Abatron config */ lis r6, swapper_pg_dir at h ori r6, r6, swapper_pg_dir at l tophys(r5, r5) stw r6, 0(r5) Good Luck. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] New PHY for ppc405_phy.c
I hope I am sending this to the right place, someone please correct me
if I am doing this wrong...
Our 405 board has a different PHY from those supported in the current
sources, the following patch makes our PHY work. If it looks
sensible, please apply.
Thanks,
-kb
--- linuxppc_2_4_devel/drivers/net/ppc405_phy.c Thu Nov 29 10:34:53 2001
+++ linux-penguinppc4/drivers/net/ppc405_phy.c Thu Nov 29 10:48:07 2001
@@ -579,6 +579,75 @@
},
};
+/* - */
+/* The Lucent Technologies LU3X31FT */
+
+/* register definitions */
+
+#define MII_LU3X31FT_PHYCTRLSTS 0x17/* PHY Control/Status Register */
+#define MII_LU3X31FT_IER0x1D/* PHY interrupt enable Register */
+#define MII_LU3X31FT_ISR0x1E/* PHY interrupt status Register */
+
+static void mii_parse_lu3x31ft_pcr(uint mii_reg, struct net_device *dev)
+{
+ struct fec_enet_private *fep = dev-priv;
+ volatile uint *s = (fep-phy_status);
+
+ *s = ~(PHY_STAT_SPMASK);
+
+ switch((mii_reg 8) 3) {
+ case 0:
+ *s |= PHY_STAT_10HDX;
+ break;
+ case 1:
+ *s |= PHY_STAT_10FDX;
+ break;
+ case 2:
+ *s |= PHY_STAT_100HDX;
+ break;
+ case 3:
+ *s |= PHY_STAT_100FDX;
+ break;
+ }
+}
+
+static phy_info_t phy_info_lu3x31ft = {
+ 0x90307421,
+ LU3X31FT,
+ 0,
+ (const phy_cmd_t []) { /* config */
+
+ /* parse cr and anar to get some info */
+
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* startup - enable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0x), NULL },
+ { mk_mii_write(MII_REG_CR, PHY_BMCR_RST_NEG), NULL }, /*
autonegotiate */
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* ack_int */
+
+ /* we need to read ISR, SR and ANER to acknowledge */
+
+ { mk_mii_read(MII_LU3X31FT_ISR), NULL },
+ { mk_mii_read(MII_REG_SR), mii_parse_sr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+
+ /* read pcr to get info */
+
+ { mk_mii_read(MII_LU3X31FT_PHYCTRLSTS), mii_parse_lu3x31ft_pcr
},
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* shutdown - disable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0xff80), NULL },
+ { mk_mii_end, }
+ },
+};
+
+
/* - */
/* The AMD Am79C875*/
@@ -659,6 +728,7 @@
phy_info_lxt971a,
phy_info_cs8952,
phy_info_dp83846A,
+ phy_info_lu3x31ft,
phy_info_Am79C875,
NULL
};
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] New PHY for ppc405_phy.c
On Thu, Nov 29, 2001 at 11:05:30AM -0500, Kent Borg wrote: I hope I am sending this to the right place, someone please correct me if I am doing this wrong... Looks good, applied. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] New PHY for ppc405_phy.c
Kent Borg wrote:
I hope I am sending this to the right place, someone please correct me
if I am doing this wrong...
Our 405 board has a different PHY from those supported in the current
sources, the following patch makes our PHY work. If it looks
sensible, please apply.
Thanks,
-kb
--- linuxppc_2_4_devel/drivers/net/ppc405_phy.c Thu Nov 29 10:34:53 2001
+++ linux-penguinppc4/drivers/net/ppc405_phy.c Thu Nov 29 10:48:07 2001
@@ -579,6 +579,75 @@
},
};
+/* -
*/
+/* The Lucent Technologies LU3X31FT */
+
+/* register definitions */
+
+#define MII_LU3X31FT_PHYCTRLSTS 0x17/* PHY Control/Status Register */
+#define MII_LU3X31FT_IER0x1D/* PHY interrupt enable Register */
+#define MII_LU3X31FT_ISR0x1E/* PHY interrupt status Register */
+
+static void mii_parse_lu3x31ft_pcr(uint mii_reg, struct net_device *dev)
+{
+ struct fec_enet_private *fep = dev-priv;
+ volatile uint *s = (fep-phy_status);
+
+ *s = ~(PHY_STAT_SPMASK);
+
+ switch((mii_reg 8) 3) {
+ case 0:
+ *s |= PHY_STAT_10HDX;
+ break;
+ case 1:
+ *s |= PHY_STAT_10FDX;
+ break;
+ case 2:
+ *s |= PHY_STAT_100HDX;
+ break;
+ case 3:
+ *s |= PHY_STAT_100FDX;
+ break;
+ }
+}
+
+static phy_info_t phy_info_lu3x31ft = {
+ 0x90307421,
+ LU3X31FT,
+ 0,
+ (const phy_cmd_t []) { /* config */
+
+ /* parse cr and anar to get some info */
+
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* startup - enable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0x), NULL },
+ { mk_mii_write(MII_REG_CR, PHY_BMCR_RST_NEG), NULL }, /*
autonegotiate */
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* ack_int */
+
+ /* we need to read ISR, SR and ANER to acknowledge */
+
+ { mk_mii_read(MII_LU3X31FT_ISR), NULL },
+ { mk_mii_read(MII_REG_SR), mii_parse_sr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+
+ /* read pcr to get info */
+
+ { mk_mii_read(MII_LU3X31FT_PHYCTRLSTS),
mii_parse_lu3x31ft_pcr },
+ { mk_mii_end, }
+ },
+ ( const phy_cmd_t []) { /* shutdown - disable interrupts */
+ { mk_mii_write(MII_LU3X31FT_IER, 0xff80), NULL },
+ { mk_mii_end, }
+ },
+};
+
+
/* -
*/
/* The AMD Am79C875*/
@@ -659,6 +728,7 @@
phy_info_lxt971a,
phy_info_cs8952,
phy_info_dp83846A,
+ phy_info_lu3x31ft,
phy_info_Am79C875,
NULL
};
Thanks,
-- armin
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Monta Vistas HHL 2.0 ppc-8xx_gcc(2.95.3) buggy?
Hi there I am trying to compile the latest(2.4.16) ppclinux_2_4 kernel for our custom MPC860 board and it wont boot(I get a signal 11 Oops). If I reduce gcc flag -O2 to -O1 I get as far as the first call to printk() in emit_log_char() where it Oops(signal 11). If I replace the printk.c file with the one found in MV HLL 2.0 kernel, It will boot just fine. Then I change -O1 back to -O2 and I get an Oops again. This time halfway through the booting process. I can run the MV 2.4.2 kernel without problems. I am on RH 7.1 with almost all updates applied. Also tried to compile it on RH 7.0 but got the same result(signal 11). This looks to me like a compiler problem, has anyone else had similar problems ? Where can I find a good cross compiler for ppc 8xx which will run on RH 7.1? Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops while routing
Hi everybody, Ok, time for an update on the problem bellow. First of all, many thanks to Andy Lowe for his patch. The problem was gone with it, but with some performance penalties that I would like to discuss. Even before applying the patch, we found out that the crash was caused by a memory leak in the system. When the memoty was exhauted, the kernel crashed. Furthermore, we discovered that turning CONFIG...MMAP off decreased considerably the leakage rate, at least in our test setup. Then, applying the patch stopped the leak. But, just as I mentioned before, the performance of our routing test decreased a lot. Best throughput rates dropped to 15 Mbps, against 46 Mbps before patching. I'm kind of lost with this performance variations. As far as I could see, the patch did not insert much processing overhead, so... Tips, commentaries, pointers on what to seek for... everything will be appreciated. []'s, Scopmailto:scop at digitel.com.br -- What's money? A man is a success if he gets up in the morning and goes to bed at night and in between does what he wants to do. ~Bob Dylan Monday, November 26, 2001, 1:54:19 PM, Ricardo Scop wrote: RS Hi, RS I'm doing some performance tests with a proprietary Linuxppc-based box RS configured as a routing system. The processor is MPC8255 @ 133 MHz (33Mhz on RS the bus) and Linux revision is 2.4.15pre8 rsync'ed from MVista linuxppc_2_4 RS repository. RS We are using two other Linux workstations to exercise the router, both RS running Netpipe 2.4, one as a client application, the other as a server. Each RS one is connected to a different fast ethernet port of our router box RS (100MHz, full-duplex mode) using cross cables. RS We're achieving throughputs around 40 Mbps with this setup, which is enough RS for our purposes. RS But, when we try a 30 MBytes' block in Netpipe, the kernel in our Linux box RS crashes big time (trace bellow, including ksymoops decode). We also tryed RS Linux 2.4.4 version, but then the performance slows down to around 13 Mbps. RS My questions are: RS Has anyone observed this kind of crash? RS Is there any workaround? RS Any pointers or suggestions will be greatly appreciated. RS Regards, RS ~Ricardo RS R SCOP Consulting. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops while routing
Ricardo Scop wrote: I'm kind of lost with this performance variations. As far as I could see, the patch did not insert much processing overhead, so... Perhaps if someone would post the patch for the rest of us to see we could be of some assistance. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
