[PATCH 1/2] PAL: Support of the fixed PHY
On Thu, 4 May 2006 19:21:12 -0500
Andy Fleming afleming at freescale.com wrote:
What happened to this patch? It doesn't seem to have been applied to
any trees. Well, I'm gonna give it a little review now, since I have
some time.
Under final review/updates, gonna to push uptodated shortly...
On Apr 3, 2006, at 10:26, Vitaly Bordug wrote:
This makes it possible for HW PHY-less boards to utilize PAL goodies.
Generic routines to connect to fixed PHY are provided, as well as
ability
to specify software callback that fills up link, speed, etc.
information
into PHY descriptor (the latter feature not tested so far).
Signed-off-by: Vitaly Bordug vbordug at ru.mvista.com
---
[snip]
+/
*-
+ * This func is used to create all the necessary stuff, bind
+ * the fixed phy driver and register all it on the mdio_bus_type.
+ * speed is either 10 or 100, duplex is boolean.
+ * number is used to create multiple fixed PHYs, so that several
devices can
+ * utilize them simultaneously.
+
*-
*/
+static int fixed_mdio_register_device(int number, int speed, int
duplex)
+{
+ struct mii_bus *new_bus;
+ struct fixed_info *fixed;
+ struct phy_device *phydev;
+ int err = 0;
+
+ struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
+
+ if (NULL == dev)
+ return -EINVAL;
+
+ new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
+
+ if (NULL == new_bus)
+ return -ENOMEM;
You don't free dev, here
+
+ fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
+
+ if (NULL == fixed) {
+ kfree(new_bus);
+ return -ENOMEM;
+ }
And dev
+
+ fixed-regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
You don't check for failure for regs's allocation.
As to upper notes, OK.
[snip]
+ /* create phy_device and register it on the mdio bus */
+ phydev = phy_device_create(new_bus, 0, 0);
+
+ /*
+Put the phydev pointer into the fixed pack so that bus read/
write code could be able
+to access for instance attached netdev. Well it doesn't have to
do so, only in case
+of utilizing user-specified link-update...
+*/
+ fixed-phydev = phydev;
+
+ if(NULL == phydev) {
+ err = -ENOMEM;
+ goto bus_register_fail;
+ }
You're going to need to change this, because phydev isn't guaranteed
to be NULL in the event of a failure to allocate. it will be ERR_PTR
(-ENOMEM). I know you changed this in phy_device_create(), but I
have more on that later. You should do:
if (IS_ERR(phydev)) {
err = PTR_ERR(-ENOMEM);
goto bus_register_fail;
}
Assuming IS_ERR will shoot on NULL too, the code is not quite right(see below)
:)
But I agree this check is odd - will fix.
[snip]
+
+ return 0;
+
+bus_register_fail:
+ kfree(new_bus);
You need to free regs and dev, too
ok
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 459443b..c87f89e 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -66,7 +66,7 @@ int mdiobus_register(struct mii_bus *bus
phydev = get_phy_device(bus, i);
if (IS_ERR(phydev))
- return PTR_ERR(phydev);
+ continue;
No. Why'd you change that? Now mdiobus_register doesn't return an
error if memory runs out. Here's how the system works:
get_phy_device() can return one of three things:
1) A pointer to a newly allocated phy_device
2) a NULL pointer, indicating that there is no PHY at that address
(indicated by the bus returning all Fs)
3) an error (due to bus read failure, or to memory allocation
failure, as indicated by PTR_ERR(phydev)
This change has several issues:
1) due to the change below, IS_ERR(phydev) is never true
2) If you continue, mdiobus_register() will not inform its caller
that it failed.
I am not really stick to this change, but it simply does not work otherwise.
I want the whole bus to be scanned, and the code scans until first fail, and
returns error when there's no phy. Hereby, having phy's on 0 and 3 I end up
with only 0 registered on bus. So maybe check for NULL and continue, check for
err and return... Will inquire and fix - no big deal.
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
phy_device.c
index 7da0e3d..0dffecf 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -46,6 +46,35 @@ static struct phy_driver genphy_driver;
extern int mdio_bus_init(void);
extern void mdio_bus_exit(void);
+struct phy_device* phy_device_create(struct mii_bus *bus, int
addr, int phy_id)
+{
+ struct phy_device
frequent sig 11 with malloc() on mpc8xx
Wolfgang Denk wrote: In message 4459B1CF.60909 at eisodus.com you wrote: We are having a frequent sig 11 problem on our custom mpc852t board with linux kernel 2.6.14 and U-boot version 1.1.3 That's a FAQ. I had the same problem with 2.4 kernel and after posting the problem This confirms that the FAQ matches your problem. See http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly Thanks for the reply. We have checked the cpu sdram settings and would re-check the sdram initialization sequence. However the problem faced is following: The sig. 11 is generated at a specific instance of accessing memory areas in range of 0x0024 - 0x00C8 (i.e low address range). AFAIK this is assigned to kernel area. We have a ptrintk in arch/ppc/mm/fault.c which shows the frequent page fault and its recovery from the fault, however as soon as the DAR loads 0x0024 or such low address we get a sig. 11. Bad emulation malloctest/657 NIP: 3c10 instruction: opcode: 0 A: 0 B: 0 C: 0 code: 0 rc: 0 pte @ 0x3c10: (0xc1d3b300)-(0xc020f000)-0x01c2b889 RPN: 01c2b PP: 2 SPS: 1 SH: 0 CI: 0 v: 1 Kernel VA for NIP c1c2bc10 pte @ 0xc1c2bc10: no pmd Oops: kernel access of bad area, sig: 11 [#1] NIP: C00286C8 LR: C0186684 SP: C02CDCA0 REGS: c02cdbf0 TRAP: 0300Not tainted MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: , DSISR: C200 here the DAR is 0x TASK = c1d0e070[657] 'malloctest' THREAD: c02cc000 We have tested the SDRAM in both U-boot (mtest) and linux, and the tests doesnt show anything wrong with the SDRAM. thanks in advance.
Bad page state in process 'swapper'
Hi, I'm quoting here Grant's answer: * On 4/11/06, Vincent Winstead vwinstead at yahoo.com wrote: I'm having a real difficulty trying to get linux onto this board. So I'm finally turning to the community for help. The only people that have documented their approach to putting open source linux onto the ML310 board have used bitkeeper to download the kernel for the project, but bitkeeper isn't used any more is it? I've been going straight to kernel.org and getting kernels from there and crosscompiling them on my machine to be transported to the ppc core on the ML310. Is this wrong? Is there a patch or some kernel source that I don't know about for PPC? Thanks! Are you using 2.4 or 2.6? Support for the ML300 ML403 is in the mainline 2.6 git tree. As long as you've got an xparameters.h file for your FPGA bitstream, you should be able to port a 2.6 kernel really easily. If you want to use 2.4, you can pull the linuxppc rsync mirror which has ML300 support in it. http://www.penguinppc.org/kernel/ (Look at the very bottom of the page for the RSYNC mirror) Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 399-0195 * After changing the xparameters.h, I was able to boot with the 2.6.16.13 kernel, which I got from kernel.org, but then I'm having a bad page problem as shown in the output below: loaded at: 0040 006011A0 board data at: 005FF124 005FF1A0 relocated to: 004051B4 00405230 zimage at: 0040592D 00495B48 initrd at: 00496000 005FEE44 avail ram: 00602000 0400 Linux/PPC load: console=ttyS0,9600 Uncompressing Linux...done. Now booting the kernel Linux version 2.6.16.13 (root at rgdev) (gcc version 3.4.1) #19 Fri May 5 13:39:53 PHT 2006 Xilinx Virtex-II Pro port Port by MontaVista Software, Inc. (source at mvista.com) Built 1 zonelists Kernel command line: console=ttyS0,9600 Xilinx INTC #0 at 0x4120 mapped to 0xFDFFE000 PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 62060k available (908k kernel code, 364k data, 64k init, 0k highmem) Bad page state in process 'swapper' page:c01539c0 flags:0x0080 mapping: mapcount:0 count:1 Trying to fix it up, but a reboot is needed Backtrace: Call Trace: [C012DDF0] [C00094B4] show_stack+0x58/0x180 (unreliable) [C012DE20] [C00452EC] bad_page+0x5c/0xa0 [C012DE40] [C0045DD0] get_page_from_freelist+0x2cc/0x454 [C012DE90] [C0045FAC] __alloc_pages+0x54/0x278 [C012DED0] [C005869C] cache_alloc_refill+0x2e0/0x53c [C012DF10] [C0058398] kmem_cache_alloc+0x50/0x74 [C012DF30] [C00594A8] kmem_cache_create+0x3a0/0x508 [C012DFA0] [C013846C] kmem_cache_init+0x180/0x3a0 [C012DFD0] [C012E5E4] start_kernel+0x138/0x1a4 [C012DFF0] [C000225C] start_here+0x44/0xb0 Now, I tried to debug the functions in the call trace, and it seems that the prep_new_page function calls the bad_page because the test for page_count(page) != 0 is TRUE (count value is 1). I know that the hardware or the memory is working because I have 2.4.20 running. What could probably cause this problem? Is there a patch for ml300 available to fix this? Many thanks!!! * Richard __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
frequent sig 11 with malloc() on mpc8xx
In message 445B1019.9010103 at eisodus.com you wrote: ... We have tested the SDRAM in both U-boot (mtest) and linux, and the tests doesnt show anything wrong with the SDRAM. No, of course not. Please read the FAQ to understand why standard RAM tests will never detect this type of problem. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Here is an Appalachian version of management's answer to those who are concerned with the fate of the project: Don't worry about the mule. Just load the wagon. - Mike Dennison's hillbilly uncle
Some issues while booting the 2.6.13.4 kernel on PPC440GR with CMD649 IDE
Hi All, I am porting the 2.6.13.4 kernel to PPC440GR board. When I try to boot the kernel with CMD649 IDE support enabled, I get kernel panic. Without CMD649, the kernel boots just fine. I read the PCI config space from the driver (inside do_ide_setup_pci_device function) and verified that DEVICE id,VENDOR id and interrupt lines are correct. However, bar address does not seem to be correct (actual phy and virtual set while PCI bridge config is 0xa000). Below is the kernel boot log for reference: .. .. ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx CMD649: IDE controller at PCI slot :00:0c.0 CMD649: chipset revision 1 CMD649: 100% native mode on irq 25 Data machine check in kernel mode. PLB0: BEAR=0x ACR= 0x BESR= 0x360eff98 POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x BESR1=0x OPB0: BEAR=0x0151 BSTAT=0x Oops: machine check, sig: 7 [#1] NIP: LR: C0106024 SP: C1981EC0 REGS: c026af50 TRAP: 0202Not tainted MSR: EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00 TASK = c1134b10[1] 'swapper' THREAD: c198 Last syscall: 120 GPR00: FDFFEFD2 C1981EC0 C1134B10 0060 FDFEE004 0002 C1981EA8 GPR08: C027 0008 FDFEE004 3000 C0277CB0 C0277CB0 GPR16: C0277CB0 0019 C0277CB0 C0277CB0 C113 C1981F58 C113 GPR24: C0265A2A C113 FFD0 C0265A08 4000 C0277CB0 C0277CB0 NIP [] 0x0 LR [c0106024] ide_pci_setup_ports+0x61c/0x71c Call trace: [c010633c] do_ide_setup_pci_device+0x218/0x464 [c01065a8] ide_setup_pci_device+0x20/0x9c [c02298d0] cmd64x_init_one+0x24/0x34 [c022a2f0] ide_scan_pcidev+0x80/0xc4 [c022a360] ide_scan_pcibus+0x2c/0xf8 [c022a24c] ide_init+0x58/0x7c [c0001868] init+0x7c/0x2cc [c0004b90] kernel_thread+0x48/0x64 Data machine check in kernel mode. PLB0: BEAR=0x ACR= 0x BESR= 0x360eff98 POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x BESR1=0x OPB0: BEAR=0x0151 BSTAT=0x Oops: machine check, sig: 7 [#2] NIP: LR: C00028DC SP: C026AE70 REGS: c026af50 TRAP: 0202Not tainted MSR: EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00 TASK = c1134b10[1] 'swapper' THREAD: c198 Last syscall: 120 GPR00: 0800 C026AE70 C1134B10 C026AE80 0C1B C027 C01E511C GPR08: C01E C00028DC 00021002 C0003CDC C1134CD8 3000 C0277CB0 C0277CB0 GPR16: C0277CB0 0019 C0277CB0 C0277CB0 C113 C1981F58 C113 GPR24: C0265A2A C113 FFD0 C0265A08 4000 C026AF50 0007 NIP [] 0x0 LR [c00028dc] ret_from_except+0x0/0x18 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. This is what I get when I print some PCI config space parameters: VENDOR ID: 0x1095 DEVICE ID: 0x0649 INTERRUPT LINE: 0x1C REVISION: 0x01 BASE REG 0 is: 0xFFF0 BASE REG 1 is: 0xFFF0 BASE REG 2 is: 0xFFE0 BASE REG 3 is: 0xFFE0 The pci command from u-Boot shows the following: = pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class __00.00.00 0x1014 0x027f Bridge device 0x80 00.0c.00 0x1095 0x0649 Mass storage controller 0x04 = I enabled the following for CMD649 in kernel configuration: CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_IDEDMA=y Please let me know if - anybody has seen this error before/knows the fix for this issue. Thanks for the help. -Vinay. Yahoo! India Answers: Share what you know. Learn something new. http://in.answers.yahoo.com
frequent sig 11 with malloc() on mpc8xx
Wolfgang Denk wrote: No, of course not. Please read the FAQ to understand why standard RAM tests will never detect this type of problem. Best regards, Wolfgang Denk Thanks for the reply. We are aware that its a FAQ and we rechecked the SDRAM configuration, everything seems fine. We disabled burst mode and tried but that didnt help. Now we want to disable cache and check. Is the cache disabled from u-boot or linux? Where do we have to modify the code to disable the cache completely. Basically we want to run the linux without using cache. regards, gautam.
Moving from 2.4 to 2.6 kernel
Grant Likely wrote: On 5/4/06, Chris Dumoulin cdumoulin at ics-ltd.com wrote: I'm looking into getting a BDI 2000 so I can start stepping through and see what is going on. I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx folder, but I did not use any of that in my code. It looks like this is intended to be used with the BSP that is generated by Xilinx Platform Studio. I've tried generating the BSP this way, but the generated code is obviously not a complete patch to port Linux to your hardware, and I figure that by the time I figure out what I do/don't have to add, I might as well write the whole thing by myself. Have you had success integrating the automatically generated BSP from Xilinx Platform Studio? No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4 is). However, you do need to extract the xparameters.h file from the platform studio BSP. You can generate a Linux BSP w/o actually telling it where your Linux tree is. Once its generated; pull out xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in your source tree. Note: it's important that you generate a LINUX BSP; not a 'standalone' bsp. If you don't, then you'll be missing a bunch of #defines. Let me say that once more for clarity: The only file you need from platform studio is the generated xparameters.h This will give you at the very least a serial port driver. Once your booting with that, you can focus on other device drivers. Trust me; this is the path of far less pain. Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 399-0195 I generated the xparameters_ml300.h file and built my kernel configured for the ML300 board, but I still had the same problem. I'm wondering if there's something in the hardware that's not being setup by u-boot as the linux kernel expects it. I'm looking through the ML300 code in u-boot 1.1.4 to see if can spot anything that's being done in there that's not being done in my u-boot code. Do you have any ideas about some hardware (or other) initialization that I could be neglecting to do in u-boot that might cause things to hang? On a similar note, is there any guide to porting u-boot that I could read that would enumerate all the steps I should be taking in u-boot? I know the README in the u-boot source basically says to browse the mailing list (which I'm doing), read the DULG (which I've done), and read the source (which I'm also doing), but some kind of succinct guide would be nice, if it exists. Cheers, Chris -- *--Christopher Dumoulin--* Software Team Leader http://ics-ltd.com/ http://ics-ltd.com/ Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON K1J 9G2 (613)749-9241 1-800-267-9794 (USA only) This e-mail is private and confidential and is for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient.
Calculating virtual address from physical address
I'm using a Virtex II Pro-based board with a PPC405. The board is hanging somewhere very early in the kernel boot process. I believe it may be dying at the point where the MMU is enabled. In order to determine the exact point at which my board hangs, I'm blinking two LEDs in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I am only able to successfully access the LEDs before the MMU is turned on, but I can't be sure that I'm calculating the virtual address properly when I try to access the LED after the MMU is turned on. My LEDs are at address 0x4F60 and my CONFIG_KERNEL_START is 0xC000. If this address were low enough, I would just add 0xC000 to the address to get the virtual address, but since my LED address is so high, the sum will be well past the 32-bit maximum address value. How is a virtual address calculated for a high address like 0x4F60? BTW, he is the assembly code that I'm working with (from arch/ppc/kernel/head_4xx.S): .text _GLOBAL(_stext) _GLOBAL(_start) /* Save parameters we are passed. */ mrr31,r3 mrr30,r4 mrr29,r5 mrr28,r6 mrr27,r7 /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_0 stw r25,0(r26) /* We have to turn on the MMU right away so we get cache modes * set correctly. */ blinitial_mmu /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_1 stw r25,0(r26) /* We now have the lower 16 Meg mapped into TLB entries, and the caches * ready to work. */ turn_on_mmu: lisr0,MSR_KERNEL at h orir0,r0,MSR_KERNEL at l mtsprSPRN_SRR1,r0 lisr0,start_here at h orir0,r0,start_here at l mtsprSPRN_SRR0,r0 SYNC /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_2 stw r25,0(r26) rfi/* enables MMU */ /* CRD: set LED state here */ /* This address should be a virtual address */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_3 stw r25,0(r26) b./* prevent prefetch past rfi */ Regards, Chris Dumoulin -- *--Christopher Dumoulin--* Software Team Leader http://ics-ltd.com/ http://ics-ltd.com/ Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON K1J 9G2 (613)749-9241 1-800-267-9794 (USA only) This e-mail is private and confidential and is for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient.
Moving from 2.4 to 2.6 kernel
On 5/5/06, Chris Dumoulin cdumoulin at ics-ltd.com wrote: I generated the xparameters_ml300.h file and built my kernel configured for the ML300 board, but I still had the same problem. I'm wondering if there's something in the hardware that's not being setup by u-boot as the linux kernel expects it. I'm looking through the ML300 code in u-boot 1.1.4 to see if can spot anything that's being done in there that's not being done in my u-boot code. Do you have any ideas about some hardware (or other) initialization that I could be neglecting to do in u-boot that might cause things to hang? Probably not; The nice thing about the V2Pro is that there is pretty much no setup that needs to be done. The bitstream takes care of configuring SDRAM. :). For my daily work; I don't even use u-boot. I'm downloading a zImage directly through my BDI 2000. (But u-boot does work for me too) Can you post your xparameters file? (Or email it to me directly) Are you using a full UART or UART lite? On a similar note, is there any guide to porting u-boot that I could read that would enumerate all the steps I should be taking in u-boot? I know the README in the u-boot source basically says to browse the mailing list (which I'm doing), read the DULG (which I've done), and read the source (which I'm also doing), but some kind of succinct guide would be nice, if it exists. Not that I know of; I had to pile throught the same stuff to learn it. Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON Hey; you going to OLS this year? Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 399-0195
Calculating virtual address from physical address
Chris Dumoulin wrote: I'm using a Virtex II Pro-based board with a PPC405. The board is hanging somewhere very early in the kernel boot process. I believe it may be dying at the point where the MMU is enabled. In order to determine the exact point at which my board hangs, I'm blinking two LEDs in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I am only able to successfully access the LEDs before the MMU is turned on, but I can't be sure that I'm calculating the virtual address properly when I try to access the LED after the MMU is turned on. Typical when trying to bring up board ... Once the MMU is turned on, you leds register are most likely ... nowhere ... i.e. if you don't create a mapping your self there is just no virtual address that will access your leds physical address. What I did on some ppc work was tu use a quick BAT mapping to map some leds. It's pretty easy to setup. Be aware though that this mapping will get wiped out when the kernel sets up the BAT for itself. Sylvain
[PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
(please ignore last patch, its incomplete) Instantiation of 8MB pages on the TLB cache for the kernel static mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations. Signed-off-by: Marcelo Tosatti marcelo at kvack.org diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index ec53c7d..09b3adc 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -355,9 +355,7 @@ #endif . = 0x1200 DataStoreTLBMiss: -#ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) -#endif DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 @@ -417,9 +415,7 @@ #endif lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is an instruction TLB error on the MPC8xx. This could be due @@ -500,9 +496,7 @@ LoadLargeDTLB: lwz r11, 4(r0) lwz r12, 16(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is the data TLB error on the MPC8xx. This could be due to
Calculating virtual address from physical address
On Fri, May 05, 2006 at 09:27:50PM +0200, Sylvain Munaut wrote: Chris Dumoulin wrote: I'm using a Virtex II Pro-based board with a PPC405. The board is hanging somewhere very early in the kernel boot process. I believe it may be dying at the point where the MMU is enabled. In order to determine the exact point at which my board hangs, I'm blinking two LEDs in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I am only able to successfully access the LEDs before the MMU is turned on, but I can't be sure that I'm calculating the virtual address properly when I try to access the LED after the MMU is turned on. Typical when trying to bring up board ... Once the MMU is turned on, you leds register are most likely ... nowhere ... i.e. if you don't create a mapping your self there is just no virtual address that will access your leds physical address. What I did on some ppc work was tu use a quick BAT mapping to map some leds. It's pretty easy to setup. Be aware though that this mapping will get wiped out when the kernel sets up the BAT for itself. There are no BATs on 4xx. However, the same conceptual thing can be done by wiring a fixed TLB entry to cover those LEDs temporarily during bringup debug. The temporary TLB entry will be wiped out by normal tlb misses after things are running whenever the fixed entry is clobbered by the round robin replacement. -Matt
Calculating virtual address from physical address
On Fri, 2006-05-05 at 13:24 -0700, Matt Porter wrote: There are no BATs on 4xx. However, the same conceptual thing can be done by wiring a fixed TLB entry to cover those LEDs temporarily during bringup debug. The temporary TLB entry will be wiped out by normal tlb misses after things are running whenever the fixed entry is clobbered by the round robin replacement. At which point you should be able to call ioremap to generate a virtual address inside a device driver or board file. josh
Calculating virtual address from physical address
Chris Dumoulin wrote: My LEDs are at address 0x4F60 and my CONFIG_KERNEL_START is 0xC000. If this address were low enough, I would just add 0xC000 to the address to get the virtual address, but since my LED address is so high, the sum will be well past the 32-bit maximum address value. How is a virtual address calculated for a high address like 0x4F60? There are macros tophys and tovirt that convert addresses between physical and virtual. There are use example in the head_4xx.S file you are already in. If you are going to use a port for debugging you need to create a tlb entry for it. Same file in initial_mmu the code inside the if defined(CONFIG_SERIAL_TEXT_DEBUG) should provide an example how to do that. Be forwarned that any entries you create now will eventually disappear (took 2 weeks to figure that out once), but that may not happen intil after /init starts. Also with a little of jiggering arround the bits in MSR_KERNEL you can enable Data address translation independently of instruction address translation as well as disable or enable a variety of checks. It took me three weeks to get a new Xilinx V4 board through the rfi and to start_here in the same turn_on_mmu code you are working on. Eventually I ended up enabling the MSR bits one at a time until I discovered that enabling the Machine Check sent me to space. Regardless, once I relialized I could test the code with the MSR bits enabled one at a time isolating the problem became easier. The two issues I addressed above which relate specifically to your efforts with the ml300, constituted more than 80% of my effort to get a Xilinx Virtex 4 running. Finally, I started prior to grants platform bus changes. I have been adapting my V4 code to fit with Grants changes (the client has what they want so they do not care) I have not put alot of effort into this, but I currently get waylayed much later in new platform bus specific initialization code. I had no problem with the older board specific initialization code. If you are running on a real ml300 I am surprised you are having any problems though I do not have an ml300 to check that. But if you are running on a custom V2Pro board you have to get the board specific initalization right and therefore could trip over the issue I am currently having migrating from old to new. BTW, he is the assembly code that I'm working with (from arch/ppc/kernel/head_4xx.S): .text _GLOBAL(_stext) _GLOBAL(_start) /* Save parameters we are passed. */ mrr31,r3 mrr30,r4 mrr29,r5 mrr28,r6 mrr27,r7 /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_0 stw r25,0(r26) /* We have to turn on the MMU right away so we get cache modes * set correctly. */ blinitial_mmu /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_1 stw r25,0(r26) /* We now have the lower 16 Meg mapped into TLB entries, and the caches * ready to work. */ turn_on_mmu: lisr0,MSR_KERNEL at h orir0,r0,MSR_KERNEL at l mtsprSPRN_SRR1,r0 lisr0,start_here at h orir0,r0,start_here at l mtsprSPRN_SRR0,r0 SYNC /* CRD: set LED state here */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_2 stw r25,0(r26) rfi/* enables MMU */ /* CRD: set LED state here */ /* This address should be a virtual address */ lisr26,0x4F60 at h orir26,r26,0x4F60 at l li r25,LED_STATE_3 stw r25,0(r26) b./* prevent prefetch past rfi */ Regards, Chris Dumoulin -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 dhlii at dlasys.nethttp://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. Albert Einstein
[PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
Instantiation of 8MB pages on the TLB cache for the kernel static mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations. Signed-off-by: Marcelo Tosatti marcelo at kvack.org diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index ec53c7d..7a2f205 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -355,9 +355,7 @@ #endif . = 0x1200 DataStoreTLBMiss: -#ifdef CONFIG_8xx_CPU6 stw r3, 8(r0) -#endif DO_8xx_CPU6(0x3f80, r3) mtspr SPRN_M_TW, r10 /* Save a couple of working registers */ mfcrr10 @@ -417,9 +415,7 @@ #endif lwz r11, 0(r0) mtcrr11 lwz r11, 4(r0) -#ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) -#endif rfi /* This is an instruction TLB error on the MPC8xx. This could be due
