[U-Boot-Users] PPC Discontiguous Memory Space
We have a client building a PPC8548-based product who insists that we allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in the 36-bit address space. It doesn't look like U-Boot's bd_info structure allows for that, and it doesn't look like the Linux init routines (which accesses the passed table) knows how to handle discontiguous memory either (as opposed to X86 Linux, which can accept an E820 table).
It looks like Linux cleans out the TLB's pretty quickly, so it wouldn't know the VA-to-RA mapping.
I've seen papers on some PPC Linuxes that handle large discontiguous real DRAM memory spaces, but it doesn't look like the Linux in ELDK does. Is that correct?
This is just the start of a headache between the architects and we poor implementers. It's not clear to us that, even with ATMU support, how normal drivers are going to know how to create real addresses for buffers and such to use when programming DMA controllers or external PCI devices.
Any comments would be VERY appreciated.
Regards, J
In message 6331980.post@talk.nabble.com you wrote:
We have a client building a PPC8548-based product who insists that we allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in the 36-bit address space. It doesn't look like U-Boot's bd_info structure allows for that, and it doesn't look like the Linux init routines (which accesses the passed table) knows how to handle discontiguous memory either (as opposed to X86 Linux, which can accept an E820 table).
The memory map is just a matter of software definiton. Ignore the silly request and map the RAM contiguously.
Any comments would be VERY appreciated.
Stop people fromn doing stupid things.
Best regards,
Wolfgang Denk
Danke, Wolfgang. They do, however, pay the bills, and I'd like to have more support for my argument.
It *looks* like it will be some work in U-Boot (changing the bd_table) and the kernel init routines to support discontiguous memory. Am I right?
The second problem is that the bottom 2GB of memory would be in the 4GB-6GB real space. We only have 32-bit PCI, but the client is convinced that ATMU registers would solve the mapping problem. That's not the way I read it ... I think every driver would have to look at the ATMU register to figure out the reverse-mapping.
A million thanks for your quick response. We've done 40 or 50 product board bringups with RedBoot, CFE, and commercial BIOSes. We really like U-Boot and hope to use it again on future PPC and ARM projects.
Regards, J
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Friday, September 15, 2006 4:52 PM To: jbahr Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] PPC Discontiguous Memory Space
In message 6331980.post@talk.nabble.com you wrote:
We have a client building a PPC8548-based product who insists that we allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in the 36-bit address space. It doesn't look like U-Boot's bd_info structure allows for that, and it doesn't look like the Linux init routines (which accesses the passed table) knows how to handle discontiguous memory either (as opposed to X86 Linux, which can accept an
E820 table).
The memory map is just a matter of software definiton. Ignore the silly request and map the RAM contiguously.
Any comments would be VERY appreciated.
Stop people fromn doing stupid things.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "He only drinks when he gets depressed." "Why does he get depressed?" "Sometimes it's because he hasn't had a drink." - Terry Pratchett, _Men at Arms_
participants (3)
-
jbahr -
Jeffery Bahr
-
Wolfgang Denk