* Porting Linux on radstone ppc7a board
From: smiling_23 @ 2005-07-14 12:22 UTC (permalink / raw)
To: linuxppc-embedded
HI to all,
I am studying the Manuals related ppc7a,I have to write board
setup code . How to write board setup code, What are the basic things i have
to consider for writing it. If there are any articles related to this topic
please give me the links.
With thnks and regards,
cjag
^ permalink raw reply
* MPC5200 Rev B Deep Sleep Mode
From: Susheel Raj @ 2005-07-14 8:34 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am new to my job and needs help from you. I have
to make this new core into Deep Sleep Mode where all
the periperals and most of the clock oscilaltors are
shut down for power saving and the core can be waked
using one asyncronous external interrupt.
Does anyone have any idea if the previous version of
this core (MPC5200) has this service. Any sort of
suggetions, guidelines or redirections would be of
great help and would be appreciated.
I hope atleast few of them kind enough to reply me back.
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* ptrace on linux 2.6.12 causes oops
From: Anton Wöllert @ 2005-07-14 8:23 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050701101713.GC11121@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]
Hello
when i try to run strace or gdbserver on a program, the following comes:
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
mm/memory.c/1306
and strace or gdbserver of course says segmentation fault. with gdbserver,
this happens every time. with strace, the first time it works nearly all
time, but when i strace a second time program again, it segfaults. i think
the access_process_vm is accessed trough PEEKDATA and PEEKTEXT in
sys_ptrace. so here some more debug :) :
DEBUG: peekdata @ 1006d4ec
DEBUG: peektext @ 1006d4f0
DEBUG: peekdata @ 1006d4f0
DEBUG: peektext @ 1006d4f4
DEBUG: peekdata @ 1006d4f4
DEBUG: peektext @ 1006d4f8
DEBUG: peekdata @ 1006d4f8
DEBUG: peektext @ 1006d4fc
DEBUG: peekdata @ 1006d4fc
DEBUG: peektext @ 1006d500
DEBUG: peekdata @ 1006d500
DEBUG: peektext @ 1006d504
DEBUG: peekdata @ 1006d504
DEBUG: peektext @ 1006d508
DEBUG: peekdata @ 1006d508
DEBUG: peektext @ 1006d50c
DEBUG: peekdata @ 1006d50c
DEBUG: peektext @ 1006d510
DEBUG: peekdata @ 1006d510
DEBUG: peektext @ 1006d514
DEBUG: peekdata @ 1006d514
DEBUG: peektext @ 1006d518
DEBUG: peekdata @ 1006d518
DEBUG: peektext @ 1006d51c
DEBUG: peekdata @ 1006d51c
DEBUG: peektext @ 1006d520
DEBUG: peekdata @ 1006d520
DEBUG: peektext @ 1006d524
DEBUG: peekdata @ 1006d524
DEBUG: peektext @ 1006d528
DEBUG: peekdata @ 1006d528
DEBUG: peektext @ 1006d52c
DEBUG: peekdata @ 1006d52c
DEBUG: peektext @ 00000000
DEBUG: peekdata @ 00000000
DEBUG: peektext @ 3000ac18
DEBUG: peekdata @ 3000ac18
DEBUG: peektext @ 3000ac18
DEBUG: peekdata @ 3000ac18
DEBUG: flush_dcache_icache_page
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not
tainted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK = c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
mm/memory.c:2054: spin_lock(kernel/fork.c:c0ea1618) already locked by
mm/memory.c/1306
[-- Attachment #2: Type: text/html, Size: 4221 bytes --]
^ permalink raw reply
* Help required Porting Linux on radstone PPC7a
From: smiling_23 @ 2005-07-14 7:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
I am trying to port Linux kenel 2.6.12 on Radstone PPC7a board. I am new
to this board. If any one is working on this board help me in porting linux.
Thanks and regards,
cjag
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: Pantelis Antoniou @ 2005-07-14 7:15 UTC (permalink / raw)
To: ming lei; +Cc: linuxppc-embedded
In-Reply-To: <20050714015703.34280.qmail@web61015.mail.yahoo.com>
ming lei wrote:
> Dan,
>
> No one intents to make memory corruption in kernel
> space but it happens sometimes.
>
> Say I have a global var in my kernel module which
> called test-mod, it picks up a physical page allocated
> by some code with kmalloc and later kfreed(suppose
> when it does, the whole page gets freed). But then
> this code forgets a pointer(which maped to this
> physical page) already freed and modifies the pointer,
> the write gets thru since that virt address's PTE
> still valid and points to the physical page currently
> used by test-mod. So the memory corruption happens.
>
> Maybe I miss something in the linux kernel code that
> prevents this double PTE thing.
>
> Ming
>
If you want to guard against stuff like this you have
some options...
1) Run different services on the same cpu on a a hypervisor
like Xen.
2) Run most of the module's code in user space, and keep
kernel space code to a minimum.
3) Use QNX.
Regards
Pantelis
^ permalink raw reply
* 8272ADS and Linux 2.6.12
From: SIP COP 009 @ 2005-07-14 6:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We
wanted to move to 2.6. I downloaded the latest 2.6.12 sources and
compiled the sources for this platform. The kernel is built, have run
the mkimage tool, but the kernel wont boot. It just hangs after
decompressing the image.
Any ideas ? Anything different that needs to be done for 2.6 ? Or any
known issues ?
Thanks!
ashutosh
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Anton Wöllert @ 2005-07-14 5:44 UTC (permalink / raw)
To: Theo Gjaltema, linuxppc-embedded
In-Reply-To: <42D5361B.2070402@chello.nl>
Theo Gjaltema wrote:
> Has anyone an idea why only this large application failed? busybox_1.0
> and more applications work fine.
> system is a: mcp862/32Mb SDRAM started from u-boot 0.4.1,
> kernel enhanced with atm/utopia driver.
>
> This driver causes the CPM sometimes to hang when performing a memset,
> can this be caused by the same problem?
> (CPM stops responding, console buffers are not flused anymore and
> kernel stops waiting for buffers)
>
> Greetings,
> Theo Gjaltema
>
the problem ( so i think ) is, that larger applications will need more
space, which in turn is satisfied by malloc (or mmap with fd = -1).
these allocated pages are not real initialized after malloc ( they will
be initialized completely, if a write on it is done, which will cause
the page fault handler, that does the hardware mmu-stuff, so that a
write can be done). so they will cause a page fault on a first access.
no problem so long, but when the memset.S routine in libc tries to set
all to zero, it uses the dcbz instructions. this instruction then causes
a page fault or better a TLB miss (if i'm right). after the exception is
raised, the address where the write to was done is looked up in the DAR
(data address register), which could be bogus on the dcb* instruction
(on 8xx, where is the errata for that?).
to sum up, the chance, that a memset( .., '\0', ..) with dcbz is done on
a page (that has just registered structures in the kernel, and not
cached in the tlb or even marked as writeable) is bigger :)
that's my opinion. if someone has more knowledge about that, or if i'm
wrong - please! correct me.
anton
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: ming lei @ 2005-07-14 1:57 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <17068cbdcbb1e2de531d33eb07f768e5@embeddededge.com>
Dan,
No one intents to make memory corruption in kernel
space but it happens sometimes.
Say I have a global var in my kernel module which
called test-mod, it picks up a physical page allocated
by some code with kmalloc and later kfreed(suppose
when it does, the whole page gets freed). But then
this code forgets a pointer(which maped to this
physical page) already freed and modifies the pointer,
the write gets thru since that virt address's PTE
still valid and points to the physical page currently
used by test-mod. So the memory corruption happens.
Maybe I miss something in the linux kernel code that
prevents this double PTE thing.
Ming
--- Dan Malek <dan@embeddededge.com> wrote:
>
> On Jul 13, 2005, at 2:48 PM, ming lei wrote:
>
> > Why linux kernel does such thing and no one
> consider
> > it's a problem?
>
> Because we don't write software that accesses the
> memory
> from both of those locations, unless it is very
> intentional
> and necessary. If you are just fishing for ways
> software
> _could_ do bad things, there are tons of them. It's
> our
> job to write it so it doesn't :-)
>
> Thanks.
>
>
> -- Dan
>
>
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ permalink raw reply
* Re: DTC: write_dt_blob() question
From: David Gibson @ 2005-07-14 1:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1121271391.21013.4.camel@cashmere.sps.mot.com>
On Wed, Jul 13, 2005 at 11:16:32AM -0500, Jon Loeliger wrote:
> David,
>
> Over in flattree.c's write_dt_blob() there is this code:
>
> make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
>
> /* Align the reserve map to an 8 byte boundary */
> for (i = vi->hdr_size; i < be32_to_cpu(bph.off_mem_rsvmap); i++)
> fputc(0, f);
>
> fwrite(&bph, vi->hdr_size, 1, f);
> for (i = 0; i < reservenum+1; i++)
> fwrite(&re, sizeof(re), 1, f);
>
> However, I think the boot_param_header should be emitted
> first, before the alignment:
>
> make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
>
> fwrite(&bph, vi->hdr_size, 1, f);
>
> /* Align the reserve map to an 8 byte boundary */
> for (i = vi->hdr_size; i < be32_to_cpu(bph.off_mem_rsvmap); i++)
> fputc(0, f);
>
> for (i = 0; i < reservenum+1; i++)
> fwrite(&re, sizeof(re), 1, f);
>
> Thoughts?
Oops, yes, stupid screwup on my part. I've really got to get this
testsuite thing going...
I've committed a fix for this, but it won't go up on the site until
I'm able to fix my laptop, unfortunately (disk died the other day).
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-14 1:02 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <597c90908e1aae7e7917be736d8901a3@kernel.crashing.org>
On Tue, Jul 12, 2005 at 10:02:16AM +0200, Segher Boessenkool wrote:
> >>> and forcing the user to
> >>>split up these 64-bit quantities into cells is kind of silly.
> >>
> >>Hey, I didn't set that up! :-) There wasn't an existing
> >>clean way to state 64 bit values, and an arbitrary list of
> >>them. So I uh, leveraged the existing cell_t support!
> >
> >Cells make sense for the actual OF-like data, becayse they're an OF
> >concept. For memreserve, which is purely Linux specific, they don't/
>
> No. This is _not_ what is called a cell. "Cell" is a Forth concept.
> A cell can be any size. Open Firmware puts the extra restriction on it
> to be _at least_ 32 bits.
>
> The thing you are referring to is what is called in OF
>
> "32-bit integer property encoding format".
>
> It is defined to always be 32-bit, and not the cell size of the
> firmware,
> so that you can use a 64-bit firmware with a 32-bit OS, and vice versa
> (of course there could be different reasons why this isn't practical,
> but
> that's not the point).
>
> In OF words, this format is normally abbreviated as "int".
My mistake, I misunderstood the terminology. But the basic point is
that lots of things in the kernel already assume a cell is 32-bits, so
it would be silly to try and change that here. This is not true for
the memreserve values.
> Btw -- beware of the fact that such an "int" does _not_ have any
> alignment restrictions -- so you better read it byte by byte...
Erm.. in what context. dtc never reads ints from the blob format as
ints - properties are just byte strings to it. At present you can't
mix cell input format with other sorts, which means the ints must, in
fact, be aligned, since properties are.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Wolfgang Denk @ 2005-07-13 23:11 UTC (permalink / raw)
To: Theo Gjaltema; +Cc: linuxppc-embedded
In-Reply-To: <42D58861.5040900@chello.nl>
In message <42D58861.5040900@chello.nl> you wrote:
>
> >>It appeard that on my mpc862 target I had also this problem. I am using
> >>ELDK3.1.1 which includes a 2.4.25 kernel.
> >
> >No, most definitely not.
> >
> I don't understand this, on
> /pub/Linux/distributions/eldk/3.1.1/ppc-linux-x86/distribution/common
> there are the sources of a 2.4.25 kernel.
Yes, sure. But most definitely you did not have *this* problem.
You have a *different* one.
> >I bet that this is a FAQ. Your SDRAM initialization is broken.
> >
> This was one of my guesses also. Since this is beyond my knowledge, I
> had the parametes initialisation parameters compared to an other
> platform which did not had the problems (rtos based), the same
> parameters were used. I did not investigate it any further.
This *is* a FAQ. Please go and read the documentation.
See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
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
"Obviously, a major malfunction has occurred."
-- Steve Nesbitt, voice of Mission Control, January 28,
1986, as the shuttle Challenger exploded within view
of the grandstands.
^ permalink raw reply
* Re: linux and sram
From: Jörn Engel @ 2005-07-13 22:20 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Russell McGuire, linuxppc-embedded
In-Reply-To: <20050713203409.B6B0C353A37@atlas.denx.de>
On Wed, 13 July 2005 22:34:09 +0200, Wolfgang Denk wrote:
> In message <20050713153231.GA17534@mail19d.g19.rapidsite.net> you wrote:
> >
> > If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE
> > values, and makes sure this is passed into the kernel.
> >
> > Does Linux 2.4.2x+ have any direct support for this? Is it just added into
> > the regular memory pool? Does it get used for specific tasks?
>
> The standard Linux kernel knows nothing about SRAM.
>
> > Or is this set aside for custom drivers?
>
> Indeed. You need a driver to support SRAM.
Some people use slram/phram for that purpose. It creates an mtd
(memory technology device) which can be translated into either a block
or a char device. Quite sufficient for most uses.
Jörn
--
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: Dan Malek @ 2005-07-13 22:36 UTC (permalink / raw)
To: ming lei; +Cc: linuxppc-embedded
In-Reply-To: <20050713214802.68288.qmail@web61016.mail.yahoo.com>
On Jul 13, 2005, at 2:48 PM, ming lei wrote:
> Why linux kernel does such thing and no one consider
> it's a problem?
Because we don't write software that accesses the memory
from both of those locations, unless it is very intentional
and necessary. If you are just fishing for ways software
_could_ do bad things, there are tons of them. It's our
job to write it so it doesn't :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: ming lei @ 2005-07-13 21:48 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <2c008f2a8b3ef3ba33ec3d0f8a5c3390@embeddededge.com>
I am worried about memory corruption if there are two
PTE entries point to the same physical page.
Considering this case: vmalloc a page to a virt
address V1 and somehow other code uses V0(which is in
identy mapping) to modify the same physical page.
I checked i386 and looks like they have the same
problem.
Why linux kernel does such thing and no one consider
it's a problem?
Thanks
Ming
--- Dan Malek <dan@embeddededge.com> wrote:
>
> On Jul 13, 2005, at 1:10 PM, ming lei wrote:
>
> > Question: does the linux ever touch this section
> of
> > page table(virt address from PAGE_OFFSET to
> > PAGE_OFFSET+A) again? like remove or modify one of
> the
> > entry?
>
> Not usually. We used to do it on 8xx for mapping
> uncached pages for coherent DMA.
>
> > Question: For every physical page, it should
> already
> > be mapped in #1, but vmalloc maps it again to a
> virt
> > address higher. Does it mean in kernel page table,
> we
> > may have two PTE entries pointing to the same
> physical
> > page, even their virt addresses are different?
>
> Yep.
>
> > Last question:
> > If this is true, is this platform implemention
> > specific? Does i386 implemention have same
> situation?
>
> Other architectures will do the same, yes. The
> level to which they do this will vary depending upon
> architectural features we have to hide/expose to
> other functions.
>
> One potential problem that arises is you have to be
> careful about the virtual address access path to
> these
> pages. All processors will behave errantly if you
> access the same physical page, but with different
> attributes, through the different VAs. How they
> behave
> will depend upon the attributes. If the PTEs have
> different cache modes or page sizes, it's usually
> a big problem. If they just share different write
> permissions, it's usually OK. These problems
> usually
> arise when device driver writers either don't
> understand
> the mapping issues or try something that may work
> on one architecture but not on another.
>
>
> -- Dan
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Theo Gjaltema @ 2005-07-13 21:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050713203204.7F711353A37@atlas.denx.de>
Wolfgang Denk schreef:
>In message <42D5361B.2070402@chello.nl> you wrote:
>
>
>>It appeard that on my mpc862 target I had also this problem. I am using
>>ELDK3.1.1 which includes a 2.4.25 kernel.
>>
>>
>
>No, most definitely not.
>
>
>
I don't understand this, on
/pub/Linux/distributions/eldk/3.1.1/ppc-linux-x86/distribution/common
there are the sources of a 2.4.25 kernel.
>> Large application (20MB c++, mostly shared-libs) crashes (sigseg) at
>>startup BEFORE main() is called.
>> Attempts to debug the application also fail: the debugger crashes
>>also (sigseg).
>>
>>
>
>I bet that this is a FAQ. Your SDRAM initialization is broken.
>
>
This was one of my guesses also. Since this is beyond my knowledge, I
had the parametes initialisation parameters compared to an other
platform which did not had the problems (rtos based), the same
parameters were used. I did not investigate it any further.
>
>
>>I didn't change the C-lib, I took the 2.4.30/arch/ppc/kernel/head_8xx.S
>>file and copied this over the 2.4.25 head_8xx.S file.
>>In the 2.4.30 version there is a piece of code mentioning the dcbX
>>instruction problems.
>>
>>
>
>And did this fix the problem completely? I would be a bit surprised.
>
>
>
No problem since.
>>This driver causes the CPM sometimes to hang when performing a memset,
>>can this be caused by the same problem?
>>
>>
>
>Yes. When your SDRAM init is broken, strange things will happen.
>
>
>
I'll try the kernel with the original atm/utopia to see what happens.
>Best regards,
>
>Wolfgang Denk
>
>
>
Thanks,
Theo Gjaltema.
^ permalink raw reply
* Re: double kernel page table entry for the same physical page?!
From: Dan Malek @ 2005-07-13 21:27 UTC (permalink / raw)
To: ming lei; +Cc: linuxppc-embedded
In-Reply-To: <20050713201022.69351.qmail@web61023.mail.yahoo.com>
On Jul 13, 2005, at 1:10 PM, ming lei wrote:
> Question: does the linux ever touch this section of
> page table(virt address from PAGE_OFFSET to
> PAGE_OFFSET+A) again? like remove or modify one of the
> entry?
Not usually. We used to do it on 8xx for mapping
uncached pages for coherent DMA.
> Question: For every physical page, it should already
> be mapped in #1, but vmalloc maps it again to a virt
> address higher. Does it mean in kernel page table, we
> may have two PTE entries pointing to the same physical
> page, even their virt addresses are different?
Yep.
> Last question:
> If this is true, is this platform implemention
> specific? Does i386 implemention have same situation?
Other architectures will do the same, yes. The
level to which they do this will vary depending upon
architectural features we have to hide/expose to
other functions.
One potential problem that arises is you have to be
careful about the virtual address access path to these
pages. All processors will behave errantly if you
access the same physical page, but with different
attributes, through the different VAs. How they behave
will depend upon the attributes. If the PTEs have
different cache modes or page sizes, it's usually
a big problem. If they just share different write
permissions, it's usually OK. These problems usually
arise when device driver writers either don't understand
the mapping issues or try something that may work
on one architecture but not on another.
-- Dan
^ permalink raw reply
* Re: linux and sram
From: Wolfgang Denk @ 2005-07-13 20:34 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050713153231.GA17534@mail19d.g19.rapidsite.net>
In message <20050713153231.GA17534@mail19d.g19.rapidsite.net> you wrote:
>
> If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE
> values, and makes sure this is passed into the kernel.
>
> Does Linux 2.4.2x+ have any direct support for this? Is it just added into
> the regular memory pool? Does it get used for specific tasks?
The standard Linux kernel knows nothing about SRAM.
> Or is this set aside for custom drivers?
Indeed. You need a driver to support SRAM.
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
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Wolfgang Denk @ 2005-07-13 20:32 UTC (permalink / raw)
To: Theo Gjaltema; +Cc: linux-ppc-embedded
In-Reply-To: <42D5361B.2070402@chello.nl>
In message <42D5361B.2070402@chello.nl> you wrote:
>
> It appeard that on my mpc862 target I had also this problem. I am using
> ELDK3.1.1 which includes a 2.4.25 kernel.
No, most definitely not.
> Large application (20MB c++, mostly shared-libs) crashes (sigseg) at
> startup BEFORE main() is called.
> Attempts to debug the application also fail: the debugger crashes
> also (sigseg).
I bet that this is a FAQ. Your SDRAM initialization is broken.
> I didn't change the C-lib, I took the 2.4.30/arch/ppc/kernel/head_8xx.S
> file and copied this over the 2.4.25 head_8xx.S file.
> In the 2.4.30 version there is a piece of code mentioning the dcbX
> instruction problems.
And did this fix the problem completely? I would be a bit surprised.
> This driver causes the CPM sometimes to hang when performing a memset,
> can this be caused by the same problem?
Yes. When your SDRAM init is broken, strange things will happen.
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
Work 8 hours, sleep 8 hours; but not the same 8 hours.
^ permalink raw reply
* Re: UART problem on MPC8272ADS
From: Eugene Surovegin @ 2005-07-13 20:19 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42D557E3.9060503@ru.mvista.com>
On Wed, Jul 13, 2005 at 10:05:23PM +0400, Vitaly Bordug wrote:
> Hi!
> Do anyone have 2-nd UART port working on MPC8272ADS?
>
> The target boots OK via both UARTs as console, but any attempt to
> transmit/receive data via the other port have failed.
> A quick lookup results that ...init_scc is called only in `console`
> case. After addition of this call to the cpm_uart_startup (just for
> instance) transmit from the target occur, but with only half of data. I
> tried various pin settings including working combinations from the old
> uart driver but with the same result.
>
> I guess that 8xx that are also handled by this driver may behave
> likewise, so any information whether cpm_uart driver works well (or
> not) on 8xx is also valuable.
>
> Any ideas how to solve this or concerning possible reasons of such
> behavior are greatly appreciated.
I had some problems with multiple UARTs (SMC and SCC) on 8248-based
custom board. It was due to completely brain-damaged BRG allocation in
cpm2_io/uart.c. I had to hack it to make SCC UART working along with
SMC one.
--
Eugene
^ permalink raw reply
* double kernel page table entry for the same physical page?!
From: ming lei @ 2005-07-13 20:10 UTC (permalink / raw)
To: linuxppc-embedded
1. In PPC MMU_init sets up kernel page table for all
the physical pages available(say size is A) to the
virt address starting from PAGE_OFFSET to
(PAGE_OFFSET+A).
Question: does the linux ever touch this section of
page table(virt address from PAGE_OFFSET to
PAGE_OFFSET+A) again? like remove or modify one of the
entry?
2. In VMALLOC, say we have virt address
B(B>PAGE_OFFSET+A), sets up the page table entry for
this B to any one of the physical pages.
Question: For every physical page, it should already
be mapped in #1, but vmalloc maps it again to a virt
address higher. Does it mean in kernel page table, we
may have two PTE entries pointing to the same physical
page, even their virt addresses are different?
Last question:
If this is true, is this platform implemention
specific? Does i386 implemention have same situation?
Thanks,
Ming
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* linux and sram
From: Russell McGuire @ 2005-07-13 19:32 UTC (permalink / raw)
To: linuxppc-embedded
Everyone,
If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE
values, and makes sure this is passed into the kernel.
Does Linux 2.4.2x+ have any direct support for this? Is it just added into
the regular memory pool? Does it get used for specific tasks?
Or is this set aside for custom drivers?
Thanks,
Russell McGuire
^ permalink raw reply
* UART problem on MPC8272ADS
From: Vitaly Bordug @ 2005-07-13 18:05 UTC (permalink / raw)
To: linuxppc-embedded list
Hi!
Do anyone have 2-nd UART port working on MPC8272ADS?
The target boots OK via both UARTs as console, but any attempt to
transmit/receive data via the other port have failed.
A quick lookup results that ...init_scc is called only in `console`
case. After addition of this call to the cpm_uart_startup (just for
instance) transmit from the target occur, but with only half of data. I
tried various pin settings including working combinations from the old
uart driver but with the same result.
I guess that 8xx that are also handled by this driver may behave
likewise, so any information whether cpm_uart driver works well (or
not) on 8xx is also valuable.
Any ideas how to solve this or concerning possible reasons of such
behavior are greatly appreciated.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] update ppc defconfigs
From: Tom Rini @ 2005-07-13 18:02 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20050713170351.GA19133@suse.de>
On Wed, Jul 13, 2005 at 07:03:51PM +0200, Olaf Hering wrote:
> On Wed, Jul 13, Tom Rini wrote:
>
> > > -CONFIG_LOCALVERSION=""
> > > +CONFIG_LOCALVERSION="common_defconfig"
> >
> > Please don't do that. $WHOMEVERs mass-compile-scripts should be setting
> > this to $WHATEVER.
>
> Will send updated patch.
>
> > > -CONFIG_MODULE_FORCE_UNLOAD=y
> > > +# CONFIG_MODULE_FORCE_UNLOAD is not set
> >
> > Why? It looks like you're doing more than running oldconfig here..
>
> That doesnt belong to a default kernel, anyone who wants that can just
> enable it.
I disagree, force unload should be the default because it's a handy
'oops, I need to not reboot' thing.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] update ppc defconfigs
From: Olaf Hering @ 2005-07-13 17:03 UTC (permalink / raw)
To: Tom Rini; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20050713160405.GK7741@smtp.west.cox.net>
On Wed, Jul 13, Tom Rini wrote:
> > -CONFIG_LOCALVERSION=""
> > +CONFIG_LOCALVERSION="common_defconfig"
>
> Please don't do that. $WHOMEVERs mass-compile-scripts should be setting
> this to $WHATEVER.
Will send updated patch.
> > -CONFIG_MODULE_FORCE_UNLOAD=y
> > +# CONFIG_MODULE_FORCE_UNLOAD is not set
>
> Why? It looks like you're doing more than running oldconfig here..
That doesnt belong to a default kernel, anyone who wants that can just
enable it.
^ permalink raw reply
* DTC: write_dt_blob() question
From: Jon Loeliger @ 2005-07-13 16:16 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
David,
Over in flattree.c's write_dt_blob() there is this code:
make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
/* Align the reserve map to an 8 byte boundary */
for (i = vi->hdr_size; i < be32_to_cpu(bph.off_mem_rsvmap); i++)
fputc(0, f);
fwrite(&bph, vi->hdr_size, 1, f);
for (i = 0; i < reservenum+1; i++)
fwrite(&re, sizeof(re), 1, f);
However, I think the boot_param_header should be emitted
first, before the alignment:
make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
fwrite(&bph, vi->hdr_size, 1, f);
/* Align the reserve map to an 8 byte boundary */
for (i = vi->hdr_size; i < be32_to_cpu(bph.off_mem_rsvmap); i++)
fputc(0, f);
for (i = 0; i < reservenum+1; i++)
fwrite(&re, sizeof(re), 1, f);
Thoughts?
Thanks,
jdl
^ 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