* PPC 44x Watchdog timer
From: Glenn Burkhardt @ 2005-04-19 1:37 UTC (permalink / raw)
To: linuxppc-embedded
Is there a patch for the built in watchdog timer in the 440GP available
anywhere for the 2.4 kernel (viz., ELDK kernels)?
I found a driver for the 2.6 kernel in the mailing list submitted
by Takeharu KATO last February, and, if nothing else is available, plan
to back fit it to the 2.4 kernel.
Thanks!
^ permalink raw reply
* Re: using initramfs with ppc
From: Manoj Padhi @ 2005-04-19 0:36 UTC (permalink / raw)
To: Pawel Studencki, linuxppc-embedded
In-Reply-To: <20050418220133.GD25352@gate.ebshome.net>
Pawel,
I am new to embedded linux development and planning to develop a small
project using embedded linux.
I looked for an evaluation kit in the market and it comes around $1100
+ development tool licence (starts at $6K). Hence I need some advice
regarding getting an custom board and use free tools. Can you suggest
such a board.
Thanks in advance for your help.
-Manoj
On 4/18/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Apr 18, 2005 at 02:24:01PM -0700, Pawel Studencki wrote:
> > It can be wrong kernel parameter or problem with mtd
> > or cramfs support. But if I see my kernel messages,
> > everything seems to be OK for me. I've attached kernel
> > logging, so let me know, if I'm wrong.
>=20
> Could you send me privately your .config ?
>=20
> --
> Eugene
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
Thanks
Manoj
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-19 0:27 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050418161112b879b5@mail.gmail.com>
On Mon, Apr 18, 2005 at 04:11:02PM -0700, Shawn Jin wrote:
[snip]
> However there could be a possible problem when a 2nd critical
> interrupt is asserted before the 1st one is served. Then fetching the
> VR returns the address for the 2nd interrupt. Of course if UIC can
> queue interrupts when calculating VRs, there wouldn't be such a
> problem.
According to the user manual, UIC indeed queues IRQs based on their
priorities, so I guess there shouldn't be any problems.
Look at paragraphs titled "Vector generation scenarios".
--
Eugene
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Shawn Jin @ 2005-04-18 23:11 UTC (permalink / raw)
To: Shawn Jin, ppcembed
In-Reply-To: <20050418220605.GE25352@gate.ebshome.net>
On 4/18/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Apr 18, 2005 at 02:14:23PM -0700, Shawn Jin wrote:
> >
> > > 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 :)
> >
> > If we use VR to determine which IRQ was asserted, it's kind of
> > reverse. We usually fetch a handler by its IRQ number. It could
> > require to change irq_desc[] and request_irq().
>=20
> You seems don't undestand what I'm talking about. VR can help us with
> determining what IRQ was asserted. It has nothing to do with irq_desc.
I guess I understand your statement of using VR to quickly determin
IRQ number. (VR - VCR) >> 9 is the irq number if UIC0_SR0 has the
highest priority, which is quicker than bit searching.
However there could be a possible problem when a 2nd critical
interrupt is asserted before the 1st one is served. Then fetching the
VR returns the address for the 2nd interrupt. Of course if UIC can
queue interrupts when calculating VRs, there wouldn't be such a
problem.
Regards,
-Shawn.
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-18 22:27 UTC (permalink / raw)
To: Lawrence E. Bakst; +Cc: ppcembed
In-Reply-To: <p06210215be89c5d708df@mail.iridescent.org>
On Mon, Apr 18, 2005 at 01:54:44PM -0700, Lawrence E. Bakst wrote:
> I'd point out that your own statements were pretty general to start
> off with.
Sure, because I wasn't the one who needed critical IRQs :). It really
works this way: people who need some new facility either implement it
themselves and submit patch or present their case which can, in
theory, motivate someone else to implement this.
So far _none_ of the people whining about absence of critical IRQs did
either.
Things like "It'd be nice to have this" aren't good enough :)
> I would have liked to elaborate but unfortunately the work
> is an ongoing research effort for a client under NDA so I can't say
> very much.
Nice.
>
> >Also, it'd be nice if you explained how you dealt with infrastructure
> >problems I mentioned in my previous e-mail.
>
> We didn't deal with them as we have a kind of special case. I am not
> trying to minimize the importance of that issue in the general case.
>
> >
> >Answering your question about "real time interrupt latency
> >constraints", I have to ask what _exact_ latencies you need, and why
> >do you think Linux can provide hard real-time guarantees?
>
> We are trying to get to an interrupt response time of substantially
> less than what you mention below. In this case "substantially" means
> between 2 and 3 decimal orders of magnitude.
Are you really sure that Linux on 440GX is a good platform for
microsecond or less IRQ latency? At this speeds, you have to worry
about TLB misses, cache issues, etc.
> The only point I was trying to make is that the critical interrupt
> facility was useful to us. That was it. It's not clear to me that
> within the constraints of how Linux works, the various
> infrastructure issues, as well as politics, that it could be made
> useful to others in a generalized form.
IMO, it'd be nice to have something like super-high-priority IRQs for
some specific tasks in the kernel. However, this needs some generic
support first, to be useful. Also, not all CPUs have something like
Critical interrupts, so maybe simple IRQ virtualization will be more
generic approach.
So far, I see one use for critical interrupts, which doesn't require
such generic support - make all IRQS critical, so we can use some
basic prioritization and vector generation.
--
Eugene
^ permalink raw reply
* IT Consultants
From: Consultants @ 2005-04-19 17:16 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
How can I help with your current need for IT Consultants? CGT Consulting
provides highly specialized contract consultants or permanent employees for
immediate results. We provide consultants and employees in the areas of
ERP, CRM, Wireless and Web-based technology, Engineering, and more. In
addition, CGT draws from an immense in-house database of over 1.5 Million
outside candidates for the most specialized requirements.
How can I be of service?
Thank you.
Randy Maiter
CGT Consulting Inc.
18032-C Lemon Drive, Suite 350
Yorba Linda, CA 92886
Tel: (714) 572-0454
To opt-out of future correspondence please reply with "Remove" in the body.
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-18 22:06 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05041814144133a608@mail.gmail.com>
On Mon, Apr 18, 2005 at 02:14:23PM -0700, Shawn Jin wrote:
>
> > 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 :)
>
> If we use VR to determine which IRQ was asserted, it's kind of
> reverse. We usually fetch a handler by its IRQ number. It could
> require to change irq_desc[] and request_irq().
You seems don't undestand what I'm talking about. VR can help us with
determining what IRQ was asserted. It has nothing to do with irq_desc.
Curently, we use some bit searching functions like ffs to get IRQ
number, VR can be used instead.
--
Eugene
^ permalink raw reply
* Re: using initramfs with ppc
From: Eugene Surovegin @ 2005-04-18 22:01 UTC (permalink / raw)
To: Pawel Studencki; +Cc: linuxppc-embedded
In-Reply-To: <20050418212401.33270.qmail@web51310.mail.yahoo.com>
On Mon, Apr 18, 2005 at 02:24:01PM -0700, Pawel Studencki wrote:
> It can be wrong kernel parameter or problem with mtd
> or cramfs support. But if I see my kernel messages,
> everything seems to be OK for me. I've attached kernel
> logging, so let me know, if I'm wrong.
Could you send me privately your .config ?
--
Eugene
^ permalink raw reply
* Re: using initramfs with ppc
From: Pawel Studencki @ 2005-04-18 21:24 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
hello,
It can be wrong kernel parameter or problem with mtd
or cramfs support. But if I see my kernel messages,
everything seems to be OK for me. I've attached kernel
logging, so let me know, if I'm wrong.
Do I need initramfs if I want to mount root filesystem
on CRAMFS? If so, with special devices?
I found some problems here:
static int __init do_mount_root(char *name, char *fs,
int flags, void *data)
{
int err = sys_mount(name, "/root", fs, flags, data);
if (err)
return err;
[...]
}
return -2.
Directory "/root" hasn't been found! Does this funtion
look for on initramfs???
best regards
Pawel
------------------------------------
Kernel command line: console=ttyCPM0, 57600
root=/dev/mtdblock1
rootfstype=cramfs ro
PID hash table entries: 128 (order: 7, 2048 bytes)
Decrementer Frequency = 187500000/60
m8xx_wdt: wdt disabled (SYPCR: 0xFFFFFF88)
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384
ytes)
Inode-cache hash table entries: 2048 (order: 1, 8192
ytes)
Memory: 14772k available (976k kernel code, 368k data,
60k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xff000a60 (irq = 43) is a CPM UART
io scheduler noop registered
loop: loaded (max 8 devices)
physmap flash device: 400000 at ffc00000
phys_mapped_flash: Found 1 x16 devices at 0x0 in
16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due
to code
brokenness.
Creating 5 MTD partitions on "phys_mapped_flash":
0x00000000-0x000d0000 : "Kernel"
mtd: Giving out device 0 to Kernel
0x000d0000-0x001d0000 : "RootFS"
mtd: Giving out device 1 to RootFS
0x001d0000-0x00300000 : "ApplFS1"
mtd: Giving out device 2 to ApplFS1
0x00300000-0x00330000 : "U-Boot"
mtd: Giving out device 3 to U-Boot
0x00330000-0x00400000 : "ApplFS2"
mtd: Giving out device 4 to ApplFS2
VFS: Cannot open root device "mtdblock1" or
unknown-block(31,1)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root
fs on
unknown-block(31,1)
--- Eugene Surovegin <ebs@ebshome.net> wrote:
> On Mon, Apr 18, 2005 at 08:34:42AM -0700, Pawel
> Studencki wrote:
> > Hello,
> >
> > I use a custom board with 8xx and kernel 2.6.11
> and
> > try to mount root fs
> > based on cramfs. I still have problems with
> mounting
> > VFS:
> >
> > VFS: Cannot open root device "mtdblock1" or
> > unknown-block(31,1)
> > Please append a correct "root=" boot option
> > Kernel panic - not syncing: VFS: Unable to mount
> root
> > fs on
> > unknown-block(31,1)
> >
> > I found, that perhaps the reason is initramfs.
>
> Unlikely.
>
> Please, check that you have mtdblock device enabled
> in config, also
> that you have configured your flash support, and
> mtdblock1 partition
> actually exists.
>
> --
> Eugene
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* writev test failure related to arch/ppc/lib/string.S changes?
From: Phil Estes @ 2005-04-18 19:42 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Recently I applied some 2.6.7 ppc32 patches to a 2.6.5 kernel, which
included the 1.1612.2.78 changeset titled "[PATCH] PPC32: Fix copy
prefetch on non coherent PPCs". The functionality I meant to get from
that backport is working fine, but a test team which is testing my
changes note that a standard LTP testcase in the writev family now
fails, which they tracked to the changes made in arch/ppc/lib/string.S
from the above changeset.
Their comments follow:
> I checked the string.S of 2.6.7. I think there is a bug in it.
> At 114, we set ctr=r0-r7. If exception occurs, it then goes to 104,
> then 92 where r3 is set to LG_CACHELINE_BYTES. Then it goes to 99.
>
> But in the remarks before 99, the number of bytes not copied is
> r5 + (ctr << r3). This is not as what has happen because
> ctr = r0 - r7. The ctr should be adjusted before it goes to 99.
The failing test being noted is the LTP writev02 test, which is
an "expected to FAIL" testcase, but passes in this case. A bad
address is passed to writev, but instead of EFAULT, a positive
integer is returned. Again, backing out the above changeset
causes this test (among a few other writev variants which expect
failure) to pass accordingly.
Thanks for your help,
Phil Estes
pestes@us.ibm.com
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Shawn Jin @ 2005-04-18 21:14 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050416005026.GB1086@gate.ebshome.net>
On 4/15/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> 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.
OK, I'll look into RTAI or RTLinux for priority issue.
> 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 :)
If we use VR to determine which IRQ was asserted, it's kind of
reverse. We usually fetch a handler by its IRQ number. It could
require to change irq_desc[] and request_irq().
VR can be calculated automatically provided that VCR is set. What
should be the vector base address? One possible way is similar to the
way how IVPR is set to interrupt_base in head_44x.S but leave the
actual interrupt handler blank, which will be filled in later with a
jump instruction which jumps to the actual ISR once a device driver
request its irq. This means that request_irq() needs to modify kernel
code. Kinda of dangerous, isn't it? This might be part of
infrastructure change you mentioned?
Regards,
-Shawn.
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Lawrence E. Bakst @ 2005-04-18 20:54 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: ppcembed
In-Reply-To: <20050418172532.GB25352@gate.ebshome.net>
At 10:25 AM -0700 4/18/05, Eugene Surovegin wrote:
>On Mon, Apr 18, 2005 at 10:01:02AM -0700, Lawrence E. Bakst wrote:
>> I just want to say that in certain applications critical interrupts
>> can be put to good use. There are issues you have to deal with when
>> you use them. I wonder if any of the people saying that they "really
>> don't think it's worth it" have ever had to meet any real time
>> interrupt latency constraints?
>
>You know, it'd help if instead of some general statements, you gave
>real example and explained, why default stuff doesn't work for you.
I'd point out that your own statements were pretty general to start off with. I would have liked to elaborate but unfortunately the work is an ongoing research effort for a client under NDA so I can't say very much.
>Also, it'd be nice if you explained how you dealt with infrastructure
>problems I mentioned in my previous e-mail.
We didn't deal with them as we have a kind of special case. I am not trying to minimize the importance of that issue in the general case.
>
>Answering your question about "real time interrupt latency
>constraints", I have to ask what _exact_ latencies you need, and why
>do you think Linux can provide hard real-time guarantees?
We are trying to get to an interrupt response time of substantially less than what you mention below. In this case "substantially" means between 2 and 3 decimal orders of magnitude.
>
>And yes, I work for company which makes VoIP hardware, and soft
>real-time qualities of 2.4 Linux kernel (preempt, low-lat) are good
>enough for us (~1-5 ms average scheduling latency), without any need
>of critical interrupts.
We're operating in different environments and doing different things. With the kind of response time we're trying to achieve we can't afford to schedule anything.
The only point I was trying to make is that the critical interrupt facility was useful to us. That was it. It's not clear to me that within the constraints of how Linux works, the various infrastructure issues, as well as politics, that it could be made useful to others in a generalized form.
Best,
leb
>
>--
>Eugene
^ permalink raw reply
* Re: 824x Sandpoint with 2.6.x
From: Mark A. Greer @ 2005-04-18 19:55 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <42641069.80008@mvista.com>
Mark A. Greer wrote:
>>>RAMDISK support kernel. The console setting was
>>>"ttyS0,115200". But hanged after loading the
>>>kernel... What could the problem be?
>>>
>>>
Also, are you sure 115200 is the correct baud rate?
^ permalink raw reply
* Re: 824x Sandpoint with 2.6.x
From: Mark A. Greer @ 2005-04-18 19:54 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20050415022430.52080.qmail@web15806.mail.cnb.yahoo.com>
Sam,
Sorry for the delay, I was on vacation last week.
--
Sam Song wrote:
><snip>
>
>--- Sam Song <samlinuxppc@yahoo.com.cn> wrote:
>
><snip>
>
>>I created one image only with 8250 serial and
>>RAMDISK support kernel. The console setting was
>>"ttyS0,115200". But hanged after loading the
>>kernel... What could the problem be?
>>
>>
>
>Still no luck. From the print message I set, it passed
>MMU_init() and mpc10x_bridge_init(), then stopped.
>
>Any clue on it?
>
It could be lots of things. Can you dump __log_buf? If so, please dump
and send it so we can have a look. If not, try adding more progress
stmts and telling us exactly where its stopping.
Mark
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Eugene Surovegin @ 2005-04-18 17:25 UTC (permalink / raw)
To: Lawrence E. Bakst; +Cc: ppcembed
In-Reply-To: <p06210211be8997487f7c@mail.iridescent.org>
On Mon, Apr 18, 2005 at 10:01:02AM -0700, Lawrence E. Bakst wrote:
> I just want to say that in certain applications critical interrupts
> can be put to good use. There are issues you have to deal with when
> you use them. I wonder if any of the people saying that they "really
> don't think it's worth it" have ever had to meet any real time
> interrupt latency constraints?
You know, it'd help if instead of some general statements, you gave
real example and explained, why default stuff doesn't work for you.
Also, it'd be nice if you explained how you dealt with infrastructure
problems I mentioned in my previous e-mail.
Answering your question about "real time interrupt latency
constraints", I have to ask what _exact_ latencies you need, and why
do you think Linux can provide hard real-time guarantees?
And yes, I work for company which makes VoIP hardware, and soft
real-time qualities of 2.4 Linux kernel (preempt, low-lat) are good
enough for us (~1-5 ms average scheduling latency), without any need
of critical interrupts.
--
Eugene
^ permalink raw reply
* Re: Interrupt prioritization on linux for ppc440
From: Lawrence E. Bakst @ 2005-04-18 17:01 UTC (permalink / raw)
To: Shawn Jin, ppcembed
In-Reply-To: <c3d0340b0504151609397d73f7@mail.gmail.com>
I just want to say that in certain applications critical interrupts can be put to good use. There are issues you have to deal with when you use them. I wonder if any of the people saying that they "really don't think it's worth it" have ever had to meet any real time interrupt latency constraints?
Best,
leb
At 4:09 PM -0700 4/15/05, 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? 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?
>>
>> 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?
>>
>> 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.
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: Unable to capture device interrupts on ppc440gx?
From: Sanjay Bajaj @ 2005-04-18 17:02 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Eugene,
That did help. I was using the Interrupt Line D, whereas hardware is =
generating interrupt on Interrupt Line A. Correcting the IRQ number to =
the one specified in the arch/platforms file captured the interrupt in =
the device driver.
Thanks for the help.
Have a nice day.
Sanjay
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Monday, April 18, 2005 12:14 PM
To: Sanjay Bajaj
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Unable to capture device interrupts on ppc440gx?
On Mon, Apr 18, 2005 at 12:02:52PM -0400, Sanjay Bajaj wrote:
> In the device driver open function, I call request_irq() to register=20
> my interrupt handler function to a specified IRQ number. It=20
> succeeds.=20
> But when I enable the interrupt (and we can detect the hardware line=20
> is active) on the hardware, the interrupt handler in NOT invoked. Is=20
> there something I am missing? Any help or pointers are appreciated.
Did you configure polarity and triggering settings for this IRQ=20
source? If not, look for example at ebony.c (ppc4xx_uic_ext_irq_cfg)=20
keeping in mind, that Ebony has 440GP CPU. 440GX has 5 additional=20
IRQ lines.
--=20
Eugene
^ permalink raw reply
* Re: Problems with MontaVista Linux on a Memec Virtex-II pro ff672 board
From: Tony Lee @ 2005-04-18 16:52 UTC (permalink / raw)
To: Peter Ryser; +Cc: Linuxppc-embedded
In-Reply-To: <4239C6AE.3050803@xilinx.com>
Peter,=20
Maybe xilinx can come up with app note on how to debug the kernel=20
bring up / hanging issue with chipscope on PLB bus.
That would be the most powerful way to demo how to use the=20
Xilinx VP HW platform to debug some tricky kernel issues.
You have a extreme flexible platform for this. We just need a
xilinx's guiding hand from time to time.
I can use the same help too for following issues with linux on VP 20. :-) =
=20
* I have trouble finding where 700+ msec cpu time went in my
currect system - kernel, ISR, other user tasks.
* Sometime on power on, the linux would lockup before everything is read=
y.
-Tony
On 3/17/05, Peter Ryser <Peter.Ryser@xilinx.com> wrote:
> Also try to boot the first Linux kernel (the one without the Flash
> support) on the EDK design with Flash support. It will help narrow down
> the problem to the HW or the SW.
>=20
> - Peter
>=20
> S. van Beek wrote:
>=20
> >>How did you add the Flash (EMC) peripheral? Did you use the Base System
> >>Builder to generate your hardware?
> >>
> >>
> >
> >Yes, we started a new project using the base system builder with the sam=
e
> >options as the previous (working) project and flash, so the address rang=
e
> >should be ok. I'll check tomorrow, right now its time to go home ;)
> >
> >Regards,
> >Sander
> >
> >----- Original Message -----
> >From: "Peter Ryser" <Peter.Ryser@xilinx.com>
> >To: "S. van Beek" <nlv11891@prle>
> >Cc: <Linuxppc-embedded@ozlabs.org>
> >Sent: Thursday 17 March 2005 16:37
> >Subject: Re: Problems with MontaVista Linux on a Memec Virtex-II pro ff6=
72
> >board
> >
> >
> >
> >
> >>How did you add the Flash (EMC) peripheral? Did you use the Base System
> >>Builder to generate your hardware?
> >>
> >>If you configure the hardware manually and use the OPB EMC make sure
> >>that you add the address range to the PLB2OPB bridge.
> >>
> >>- Peter
> >>
> >>
> >>S. van Beek wrote:
> >>
> >>
> >>
> >>>Hello there,
> >>>
> >>>This is our first post on this list, hi all!
> >>>We're two Dutch students working with a Virtex-II pro ff672 board from
> >>>Memec with the Communications 2 module. We've compiled a simple kernel
> >>>wich comes with MontaVista Linux 3.1 (2.4.20) with ethernet and a
> >>>serial port. It mounts its root filesystem over NFS and everything
> >>>seems to work nicely. The next step we wanted to make was
> >>>adding support for the Flash on the com board. We added the IP to the
> >>>hardware and loaded the new bitstream in the FPGA. Next thing, we
> >>>enabled support for MTD devices in the kernel. After that, the kernel
> >>>did not seem to boot anymore. It stopped at the message 'Now booting
> >>>the kernel'. So we read some documentation about debugging. We
> >>>recompiled this kernel with the -g -ggdb options and removed the -O
> >>>(optimalization) flag. Then we did not even see the ppc boot loader
> >>>messages anymore when trying to boot. So we tried to compile the first
> >>>kernel (with only serial and ethernet support) -wich worked fine
> >>>before- with debugging and it gave us the same result.. no output at
> >>>
> >>>
> >all.
> >
> >
> >>>Can anyone give us some hints on what we can try more to find out what
> >>>is going wrong?
> >>>
> >>>Regards,
> >>>Sander van Beek
> >>>Daniel van Os
> >>>
> >>>----------------------------------------------------------------------=
--
> >>>
> >>>_______________________________________________
> >>>Linuxppc-embedded mailing list
> >>>Linuxppc-embedded@ozlabs.org
> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
-Tony
Having fun with FPGA HW + ppc + Linux
^ permalink raw reply
* Re: Unable to capture device interrupts on ppc440gx?
From: Eugene Surovegin @ 2005-04-18 16:14 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-embedded
In-Reply-To: <0007F077BB3476449151699150E8FEA20592C8@exchange.tsi-telsys.com>
On Mon, Apr 18, 2005 at 12:02:52PM -0400, Sanjay Bajaj wrote:
> In the device driver open function, I call request_irq() to register
> my interrupt handler function to a specified IRQ number. It
> succeeds.
> But when I enable the interrupt (and we can detect the hardware line
> is active) on the hardware, the interrupt handler in NOT invoked. Is
> there something I am missing? Any help or pointers are appreciated.
Did you configure polarity and triggering settings for this IRQ
source? If not, look for example at ebony.c (ppc4xx_uic_ext_irq_cfg)
keeping in mind, that Ebony has 440GP CPU. 440GX has 5 additional
IRQ lines.
--
Eugene
^ permalink raw reply
* Re: using initramfs with ppc
From: Eugene Surovegin @ 2005-04-18 16:03 UTC (permalink / raw)
To: Pawel Studencki; +Cc: linuxppc-embedded
In-Reply-To: <20050418153442.83479.qmail@web51309.mail.yahoo.com>
On Mon, Apr 18, 2005 at 08:34:42AM -0700, Pawel Studencki wrote:
> Hello,
>
> I use a custom board with 8xx and kernel 2.6.11 and
> try to mount root fs
> based on cramfs. I still have problems with mounting
> VFS:
>
> VFS: Cannot open root device "mtdblock1" or
> unknown-block(31,1)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root
> fs on
> unknown-block(31,1)
>
> I found, that perhaps the reason is initramfs.
Unlikely.
Please, check that you have mtdblock device enabled in config, also
that you have configured your flash support, and mtdblock1 partition
actually exists.
--
Eugene
^ permalink raw reply
* Unable to capture device interrupts on ppc440gx?
From: Sanjay Bajaj @ 2005-04-18 16:02 UTC (permalink / raw)
To: linuxppc-embedded
In the device driver open function, I call request_irq() to register my =
interrupt handler function to a specified IRQ number. It succeeds. But =
when I enable the interrupt (and we can detect the hardware line is =
active) on the hardware, the interrupt handler in NOT invoked. Is there =
something I am missing? Any help or pointers are appreciated.
Sanjay
^ permalink raw reply
* using initramfs with ppc
From: Pawel Studencki @ 2005-04-18 15:34 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I use a custom board with 8xx and kernel 2.6.11 and
try to mount root fs
based on cramfs. I still have problems with mounting
VFS:
VFS: Cannot open root device "mtdblock1" or
unknown-block(31,1)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root
fs on
unknown-block(31,1)
I found, that perhaps the reason is initramfs. How do
you use initramfs on
ppc?
Is it possible to turn off initramfs? If I've
understood correct
"Documentation/early-userspace/README", there is
possibility to boot direct
from flash.
My filesystem for initramfs is very simple in default
"initramfs_list" file:
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
dir /root 0700 0 0
do I have to append special files or directories?
thanks for any hints.
regards
Pawel
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
^ permalink raw reply
* Re: 2.6.11 kernel, PPC, and IPv6
From: Eugene Surovegin @ 2005-04-18 15:24 UTC (permalink / raw)
To: Bellino, Phil; +Cc: LinuxPPC
In-Reply-To: <19EE6EC66973A5408FBE4CB7772F6F0A02899377@ltnmail.xyplex.com>
On Mon, Apr 18, 2005 at 09:20:39AM -0400, Bellino, Phil wrote:
> 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?
I'm using IPv6 on my powerbook and 440GX ref platform (Ocotea). They
both seems to get link-local and global addresses (from local router
running radvd) just fine.
But don't mail me directly :), if you have questions - just ask the
list, although I don't think this a proper place. Try netdev list
(netdev@oss.sgi.com)
--
Eugene
^ permalink raw reply
* 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
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