More dtc changes
On Thu, Jun 16, 2005 at 03:49:16PM -0500, Jon Loeliger wrote: On Thu, 2005-06-16 at 02:08, David Gibson wrote: I now have a git tree for the device tree compiler up at http://www.ozlabs.org/~dgibson/dtc/dtc.git Very Cool! And, um, rats. So, I'm the victim of an aggressive and anti-social IT Firewall poo-poolicy Or maybe I am just being dumb and haven't Googled up the Right Magic. Is there a way to set an HTTP Proxy definition, flag, parameter, environment variable, or other doo-dad that will help me cg-pull/git-http-pull through my firewall? Alternatively, any chance we can convert it to, or add, an rsync tree? Oh, oops, I meant to set up an rsync tree, but forgot. It's now done, and you can also pull it from: ozlabs.org::dtc/dtc.git -- 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/people/dgibson
mmap on 440gx
On 6/16/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote: Thanks for taking the time to reply. I've been struggling with implementing mmap on a 440gx-based custom board. I have been able to use ioremap(), but we really need a mmap() for our software. The kernel is 2.4.18 (TimeSys 4.0). There are some special things done for handling [io]_remap_page/pfn_range on other vendor kernels and the current mainline kernel. I'm not sure if your vendor kernel addressed them since it would be a vendor-specific patch in that timeframe. The special things are due to 36-bit addressing. I'm trying to access one of our FPGA's located at 0x5000. Offsets Let's start at the beginning. How do you have FPGA's at 0x5000? that address falls with the fix DDR SDRAM area on the 440GX memory map. All peripheral and EBC space is mapped by 4GB. You lost me right here. Oh wait, are you referring to the least significant 32-bits of the physical mapping. It's not really at 0x5000. Of course, you're correct. The 36-bit base address is 0x1__. It is mapped to the 32-bit address 0x5000_. Should I pass the 36-bit address to remap_page_range()? For what it's worth, __pa(0x5000_) returns 0x9000_. You need something like the bigphys_remap patch for 2.4 that can be found at ftp://source.mvista.com/pub/linuxppc/ I just checked the source, and that patch has indeed been applied. It does the same fixup for remap_page_range() that happens for ioremap(). In 2.6 this stuff is all in the mainline kernel but you use io_rename_[page|pfn]_range() there. -Matt Thanks, Ed
mmap on 440gx
On 6/17/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote: On 6/16/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote: Thanks for taking the time to reply. I've been struggling with implementing mmap on a 440gx-based custom board. I have been able to use ioremap(), but we really need a mmap() for our software. The kernel is 2.4.18 (TimeSys 4.0). For what it's worth, __pa(0x5000_) returns 0x9000_. Sure, you just asked it to subtract KERNELBASE from a physical address. Don't use __pa() in drivers. That's expected behavior. Why are you doing that? Desperation. You need something like the bigphys_remap patch for 2.4 that can be found at ftp://source.mvista.com/pub/linuxppc/ I just checked the source, and that patch has indeed been applied. Ok, assuming it's all correct then I don't know why it does work for you in your vendor tree. Have you asked Timesys for help? Not yet. I wanted to get some confidence that I was using the correct APIs appropriately. Put some debug statements throughout fixup_bigphys_addr() to see what's going on. My include/asm/mmu.h has it defined as: #ifndef CONFIG_440 #include asm-generic/mmu.h #else typedef unsigned long long phys_addr_t; #define fixup_bigphys_addr(addr, size) (addr) #endif I see that in later 2.4 kernels and in mainline 2.6 it is implemented as an actual working routine. Perhaps that explains it all. The ioremap() in my tree implements the fixup code inline, which would explain why it works, right? -Matt Thanks again. Ed
RFC cpm2_devices DPRAM resource
Allen Curtis wrote: Should the DPRAM appear as it's own platform_device? No. Option 1) Specify the portion of the DPRAM used by each device with that platform_device definition. (current) You mean the parameter space? That's different from DPRAM. Option 2) Define the whole DPRAM region as its own platform_device entry. Move the device DPRAM information to the device specific platform structure. How is this any different from using the dpalloc() as it is today? The problem is that for the few standard devices we publicly support in Linux it is easy to think of DPRAM as a general resource. However, for more challenging devices and implementation, there are sometimes specific regions of DPRAM that must be used with various additional restrictions. For many of the real world devices I have done, drivers would manage their own, well known, DPRAM areas. It isn't something that is easy to generalize or configure in advance. Time for code. - Allen FWIW the current dpalloc implementation supports carving out the usable dpram out of the whole. I mean you could conceivably not give the driver specific dpram areas to the generic allocator. This should be a per platform configuration item. The current code just doesn't bother... Regards Pantelis
mmap on 440gx
On Fri, Jun 17, 2005 at 01:42:07AM -0400, Ed Goforth wrote: On 6/17/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 11:47:22PM -0400, Ed Goforth wrote: On 6/16/05, Matt Porter mporter at kernel.crashing.org wrote: On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote: Thanks for taking the time to reply. I've been struggling with implementing mmap on a 440gx-based custom board. I have been able to use ioremap(), but we really need a mmap() for our software. The kernel is 2.4.18 (TimeSys 4.0). For what it's worth, __pa(0x5000_) returns 0x9000_. Sure, you just asked it to subtract KERNELBASE from a physical address. Don't use __pa() in drivers. That's expected behavior. Why are you doing that? Desperation. Heh, I like that. :) snip Put some debug statements throughout fixup_bigphys_addr() to see what's going on. My include/asm/mmu.h has it defined as: #ifndef CONFIG_440 #include asm-generic/mmu.h #else typedef unsigned long long phys_addr_t; #define fixup_bigphys_addr(addr, size) (addr) #endif I see that in later 2.4 kernels and in mainline 2.6 it is implemented as an actual working routine. Perhaps that explains it all. The ioremap() in my tree implements the fixup code inline, which would explain why it works, right? It sure does. That code is 100% wrong. Just merge in mainline 2.4 stuff and you should be golden. -Matt
Does any body have HYNIX or AMIC 32M SDRAM reference cdoe?
Hi All:
I used HY57641620 * 2 total all 16M SDRAM at my MPC852T board, now i
want to
used HY57V281620ET-H * 2 or AMIC A43L3616-6 * 2 total all 32M SDRAM, but i
don't know
how to setting UPM to control it, i need help.If you used another 32M SDRAM
solution,
please tell me, thanks.
#define _NOT_USED_ 0x
const uint sdram_table[] = /* for HY57641620 * 2 16M SDRAM */
{
/* Single Read. (offset 0x0-0x4 in UPM RAM) */
/* Precharge and MRS(offset 0x5-0x7 in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x11ADFC04, 0xEFBBBC00,
0x1FF77C47, 0x1FF77C35, 0xEFEABC34, 0x1FB57C35,
/* Burst Read. (offset 0x8-0xf in UPM RAM) */
0x1F07FC04, 0xEEAEFC04, 0x10ADFC04, 0xF0AFFC00,
0xF0AFFC00, 0xF1AFFC00, 0xEFBBBC00, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Single Write. (offset 0x18-0x1F in UPM RAM) */
0x1F27FC04, 0xEEAEBC00, 0x01B93C04, 0x1FF77C47,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Burst Write. (offset 20-2F in UPM RAM) */
0x1F07FC04, 0xEEAEBC00, 0x10AD7C00, 0xF0AFFC00,
0xF0AFFC00, 0xE1BBBC04, 0x1FF77C47, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Refresh timer expired (offset 30-3B in UPM RAM) */
0x1FF5FC84, 0xFC04, 0xFC04, 0xFC04,
0xFC84, 0xFC07, 0x, _NOT_USED_,
_NOT_USED_, _NOT_USED_, _NOT_USED_, _NOT_USED_,
/* Exception. (offset 3c-3f in UPM RAM) */
0x7C07, _NOT_USED_, _NOT_USED_, _NOT_USED_
};
long int initdram(int board_type)
{
volatile immap_t *immap = (immap_t *)CFG_IMMR;
volatile memctl8xx_t *memctl = immap-im_memctl;
upmconfig(UPMA, (uint *)sdram_table, sizeof(sdram_table)/sizeof(uint));
memctl-memc_mptpr = 0x0400;
/*
* Configure the refresh (mostly). This needs to be
* based upon processor clock speed and optimized to provide
* the highest level of performance. For multiple banks,
* this time has to be divided by the number of banks.
* Although it is not clear anywhere, it appears the
* refresh steps through the chip selects for this UPM
* on each refresh cycle.
* We have to be careful changing
* UPM registers after we ask it to run these commands.
*/
memctl-memc_mamr = 0xD0904114;
memctl-memc_mar = 0x0088;
udelay(200);
memctl-memc_mcr = 0x80004105; /* precharge */
udelay(200);
memctl-memc_mamr = 0xD0904114;
memctl-memc_mcr = 0x80004830; /* refresh */
udelay(200);
memctl-memc_mamr = 0xD0904114;
memctl-memc_mcr = 0x80004106;
udelay(200);
memctl-memc_or2 = 0xFE000A00;
memctl-memc_br2 = 0x0081;
return (32 * 1024 *1024);
} /* end of initdram */
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050617/52186aee/attachment.htm
MPC5200/Lite5200 and ethernet
Dale Farnsworth wrote: On Thu, Jun 16, 2005 at 10:55:15PM +0400, Andrey Volkov wrote: Grant Likely wrote: On 6/16/05, Andrey Volkov avolkov at varma-el.com wrote: AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in vanilla kernel. Except, bestcomm, certainly :(. FEC is missing too. Is anybody even working on bestcomm at the moment? It may be Dale Farnsworth or smb. quietly in Freescale. I sent patches to Sylvain in August 2004 with 5200 FEC support, including my rewrite of the bestcomm FEC code. I've bugged him about it a few times, and I don't know why he hasn't made it available. I haven't done much with the 5200 since then. I'm traveling now and have some other pressing issues, but I'll try to post what I have in the next couple of weeks. -Dale Dale, don't worry, Sylvain public your patches in himself src tree (http://www.246tnt.com/mpc52xx/) at August/September,2004. But, after that, OCP infra was dropped in kernel, and, hence, this driver was not sent to Andrew Morton (Bestcomm stuff, until now, OCP depended). And no one find time to convert Bestcomm to platform bus model :(. I planned start this job at July/August, so if someone wish to do it NOW (June) - welcome. -- Regards Andrey Volkov
MPC5200/Lite5200 and ethernet
On Fri, Jun 17, 2005 at 02:28:23PM +0400, Andrey Volkov wrote: I sent patches to Sylvain in August 2004 with 5200 FEC support, including my rewrite of the bestcomm FEC code. I've bugged him about it a few times, and I don't know why he hasn't made it available. I haven't done much with the 5200 since then. I'm traveling now and have some other pressing issues, but I'll try to post what I have in the next couple of weeks. -Dale Dale, don't worry, Sylvain public your patches in himself src tree (http://www.246tnt.com/mpc52xx/) at August/September,2004. But, after that, OCP infra was dropped in kernel, and, hence, this driver was not sent to Andrew Morton (Bestcomm stuff, until now, OCP depended). And no one find time to convert Bestcomm to platform bus model :(. I planned start this job at July/August, so if someone wish to do it NOW (June) - welcome. Thank you Andrey, and my apologies to Sylvain. I didn't realize that they were available. I'll take a look at converting to the platform bus model, but it will be at least a week before I start. -Dale
Problems on Philips ISP1362 Driver
Hi all, We are using ISP1362 usb host controller in our PPC-linux embedded system and we have had following problems: 1) ATL Interrupt doesn't work correctly. We have to use ATL_THRESHOLD_TIMEOUT, that has the minimun resolution 1 msec, to bypass it. 2) The latency from PTD completion. From a usb frame analyzer we have seen that the controller has gaps between every 4 64-bytes frames for 265 bytes PTD configured in bulk transmission. The limit of 265 byte for PTD is due to the end-point number. 3) The isochronous mode doesn' t work. That we've seen was we were loop on frame number, so the machine went to hang! The driver is ported from those of philips (last updated was 2002), I don't know if there is any updated driver. I've seen on the list that Wolfgang Denk has test it on many devices and works fine. I'd like to know from Wolfgang which driver did you use? Is the driver is open source? Thanks in advance! Jianliang Lu
Active 2.4 kernel repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a 405GPr based custom board that is running Linux 2.4, and we want to stay there for the while. I've been keeping up to date (more or less) with the linuxppc-2.4 BitKeeper tree but that tree is done now and I would like to point at a managed tree (CVS, git, whatever) that I can use to keep my board support patches up to date against. I can of course go to kernel.org and get the latest kernel trees from there, but I really would rather follow an actively maintained tree. So what's the story? Maybe there is a community managed tree where I can submit my board support patches? - -- Steve WilliamsThe woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCswx9rPt1Sc2b3ikRApGwAJ9W+t/cPY1mGuy3qses8e0QuLV4NACcDYlI KUwD6QsYb1N40vqH8WhdhDQ= =VWMT -END PGP SIGNATURE-
