Low latecy patch
Hi , Can any one please tell me from where I can get Low-latency and rtc-debug patches for linux-2.4.24 kernel source and MPC8248 processor platform. Thanks Prabhat Singh DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060508/d4fede06/attachment.htm
Setting ID cache enable in the same mtspr instruction
Hi, I think the implementation of setup_common_caches() in file cpu_setup_6xx.S; not according to the spec as far as MPC74xx concerns. Looking in the spec (MPC7450 RISC Microprocessor Family Reference Manual, MPC7450UM Rev. 5 1/2005) section 3.4.1.5 L1 Instruction and Data Cache Flash Invalidation it says: Note that HID0[ICFI] and HID0[DCFI] must not both be set with the same mtspr instruction, due to the synchronization requirements described in Section 2.4.2.4.1, Context Synchronization. But in the code those two do set together. Also, the same section says: An isync must precede the setting of the HID0[ICFI] in order for the setting to take effect. But in the code, only 'sync' can be found. /* Enable caches for 603's, 604, 750 7400 */ setup_common_caches: mfspr r11,SPRN_HID0 andi. r0,r11,HID0_DCE ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1: sync mtspr SPRN_HID0,r8/* enable and invalidate caches */ ^^^ Here we set both ICFI and DCFI in the same mtspr instruction. Also, no isync before setting ICFI. sync mtspr SPRN_HID0,r11 /* enable caches */ sync isync blr Please advice. Thanks.
Large Page Support, 2.6 kernel , PPC440
Morris, A long time ago, I did this for a 405 and it involves much more than just changing the page shift. From my memory, I will give you what I think you have to do. 1)you must go into tlb handling code and change it. That is in the header file 44x.S i beleive. 2)You have to change the pte directory sizes 3)You have to chage the linker script. 4)You have to change the size of the zero page. 5)you have to chage dcache flush routines, to cover the new page size. You have to find where 4096/4095 is hard coded as the page size and change it. This is no small job, and what you come up with will be very unsupported. I beleive If you pin the kerel TLB you might get the performance you need and this should be in the kernel config scripts. Good luck, Chip On 5/1/06, moris dong moris_dong at hotmail.com wrote: Friends, My PPC440 (32bit) MMU supports multiple page sizes. For the default 4K pages, my 2.6.11 kernel compiles and boots just fine. I want to re-build it with large pages, to improve my application performance. I tried modifying PAGE_SHIFT in page.h to 13 (8K pages) and re-build my kernel. Compilation worked out fine, but my kernel does NOT boot, nor it prints anything to the console. Has anyone successfully compiled booted a 2.6 kernel with pages larger than 4K ? What am I doing wrong ? Thanks a lot. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060508/7d2099da/attachment.htm
[PATCH 1/2] PAL: Support of the fixed PHY
On May 4, 2006, at 19:51, Vitaly Bordug wrote:
On Thu, 4 May 2006 19:21:12 -0500
Andy Fleming afleming at freescale.com wrote:
[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.
IS_ERR should be 0 if phydev is NULL. At least, that is my
interpretation of the code:
#define IS_ERR_VALUE(x) unlikely((x) (unsigned long)-1000L)
static inline long IS_ERR(const void *ptr)
{
return IS_ERR_VALUE((unsigned long)ptr);
}
[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.
I don't think you've understood the code. Was this happening to
you? Because mdiobus_register scans every PHY. If get_phy_device
returns an error, it means that it failed to allocate memory, or it
failed to manipulate the bus. Both are terminal errors, since it
means that either you can't allocate a device, or you can't actually
read from the bus. And that means mdiobus_register() needs to return
failure. Actually, it looks like there's a memory leak if that happens.
The behavior you suggest is what happens: If there is an error, the
loop terminates. If it returned NULL, then the rest of the loop
doesn't execute (except for setting bus-phymap[i];
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 *dev;
+ /* We allocate the device, and initialize the
+* default values */
+ dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
+
+ if (NULL == dev)
+ return NULL;
Here's the other change which breaks get_phy_device(). Now it
doesn't return an error when it fails to allocate memory, it returns
NULL. Which mdiobus_register doesn't interpret as an error (because
it isn't. Not every PHY address has a device on it).
OK, this part definitely needs a bit attention and a rework. So,
phy_device_create should return PTR_ERR if it fail to allocate
memory, and we need to keep get_phy_device() return as it was, right?
Were you having problems with the code the old way? Because I
believe it should all just work as you want the way it was. If not,
we need to look into why NULL pointers were triggering IS_ERR() checks.
Andy
BDI2000 help
Hello All. Yes it's me again. So I've got a BDI2000. I have my serial cable hooked up and I can run the ./bdisetup -v program. The question I have is what type do I select for my MPC8260. As you can see I'm new to this part of the PPC world. I'm usually a bit higher up and someone has already set this up for me. I think I have everything else setup right, I just don't get that last bit. Because I think I need a configuration file for it. Correct? Thanks. -stv
[PATCH] Add PVR for new Rev C 440EP
Here's a patch to add the PVR for the AMCC 440EP Rev C:
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e4e8137..a2967b6 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -938,6 +938,16 @@ struct cpu_speccpu_specs[] = {
.dcache_bsize = 32,
.platform = ppc440,
},
+ {
+ .pvr_mask = 0xffff,
+ .pvr_value = 0x48d4,
+ .cpu_name = 440EP Rev. C,
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = ppc440,
+ },
{ /* 440GP Rev. B */
.pvr_mask = 0xffff,
.pvr_value = 0x4440,
BDI2000 help
Ummm... if you want to use the BDI2000 with a MPC8260 processor you need a firmware version for such a CPU. Abatron always ships these with manual included (both on paper copy and on floppy disk). outdated. I couldn't readily find the newer manual. So when all else fails. Ask. :) Before asking, search. You should be able to find http://www.abatron.ch/, and then http://www.abatron.ch/Files/ManGdbCOP-2000C.pdf Thanks. And yes I got this all legal its just that some people in the company quit and I'm still trying to find everything.
