* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Kumar Gala @ 2005-08-12 16:18 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FCC234.8070008@ru.mvista.com>
Can you do a sizeof instead?
#define num_ele sizeof(ppc_sys_specs[])/sizeof(struct ppc_sys_spec)
Something like matchted[num_ele] ??
- kumar
On Aug 12, 2005, at 10:37 AM, Vitaly Bordug wrote:
> Marcelo Tosatti wrote:
>
>> On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
>>
>>
>>> Marcelo Tosatti wrote:
>>>
>>>
>>>> On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>>>>
>>>>
>>>>
>>>>> +static int __init find_chip_by_name_and_id(char *name, u32 id)
>>>>> +{
>>>>> + int ret = -1;
>>>>> + unsigned int i = 0;
>>>>> + unsigned int j = 0;
>>>>> + unsigned int dups = 0;
>>>>> +
>>>>> + unsigned int matched[count_sys_specs()];
>>>>>
>>>>> Is is legit in the kernel to use dynamically sized array?
>>>>>
>>>>
>>>>
>>>> kmalloc() is certainly safer - why not use it?
>>>>
>>>
>>> Practically , version with kmalloc works, but setup_arch and
>>> thus this
>>> function is called before mem_init, so I just wonder if kmalloc can
>>> handle this case. On the other hand, I don't like to deal with
>>> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
>>> does) just for the temporary buffer.
>>>
>>> But it's the only _right_ way (or I 've missed something) - sure
>>> I'll
>>> follow it.
>>>
>>
>>
>> I dont see any problem with dynamic array usage on the kernel
>> (maybe someone
>> else has good argumentation against it).
>>
>> Just that you have a 4kb stack. Does count_sys_specs() have an
>> appropriate
>> maximum?
>>
>>
>>
> Yes it does, but there is no define for it. The ppc_sys_specs array
> should always end at the "default match" - element with name field set
> to "" and value=0 (without it every existing ppc_sys identify will
> fall
> into infinite loop). This array is defined in syslib/<board>_sys.c end
> is finite of course. Its size depends on amount of supported boards.
>
> So, if the dynamic array is ok with conditions, it will be great.
> But now I'm inclined to implement the same using kmalloc/alloc_bootmem
> to prevent flame when it will proceed. BTW, will free_bootmem properly
> release the memory allocated by alloc_bootmem()? I haven't encountered
> examples of this so far...
>
>
> --
> Sincerely,
> Vitaly
>
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-12 15:37 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
In-Reply-To: <20050811224523.GA5395@dmt.cnet>
Marcelo Tosatti wrote:
> On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
>
>>Marcelo Tosatti wrote:
>>
>>>On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>>>
>>>
>>>>+static int __init find_chip_by_name_and_id(char *name, u32 id)
>>>>+{
>>>>+ int ret = -1;
>>>>+ unsigned int i = 0;
>>>>+ unsigned int j = 0;
>>>>+ unsigned int dups = 0;
>>>>+
>>>>+ unsigned int matched[count_sys_specs()];
>>>>
>>>>Is is legit in the kernel to use dynamically sized array?
>>>
>>>
>>>kmalloc() is certainly safer - why not use it?
>>
>>Practically , version with kmalloc works, but setup_arch and thus this
>>function is called before mem_init, so I just wonder if kmalloc can
>>handle this case. On the other hand, I don't like to deal with
>>alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
>>does) just for the temporary buffer.
>>
>>But it's the only _right_ way (or I 've missed something) - sure I'll
>>follow it.
>
>
> I dont see any problem with dynamic array usage on the kernel (maybe someone
> else has good argumentation against it).
>
> Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
> maximum?
>
>
Yes it does, but there is no define for it. The ppc_sys_specs array
should always end at the "default match" - element with name field set
to "" and value=0 (without it every existing ppc_sys identify will fall
into infinite loop). This array is defined in syslib/<board>_sys.c end
is finite of course. Its size depends on amount of supported boards.
So, if the dynamic array is ok with conditions, it will be great.
But now I'm inclined to implement the same using kmalloc/alloc_bootmem
to prevent flame when it will proceed. BTW, will free_bootmem properly
release the memory allocated by alloc_bootmem()? I haven't encountered
examples of this so far...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: GDB backtrace and signal trampolines
From: Hollis Blanchard @ 2005-08-12 13:58 UTC (permalink / raw)
To: Anton Blanchard; +Cc: PPC64-dev List, Linux PPC Dev
In-Reply-To: <20050812050609.GA7355@krispykreme>
On Aug 12, 2005, at 12:06 AM, Anton Blanchard wrote:
>
>> Would it make sense to limit the test to within a few hundred bytes of
>> the stack pointer? Or some better way to detect that the PC is in a
>> signal trampoline?
>
> With recent kernels we should be able to use the dwarf2 unwind
> information in the vdso I think.
I guess compatibility with older kernels will still need to be
maintained, though.
I see this note in arch/ppc64/mm/fault.c:
/*
* N.B. The POWER/Open ABI allows programs to access up to
* 288 bytes below the stack pointer.
* The kernel signal delivery code writes up to about 1.5kB
* below the stack pointer (r1) before decrementing it.
* The exec code can write slightly over 640kB to the stack
* before setting the user r1. Thus we allow the stack to
* expand to 1MB without further checks.
*/
So would 2KB be a reasonable limit to the signal frame check, as I
described before?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* BankOfTheWest Inc: Please Confirm Your Banking Details [Fri, 12 Aug 2005 12:38:14 -0100]
From: BankOfTheWest @ 2005-08-12 13:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3864 bytes --]
^ permalink raw reply
* BankOfTheWest Inc: Please Confirm Your Banking Details [Fri, 12 Aug 2005 12:38:14 -0100]
From: BankOfTheWest @ 2005-08-12 13:16 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 3864 bytes --]
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Christian @ 2005-08-12 10:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050811194307.GW3187@smtp.west.cox.net>
> On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
>>If anybody has objections to this as the default, let me know. It
>>still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
>>affect the IBM PReP paths. My goal with this is to be able to run
>>a stock 2.6 defconfig PReP build on qemu.
i applied the patch to the latest 2.6-git tree and my PReP[1] boots just
fine!
thanks for maintaining this exotic platform,
Christian.
[1] http://www.nerdbynature.de/bits/hal/2.6.13-rc6
--
BOFH excuse #367:
Webmasters kidnapped by evil cult.
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: cajus.hahn @ 2005-08-12 8:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050812080113.AA881352B36@atlas.denx.de>
My description seems to be a little misleading.
WITHOUT the force_reinit() my SPI driver reports transmission errors if the
I2C bus has longer disturbances.
WITH the force_reinit() my SPI driver works fine.
This sounds like the I2C allocates a new buffer for every timed-out
transmision. If all I2C buffers are full, the SPI buffers get overwritten
!?
I did not really trace back the problem, this is only my suspicion.
Because the force_reinit() resets all the buffer pointer to their init
values the problem with the SPI does not occur.
Cajus
Message from Wolfgang Denk <wd@denx.de>@denx.de received on 12.08.2005
10:01
12.08.2005 Wolfgang Denk <wd@denx.de>@denx.de
10:01
Sent by wd@denx.de
To: Cajus Hahn/DEAPR/ABB@ABB_DE01
cc: linuxppc-embedded@ozlabs.org
Subject: Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
In message
<OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com> you
wrote:
>
> Then I set the SCL line to ground to simulate a longer bus disturbance.
> After some timeouts my SPI bus, yes the SPI bus, reportet transmission
> errors. Both bus-interfaces use the CPM. It looks like the SPI buffer
gets
> garbaged by the I2C interface.
This is "normal". We see similar problems even with perfectly legal
operations on the CPM. The SPI is running at lowest priority on the
CPM, and anything that causes higher CPM load will starve SPI.
Obviously your operation causes the CPM to go into some strange
state.
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
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Wolfgang Denk @ 2005-08-12 8:01 UTC (permalink / raw)
To: cajus.hahn; +Cc: linuxppc-embedded
In-Reply-To: <OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com>
In message <OF29EF0D8D.F0A40A5C-ONC125705B.0028FA70-C125705B.002AF212@de.abb.com> you wrote:
>
> Then I set the SCL line to ground to simulate a longer bus disturbance.
> After some timeouts my SPI bus, yes the SPI bus, reportet transmission
> errors. Both bus-interfaces use the CPM. It looks like the SPI buffer gets
> garbaged by the I2C interface.
This is "normal". We see similar problems even with perfectly legal
operations on the CPM. The SPI is running at lowest priority on the
CPM, and anything that causes higher CPM load will starve SPI.
Obviously your operation causes the CPM to go into some strange
state.
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
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4
^ permalink raw reply
* Re: strange things about swap on NFS
From: Wolfgang Denk @ 2005-08-12 7:58 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E86505F@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E86505F@ydmail.sbell.com.cn> you wrote:
>
> But I found that the "dd if=/dev/zero of=swapfile bs=1M
> count=62" is not easy to executed:
This command alone should just work fine.
> The system is often no response after execute this command. On several
> time, it add swap successfully.
> But when I start to compile package. The system then no response !!
>From your subject and this description I understand that you then try
to use this file as swapfile over NFS, and this causes problems.
There is a known problem with swap over NFS, at least for 2.4 kernels.
> How to slove the problem? Is the reason of my hard disk? I think not,
RTFM. A solution is described in detail at
http://www.denx.de/twiki/bin/view/DULG/SwappingOverNFS
Note that this is terribly slow, though - but sometimes it's better
to have a slow and working system than one which is fast and out of
memory.
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
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
^ permalink raw reply
* 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: cajus.hahn @ 2005-08-12 7:49 UTC (permalink / raw)
To: linuxppc-embedded
Hello Tjernlund, Hello Debora
>Try changing all
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
>to
> i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
>
>That should remove the need to do force_reinit(cpm) I hope.
This is NOT working in every case!
It will work, on short bus-disturbances on the SCL line.
I suggest adding the "| 0x01" even this will not help on every transmission
problem.
If you have longer disturbances on SCL or SDA, something in the CPM will
prevent the I2C bus to continue working after the disturbances are gone.
Perhaps there is a problem with the buffer allocation.
I changed the i2c-algo-8xx.c to work with your patch and without the
force_reinit() code.
Then I set the SCL line to ground to simulate a longer bus disturbance.
After some timeouts my SPI bus, yes the SPI bus, reportet transmission
errors. Both bus-interfaces use the CPM. It looks like the SPI buffer gets
garbaged by the I2C interface.
With the force_reinit() this problem did not occur.
Cajus
^ permalink raw reply
* strange things about swap on NFS
From: FCG WANG Baohua @ 2005-08-12 6:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Dear all:
I use ELDK 3.1.1, kernel 2.4.25 on my HD860 board, using NFS. I add a "ext2.img" as mentioned in the ELDK doc.
But I found that the "dd if=/dev/zero of=swapfile bs=1M count=62" is not easy to executed:
The system is often no response after execute this command. On several time, it add swap successfully.
But when I start to compile package. The system then no response !!
How to slove the problem? Is the reason of my hard disk? I think not,
thanks!
[-- Attachment #2: Type: text/html, Size: 1509 bytes --]
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Marcelo Tosatti @ 2005-08-11 22:45 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FB6DE0.4070506@ru.mvista.com>
On Thu, Aug 11, 2005 at 07:25:20PM +0400, Vitaly Bordug wrote:
> Marcelo Tosatti wrote:
> >On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
> >
> >>+static int __init find_chip_by_name_and_id(char *name, u32 id)
> >>+{
> >>+ int ret = -1;
> >>+ unsigned int i = 0;
> >>+ unsigned int j = 0;
> >>+ unsigned int dups = 0;
> >>+
> >>+ unsigned int matched[count_sys_specs()];
> >>
> >>Is is legit in the kernel to use dynamically sized array?
> >
> >
> >kmalloc() is certainly safer - why not use it?
> Practically , version with kmalloc works, but setup_arch and thus this
> function is called before mem_init, so I just wonder if kmalloc can
> handle this case. On the other hand, I don't like to deal with
> alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
> does) just for the temporary buffer.
>
> But it's the only _right_ way (or I 've missed something) - sure I'll
> follow it.
I dont see any problem with dynamic array usage on the kernel (maybe someone
else has good argumentation against it).
Just that you have a 4kb stack. Does count_sys_specs() have an appropriate
maximum?
^ permalink raw reply
* Re: 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Debora Liu @ 2005-08-12 5:11 UTC (permalink / raw)
To: Tjernlund; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
Hello, Tjernlund
In message <2005-08-12 01:50:45 tjernlund@tjernlund.se> you wrote:
>Try changing all
> i2c->i2c_i2com |= 0x80; /* Begin transmission */
>to
> i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
>
>That should remove the need to do force_reinit(cpm) I hope.
>See http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019600.html for a litte more info.
>
>Also, I think you should remove the busy wait code. Its not needed IMHO.
update i2c_algo_8xx.c as same
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-12
^ permalink raw reply
* Re: GDB backtrace and signal trampolines
From: Anton Blanchard @ 2005-08-12 5:06 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: PPC64-dev List, Linux PPC Dev
In-Reply-To: <a22149f6d9cc6f65ae2f8f339d982dd2@us.ibm.com>
Hi,
> Would it make sense to limit the test to within a few hundred bytes of
> the stack pointer? Or some better way to detect that the PC is in a
> signal trampoline?
With recent kernels we should be able to use the dwarf2 unwind
information in the vdso I think.
Anton
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Debora Liu @ 2005-08-12 5:01 UTC (permalink / raw)
To: Shawn Jin; +Cc: Linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hello, Shawn Jin
In message <2005-08-12 06:41:21 shawnxjin@gmail.com> you wrote:
>Hi,
>
>I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
>is 16550 compatible. U-Boot is already running fine.
Please check your uboot bootargs console rate setting.
= = = = = = = = = = = = = = = = = = = =
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Debora Liu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡deboralh@fel.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-08-12
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-12 4:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <17148.7234.193140.997481@cargo.ozlabs.ibm.com>
On Fri, Aug 12, 2005 at 01:49:22PM +1000, Paul Mackerras wrote:
> Tom Rini writes:
>
> > I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> > OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
>
> Ummm, no, not exactly. The distinctive thing about pSeries is the
> hypervisor interfaces. And in fact most pSeries boxes aren't
> 970-based, rather POWER4/4+/5. If you want to generalize, we could
> call the directory "papr" (for Power Architecture Platform
> Requirements, the name of the document that describes the pSeries
> platforms) rather than pSeries, but I suspect that would just confuse
> people. :)
Ok. How about 9xx/ instead of classic64 ?
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Paul Mackerras @ 2005-08-12 3:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
Tom Rini writes:
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
Ummm, no, not exactly. The distinctive thing about pSeries is the
hypervisor interfaces. And in fact most pSeries boxes aren't
970-based, rather POWER4/4+/5. If you want to generalize, we could
call the directory "papr" (for Power Architecture Platform
Requirements, the name of the document that describes the pSeries
platforms) rather than pSeries, but I suspect that would just confuse
people. :)
Paul.
^ permalink raw reply
* Redwood-6 and 2.6
From: Otto Solares @ 2005-08-12 3:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
Redwood-6 support in 2.6 is broken. I subscribed to this
list just to know if somebody is working on it? 2.4.30
works ok.
If nobody is working on it please just tell me what is wrong
and I would try to figure out:
---
CC arch/ppc/syslib/ppc4xx_dma.o
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_enable_burst': arch/ppc/syslib/ppc4xx_dma.c:638: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c:638: error: (Each undeclared identifier is reported only once arch/ppc/syslib/ppc4xx_dma.c:638: error: for each function it appears in.)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_disable_burst': arch/ppc/syslib/ppc4xx_dma.c:657: error: `DMA_CTC_BTEN' undeclared (first use in this function)
arch/ppc/syslib/ppc4xx_dma.c: In function `ppc4xx_set_burst_size': arch/ppc/syslib/ppc4xx_dma.c:682: error: `DMA_CTC_BSIZ_MSK' undeclared (first use in this function)
make[1]: *** [arch/ppc/syslib/ppc4xx_dma.o] Error 1
make: *** [arch/ppc/syslib] Error 2
---
In 2.4 'DMA_CTC_BTEN' does not exists.
Thanks.
-otto
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-12 3:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <9C2E830E-288C-4373-BDE3-49C5FE47A01C@freescale.com>
On Thu, Aug 11, 2005 at 09:34:57PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:
>
> >On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> >[snip]
> >
> >>I think this causes confusion. the reason we suggested pq2 and
> >>classic32 was to handle things like sandpoint. Sandpoint would live
> >>in classic32. The confusion partial comes from the fact that we can
> >>run 8240/1/5 on a Sandpoint. The thinking was everything that was
> >>6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
> >>10x bridge would be classic32.
> >>
> >
> >Thanks for the explanation. But I think this is overkill for the
> >sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> >which are in the kernel tree). I think we can field the "I wanna hack
> >on my Sandpoint/8240, but don't see the code under 82xx/!"
> >question. :)
>
> So where do you suggest Sandpoint goes in this directory structure?
classic32/
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-12 2:34 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811231948.GA3187@smtp.west.cox.net>
On Aug 11, 2005, at 6:19 PM, Tom Rini wrote:
> On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
> [snip]
>
>> I think this causes confusion. the reason we suggested pq2 and
>> classic32 was to handle things like sandpoint. Sandpoint would live
>> in classic32. The confusion partial comes from the fact that we can
>> run 8240/1/5 on a Sandpoint. The thinking was everything that was
>> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
>> 10x bridge would be classic32.
>>
>
> Thanks for the explanation. But I think this is overkill for the
> sandpoint or true like a sandpoint (Zynx something, Willow, neither of
> which are in the kernel tree). I think we can field the "I wanna hack
> on my Sandpoint/8240, but don't see the code under 82xx/!"
> question. :)
So where do you suggest Sandpoint goes in this directory structure?
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Josh Boyer @ 2005-08-12 2:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
On Thu, 2005-08-11 at 12:59 -0700, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>
> [snip]
> > platforms/
> > - platform-specific code laid out in the following
> > directories:
> > pSeries/
> > iSeries/
> > pmac/ (both 32 and 64-bit)
> > classic32/ (platforms containing
> > 6xx/7xx/74xx/8240/8241/8245)
> > classic64/ (Maple?)
>
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
> (which is a class of its own).
I myself am also pretty ppc64 ignorant, but I do know that not all
pSeries are 9xx based. There are POWER 4 and POWER 5 pSeries boxes too.
josh
^ permalink raw reply
* Update your account information
From: service @ 2005-08-11 23:54 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 8514 bytes --]
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Dan Malek @ 2005-08-11 23:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev, Tom Rini
In-Reply-To: <DE2CC80C-91A2-4860-B452-6AD171F3588A@freescale.com>
On Aug 11, 2005, at 7:07 PM, Kumar Gala wrote:
> ...... The idea being that we might be able to build kernels in
> either directory that supported a large number of boards with one
> image.
Please don't go there :-) I'm having enough trouble meeting reasonable
performance goals in 2.6 on embedded systems that I don't need the
overhead
of code bloat or extra cycles to determine what board I'm on. Contrary
to
the belief of developers, products don't have the resource wealth we see
on these evaluation and ODM boards. Embedded products still require
we build kernels (and everything else) as concisely and efficient as
possible.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 23:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <DE2CC80C-91A2-4860-B452-6AD171F3588A@freescale.com>
On Thu, Aug 11, 2005 at 06:07:03PM -0500, Kumar Gala wrote:
[snip]
> I think this causes confusion. the reason we suggested pq2 and
> classic32 was to handle things like sandpoint. Sandpoint would live
> in classic32. The confusion partial comes from the fact that we can
> run 8240/1/5 on a Sandpoint. The thinking was everything that was
> 6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
> 10x bridge would be classic32.
Thanks for the explanation. But I think this is overkill for the
sandpoint or true like a sandpoint (Zynx something, Willow, neither of
which are in the kernel tree). I think we can field the "I wanna hack
on my Sandpoint/8240, but don't see the code under 82xx/!" question. :)
> If it was 82xx w/o a CPM it went into classic32. If it was a 82xx w/
> CPM it went into pq2. The idea being that we might be able to build
> kernels in either directory that supported a large number of boards
> with one image.
We can certainly investigate just how many distinct boards can be
supported with one image when infos are passed dynamically. If we can
simplify things enough, maybe we can break the rule of no .[ch] files in
arch/powerpc/platforms since it'll just be 82xx.[ch], 83xx.[ch] and so
on, execept for that damn pmac. ;)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Eugene Surovegin @ 2005-08-11 23:17 UTC (permalink / raw)
To: Shawn Jin, ppcembed
In-Reply-To: <20050811231454.GA5796@gate.ebshome.net>
On Thu, Aug 11, 2005 at 04:14:54PM -0700, Eugene Surovegin wrote:
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> > ??????
>
> Try disabling early text debugging (all that "MMU:..." stuff).
>
Also, make sure you pass correct "console=..." line to the kernel
(with correct device name and baud rate).
--
Eugene
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox