* gdb-6.3 for mpx8xx?
From: Steven Scholz @ 2005-04-18 13:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
has someone successfully built gdb-6.3 for mpx8xx processors?
Thanks.
--
Steven
^ permalink raw reply
* 2.6.11 kernel, PPC, and IPv6
From: Bellino, Phil @ 2005-04-18 13:20 UTC (permalink / raw)
To: LinuxPPC
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
Hello,
I do not know if this email is appropriate for this mailing list, but I
thought I would give it a try.
Is there anyone out there who is using(or attempting to use) IPv6 with PPC
and a 2.6.11 kernel with whom I could email directly with some specific
questions?
One of my questions is at boot time, my eth0 device does not have it's
link-local address. I must issue an "ifconfig eth0 down" and then an
"ifconfig eth0 up" to get this work work.
Also, it does not auto-configure the info for a link-global prefix/address
that is provided by the router announcements.
There are PCs in my network on i686 athlons, i386 running 2.6.5 kernels that
do in fact handle the above IPv6 correctly.
I do understand that there are IPv6 mailing list and I do belong to them,
but thus far no one has been able to assist me in these issues.
I apologize if this is not the correct forum for these types of questions.
Thank you,
Phil Bellino
============================
Phil Bellino
MRV Communications, Inc.
Boston Product Division
295 Foster St.
Littleton,MA 01460
Tel: (978)952-4807
Email: pbellino@mrv.com
============================
[-- Attachment #2: Type: application/ms-tnef, Size: 2413 bytes --]
^ permalink raw reply
* RE: Impact of change n port size
From: Atit_Shah @ 2005-04-18 6:05 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Hi
Please IGNORE the "DISCLAIMER" which follows my mail, the company I work
for adds this and I don't know where in my mailbox setting I can disable
this option.
Atit=20
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
Sent: Monday, April 18, 2005 11:22 AM
To: Atit_Shah
Subject: Re: Impact of change n port size
On Mon, Apr 18, 2005 at 10:01:27AM +0530, Atit_Shah wrote:
[snip]=20
> DISCLAIMER:
> This email (including any attachments) is intended for the sole use=20
> of the intended recipient/s and may contain material that is=20
> CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance=20
> by others or copying or distribution or forwarding of any or all of=20
> the contents in this message is STRICTLY PROHIBITED. If you are not=20
> the intended recipient, please contact the sender by email and=20
> delete all copies; your cooperation in this regard is appreciated.
Please, remove this disclaimer when posting to mail list, and then=20
I probably will be able to answer your questions.
--=20
Eugene
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.
^ permalink raw reply
* Impact of change n port size
From: Atit_Shah @ 2005-04-18 4:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I have a kernel image which works perfectly for my reference
board. When I try to port the same image on my board I seem to be facing
problems. The only difference I see between the reference board and my
board is the port size and capacity of RAM.=20
I have taken care of sending the right value for the RAM size
through BD_INFO. Would there be and where all would the change be, if
any, in the kernel code OR when I make the kernel image ie through "make
menuconfig" / "menu xconfig" required to be made for port size of RAM?
Out of curiosity what would be the change required for different
FLASH port size again on the kernel side.
=09
Thanks and Regards
Atit
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.
^ permalink raw reply
* Re: Problems porting to a custom PPC405GPr board using a vanilla 2.6.10 kernel
From: Niklaus Giger @ 2005-04-17 20:13 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <200502271820.45081.niklaus.giger@member.fsf.org>
Hi
Just to document my error I respond to my previous posting.
After having dropped my work on this problem for a few weeks
I figured my problem. I was merging code from the walnut board which was ba=
sed=20
on the IBM boot eprom which has a different layout to pass the information =
to
the Linux kernel.
After switching to the U-Boot memory the kernel booted okay.=20
After disabling the following two lines in drivers/serial/8250.c
serial_outp(up, UART_DLL, quot & 0xff); /* LS of divisor */
serial_outp(up, UART_DLM, quot >> 8); /* MS of divisor */
my console stays at 9600 baud.=20
Best regards
Am Sonntag, 27. Februar 2005 18.20 schrieb Niklaus Giger:
> Am Sonntag, 27. Februar 2005 17.08 schrieb Matt Porter:
> > On Sun, Feb 27, 2005 at 04:10:30PM +0100, Niklaus Giger wrote:
> > > Am Samstag, 26. Februar 2005 23.28 schrieb Niklaus Giger:
> > > > Hi
> > > >
> > > > I would like to port Linux to a custom PPC405GPr board. Its hardware
> > > > runs vxWorks fine for more than a year.
> > >
> > > I made some more progress. After adding 3 lines for MMU support with
> > > the BDI I can debug the startup up to kernel_start using BDI.
> > >
> > > Afterwards my console changes the baudrate for still unknown reasons.
> >
> > How do you know this? Console isn't initialized until after the kernel
> > command line printk and a few other facilities are initialized.
>
> Because I see the following output
> arch: exit
> *=CB=AB=E3=BE=B5=BA=B3=B9=BF=BE=B6=B9=B3=BC=B1=B5=B3=A0=B6=B7=BE=B7=B9=B7=
=B5=B2=B4=B9=B6=B4=BE=B3=BF=BA=B7=B7=B3=B3=A6=B5=B2=BB=B9=BF=BE=A4=B5=B2=B9=
=B1=BE=A3=B5=BE=A6=B5=B2=A3=A5=A4=A2=BD=B9=BC
> =B4=BA=B7=BE=B5=BC=B9=B3=BC=B3=A3=B5=B2=BE=B5=BC=B3=B7=BD=BD=B1=BE=B4=BC=
=B1=BE=B5=B3=B7=BE=BB=BF=BC=B5=B4=BC=B9=AB=B1=B0=A0=A1=A4=B8=B1=B3=B8=BC=B1=
=B2=BC=B5=B5=BE=BC=B2=B1=B5=BB=B7=B2=B4=B5=B2=B2=B9=B4=B5=B3
> which for me is typical for a wrong baudrate.
> Okay, I do not know this. Specially it may not be the "console" device but
> whatever is going out at this moment via the PPC405GPr internal UART0
> device.
>
> > > Analysing the __log_buf I get the following output
> > > (gdb) x/s &__log_buf
> > > 0xc01accfc <ratelimit_lock.9>: "<4>Linux version 2.6.10
> > > (niklaus@ng.ngiger.dyndns.org) (gcc-Version 3.3.5 (Debian 1:3.3.5-8))
> > > #15 Sun Feb 27 14:44:27 CET 2005\n<7>On node 0 totalpages: 8240\n<7>=
=20
> > > DMA zone: 8240 pages, LIFO batch:2\n<7>"...
> > > (gdb) x
> > > 0xc01acdc4 <ratelimit_lock.9+200>: " Normal zone: 0 pages, LIFO
> > > batch:1\n<7> HighMem zone: 0 pages, LIFO batch:1\n<4>Built 1
> > > zonelists\n<4>Kernel command line: ip=3D172.25.1.6\n<4>PID hash table
> > > entries: 256 (order:8, 4096 bytes)\n"
> > > (gdb) x
> > > 0xc01ace84 <ratelimit_lock.9+392>: ""
> >
> > Is this all of the log_buf output? Try setting your kernel cmdline
> > with "console=3DttyS0,115200" where 115200 is you console baudrate
> > you are using in U-Boot. Otherwise, the kernel 8250 driver has no
> > idea which baudrate to set for the 8250/console.
>
> Yes, this is all. I tried you suggestion, but I got no other result. The
> paramter "console=3DttyS0,9600" now is found in the log buffer. Or is tty=
S0
> the wrong device name for the internal PPC405Gpr UART0?
> I am using 9600 8 bit no parity which should be anyway the default baudra=
te
> for the console.
>
> Thanks for your help
=2D-=20
Niklaus Giger
Wieshoschet 6
CH-8753 Mollis
Tel. ++41 55 612 20 54 (privat)
Tel. ++41 55 618 64 68 (Gesch=E4ft)
^ permalink raw reply
* [PATCH 2.6.11.7] macintosh/adbhid.c: adb buttons support for aluminium PowerBook G4
From: Andreas Jaggi @ 2005-04-17 13:42 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Andrew Morton, linux-kernel, linuxppc-dev, debian-powerpc,
linux-input
Hi,
This patch adds support for the special adb buttons of the aluminium
PowerBook G4.
Signed-off-by: Andreas Jaggi <andreas.jaggi@waterwave.ch>
diff -uNr a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
--- a/drivers/macintosh/adbhid.c 2005-04-09 22:49:49.000000000 +0200
+++ b/drivers/macintosh/adbhid.c 2005-04-10 15:27:54.000000000 +0200
@@ -555,6 +555,42 @@
#endif /* CONFIG_PMAC_BACKLIGHT */
input_report_key(&adbhid[id]->input, KEY_BRIGHTNESSUP, down);
break;
+
+ case 0xc: /* videomode switch */
+ input_report_key(&adbhid[id]->input, KEY_SWITCHVIDEOMODE, down);
+ break;
+
+ case 0xd: /* keyboard illumination toggle */
+ input_report_key(&adbhid[id]->input, KEY_KBDILLUMTOGGLE, down);
+ break;
+
+ case 0xe: /* keyboard illumination decrease */
+ input_report_key(&adbhid[id]->input, KEY_KBDILLUMDOWN, down);
+ break;
+
+ case 0xf:
+ switch (data[1]) {
+ case 0x8f:
+ case 0x0f:
+ /* keyboard illumination increase */
+ input_report_key(&adbhid[id]->input, KEY_KBDILLUMUP, down);
+ break;
+
+ case 0x7f:
+ case 0xff:
+ /* keypad overlay toogle */
+ break;
+
+ default:
+ printk(KERN_INFO "Unhandled ADB_MISC event %02x, %02x, %02x, %02x\n",
+ data[0], data[1], data[2], data[3]);
+ break;
+ }
+ break;
+ default:
+ printk(KERN_INFO "Unhandled ADB_MISC event %02x, %02x, %02x, %02x\n",
+ data[0], data[1], data[2], data[3]);
+ break;
}
}
break;
@@ -775,6 +811,10 @@
set_bit(KEY_BRIGHTNESSUP, adbhid[id]->input.keybit);
set_bit(KEY_BRIGHTNESSDOWN, adbhid[id]->input.keybit);
set_bit(KEY_EJECTCD, adbhid[id]->input.keybit);
+ set_bit(KEY_SWITCHVIDEOMODE, adbhid[id]->input.keybit);
+ set_bit(KEY_KBDILLUMTOGGLE, adbhid[id]->input.keybit);
+ set_bit(KEY_KBDILLUMDOWN, adbhid[id]->input.keybit);
+ set_bit(KEY_KBDILLUMUP, adbhid[id]->input.keybit);
break;
}
if (adbhid[id]->name[0])
diff -uNr a/include/linux/input.h b/include/linux/input.h
--- a/include/linux/input.h 2005-04-09 22:49:49.000000000 +0200
+++ b/include/linux/input.h 2005-04-10 15:28:33.214974136 +0200
@@ -328,6 +328,11 @@
#define KEY_BRIGHTNESSUP 225
#define KEY_MEDIA 226
+#define KEY_SWITCHVIDEOMODE 227
+#define KEY_KBDILLUMTOGGLE 228
+#define KEY_KBDILLUMDOWN 229
+#define KEY_KBDILLUMUP 230
+
#define KEY_UNKNOWN 240
#define BTN_MISC 0x100
^ permalink raw reply
* Status report for 2.6.12-rc2
From: Wolfram Quester @ 2005-04-17 9:18 UTC (permalink / raw)
To: linuxppc-dev list
In-Reply-To: <1113184854.9567.522.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]
Hi,
I use debian on my Powerbook6,2 and recently upgraded from kernel 2.6.10
with the patch Guido Günther provides at [1] to 2.6.12-rc2 with ben's
tumbler/snapper patches applied.
So far I've seen the following issues:
1. I tried the new nvidiafb - just because I'm curious and the help says
"This driver supports graphics boards with the nVidia chips, TNT and
newer. For very old chipsets, such as the RIVA128, then use the
rivafb."
The kernel crashed during boot when it tried to switch to nvidiafb. I
could see the messages that appeared before this stage until I
switched the computer off. Booting with video=ofonly went well and
using the traditional rivafb works fine.
This situation reminds me to crashes I had sometime ago when I was
testing Guido's patches for rivafb when he tried to get proper
support for NV30 into rivafb.
2. Sometimes the machine crashes on suspend to disk. It only happens when I work
in X and it seems to freeze in the process of switching to a virtual
terminal. The screen shows a distorted image of the previous screen
(as if I had 8Bit colour depth with oversized pixels).
I never had such freezes with 2.6.10 and this is the issue which
annoys me most ATM. I don't have a way to clearly reproduce the
freeze. It happend in two out of perhaps 20 suspends. It only seems
to happen on the first suspend after boot.
The suspend itself is much much faster than with 2.6.10 however.
3. I configured sound to use snd-powermac. Before I used
dmasound-{pmac,core} and it works mostly. After a
suspend-resume-cycle I have to kill xfce4-panel, which accesses
/dev/mixer0, rmmod snd-powermac, wait a second and reinsert the
module.
4. Something that is quite annoying but harmless is that after wakeup
the machine sometimes suspends again immediately. I had something
like this before. On resume the PMU seems to be some kind of
irritated and gives wrong information about remaining runtime.
If this remaining time is 0 pbbuttonsd suspends the machine again.
Thanks,
Wolfi
1. http://honk.physik.uni-konstanz.de/~agx/linux-ppc/kernel/2.6.11.6-agx0.diff
--
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Your credit/debit card information must be updated!
From: eBay @ 2005-04-12 20:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 13112 bytes --]
^ permalink raw reply
* Your credit/debit card information must be updated
From: eBay @ 2005-04-16 17:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 13127 bytes --]
^ permalink raw reply
* [PATCH] drivers/macintosh: Remove redundant NULL check before kfree
From: Jesper Juhl @ 2005-04-16 16:20 UTC (permalink / raw)
To: linux-kernel
Cc: Roman Zippel, linuxppc-dev, linux-m68k, Geert Uytterhoeven,
Joshua Thompson
This patch removes a redundant NULL check before kfree() - kfree handles
NULL pointers just fine so there's no need to check first.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
---
drivers/macintosh/adbhid.c | 3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.12-rc2-mm3-orig/drivers/macintosh/adbhid.c 2005-03-02 08:38:33.000000000 +0100
+++ linux-2.6.12-rc2-mm3/drivers/macintosh/adbhid.c 2005-04-16 18:00:10.000000000 +0200
@@ -806,8 +806,7 @@ adbhid_input_register(int id, int defaul
static void adbhid_input_unregister(int id)
{
input_unregister_device(&adbhid[id]->input);
- if (adbhid[id]->keycode)
- kfree(adbhid[id]->keycode);
+ kfree(adbhid[id]->keycode);
kfree(adbhid[id]);
adbhid[id] = NULL;
}
--
Jesper Juhl
PS. Sorry about the long CC list, but I was unsure who to send this to.
Please CC me on replies.
^ permalink raw reply
* bftpd (correction)
From: Vijay Padiyar @ 2005-04-16 5:24 UTC (permalink / raw)
To: BusyBox Support, LinuxPPC Support
Correction!! The line I added to /etc/inetd.conf was:
ftp stream tcp nowait root /usr/sbin/bftpd bftpd
Guess you'd realize that on your own, though.
http://www.vijaypadiyar.eu.tf
^ permalink raw reply
* i went for bftpd...
From: Vijay Padiyar @ 2005-04-16 5:16 UTC (permalink / raw)
To: BusyBox Support, LinuxPPC Support
Hi guys
Thanks a lot, guys, for your advice and immediate responses!!!
I finally decided to go with bftpd (http://bftpd.sourceforge.net). I think
it's great for embedded applications. The final stripped executable is about
45 KB in size and it also works with inetd, which is great from my point of
view.
All I needed to do is configure it for my target (MPC8260) and then compile
it with the resulting makefile. Then I copied the final stripped executable
to /usr/sbin on my target's root filesystem and added the following entry to
/etc/inetd.conf on my target:
ftp stream nowait root /usr/sbin/bftpd bftpd
After that, I copied the configuration file bftpd.conf supplied with the
bftpd source, customized it according to my requirements and placed it in
the /etc folder on my target. And that was it. I'm now able to connect
successfully and use it just fine.
Regards
Vijay Padiyar
http://www.vijaypadiyar.eu.tf
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-16 0:50 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b0504151609397d73f7@mail.gmail.com>
On Fri, Apr 15, 2005 at 04:09:08PM -0700, Shawn Jin wrote:
> On 4/15/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> > On Fri, Apr 15, 2005 at 02:36:51PM -0700, Shawn Jin wrote:
> > >
> > > The home-made interrupt controller PIC supports interrupt priorities
> > > and critical/non-critical interrupts. I found that the current kernel
> > > doesn't support interrupt priorities.
> >
> > Yes, we don't have IRQ priorities on 4xx. Theoretically, they can be
> > emulated in get_irq, but I really don't think it's worth it.
>
> Hmmm...that's one way I thought of to implement IRQ priority. Why
> isn't it worth it?
It will significantly complicate PIC code, so if we want to go down
this road, there should be some _real_ reasons and examples, that such
change will be beneficial. For all the time I have been working with
4xx based designs, I never needed such functionality.
> ppc4xx_pic gets the first irq from the least
> significant bit by calling ffs(). So theoretically and maybe
> practically some external interrupts will keep UART's interrupt from
> being served.
Yeah, _theoretically_ this is possible, although, in this case I think
UART IRQ starvation will be your least problem :).
> > > I noticed that the implementation of ppc4xx_pic.c disables all
> > > critical interrupts during initialization. To support critical
> > > interrupts, is it so simple that we change the handler of critical
> > > exception from CriticalInput to do_IRQ in head_44x.S?
> >
> > No, it's not that simple. Linux doesn't support a notion of critical
> > IRQs versus normal ones. Until there is an infrastructure for this, it
> > doesn't make any sense to implement 4xx support.
>
> What kind of infrastructure can you think of to support this? ppc440
> at least provides some interrupt processing registers (CSSR0/1) to
> differentiate critical and non-critical interrupts.
OK, think about local_irq_disable/enable, and all code which is
affected by this. Should these function disable all IRQs or just
normal ones? If just normal one, what will happen if your critical IRQ
handler calls the code, which assumes it's non-reentrant, because it
called local_irq_disable()? Etc..
I really think that if you need some special higher-priority IRQ
context you'd better use RTAI or RTLinux. At least, they make clear
(IIRC) that these IRQ contexts are special.
>
> Another confusion about 440GP/GX UIC is the registers VCR (Vector
> Configuration Reg) and VR (Vector Reg). They seem to be totally
> useless on linux. The interrupt vector is already in the table of
> irq_desc[]. Why does the controller have to generate the address?
It's being generated only for critical IRQs, so yes, because we don't
use them, it's completely useless for us.
What could be interesting, though, is to to make all 4xx IRQs
critical, in this case we could use VR to quickly determine which IRQ
was asserted, instead of current implementation when we use bit
operations. Not sure, if performance gain is really worth the
effort :)
--
Eugene
^ permalink raw reply
* Re: Question on fixup_bigphys_addr() in syslib/ibm44x_common.c
From: Eugene Surovegin @ 2005-04-16 0:36 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05041517167c0cfa5c@mail.gmail.com>
On Fri, Apr 15, 2005 at 05:16:32PM -0700, Shawn Jin wrote:
> Hi,
>
> When looking into ppc440 support, I'm confused on the functionality of
> fixup_bigphys_addr() in syslib/ibm44x_common.c. It's called by
> ioremap() in arch/ppc/mm/pgtable.c. The prototype is as follows.
> phys_addr_t fixup_bigphys_addr(phys_addr_t addr, phys_addr_t size)
>
> Why do we need this fixup? ioremap() takes a physical address as an
> argument and maps the physical address space to virtual address space
> with the specified size. Since it's already a physical address, which
> is 36-bit address in the case of 440, why do we need to fix up the
> ERPN? I must be missing something here.
phys addr which is passed to ioremap doesn't always contain full
36-bit address. The reason for this is that some generic Linux
subsystems (e.g. PCI) for 32-bit archs assume that physical address is
always 32-bit. To make such generic (not 440-specific) drivers work
on 44x we need this hack.
IIRC there is an effort under way to fix this generic kernel
limitation, so hopefully we will be able to get rid of this hack soon.
--
Eugene
^ permalink raw reply
* Question on fixup_bigphys_addr() in syslib/ibm44x_common.c
From: Shawn Jin @ 2005-04-16 0:16 UTC (permalink / raw)
To: ppcembed
Hi,
When looking into ppc440 support, I'm confused on the functionality of
fixup_bigphys_addr() in syslib/ibm44x_common.c. It's called by
ioremap() in arch/ppc/mm/pgtable.c. The prototype is as follows.
phys_addr_t fixup_bigphys_addr(phys_addr_t addr, phys_addr_t size)
Why do we need this fixup? ioremap() takes a physical address as an
argument and maps the physical address space to virtual address space
with the specified size. Since it's already a physical address, which
is 36-bit address in the case of 440, why do we need to fix up the
ERPN? I must be missing something here.
Thanks,
-Shawn.
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Shawn Jin @ 2005-04-15 23:09 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050415221235.GA29802@gate.ebshome.net>
On 4/15/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Fri, Apr 15, 2005 at 02:36:51PM -0700, Shawn Jin wrote:
> >
> > The home-made interrupt controller PIC supports interrupt priorities
> > and critical/non-critical interrupts. I found that the current kernel
> > doesn't support interrupt priorities.
>=20
> Yes, we don't have IRQ priorities on 4xx. Theoretically, they can be
> emulated in get_irq, but I really don't think it's worth it.
Hmmm...that's one way I thought of to implement IRQ priority. Why
isn't it worth it? ppc4xx_pic gets the first irq from the least
significant bit by calling ffs(). So theoretically and maybe
practically some external interrupts will keep UART's interrupt from
being served.
> > Is this observation true? Is
> > there any existing patch to support that?
>=20
> I'm not aware of such patch existence.
By googling the Internet I found this patch for i386 architecture
http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040304/rtirq.html.
This mustn't have been caught sight of by linux mainstream.
Anybody knows if RTAI or RTLinux supports IRQ priorities?
> > I noticed that the implementation of ppc4xx_pic.c disables all
> > critical interrupts during initialization. To support critical
> > interrupts, is it so simple that we change the handler of critical
> > exception from CriticalInput to do_IRQ in head_44x.S?
>=20
> No, it's not that simple. Linux doesn't support a notion of critical
> IRQs versus normal ones. Until there is an infrastructure for this, it
> doesn't make any sense to implement 4xx support.
What kind of infrastructure can you think of to support this? ppc440
at least provides some interrupt processing registers (CSSR0/1) to
differentiate critical and non-critical interrupts.
Another confusion about 440GP/GX UIC is the registers VCR (Vector
Configuration Reg) and VR (Vector Reg). They seem to be totally
useless on linux. The interrupt vector is already in the table of
irq_desc[]. Why does the controller have to generate the address?
Thanks for the inputs. Welcome more.
Regards,
-Shawn.
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-15 22:12 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05041514362746169a@mail.gmail.com>
On Fri, Apr 15, 2005 at 02:36:51PM -0700, Shawn Jin wrote:
>
> The home-made interrupt controller PIC supports interrupt priorities
> and critical/non-critical interrupts. I found that the current kernel
> doesn't support interrupt priorities.
Yes, we don't have IRQ priorities on 4xx. Theoretically, they can be
emulated in get_irq, but I really don't think it's worth it.
> Is this observation true? Is
> there any existing patch to support that?
I'm not aware of such patch existence.
> I noticed that the implementation of ppc4xx_pic.c disables all
> critical interrupts during initialization. To support critical
> interrupts, is it so simple that we change the handler of critical
> exception from CriticalInput to do_IRQ in head_44x.S?
No, it's not that simple. Linux doesn't support a notion of critical
IRQs versus normal ones. Until there is an infrastructure for this, it
doesn't make any sense to implement 4xx support.
--
Eugene
^ permalink raw reply
* Interrupt prioritization on linux for ppc440
From: Shawn Jin @ 2005-04-15 21:36 UTC (permalink / raw)
To: ppcembed
Hi,
The home-made interrupt controller PIC supports interrupt priorities
and critical/non-critical interrupts. I found that the current kernel
doesn't support interrupt priorities. Is this observation true? Is
there any existing patch to support that? Can RTAI or RTLinux
prioritize interrupts?
I noticed that the implementation of ppc4xx_pic.c disables all
critical interrupts during initialization. To support critical
interrupts, is it so simple that we change the handler of critical
exception from CriticalInput to do_IRQ in head_44x.S?
Would you please share some of your inputs with me while I'm googling
this issue?
Thanks,
-Shawn.
^ permalink raw reply
* Re: Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jon Loeliger @ 2005-04-15 14:22 UTC (permalink / raw)
To: Jakob Viketoft
Cc: Jon Masters, Tom Rini, Andrei Konovalov, Sylvain Munaut,
Linux PPC Embedded list
In-Reply-To: <425E3DC6.7030007@bitsim.se>
On Thu, 2005-04-14 at 04:54, Jakob Viketoft wrote:
> Has any more happened on this off-list,
Not by me. A couple folks are also known to be on vacation.
> or it is just in testing-mode right now?
likely. Still waiting for feedback such as yours! (Thanks!)
> I applied the changes to a 2.6.12-rc2 tree (with some minor rejects to
> sort out) and it compiles and boots fine on my Memec FF1152 board with
> the Virtex-II Pro chip (Xilinx ML300 config).
Excellent.
> A couple of small changes to be able to use the simple boot-loader is below.
I'll add these to my mix!
Thanks,
jdl
^ permalink raw reply
* Freescale PowerQuick8540ADS board vs QUICCStart MPC8540
From: emre kara @ 2005-04-15 11:10 UTC (permalink / raw)
To: linuxppc-embedded
Dear All;
I'll buy a QUICCStart MPC8540 from freecale, it
includes linux 2.4 port from metrowerks, but I want to
use 2.6 vanilla linux, on the kernel source tree, I
can't find any board special config or source file, is
this board compatible with 8540ADS, if not, how much
modifications does it need?
Thanks alot.
Emre
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* Re: CPM uart
From: Marco Schramel @ 2005-04-15 8:38 UTC (permalink / raw)
To: Dan Malek; +Cc: PPC_LINUX
In-Reply-To: <ca0dbea676037b37464b3318b4271a30@embeddededge.com>
Hi all,
thanks for helping me.
Now it works with my configuration.
I added SCC_NUM_BASE as it is without console. And now it works.
#ifdef SCC_CONSOLE
switch (state->smc_scc_num - SCC_NUM_BASE) { /*SCC_NUM_BASE added*/
case 0:
page = CPM_CR_SCC1_PAGE;
sblock = CPM_CR_SCC1_SBLOCK;
break;
case 1:
page = CPM_CR_SCC2_PAGE;
sblock = CPM_CR_SCC2_SBLOCK;
break;
case 2:
page = CPM_CR_SCC3_PAGE;
sblock = CPM_CR_SCC3_SBLOCK;
break;
}
#else
.
.
.
Seems the use of SMC in conjunction with console on SCC was not planed in this version.
Furthermore i will test it and post if it fails.
Best regards
Marco
---------
Marco Schramel
^ permalink raw reply
* Re: MTD Mapping driver - out of vmalloc space
From: Jörn Engel @ 2005-04-15 5:45 UTC (permalink / raw)
To: Chris Elston; +Cc: linuxppc-embedded
In-Reply-To: <F38DEABE0E171746B133C1ABBD142D9703691B00@radmail.Radstone.Local>
On Tue, 12 April 2005 11:07:38 +0100, Chris Elston wrote:
>
> Thanks for everyone's input on this, I've moved the kernel virtual
> base address to 0xa0000000, and it works fine now.
>
> I'm still not convinced that this is a future proof solution
> though. What happens when I get a board with 512MB Flash 1GB SDRAM?
> I can push the top of the SDRAM out to the high mem area, but I'll
> have to encroach further into user space to map the Flash. There's
> no good reason that the whole of the Flash need be mapped at the same
> time. (Perhaps performance?)
Definitely performance. At the end of the day, you need a bigger
namespace of some sorts. Possible solutions are:
o a 64bit machine,
o a 4GiB/4GiB kernel/user split and
o a PPC440 with 36bit addressing and some hardware and ioremap tricks
to move flash above the 32bit limit.
The 4/4 split also costs some performance. It doesn't violate the
'flash read must be atomic' requirement, though.
Jörn
--
...one more straw can't possibly matter...
-- Kirby Bakken
^ permalink raw reply
* Re: {PATCH] Fix IBM EMAC driver ioctl bug
From: Eugene Surovegin @ 2005-04-15 4:01 UTC (permalink / raw)
To: Geoff Levand; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <425EB470.9040203@am.sony.com>
On Thu, Apr 14, 2005 at 11:20:32AM -0700, Geoff Levand wrote:
> Fix IBM EMAC driver ioctl bug.
>
> I found IBM EMAC driver bug.
> So mii-tool command print wrong status.
>
> # mii-tool
> eth0: 10 Mbit, half duplex, no link
> eth1: 10 Mbit, half duplex, no link
>
> I can get correct status on fixed kernel.
>
> # mii-tool
> eth0: negotiated 100baseTx-FD, link okZZ
> eth1: negotiated 100baseTx-FD, link ok
>
There is a problem with this patch. I'm aware of this problem for
quite some time, but chose to keep the current code.
This IOCTL implementation has been here for many years in all
revisions of the driver, so I think we should keep it as is, because
some software could rely on it, and your change will break it.
And all new code should use ethtool anyway :).
--
Eugene
^ permalink raw reply
* Re: CPM uart
From: Dan Malek @ 2005-04-15 2:50 UTC (permalink / raw)
To: Ricardo Scop; +Cc: PPC_LINUX
In-Reply-To: <200504142024.41126.rscop@matrix.com.br>
On Apr 14, 2005, at 7:24 PM, Ricardo Scop wrote:
> I suggest you to seek all smc_scc_num references inside both the
> console
> routines and the #ifdef SCC_CONSOLE ... #endif code snippets. They
> should be
> subtracted by SCC_NUM_BASE whenever they're used to access SCC-related
> stuff,
This has all been corrected in later versions of the driver. Take a
look at the linuxppc_2.4_devel or some other BK ppc kernels. Start
at penguinppc.org for kernel access information.
Yes, I know, it shouldn't be in this state, but it is. Find the
various kernel
sources and peruse for what fits your requirements.
Thanks.
-- Dan
^ permalink raw reply
* {PATCH] Fix IBM EMAC driver ioctl bug
From: Geoff Levand @ 2005-04-14 18:20 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-kernel, linuxppc-embedded
Fix IBM EMAC driver ioctl bug.
I found IBM EMAC driver bug.
So mii-tool command print wrong status.
# mii-tool
eth0: 10 Mbit, half duplex, no link
eth1: 10 Mbit, half duplex, no link
I can get correct status on fixed kernel.
# mii-tool
eth0: negotiated 100baseTx-FD, link okZZ
eth1: negotiated 100baseTx-FD, link ok
Hiroaki Fuse
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
---
Index: linux-2.6.11/drivers/net/ibm_emac/ibm_emac_core.c
===================================================================
--- linux-2.6.11.orig/drivers/net/ibm_emac/ibm_emac_core.c 2005-04-14 10:54:20.014023550 -0700
+++ linux-2.6.11/drivers/net/ibm_emac/ibm_emac_core.c 2005-04-14 10:55:24.723458722 -0700
@@ -1587,7 +1587,7 @@
static int emac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct ocp_enet_private *fep = dev->priv;
- uint *data = (uint *) & rq->ifr_ifru;
+ uint16_t *data = (uint16_t *) & rq->ifr_ifru;
switch (cmd) {
case SIOCGMIIPHY:
-EOF
^ 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