* Re: Dynamic libraries do not work
From: Theo Gjaltema @ 2005-05-27 5:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc05052615304d896b94@mail.gmail.com>
Grant Likely schreef:
>On 5/26/05, Theo Gjaltema <gjalt007@chello.nl> wrote:
>
>
>>Hello,
>>
>>I have a linux 2.4.20 kernel running, but the files in the ramdisk fail
>>to execute if they are dynamically build.
>>The whole system stops (debuggers shows that it crashed while in an erea
>>where no flash/ram is present.
>>Anyone an idea?
>>There is nog difference between the use of a ramdisk or an nfs mounted
>>root filesystem.
>>
>>
>>
>More data please; Make sure you attach actual output when asking for help.
>
>
>
You are right, this gives too little info. Since the system stops
without giving any data, I don't know what to attach
maybe:
RAM: 64 Mbyte
(using a static linked busybox: activating a sh (=busybox) b
::sysinit:/bin/sh)
sh: /lib/ld.so.1
< help page of ld.so.1>
sh: /lib/ld.so.1 --verify /bin/xxx (or just any dynamic linked library)
<here the system has crahed>
or
sh: /bin/xxx
<here the system has crashed>
I have tried to step through the dynamic linking, but did not succeed
til after the creation of a thread.
With a dynamic linked busybox the system stops after a message such as
"freeing xxx kbytes" (I don't know the actual number by head)
When init is then called, which is a part of the busybox which is dyn.
liked, it crashes.
Greetings,
Theo
^ permalink raw reply
* [ppc44x-patch] Is this a bug?
From: Chenfeng Zhou @ 2005-05-27 4:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
In linux-2.4.25 source tree, maybe there's something wrong with the boot process of
ppc44x cpu.
In arch/ppc/boot/common/relocate.S, we decompress the kernel to address 0, then jump
there to do real boot job (arch/ppc/kernel/head_44x.S). But the last expression is `ba 0x000c'.
Actually there's only one nop at the begining of head_44x.S, so the expression should
be `ba 0x0004' for ppc-44x. But for compatibility, i think it should be `ba 0x0',
because there's different number of 'nops' in head.S for different cpus.
Actually, in linux-2.4.26, linux-2.4.30, i also found the same problem.
but in linux-2.6, it seems solved already.
Thank you.
patch below:
diff -rNu linux-2.4.25/arch/ppc/boot/common/relocate.S linux-2.4.25.me/arch/ppc/boot/common/relocate.S
--- linux-2.4.25/arch/ppc/boot/common/relocate.S 2003-08-25 19:44:40.000000000 +0800
+++ linux-2.4.25.me/arch/ppc/boot/common/relocate.S 2005-05-27 12:07:05.000000000 +0800
@@ -203,6 +203,7 @@
* three instructions are 'nop' since we
* sometimes overwrite them).
*/
- ba 0x000c
+ #ba 0x000c
+ ba 0x0
.comm .stack,4096*2,4
[-- Attachment #2: Type: text/html, Size: 2001 bytes --]
^ permalink raw reply
* memec virtex 2 Pro
From: mcnernbm @ 2005-05-27 2:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
Has anyone had any success getting linux to boot on a memc viretx 2 board?
I am trying to replicate the steps to get the kernel built for the ml300
but run error after error in doing so. The make zImage is borken and
fails all the time. Anybody that has success with the memec virtex 2 pro
or the xilinx ml300 board it would be greatly appreciated if you could
explain how you did so.
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 544 bytes --]
^ permalink raw reply
* [PATCH] ppc32: Simplified load string emulation error checking
From: Kumar Gala @ 2005-05-27 0:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kim.Phillips, linux-kernel, linuxppc-embedded
The error checking for emulation of load string instructions was overly
generous and would cause certain valid forms of the instructions to be
treated as illegal. We drop the range checking since the architecture
allows this to be boundedly undefined. Tests on CPUs that support these
instructions appear not do cause illegal instruction traps on range
errors and just allow the execution to occur.
Thanks to Kim Phillips for debugging this and figuring out what real HW
was doing.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 219d058f65dbd666964b1e951b8d491e4b19dc0c
tree 109a4648d2cc627d17c129bc1ca102a736c817aa
parent 4b1b1ed3400c905819fc4668838dbec4099f2d8d
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 26 May 2005 18:55:56 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 26 May 2005 18:55:56 -0500
ppc/kernel/traps.c | 7 +------
1 files changed, 1 insertion(+), 6 deletions(-)
Index: arch/ppc/kernel/traps.c
===================================================================
--- 94fc6c9507563e89a75b0838824003b2301b4321/arch/ppc/kernel/traps.c (mode:100644)
+++ 109a4648d2cc627d17c129bc1ca102a736c817aa/arch/ppc/kernel/traps.c (mode:100644)
@@ -408,12 +408,7 @@
/* Early out if we are an invalid form of lswx */
if ((instword & INST_STRING_MASK) == INST_LSWX)
- if ((rA >= rT) || (NB_RB >= rT) || (rT == rA) || (rT == NB_RB))
- return -EINVAL;
-
- /* Early out if we are an invalid form of lswi */
- if ((instword & INST_STRING_MASK) == INST_LSWI)
- if ((rA >= rT) || (rT == rA))
+ if ((rT == rA) || (rT == NB_RB))
return -EINVAL;
EA = (rA == 0) ? 0 : regs->gpr[rA];
^ permalink raw reply
* Re: OF flat device tree for ppc32...
From: Kumar Gala @ 2005-05-26 23:08 UTC (permalink / raw)
To: Loeliger Jon-LOELIGER; +Cc: Jakob Viketoft, Linux PPC Embedded list
In-Reply-To: <1116607235.29111.20.camel@gleep>
Jon,
Can you break the patch up into a few pieces, it will be easier to
review that way. Here are the following pieces that make sense to me:
0. New firmware interface (fw_bdt*, Kconfig, ...)
1. board code changes (everything in arch/ppc/platforms/*)
2. driver changes (things in *_io, ide, net, serial dirs -- try to give
a better list below)
3. System changes (files in arch/ppc/syslib and include/asm-ppc)
Let me know if you feel these are reasonable, they suck, or otherwise.
Let's handle the removal in arch/m68knommu/platform/68360/commproc.c
outside of all of this (thus isolating ourselves to PPC).
2. DRIVER CHANGES:
ppc/8260_io/enet.c | 9
ppc/8260_io/fcc_enet.c | 15
ppc/8xx_io/commproc.c | 3
ppc/8xx_io/enet.c | 10
ppc/8xx_io/fec.c | 8
ide/ppc/mpc8xx.c | 14
mtd/maps/tqm8xxl.c | 7
net/fec.c | 6
net/fec_8xx/fec_8xx-netta.c | 5
net/oaknet.c | 6
serial/68360serial.c | 3
serial/cpm_uart/cpm_uart_core.c | 8
serial/cpm_uart/cpm_uart_cpm1.c | 13
serial/cpm_uart/cpm_uart_cpm2.c | 13
serial/mpc52xx_uart.c | 11
- kumar
On May 20, 2005, at 11:40 AM, Loeliger Jon-LOELIGER wrote:
> On Thu, 2005-05-19 at 01:41, Jakob Viketoft wrote:
>> Hello Jon!
>>
>> Any news on the port of the OF-layer to ppc32? I'd love to hear some
>> more and it would be great be able to help out, even though I have
> some
>> heavy deadlines hanging over me for the next 2 months. From what I can
>
>> see on the list, there wasn't many comments on your first preparatory
>> code, but I for one thinks it's time to move it forward anyway.
>>
>> What do you say?
>>
>> /Jakob
>
> Folks,
>
> I have updated my tree and patch to the latest GIT
> as of last night. The new patch is available here:
>
> http://www.jdl.com/bdt_cleanup_git.patch.gz
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> Please let me know if there are difficulties retrieving it.
>
> This patch has a few caveats associated with it.
> In particular, it does not address the entire
>
> arch/ppc/boot/simple
>
> issue at all. And for that reason, this patch does
> not yet actually remove the to-be-obsoleted ppcboot.h
> that is otherwise unreferenced. I am hopeful that
> someone who is muchm ore familiar with that code can
> pick up from this patch and Do The Right Thing there.
>
> This patch in no-way eliminates the U-Boot-to-Kernel
> interface yet. It merely isolates it all to one location
> and provides a functional interface to it.
>
> Enjoy,
> jdl
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Dynamic libraries do not work
From: Grant Likely @ 2005-05-26 22:30 UTC (permalink / raw)
To: Theo Gjaltema, linuxppc-embedded
In-Reply-To: <429639D5.20609@chello.nl>
On 5/26/05, Theo Gjaltema <gjalt007@chello.nl> wrote:
> Hello,
>=20
> I have a linux 2.4.20 kernel running, but the files in the ramdisk fail
> to execute if they are dynamically build.
> The whole system stops (debuggers shows that it crashed while in an erea
> where no flash/ram is present.
> Anyone an idea?
> There is nog difference between the use of a ramdisk or an nfs mounted
> root filesystem.
>=20
More data please; Make sure you attach actual output when asking for help.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Mark A. Greer @ 2005-05-26 22:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117145621.9076.147.camel@gaston>
Benjamin Herrenschmidt wrote:
>On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote:
>
>
>>Benjamin Herrenschmidt wrote:
>>
>>
>>
>>>- There is _one_ important point to keep in mind, but that has always
>>>been true: None of this work before MMU_init(),
>>>
>>>
>>>
>>>
>>This is very true and raises a couple issues that we should fix while
>>we're at it:
>>
>>1) There are progress calls in MMU_init which will try to access the
>>uart before its possible to create a mapping to the uart's regs
>>(assuming you don't make a hack to map them and that you set up
>>ppc_md.progress in your platform_init routine). We should either get
>>rid of those calls in MMU_init, provide an acceptable way to make
>>temporary pre-MMU_init mappings, or make sure nobody sets up
>>ppc_md.progress until ioremap is working (and also get rid of the calls
>>in MMU_init b/c they're never used).
>>
>>
>
>Or have the implementation of progress() check if the mapping was done
>or not ...
>
Doesn't seem worth it to me.
> In any ways, I always disliked ppc_md.progress deeply. It's
>ugly and clutters the code. It has never proven very useful to me vs.
>having an early console.
>
Okay, let's rip it out of MMU_init then. Anyone have a problem with that?
Mark
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-26 22:13 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <429631CC.6000606@mvista.com>
On Thu, 2005-05-26 at 13:30 -0700, Mark A. Greer wrote:
> Benjamin Herrenschmidt wrote:
>
> > - There is _one_ important point to keep in mind, but that has always
> >been true: None of this work before MMU_init(),
> >
> >
>
> This is very true and raises a couple issues that we should fix while
> we're at it:
>
> 1) There are progress calls in MMU_init which will try to access the
> uart before its possible to create a mapping to the uart's regs
> (assuming you don't make a hack to map them and that you set up
> ppc_md.progress in your platform_init routine). We should either get
> rid of those calls in MMU_init, provide an acceptable way to make
> temporary pre-MMU_init mappings, or make sure nobody sets up
> ppc_md.progress until ioremap is working (and also get rid of the calls
> in MMU_init b/c they're never used).
Or have the implementation of progress() check if the mapping was done
or not ... In any ways, I always disliked ppc_md.progress deeply. It's
ugly and clutters the code. It has never proven very useful to me vs.
having an early console.
> 2) Some firmwares don't provide any info on how much memory is in the
> system but MMU_init needs to know that. So the platform code has to
> read the SPD from the mem sticks via i2c, read the mem ctlr, or read a
> board reg that has the info. All of those require access to hw regs
> before or during MMU_init. I should be able to get rid of this one by
> figuring out the amount of memory in the bootwrapper and passing it in
> to the kernel. I am assuming that all the boards with this problem use
> the bootwrapper. I think that's a safe assumption but I'll have to verify.
Yes, the boot wrapper is the way to go here.
> BTW, these are the reasons that I made that set_bat hack that Dan is so
> fond of. :) I'll get rid of that hack but I need an answer to 1) first.
>
> Mark
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-26 22:10 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <4a9d31a2d06786004054e2119aafd35d@embeddededge.com>
> > ioremap_bot is set by MMU_init() and nowhere else, and to a constant
> > value (depending on HIGHMEM) and thus can perfectly be initialized
> > statically instead. It is _NOT_ intialized by io_block_mappingt() as I
> > explained already.
>
> I'm only going to say this once more with an example. A call to
> io_block_mapping() may change ioremap_bot. If ioremap_bot
> is set to say 0xf0000000, and someone says ".. I need to allocate
> more VM and phys space to my IO to make sure my devices are
> covered " will do an io_block_mapping(0xe0000000, 0xe0000000, size,
> flags)
> This will then push ioremap_bot down to 0xe0000000 to ensure
> calls made to ioremap() won't multiply map this space if the Linux
> VM has not been initialized.
Damn, thanks for repeating what I've been explaining for 3 mails.
(Sorry, I admit, my wording above shouldn't have been "ioremap_bot is
set" but "ioremap_bot is initialized").
io_block_mapping() does _nothing_ much different than ioremap in that
regard, it just "pushes it down" to avoid further conflicts. That is
100% compatible to dynamically allocating.
> > - io_block_mapping() will push-down ioremap_bot as well if the mapping
> > requests a virtual address above KERNELBASE and below the current
> > ioremap_bot value. This is obviously necessary or further unrelated
> > vmalloc/ioremap's may be "allocated" to virtual addresses overlapping
> > the io_block_mapping() which is wrong.
>
> So, why are you telling me I don't understand the code when this is
> what I've been trying to tell you for the last several days? :-)
That is what _I_ have been trying to tell you, dammit ! That and the
fact that ioremap does the exact same thing :)
> The io_block_mapping() is used in conjunction with setting up BATs or
> CAMs that have size and alignment restrictions. The io_block_mapping
> is not a memory allocator and isn't intended to be used as a substitute
> for ioremap(). If code is doing that, fix that and stop blaming a
> useful set up function.
Ugh ? This is out of topic. Dynamically allocating the virtual space
doesn't in any way prevent setting up BAT or CAMs ...
> Somewhere, someone has to know all of these alignment concerns.
Yup, and io_block_mapping() does know, and that doesn't prevent it to
allocate virtual addresses dynamically. How many times should I repeat
the same thing before you get it ? In French maybe ?
> I think it's just easier to use a simple call to io_block_mapping with
> the values you want for a particular processor/board port than to make up
> some complex scheme for computing these values that is going to
> vary among the different processors.
More complex scheme ? Ugh ... A mask ! that is complex ?!?! In fact, you
move the complexity to the writer of the support code :)
> So, just leave ppc_md.setup_io_mappings, and if a board port chooses
> to modify the mappings as an extension of MMU_init, then fine. You
> can achieve the same results by calling setbat() or settlbcam() and
> managing those resources yourself, or you can get the advantage of
> using io_block_mapping() to do it. In the end, you have to allow
> this to be done, so instead of calling io_block_mapping() I'll just
> make all of the board set up functions call the appropriate functions
> and update ioremap_bot, just like io_block_mapping() does.
Ugh ? I can't make any sense of the above. It looks like you are trying
hard not to understand what I'm saying and proposing.
> > - There is _one_ important point to keep in mind, but that has always
> > been true: None of this work before MMU_init(), we may want to add some
> > BUG_ON() in there. BUG_ON(ioremap_bot == 0) would do the trick. Just in
> > case somebody tries to call these from platform_init().
>
> There are various other horrible hacks we do to accommodate this, too
> :-)
No, there are not. It doesn't work. Calling io_block_mapping or ioremap
before MMU_init() will screw you up. Period.
> > That the only real difference between io_block_mapping() and ioremap()
> > are:
> >
> > - The former allows you to setup hard code v->p mappings (but I've
> > showed several times now that it shouldn't be necessary anymore)
>
> As I have said, it is necessary for the proper alignment and allocation
> of VM space so BATs/CAMs work and someone else doesn't multiply
> map the space.
>
No it's not. First you are AGAIN mixing two different things.
Alignement, and multiple allocation of the virtual space.
- Alignement can be dealt very easily. First, top-align the size (we
have to do that anyway), and then, do ioremap_bot -= size; and finally,
down-align ioremap_bot, and miracle ! you get your new virtual address !
- Multiple allocation of virtual space: that is a non issue since we
are moving ioremap_bot down. That's also what ioremap does. There is NO
problem here, unless you try calling them before MMU_init() of course.
> > - The former can use a "BAT" or "CAM" instead of page tables which can
> > be of some use for performances.
>
> This is extremely important and something we have always done.
> We already have too many performance issues with 2.6 to continually
> disregard these features.
Nobody is disregarding that feature. You are again trying very hard not
to understand what I'm saying
> > 1) Adding to io_block_mapping() the ability to alloc dynamically the
> > virtual space. That would have 0 impact on drivers using ioremap
>
> Yes, it would have a big impact because you can't map BATs/CAMs
> to arbitrary addresses.
Who is talking about arbitrary addresses ? It's just a matter of
aligning down properly ioremap_bot.
> > ... A special flag to pass to
> > __ioremap() that would make it use BATs/CAMs (the first one who says
> > that is complicated goes back to school, please !)
>
> It is complicated, and I've spent more time in school than your age :-)
Maybe too much ? :)
> How do you know how many BATs are available?
We do, we have an index in the array, and we can even scan the array for
valid bits if we want to.
> How big? How much to allocate?
The first size that fits the requested argument to ioremap, again, very
easy.
> In real-time embedded systems you need limits and known resource allocation areas.
Ugh ?
> Often, these embedded systems need careful tuning to make everything fit in the address
> spaces, something that isn't going to be known or likely to be done correctly.
Heh, again, ioremap_bot starts nicely aligned, so if you do your BAT
allocation (with either io_block_mapping() as I suggested or with a
modified ioremap) first thing first in setup_io_mappings(), they'll get
nicely aligned near the top of your address space and you won't "lose"
anything.
> You need to work on a real production system that has resource
> limitations. Yes, we do count bytes of space used by the kernel, IO,
> applications, flash, ram, everything, and they try to make it fit.
> Functions
> like these are critical to make it happen.
Bla bla bla bla... I've heard that way too much. It's the magical excuse
against anything.
> If you don't want to use them, fine, but please don't be taking away
> important features for embedded systems just because you don't
> see a use for them or know how to use them correctly.
No, it's not an "important" feature, and it can be safely removed
without problem.
> Anyway, I'm done. If you want to remove it, then please fix up and test
> all boards that use it. Be prepared to see it emerge again when I
> need this feature in embedded systems.
No, you won't need it unless you do things wrong.
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-26 21:54 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <fb2cb3a9f4b80b8fc6392698036b9f6a@embeddededge.com>
On Thu, 2005-05-26 at 15:00 -0400, Dan Malek wrote:
> The problem with ioremap() if you don't wire some spaces is it will try
> to
> allocate VM space prior to the Linux VM being initialized.
No it won't. It will just push ioremap_bot down, and has always done
that.
Ben.
^ permalink raw reply
* [PATCH][PPC32] Add Soft-Reset to MPC834x.
From: Randy Vinson @ 2005-05-26 21:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 173 bytes --]
Greetings,
The attached patch adds soft reset to the MPC834x platform. With this
patch the "reboot" command will cause a shutdown and restart sequence.
Randy Vinson
[-- Attachment #2: reset.patch --]
[-- Type: text/plain, Size: 2465 bytes --]
Add soft reset to MPC834x
This change allows mpc83xx_restart to issue a software reset.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
commit 6d63102a8653755f40a5714020f375e297c0bfae
tree 8471abaacd09aaa62ea479c926f13cbbf8906e49
parent 269bcdbf0a9f000400052b2da38348733dbfe88f
author Randy Vinson <rvinson@linuxbox.(none)> Wed, 25 May 2005 17:37:16 -0700
committer Randy Vinson <rvinson@linuxbox.(none)> Wed, 25 May 2005 17:37:16 -0700
arch/ppc/platforms/83xx/mpc834x_sys.h | 6 ++++++
arch/ppc/syslib/ppc83xx_setup.c | 28 ++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
Index: arch/ppc/platforms/83xx/mpc834x_sys.h
===================================================================
--- d10f5c31c29228a00a1a7551e3e825b439bfc741/arch/ppc/platforms/83xx/mpc834x_sys.h (mode:100644)
+++ 8471abaacd09aaa62ea479c926f13cbbf8906e49/arch/ppc/platforms/83xx/mpc834x_sys.h (mode:100644)
@@ -28,6 +28,12 @@
#define BCSR_PHYS_ADDR ((uint)0xf8000000)
#define BCSR_SIZE ((uint)(32 * 1024))
+#define BCSR_MISC_REG2_OFF 0x07
+#define BCSR_MISC_REG2_PORESET 0x01
+
+#define BCSR_MISC_REG3_OFF 0x08
+#define BCSR_MISC_REG3_CNFLOCK 0x80
+
#ifdef CONFIG_PCI
/* PCI interrupt controller */
#define PIRQA MPC83xx_IRQ_IRQ4
Index: arch/ppc/syslib/ppc83xx_setup.c
===================================================================
--- d10f5c31c29228a00a1a7551e3e825b439bfc741/arch/ppc/syslib/ppc83xx_setup.c (mode:100644)
+++ 8471abaacd09aaa62ea479c926f13cbbf8906e49/arch/ppc/syslib/ppc83xx_setup.c (mode:100644)
@@ -29,6 +29,7 @@
#include <asm/mmu.h>
#include <asm/ppc_sys.h>
#include <asm/kgdb.h>
+#include <asm/delay.h>
#include <syslib/ppc83xx_setup.h>
@@ -117,7 +118,34 @@
void
mpc83xx_restart(char *cmd)
{
+ volatile unsigned char __iomem *reg;
+ unsigned char tmp;
+
+ reg = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+
local_irq_disable();
+
+ /*
+ * Unlock the BCSR bits so a PRST will update the contents.
+ * Otherwise the reset asserts but doesn't clear.
+ */
+ tmp = in_8(reg + BCSR_MISC_REG3_OFF);
+ tmp |= BCSR_MISC_REG3_CNFLOCK; /* low true, high false */
+ out_8(reg + BCSR_MISC_REG3_OFF, tmp);
+
+ /*
+ * Trigger a reset via a low->high transition of the
+ * PORESET bit.
+ */
+ tmp = in_8(reg + BCSR_MISC_REG2_OFF);
+ tmp &= ~BCSR_MISC_REG2_PORESET;
+ out_8(reg + BCSR_MISC_REG2_OFF, tmp);
+
+ udelay(1);
+
+ tmp |= BCSR_MISC_REG2_PORESET;
+ out_8(reg + BCSR_MISC_REG2_OFF, tmp);
+
for(;;);
}
^ permalink raw reply
* Dynamic libraries do not work
From: Theo Gjaltema @ 2005-05-26 21:04 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a linux 2.4.20 kernel running, but the files in the ramdisk fail
to execute if they are dynamically build.
The whole system stops (debuggers shows that it crashed while in an erea
where no flash/ram is present.
Anyone an idea?
There is nog difference between the use of a ramdisk or an nfs mounted
root filesystem.
Greetings,
Theo.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Mark A. Greer @ 2005-05-26 20:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117089669.9076.105.camel@gaston>
Benjamin Herrenschmidt wrote:
> - There is _one_ important point to keep in mind, but that has always
>been true: None of this work before MMU_init(),
>
>
This is very true and raises a couple issues that we should fix while
we're at it:
1) There are progress calls in MMU_init which will try to access the
uart before its possible to create a mapping to the uart's regs
(assuming you don't make a hack to map them and that you set up
ppc_md.progress in your platform_init routine). We should either get
rid of those calls in MMU_init, provide an acceptable way to make
temporary pre-MMU_init mappings, or make sure nobody sets up
ppc_md.progress until ioremap is working (and also get rid of the calls
in MMU_init b/c they're never used).
2) Some firmwares don't provide any info on how much memory is in the
system but MMU_init needs to know that. So the platform code has to
read the SPD from the mem sticks via i2c, read the mem ctlr, or read a
board reg that has the info. All of those require access to hw regs
before or during MMU_init. I should be able to get rid of this one by
figuring out the amount of memory in the bootwrapper and passing it in
to the kernel. I am assuming that all the boards with this problem use
the bootwrapper. I think that's a safe assumption but I'll have to verify.
BTW, these are the reasons that I made that set_bat hack that Dan is so
fond of. :) I'll get rid of that hack but I need an answer to 1) first.
Mark
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-26 19:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1117089669.9076.105.camel@gaston>
On May 26, 2005, at 2:41 AM, Benjamin Herrenschmidt wrote:
> io_block_mapping() as a way to set a BAT/CAM to speed up access to some
> PCI resources make sense, and ioremap() can I think already find out
> whether this is BAT-mapped or not. I don't see any way that can prevent
> what I proposed.
And that's the only way it should be used. Calling io_block_mapping()
with a zero virtual address makes no sense.
> ioremap_bot is set by MMU_init() and nowhere else, and to a constant
> value (depending on HIGHMEM) and thus can perfectly be initialized
> statically instead. It is _NOT_ intialized by io_block_mappingt() as I
> explained already.
I'm only going to say this once more with an example. A call to
io_block_mapping() may change ioremap_bot. If ioremap_bot
is set to say 0xf0000000, and someone says ".. I need to allocate
more VM and phys space to my IO to make sure my devices are
covered " will do an io_block_mapping(0xe0000000, 0xe0000000, size,
flags)
This will then push ioremap_bot down to 0xe0000000 to ensure
calls made to ioremap() won't multiply map this space if the Linux
VM has not been initialized.
> - io_block_mapping() will push-down ioremap_bot as well if the mapping
> requests a virtual address above KERNELBASE and below the current
> ioremap_bot value. This is obviously necessary or further unrelated
> vmalloc/ioremap's may be "allocated" to virtual addresses overlapping
> the io_block_mapping() which is wrong.
So, why are you telling me I don't understand the code when this is
what I've been trying to tell you for the last several days? :-)
> So there is nothing, I mean absolutely _nothing_ that prevents us from
> "improving" io_block_mapping() so that it can request virtual space by
> pushing ioremap_bot down the way ioremap() does when called early.
The io_block_mapping() is used in conjunction with setting up BATs or
CAMs that have size and alignment restrictions. The io_block_mapping
is not a memory allocator and isn't intended to be used as a substitute
for ioremap(). If code is doing that, fix that and stop blaming a
useful
set up function.
Somewhere, someone has to know all of these alignment concerns.
I think it's just easier to use a simple call to io_block_mapping with
the
values you want for a particular processor/board port than to make up
some complex scheme for computing these values that is going to
vary among the different processors.
So, just leave ppc_md.setup_io_mappings, and if a board port chooses
to modify the mappings as an extension of MMU_init, then fine. You
can achieve the same results by calling setbat() or settlbcam() and
managing those resources yourself, or you can get the advantage of
using io_block_mapping() to do it. In the end, you have to allow
this to be done, so instead of calling io_block_mapping() I'll just
make all of the board set up functions call the appropriate functions
and update ioremap_bot, just like io_block_mapping() does.
> - There is _one_ important point to keep in mind, but that has always
> been true: None of this work before MMU_init(), we may want to add some
> BUG_ON() in there. BUG_ON(ioremap_bot == 0) would do the trick. Just in
> case somebody tries to call these from platform_init().
There are various other horrible hacks we do to accommodate this, too
:-)
> That the only real difference between io_block_mapping() and ioremap()
> are:
>
> - The former allows you to setup hard code v->p mappings (but I've
> showed several times now that it shouldn't be necessary anymore)
As I have said, it is necessary for the proper alignment and allocation
of VM space so BATs/CAMs work and someone else doesn't multiply
map the space.
> - The former can use a "BAT" or "CAM" instead of page tables which can
> be of some use for performances.
This is extremely important and something we have always done.
We already have too many performance issues with 2.6 to continually
disregard these features.
> 1) Adding to io_block_mapping() the ability to alloc dynamically the
> virtual space. That would have 0 impact on drivers using ioremap
Yes, it would have a big impact because you can't map BATs/CAMs
to arbitrary addresses.
> ... A special flag to pass to
> __ioremap() that would make it use BATs/CAMs (the first one who says
> that is complicated goes back to school, please !)
It is complicated, and I've spent more time in school than your age :-)
How do you know how many BATs are available? How big? How
much to allocate? In real-time embedded systems you need limits
and known resource allocation areas. Often, these embedded systems
need careful tuning to make everything fit in the address spaces,
something that isn't going to be known or likely to be done correctly.
You need to work on a real production system that has resource
limitations. Yes, we do count bytes of space used by the kernel, IO,
applications, flash, ram, everything, and they try to make it fit.
Functions
like these are critical to make it happen.
If you don't want to use them, fine, but please don't be taking away
important features for embedded systems just because you don't
see a use for them or know how to use them correctly.
Anyway, I'm done. If you want to remove it, then please fix up and test
all boards that use it. Be prepared to see it emerge again when I
need this feature in embedded systems.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-26 19:00 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20050526062057.GA25579@gate.ebshome.net>
On May 26, 2005, at 2:20 AM, Eugene Surovegin wrote:
> Dan, you must be kidding. 44x ioremaps PCI IO space, 40x uses
> io_block_mapping for that, but this is just brain-damaged and should
> be fixed.
Anyone that uses assumptions of mapping from io_block_mapping()
should be fixed, unless it is absolutely necessary, like to get an
early serial port for debugging. I've been guilty of this as well,
but everyone should be calling ioremap().
> What is so special about PCI IO space that it must be "wired" ?
My point was someone needs to set up BATs or CAMs for that
space and further configure it so the in/out macros work. Drivers
don't call ioremap for such space (although I think they should).
Assuming mappings exist, whether by calling ioremap() or
otherwise, is Linux legacy and shouldn't be done.
> Wow, this is something new for me. So you are saying that
> io_block_mapping() was supposed to be used with ioremap()?
Except in rare circumstances, it's the way I've always used
it to set up IO mapping on embedded boards.
> Could you point me to the port which actually does this?
I don't see any of them in the 2.6 right now, but the EP and STx ports
I did should do this. I certainly plan to use it on all of the 85xx
ports
so we get the advantage of CAM mapping for various IO spaces.
> So far I only saw io_block_mapping() used as a short-cut way _NOT_ to
> ioremap and get hard-coded v:p mapping and then use this knowledge to
> access physical address directly without ever calling ioremap(). And
> this is major source of problems.
That's just wrong. The only "acceptable" io_block_mapping without
an ioremap has usually been the PCI IO space. It gets abused for
early serial ports, but that's a hack no matter how you look at it :-)
> Also, by this logic, if platform doesn't have BAT or CAMs or whatever,
> which effectively prevents creating this "efficient mapping" and
> hence stated purpose of io_block_mapping cannot be achieved,
> io_block_mapping() should be eliminated on this platform, right?
Depends. If you need early ioremap() prior to VM initialized so
a vmalloc will work, you have to do this even if you do call ioremap().
The 8xx ports usually do this, and ioremap() for these boards should
know to not try to allocate VM space if this was done. Most of the 8xx
ports still skip the ioremap() because the associated code changes
to ioremap() never stuck in the code.
The problem with ioremap() if you don't wire some spaces is it will try
to
allocate VM space prior to the Linux VM being initialized. We all want
to write drivers so they use the proper ioremap() interfaces, but many
drivers call this too early if you haven't made the provisions for
ioremap()
to find the "efficient" map and just return the associated address.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Andy Fleming @ 2005-05-26 18:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050526113218.23e44164@dxpl.pdx.osdl.net>
On May 26, 2005, at 13:32, Stephen Hemminger wrote:
> I finally got around to looking at this for the new skge driver.
> The Marvell phy code has several issues:
> * hard coded hex values rather than constants
These are hard-coded because it's errata. The errata doesn't name
the registers, nor the bits being set, so the best I could do is
something like:
phy_write(phydev, M88E1101_ERRATA_REGISTER1,
M88E1101_ERRATA_REG1_VALUE1);
I'm not sure that's more useful.
> * doesn't handle restricted autonegotiation
I'm not quite sure what you mean by this one. ALL the PHYs support
restricting auto-negotiation to certain values. See drivers/net/phy/
phy_device.c:genphy_config_advert(), which is called by marvell's
config_aneg function (eventually).
> * it doesn't really help the driver that much there are too
> many other warts in the hardware.
Err... the skge hardware, or the Marvell hardware? Could you
specify some warts, so I can look into what changes might need to be
made?
Andy
^ permalink raw reply
* Re: RFC: PHY Abstraction Layer II
From: Stephen Hemminger @ 2005-05-26 18:32 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com>
I finally got around to looking at this for the new skge driver.
The Marvell phy code has several issues:
* hard coded hex values rather than constants
* doesn't handle restricted autonegotiation
* it doesn't really help the driver that much there are too
many other warts in the hardware.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Matt Porter @ 2005-05-26 16:31 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded, linuxppc-dev list
In-Reply-To: <80f48eb53b0f876138cde07a997791b6@embeddededge.com>
On Thu, May 26, 2005 at 02:00:11AM -0400, Dan Malek wrote:
>
> On May 25, 2005, at 5:44 PM, Benjamin Herrenschmidt wrote:
>
> > This is a VERY BAD habit. Just set KERNELBASE to 0x80000000 if you do
> > that, an use io_block_mapping() dynamically the way I explained to
> > alloc
> > from the top of the address space.
>
> Well, back when kernelbase was assumed in too many places
> to be 0xc0000000, it was the only option.
>
> > Well, The PCI IO space base just need to be in a global that is
> > referenced by _IO_BASE, it works fine, no need to hard code a mapping.
>
> Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
> somewhere.
As BenH and Eugene already pointed out, this is simply not true. Most
maintained ports have completely stomped out use of io_block_map()
where it's not necessary. Which is everywhere on 4xx and 8xx. The
only place it serves any purpose at all is on green book and motbooke
processors.
<big snip>
> You are missing the point. The reason for io_block_mapping() isn't
> to allocate virtual space for someone, it's to _wire_ a space using an
> efficient mapping method so someone else can call ioremap() and
> get that wired access. Based upon various configuration options,
> the board set up functions call io_block_mapping() to set up these
> spaces. Then, ioremap() just finds them in the BAT or CAM array
> and says, "oh, it's a wired entry, I'll just compute the virtual address
> and return that." Unless someone tells ioremap() there are BATs or
> CAMs, it won't use them.
Why don't we try a different approach to the problem? The problem is
that io_block_mapping() is causing a ton of problems with people
abusing it. Just check the archives for all the ways people break
their ports by passing it arbitrary values. The other issue is
that although it's dangerous, the call still serves a purposes on
those processors with BATs and CAMs. So, let's kill io_block_mapping().
i.e. the version that allows virt->phys translations to be set up
without use of BATs and CAMs. Let's add a new mmu_block_mapping()
call that will ONLY map using a BAT or CAM and is only available
on platforms with those facilities. If a free BAT or CAM is not available
or alignment/size is invalid, the call fails. I would hope that would
make everybody happy.
We still end up with a call that will help people shoot themselves
in the foot, but at least we limit it to a specific task.
-Matt
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Eugene Surovegin @ 2005-05-26 16:54 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <20050526093119.A3872@cox.net>
On Thu, May 26, 2005 at 09:31:19AM -0700, Matt Porter wrote:
> Why don't we try a different approach to the problem? The problem is
> that io_block_mapping() is causing a ton of problems with people
> abusing it. Just check the archives for all the ways people break
> their ports by passing it arbitrary values. The other issue is
> that although it's dangerous, the call still serves a purposes on
> those processors with BATs and CAMs. So, let's kill io_block_mapping().
> i.e. the version that allows virt->phys translations to be set up
> without use of BATs and CAMs. Let's add a new mmu_block_mapping()
> call that will ONLY map using a BAT or CAM and is only available
> on platforms with those facilities. If a free BAT or CAM is not available
> or alignment/size is invalid, the call fails. I would hope that would
> make everybody happy.
>
> We still end up with a call that will help people shoot themselves
> in the foot, but at least we limit it to a specific task.
I second that.
--
Eugene
^ permalink raw reply
* Cross compiler
From: Rune Torgersen @ 2005-05-26 15:33 UTC (permalink / raw)
To: linuxppc-embedded
Anybody know how to set up a cross compiler for nptl support?
I'm trying to use crosstools to compile a gcc-3.4.3/glibc-2.3.4 for
ppc-604 (actually for mpc826x) on i686.
It works if I make it with linuxthreads.
If I do GLIBC_ADDON_OPTIONS=3D=3Dnptl ./my-ppc604_new.sh
Then glibc configure fails with an error about needing a gcc with forced
unwind support.
If I try to set up gcc options to enable threading, then GCC core
compile fails with error that it cannot find pthread.h
Anybody know of a solution?
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com
^ permalink raw reply
* [PATCH] update comment about gzip scratch size
From: Olaf Hering @ 2005-05-26 12:52 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev
fix a comment about the array size.
Signed-off-by: Olaf Hering <olh@suse.de>
Index: linux-2.6.12-rc5-olh/arch/ppc/boot/openfirmware/chrpmain.c
===================================================================
--- linux-2.6.12-rc5-olh.orig/arch/ppc/boot/openfirmware/chrpmain.c
+++ linux-2.6.12-rc5-olh/arch/ppc/boot/openfirmware/chrpmain.c
@@ -39,7 +39,7 @@ char *avail_high;
#define SCRATCH_SIZE (128 << 10)
-static char scratch[SCRATCH_SIZE]; /* 1MB of scratch space for gunzip */
+static char scratch[SCRATCH_SIZE]; /* 128k of scratch space for gunzip */
typedef void (*kernel_start_t)(int, int, void *, unsigned int, unsigned int);
^ permalink raw reply
* Re: How to register a user-space function as an interrupt handler ?
From: Wolfgang Denk @ 2005-05-26 12:35 UTC (permalink / raw)
To: Garcia Jérémie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B2C@exnet.3il.fr>
Hello,
in message <D4FDDD1349B5AC46B68FC26AD8AF42D6226B2C@exnet.3il.fr> you wrote:
> Hi everybody, I'm tryin to adapt a vxWorks-designed application to a
...
> What I would like to do is to make an emulation of both vxWorks routines
> (intConnect() and intEnable()) in the linux world
> cause I'm not allowed to change that code.
This makes no sense. You cannot "port" such code from VxWorks to
Linux without making any changes.
As for your question: in Linux interrupt hadling happens in kernel
context only. You cannot register user space functions as interrupt
handlers.
> Furthermore, I'm a newbie in linux developpment and if I understand
> well, I need to be in kernel-space to call those routines.
Right.
> But here is my problem: the interrupt handler that we call is part of
> the application and uses a lot of #define,semaphores and other
> ressources of the user-application. So can I implement a new linux
> system call, that will register our user-space-function (my_handler())
This cannot and should not be done. You will have to go through your
software design and adapt it for the new operating system
environment. Unix has somewhat different concepts how some things get
done, and instead of fighting with this envrionment you should adapt
to it.
> Don't forget that I have to respect two conditions: my application must
> be run from user-space and I cannot modify the
> code (my team does not want to support versions).
Simple answer: The job cannot be done under such constraints.
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
"It is better to have tried and failed than to have failed to try,
but the result's the same." - Mike Dennison
^ permalink raw reply
* How to register a user-space function as an interrupt handler ?
From: Garcia Jérémie @ 2005-05-26 10:09 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody, I'm tryin to adapt a vxWorks-designed application to a =
Linux montavista 3.1 on a board=20
running a powerPC 405 EP. In our application, that will be run from the =
linux user-space, we connect a
routine to an interrupt vector as the example below:
/**************************/
/* /home/JG/appli/ppcos.c */
/**************************/
RET_CODE_TYPE enable_and_connect_DMA(MY_DMA_CTRL * my_param)
{
BS_RET_CODE_TYPE rc1 =3D BS_RET_OK;=20
/* Connect interrupt handler for each channel */
rc =3D intConnect((VOIDFUNCPTR *)INT_VEC_DMA, my_handler, =
(int)my_param);
=20
if(!rc)
/* Enable interrupt for first channel in the interrupt =
controller */
intEnable(INT_LVL_DMA_CH0);
else
rc1 =3D BS_RET_ERROR;
=20
return rc1;
}
What I would like to do is to make an emulation of both vxWorks routines =
(intConnect() and intEnable()) in the linux world
cause I'm not allowed to change that code.
I guess that I will have to use :
intConnect() <=3D=3D> request_irq()
intEnable() <=3D=3D> enable_irq()
(Is that correct??).
Furthermore, I'm a newbie in linux developpment and if I understand =
well, I need to be in kernel-space to call those routines.=20
But here is my problem: the interrupt handler that we call is part of =
the application and uses a lot of #define,semaphores and other=20
ressources of the user-application. So can I implement a new linux =
system call, that will register our user-space-function (my_handler())
as the interrupt handler for the given vector?? Indeed, we do that for =
several interrupts (each with a different handler) and it would
be comfortable to have a system call that would take (the handler + the =
interrupt vector + the parameters) as parameters.
Don't forget that I have to respect two conditions: my application must =
be run from user-space and I cannot modify the=20
code (my team does not want to support versions).
Please help or give me a clue.
Thanks for your precious help.
J=E9r=E9mie
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-26 6:41 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <80f48eb53b0f876138cde07a997791b6@embeddededge.com>
> > Well, The PCI IO space base just need to be in a global that is
> > referenced by _IO_BASE, it works fine, no need to hard code a mapping.
>
> Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
> somewhere.
And how does pmac do ? and chrp ? It's ioremap'ed by the host bridge
init code, and _IO_BASE is set to that value. That even works with
multiple domains using pointer arithmetic.
> To take advantage of BAT or CAM mapping, you need to wire these
> entries in conjunction with the way you have configured your PCI
> bridges. You also have to set up the arrays so ioremap() will find
> them.
io_block_mapping() as a way to set a BAT/CAM to speed up access to some
PCI resources make sense, and ioremap() can I think already find out
whether this is BAT-mapped or not. I don't see any way that can prevent
what I proposed.
> > Ugh ? Can you explain why it "doesn't have the proper effect" ?
>
> Because you need a way to wire a virtual address mapping to
> a physical space before you have any way of allocating virtual space.
No, no, no.
> It's a chicken/egg problem, since ioremap_bot doesn't have a value
> until someone has set it, and you don't know where to set it until
> the board set up has determined the mapping from configuration
> options.
No.
ioremap_bot is set by MMU_init() and nowhere else, and to a constant
value (depending on HIGHMEM) and thus can perfectly be initialized
statically instead. It is _NOT_ intialized by io_block_mappingt() as I
explained already.
> > No. If you read properly, you'll see that it will _not_ initialize it
> > if
> > it is 0, because the test virt < ioremap_bot will never be true (both
> > are unsigned long) before MMU_init() is called.
>
> I think we are talking past each other. The reason for that code
> in io_block_mapping() is so you can set multiple BAT/CAM entries,
> and the lowest (smallest) wired virtual address becomes the base
> of that space. This way, you can use io_block_mapping() to set
> up BATs and CAMs, and get ioremap() to use them if set.
Ugh ??? Damn, you don't seem to understand that code at all.
But first, let's clear things up since you are mixing several different
things at least here. Let's make a list of _facts_ :
- ioremap_bot. This is the "top" of the vmalloc space, and it can be
"pushed down" to make room for early allocations of virtual space (for
things like early ioremap) before full initialisation. This is
initialized by MMU_init(), which is called _after_ machine_init(), but
as I noted, it could/should be initialized statically instead. It is
initialized before ppc_md.setup_io_mappings() is called as well.
- io_block_mapping() will push-down ioremap_bot as well if the mapping
requests a virtual address above KERNELBASE and below the current
ioremap_bot value. This is obviously necessary or further unrelated
vmalloc/ioremap's may be "allocated" to virtual addresses overlapping
the io_block_mapping() which is wrong.
So there is nothing, I mean absolutely _nothing_ that prevents us from
"improving" io_block_mapping() so that it can request virtual space by
pushing ioremap_bot down the way ioremap() does when called early.
- Both io_block_mapping() and ioremap() can/will call map_page(). The
former on CPUs without BATs or CAMs (or running out of them), the later
if the mapping requested is for a physical address that wasn't already
covered by a BAT or CAM. The only requirement for map_page() to work is
to be able to do pte_alloc_kernel(), which is implemented such that
when !mem_init_done, it does an early_get_page() which works using the
mem_pieces mecanism when bootmem hasn't be initialized yet ... That
means that both io_block_mapping() and ioremap() both _WORK_ at any time
after MMU_init(), or more specifically, from the time
ppc_md.setup_io_mappings() has been called. ioremap will simply allocate
virtual space by pushing ioremap_bot down, and I'm simply proposing to
add this ability to io_block_mapping() too. That will _not_ change
anything to the fact that io_block_mapping's done on BATs/CAMs will be
"recorded" in the array and thus futher ioremap's will be able to use
that etc etc etc...
- There is _one_ important point to keep in mind, but that has always
been true: None of this work before MMU_init(), we may want to add some
BUG_ON() in there. BUG_ON(ioremap_bot == 0) would do the trick. Just in
case somebody tries to call these from platform_init().
So now, putting all the above together, what do we see ?
That the only real difference between io_block_mapping() and ioremap()
are:
- The former allows you to setup hard code v->p mappings (but I've
showed several times now that it shouldn't be necessary anymore)
- The former can use a "BAT" or "CAM" instead of page tables which can
be of some use for performances.
Now, what about:
1) Adding to io_block_mapping() the ability to alloc dynamically the
virtual space. That would have 0 impact on drivers using ioremap (they
would still "benefit" from the speed up if they happen to map something
already covered by a BAT/CAM). _IO_BASE can already be a variable. Only
a few platforms hard-coding other things may need to be changed (but
that is step 1, no worry...)
2) Getting rid of remaining hard coded mappings (heh, slowly, not all
at once, but that shouldn't be terribly difficult) and finally deprecate
the usage of io_block_mapping() with a hard coded virtual address.
3) Heh, no more of these ? Cool ... Now the only remaining use of
io_block_mapping() is to setup those "fast" blocks to speed up some IOs.
Can we think about something like ... ahem... A special flag to pass to
__ioremap() that would make it use BATs/CAMs (the first one who says
that is complicated goes back to school, please !)
4) ppc_md.setup_io_mappings is just a few instructions & 2 printk's
away from setup_arch(). (The common setup_arch). ppc_md.setup_arch() is
not that far away neither: ocp_init is done before, and xmon/kgdb stuff.
Do we really need that early callback _that_ early still ? can't
setup_arch() be early enough ?
> The io_block_mapping() has never been used to request
> virtual space, it's purpose is to wire virtual address spaces so
> others can use them. If all you are doing is requesting an
> arbitrary virtual address to be allocated, just use ioremap().
No, this is not the _purpose_ of io_block_mapping(), though it's what it
does. It's purpose was lost in history :) There should be no reason ever
to want to wire virtual space. Which means the only purpose left here is
to setup mappings that are "faster" than normal page tables for critical
things.
> > Damn. What I am saying is that it's plain wrong to mess around with the
> > space between TASK_SIZE and KERNELBASE and we should tie them together.
>
> Can we do that now? The reason it wasn't done in the past was because
> of the Prep memory map, our PCI configuration, and assumptions of the
> macros/functions that managed those spaces.
PowerMac did that kind of cruft too, I fixed it in about 15 minutes a
few years ago. It's just a matter of killing those constants that
contain a virtual address and use variables instead. It's not like PCI
IO space or config space was a performance sensitive thing anyway :)
> You are missing the point. The reason for io_block_mapping() isn't
> to allocate virtual space for someone, it's to _wire_ a space using an
> efficient mapping method so someone else can call ioremap() and
> get that wired access.
But it can do that without wiring the virtual space ! That is my point.
That someone else will call ioremap with a physical address, ioremap
will figure out that it matches one of the BATs/CAMs and will return the
appropriate virtual address where this BAT/CAM is virtually mapped.
Wether that actual virtual address was hard-coded when
io_block_mapping() was called, or allocated dynamically by moving
ioremap_bot is totally irrelevant and doesn't change anything to the
effect on the driver calling ioremap.
> Based upon various configuration options,
> the board set up functions call io_block_mapping() to set up these
> spaces. Then, ioremap() just finds them in the BAT or CAM array
> and says, "oh, it's a wired entry, I'll just compute the virtual address
> and return that." Unless someone tells ioremap() there are BATs or
> CAMs, it won't use them.
And ? How does that invalidate any of my previous statements ?
>
> > I don't see how that would be changed/affected in any way by making
> > io_block_mapping() capable of dynamically allocating it's virtual
> > space...
>
> Ugh. How do you know how much space is available? How do you
> know what to wire using BATs or CAMs? Someone has to do that.
Good, good, I'm not totally dismissing the usefulness of wiring some
memory using BATs and CAMs, just the fact that the virtual address is
hard coded. I don't see what is the problem with available space. That
space will be taken anyway. Since io_block_mapping() tend to be the
first thing done, it will get nicely aligned chunks of memory form
ioremap_bot, and there will be no wastage. Doesn't need to be hard coded
to obtain that result.
> The io_block_mapping isn't a replacement to ioremap(), nor is
> ioremap() a replacement for io_block_mapping(). They work together
> to provide wired virtual address mapping. In essence,
> io_block_mapping()
> tells ioremap() about wired entries.
Oh well, I've already explained what I think above, no need to repeat
myself again.
> > .... but aim to change it so that it allocates it's virtual space
>
> But, it can't.
But it CAN.
> That's the whole purpose of the function, to determine
> how much IO space can be mapped with BATs or CAMs, then to
> remove that space from the vmalloc pool and wire it into a contiguous
> space that can be covered by large mapping.
And what prevent the virtual address of that space to be calculated
instead of hard coded ?
> This is why it makes no sense to call io_block_mapping() with a zero
> for a virtual address and ask it to allocate some arbitrary space.
No, you don't make sense.
> What do you mean by "optimize"? The whole purpose here is to
> force a mapping using a BAT or CAM. You can't do that with arbitrary
> pages from vmalloc space. You have to force the alignment and
> size of the space, and the only way to do that is by simply removing
> from the top of the vmalloc pool and giving it to ioremap().
Just having io_block_mapping() moving down ioremap_bot (with appropriate
alignement of course) would just do the trick :) Again, no need for the
caller to hard code that address.
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Eugene Surovegin @ 2005-05-26 6:20 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded, linuxppc-dev list
In-Reply-To: <80f48eb53b0f876138cde07a997791b6@embeddededge.com>
On Thu, May 26, 2005 at 02:00:11AM -0400, Dan Malek wrote:
>
> >Well, The PCI IO space base just need to be in a global that is
> >referenced by _IO_BASE, it works fine, no need to hard code a mapping.
>
> Sure you do. No one ioremap()s PCI IO space. It has to be hard wired
> somewhere.
Dan, you must be kidding. 44x ioremaps PCI IO space, 40x uses
io_block_mapping for that, but this is just brain-damaged and should
be fixed.
What is so special about PCI IO space that it must be "wired" ?
[snip]
> You are missing the point. The reason for io_block_mapping() isn't
> to allocate virtual space for someone, it's to _wire_ a space using an
> efficient mapping method so someone else can call ioremap() and
> get that wired access.
Wow, this is something new for me. So you are saying that
io_block_mapping() was supposed to be used with ioremap()?
Could you point me to the port which actually does this?
So far I only saw io_block_mapping() used as a short-cut way _NOT_ to
ioremap and get hard-coded v:p mapping and then use this knowledge to
access physical address directly without ever calling ioremap(). And
this is major source of problems.
Also, by this logic, if platform doesn't have BAT or CAMs or whatever,
which effectively prevents creating this "efficient mapping" and
hence stated purpose of io_block_mapping cannot be achieved,
io_block_mapping() should be eliminated on this platform, right?
--
Eugene
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox