* Re: [PATCH] cpm_uart: Made non-console uart work
From: Pantelis Antoniou @ 2005-08-03 16:14 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <42F06F62.6050509@ru.mvista.com>
On Wednesday 03 August 2005 10:16, you wrote:
> Panto, Kumar,
>
> Thank you for review.
>
[major snipage]
> Well, all the stuff works on 8272 even without this and likewise stuff,
> but don't on 866ADS, where bus_to_virt returns value not equal to where
> we allocated DMA. I didn't dig too deep to track why this happens, since
> if we're using DMA, we should remember addresses upon allocation and
> avoid using bus_to_virt.
Well, this is weird cause I've tested my latest patch on 8xx and had no
problems...
I'll try to test your patch, some time later today.
However, what is important now is to get the fs_enet driver posted.
Please test the latest patch I've send you on a linus tree and report if you
have any problems...
Regards
Pantelis
^ permalink raw reply
* Re: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Vitaly Bordug @ 2005-08-03 14:03 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded list
In-Reply-To: <8E342283C2100540AAC5D103097054776F851C@rcexc.racoms.loc>
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
Schaefer-Hutter, Peter wrote:
>Hello Vitaly,
>
>
>
>>From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
>>
>>Mentioned support should work `out-of-the box`.
>>Make sure you have console=ttyCPM0,115200 (or whatever baudrate you
>>have) within bootargs in the U-Boot environment. U-Boot modification
>>
>>
>is
>
>
>>needed only if you wish to have both FEC MAC addresses configured via
>>U-Boot env as well. Also only the related defconfig should be used.
>>
>>
>
>I have the bootargs, but still nogo - even with the mpc885ads_defconfig.
>
>Besides, in the mpc885ads_defconfig CONFIG_SCC3_ENET is set but in the
>patch
>description it reads as if only SCC1 is supported...
>
> Best Regards,
>
> Peter
>
>
>
The board does not hang - there's somithing with console since you don't
see anything. Try to change BCSR_ADDR from 0xf4500000 to 0xf80...0 -
the newer version of the boards may have this changed.
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 1585 bytes --]
^ permalink raw reply
* RE: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Schaefer-Hutter, Peter @ 2005-08-03 14:27 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
Hello,
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> The board does not hang - there's somithing with=20
> console since you don't see anything. Try to change=20
> BCSR_ADDR from 0xf4500000 to 0xf80...0 - the newer=20
> version of the boards may have this changed.
Hrm... arc/ppc/mpc885ads.h already reads
/* U-Boot maps BCSR to 0xff080000 */
#define BCSR_ADDR ((uint)0xff080000)
And that's the same setting that my 2.4-Kernel
uses, so it should work with 0xff080000.
However, BCSR_SIZE looks suspicious in this header:
#define BCSR_SIZE ((uint)32)
Shouldn't that read:
#define BCSR_SIZE ((uint)32 * 1024)
??!?
Regards,
Peter
^ permalink raw reply
* Re: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Vitaly Bordug @ 2005-08-03 14:35 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded list
In-Reply-To: <8E342283C2100540AAC5D103097054776F8533@rcexc.racoms.loc>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
Schaefer-Hutter, Peter wrote:
>Hello,
>
>
>
>>From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
>>
>>
>
>
>
>>The board does not hang - there's somithing with
>>console since you don't see anything. Try to change
>>BCSR_ADDR from 0xf4500000 to 0xf80...0 - the newer
>>version of the boards may have this changed.
>>
>>
>
>Hrm... arc/ppc/mpc885ads.h already reads
>
> /* U-Boot maps BCSR to 0xff080000 */
> #define BCSR_ADDR ((uint)0xff080000)
>
>And that's the same setting that my 2.4-Kernel
>uses, so it should work with 0xff080000.
>
>However, BCSR_SIZE looks suspicious in this header:
>
> #define BCSR_SIZE ((uint)32)
>
>Shouldn't that read:
>
> #define BCSR_SIZE ((uint)32 * 1024)
>
>??!?
>
>Regards,
>
> Peter
>
>
>
<quotation> (This is from 8272 User Guide, but 885 I guess is the same
in this part)
> Most of the hardware options on the MPC8272ADS are controlled or
> monitored by the
> BCSR, which is a 32 bit wide read / write register file. The BCSR is
> accessed via the
> MPC8272s' memory controller (see Table 5-5) and in fact includes 8
> registers: BCSR0 to
> BCSR7. Since the minimum block size for a CS region is 32KBytes and
> only A(27:29)
> lines are decoded by the BCSR for register selection, BCSR0 - BCSR7
> are duplicated inside
> that region.
<quotation\>
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 2083 bytes --]
^ permalink raw reply
* Re: [PATCH] cpm_uart: Made non-console uart work
From: Vitaly Bordug @ 2005-08-03 14:50 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <200508031914.10973.pantelis.antoniou@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
>>Well, all the stuff works on 8272 even without this and likewise stuff,
>>but don't on 866ADS, where bus_to_virt returns value not equal to where
>>we allocated DMA. I didn't dig too deep to track why this happens, since
>>if we're using DMA, we should remember addresses upon allocation and
>>avoid using bus_to_virt.
>>
>>
>
>Well, this is weird cause I've tested my latest patch on 8xx and had no
>problems...
>
>
>
Since currently I have no ability to reproduce this issue, I'm inclined
to drop those hunks. BTW, why those bus_to_virt and virt_to_bus are
used? Isn't it more clear to use pure addresses if they are dma-allocated?
>I'll try to test your patch, some time later today.
>
>However, what is important now is to get the fs_enet driver posted.
>Please test the latest patch I've send you on a linus tree and report if you
>have any problems...
>
>
>
I'll try to test it today/tomorrow as time permits... But do you think
it can proceed with those mii issues? Though they are almost harmless,
the driver will complain that no PHY found but all seem to work fine
subsequently. As far as Andy's phy will likely to be in rc14, maybe we
can try to push this upstream (as what we have currently for 82xx and
especially for 8xx is IMO worse than even incomplete implementation).
I'll try to investigate mii troubles, but it's hard to estimate efforts...
>Regards
>
>Pantelis
>
>
>
>
--
Sincerely,
Vitaly
[-- Attachment #2: Type: text/html, Size: 2115 bytes --]
^ permalink raw reply
* RE: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Schaefer-Hutter, Peter @ 2005-08-03 15:13 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
Hi,=20
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> > Schaefer-Hutter, Peter wrote:=20
> > Shouldn't that read:
> > #define BCSR_SIZE ((uint)32 * 1024)
> <quotation> (This is from 8272 User Guide, but 885 I guess is the same
in this part)
> [ ... ]
> <quotation\>
Well, i was just wondering why fads.h and my old 2.4-Kernel define it
'(32*1024)', but
this explains it.
Thank you and best regards,
Peter
^ permalink raw reply
* MPC8541E DMA transfer
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-03 15:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Hi all,
I am developing a linux driver (2.6.10) for Freescale MPC8541E
(customized board) to read and write 8 buffers (each buffer is 960 bytes
long) every 10 ms to/from a custom made PCI card with on board DSP Chip.
The chip's internal and external memories are memory mapped to the CPU
address space.
For reason that is beyond the discussion here, the DMA request line on
the PCI card is not connected although the PCI card has DMA
capabilities.
So what are my options?
Could I still do DMA transfer from the Host to the device?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1601 bytes --]
^ permalink raw reply
* about linux 2.4.25 on MPC852T
From: 徐勝威 @ 2005-08-03 16:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
Hello all,
I'm porting Linux 2.4.25 at my MPC852T.My first used is 2.4.4, I assign my board info ptr to 0x3400 and pass it to linux 2.4.4.
It works fine. But 2.4.25's head.S changes much code I don't know how to porting it. I need help.
My add code like this
li r3, 0x3400
mr r11,r3
(../arch/ppc/mbxboot/head.S)
to 2.4.4.
Another question is where can i find older kernel like 2.4.10, 2.4.12,2.4.18 for PowerPC?I know DENX Linux kernel source tree
has the latest version, but i'm not sure there has above version that I want and I don't how to used cvs command to get it.If anyone
know where to download older kernel, please tell me,thanks.
Best Regards,
Rober Hsu
[-- Attachment #2: Type: text/html, Size: 1687 bytes --]
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Kim Phillips @ 2005-08-03 16:47 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <53547.198.22.236.230.1122997515.squirrel@198.22.236.230>
On Tue, 2 Aug 2005 11:45:15 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
>
> This is how i write the address of RNG buffer(sec1_dpd.c.
> DPDPTR->fld[i].ptr = virt_to_phys(*(unsigned int *) ((unsigned int)pReq +
> pDesc->fld[i].ptrOffset1st));
>
everything looks good except I'd try changing the above to something like:
DPDPTR->fld[i].ptr = dma_map_single(NULL, ...ptrOffset1st,
...lenOffset1st, DMA_TO_DEVICE);
and change the DMA_BIDIRECTIONAL to DMA_TO_DEVICE in the DPD's address assignment.
btw, a BSP upgrade (based on 2.6.11) for your platform should be available in a couple of weeks. I'll let you know the status of the SEC driver for it.
Kim
^ permalink raw reply
* Re: EST MPC823 board
From: Wolfgang Denk @ 2005-08-03 16:48 UTC (permalink / raw)
To: James Hughes; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <DB1B6B12D0E2F0469EB35A9586066B6ECE75FB@stivesemail.stives.linx.gbr>
In message <DB1B6B12D0E2F0469EB35A9586066B6ECE75FB@stivesemail.stives.linx.gbr> you wrote:
> We already have VXWorks working on the board, so a lot of data can be
> gleaned from the BSP for that. As a beginner to U-Boot - would the
> information from that be sufficient to get to a working build?
Yes, assuming you have sufficient hardware documentation (like
schematics) as well.
> Its difficult to see from the U-Boot tree which boards are based on the
> MPC623 - is there a quick way of finding which are? grep for 623?
623? I guess you mean 823? Yes, this is easy to find out. But it will
not help you much. You will still have to port U-Boot to *your*
board. Forget about the idea that two boards might be "similar
enough" to clone one from the other. They aren't.
You need to understand both the hardware and U-Boot, or you will
fail.
And BTW: I think your approach suffers from a serious mistake: to me
it makes little sense to use a MPC8xx based board as model for a
PXA270 target system; there are *huge* differences between these two
architectures.
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
I've already got a female to worry about. Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
^ permalink raw reply
* Re: about linux 2.4.25 on MPC852T
From: Wolfgang Denk @ 2005-08-03 16:51 UTC (permalink / raw)
To: 徐勝威; +Cc: linuxppc-embedded
In-Reply-To: <002701c59848$cb6b6ed0$0e01000a@orange>
In message <002701c59848$cb6b6ed0$0e01000a@orange> you wrote:
>
> I'm porting Linux 2.4.25 at my MPC852T.My first used is 2.4.4, I
> assign my board info ptr to 0x3400 and pass it to linux 2.4.4.
Ummm... are you sure you know what you are doing?
> It works fine. But 2.4.25's head.S changes much code I don't know how
> to porting it. I need help.
Just have a look at the existing code. MPC8xx is a standard
architecture and has been supported since a long,, long time ago.
> Another question is where can i find older kernel like 2.4.10,
> 2.4.12,2.4.18 for PowerPC?I know DENX Linux kernel source tree
You can find it for example in our CVS server.
> want and I don't how to used cvs command to get it.If anyone
If you don;t know the tools, and are not willing to try to learn to
use these, then nobody will be able to help you. Try and hire an
expert.
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
He had quite a powerful intellect, but it was as powerful like a
locomotive, and ran on rails and was therefore almost impossible to
steer. - Terry Pratchett, _Lords and Ladies_
^ permalink raw reply
* Re: MPC8541E DMA transfer
From: Kumar Gala @ 2005-08-03 18:24 UTC (permalink / raw)
To: Bizhan Gholikhamseh \((bgholikh\)); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964158494B1@xmb-sjc-212.amer.cisco.com>
I dont see any reason you couldn't use the internal DMA engine on the
MPC8541E to do what you need. You will just need to schedule the
work every 10ms.
- kumar
On Aug 3, 2005, at 10:04 AM, Bizhan Gholikhamseh \(((bgholikh\))) wrote:
>
> Hi all,
> I am developing a linux driver (2.6.10) for Freescale MPC8541E
> (customized board) to read and write 8 buffers (each buffer is 960
> bytes
> long) every 10 ms to/from a custom made PCI card with on board DSP
> Chip.
> The chip's internal and external memories are memory mapped to the CPU
> address space.
> For reason that is beyond the discussion here, the DMA request line on
> the PCI card is not connected although the PCI card has DMA
> capabilities.
> So what are my options?
> Could I still do DMA transfer from the Host to the device?
>
> Many thanks in advance,
> Bizhan
>
> <ATT293768.txt>
>
^ permalink raw reply
* RE: MPC8541E DMA transfer
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-03 18:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
Is there any support in Linux 2.6.X for using this controller, if so,
are you aware of any test driver I can take a look at?
Thanks,
Bizhan
Many thanks in =20
-----Original Message-----
From: Kumar Gala [mailto:kumar.gala@freescale.com]=20
Sent: Wednesday, August 03, 2005 11:24 AM
To: Bizhan Gholikhamseh (bgholikh)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8541E DMA transfer
I dont see any reason you couldn't use the internal DMA engine on the
MPC8541E to do what you need. You will just need to schedule the work
every 10ms.
- kumar
On Aug 3, 2005, at 10:04 AM, Bizhan Gholikhamseh \(((bgholikh\))) wrote:
>
> Hi all,
> I am developing a linux driver (2.6.10) for Freescale MPC8541E=20
> (customized board) to read and write 8 buffers (each buffer is 960=20
> bytes
> long) every 10 ms to/from a custom made PCI card with on board DSP=20
> Chip.
> The chip's internal and external memories are memory mapped to the CPU
> address space.
> For reason that is beyond the discussion here, the DMA request line on
> the PCI card is not connected although the PCI card has DMA=20
> capabilities.
> So what are my options?
> Could I still do DMA transfer from the Host to the device?
>
> Many thanks in advance,
> Bizhan
>
> <ATT293768.txt>
>
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-03 18:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050803114749.739ae51e.kim.phillips@freescale.com>
I will try the new BSP but meanwhile like to debug my ported driver.
Is there a way , like kernel level single-stepping to know why the
"interrupt status register" gets a value of "0x0000000000000040" which
means TEA , transfer error acknowledge.
I changed and tested ur latest advice but same error in "interrupt status
register"
-vikas
> On Tue, 2 Aug 2005 11:45:15 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>>
>> This is how i write the address of RNG buffer(sec1_dpd.c.
>> DPDPTR->fld[i].ptr = virt_to_phys(*(unsigned int *) ((unsigned int)pReq
>> +
>> pDesc->fld[i].ptrOffset1st));
>>
>
> everything looks good except I'd try changing the above to something like:
>
> DPDPTR->fld[i].ptr = dma_map_single(NULL, ...ptrOffset1st,
> ...lenOffset1st, DMA_TO_DEVICE);
>
> and change the DMA_BIDIRECTIONAL to DMA_TO_DEVICE in the DPD's address
> assignment.
>
> btw, a BSP upgrade (based on 2.6.11) for your platform should be available
> in a couple of weeks. I'll let you know the status of the SEC driver for
> it.
>
> Kim
>
^ permalink raw reply
* Re: MPC8245 reboot
From: Mark A. Greer @ 2005-08-03 18:39 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca65705080223401a9ce913@mail.gmail.com>
On Wed, Aug 03, 2005 at 03:40:18PM +0900, Daniel Ann wrote:
> Absolutely not. Very much like sandpoint except, we dont use SIO at all.
> FYI, most of sandpoint code from the kernel is function the board very
> well at the moment. Only big issue lies with REBOOT at this stage:(
Daniel,
IIRC, the sandpoint uses the PC style port 92 mechanism to reset the board.
You need to look at your hardware docs to see how your board can be reset.
Don't expect the sandpoint reset code to work for you.
Mark
^ permalink raw reply
* Re: [PATCH 0/10] Cleanup iSeries msChunks handling, and lmb code.
From: Jon Loeliger @ 2005-08-03 19:01 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc64-dev, linuxppc-dev@ozlabs.org
In-Reply-To: <1123064479.417492.649639846705.qpatch@concordia>
On Wed, 2005-08-03 at 05:21, Michael Ellerman wrote:
> This series of patches cleans up the iSeries msChunks structure, and
> associated macros and functions.
>
> It also removes CONFIG_MSCHUNKS from the lmb code, and eventually removes
> CONFIG_MSCHUNKS entirely.
>
> The final patch rely's on Stephen's FW_FEATURE_ISERIES patches.
>
> Booted on Power3, G5, Power5 LPAR and iSeries.
Excellent. This patch, especially the LMB simplification
and removal of the physbase bits, greatly simplifies the
notion of merging LMB form 64 land and the mem_pieces.
I have previously submitted patches against the ppc32 code
that enhance the mem_pieces towards the LMB structure as well.
Given an eventual merger of the two bodies of code, I'd
like to make the merger of these two structures more complete.
I'll work towards that goal if that's a Good Idea.
Advice here?
Thanks,
jdl
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Kim Phillips @ 2005-08-03 20:35 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <30177.198.22.236.230.1123094006.squirrel@198.22.236.230>
On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> I will try the new BSP but meanwhile like to debug my ported driver.
>
> Is there a way , like kernel level single-stepping to know why the
> "interrupt status register" gets a value of "0x0000000000000040" which
> means TEA , transfer error acknowledge.
afaik, TEA usually means memory was unable to be accessed by the sec (somewhat along the same lines as a SIGBUS or SIGSEGV).
It's a long shot, but you may want to increase the 4-byte alignment of the rng buffer (0x009ffc5c in your trace?) to at least 8-byte.
as for debugging, you can printk sec status registers every time you write one, e.g. in a sec register write wrapper fn. Be sure to check the RNG interrupt status register, and the RNG status register, and the RNG interrupt control register.
and if all else fails, you can bypass the channel infrastructure altogether, and use the RNG EU in slave mode. Reset the SEC, write the RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size register, and pull data off the RNG FIFO at will.
Kim
^ permalink raw reply
* Re: MPC8541E DMA transfer
From: Kumar Gala @ 2005-08-03 21:57 UTC (permalink / raw)
To: Bizhan Gholikhamseh \(bgholikh\); +Cc: linuxppc-embedded list
In-Reply-To: <F795765B112E7344AF36AA91127964158494B8@xmb-sjc-212.amer.cisco.com>
There has been some example code posted in the past to the list. I
suggest searching the archives and looking for something posted by
Jason McMullan.
- kumar
On Aug 3, 2005, at 1:26 PM, Bizhan Gholikhamseh \\((bgholikh\\)) wrote:
> Is there any support in Linux 2.6.X for using this controller, if so,
> are you aware of any test driver I can take a look at?
>
> Thanks,
> Bizhan
>
> Many thanks in
>
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala@freescale.com]
> Sent: Wednesday, August 03, 2005 11:24 AM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8541E DMA transfer
>
> I dont see any reason you couldn't use the internal DMA engine on the
> MPC8541E to do what you need. You will just need to schedule the work
> every 10ms.
>
> - kumar
>
> On Aug 3, 2005, at 10:04 AM, Bizhan Gholikhamseh \(((bgholikh\)))
> wrote:
>
>
>>
>> Hi all,
>> I am developing a linux driver (2.6.10) for Freescale MPC8541E
>> (customized board) to read and write 8 buffers (each buffer is 960
>> bytes
>> long) every 10 ms to/from a custom made PCI card with on board DSP
>> Chip.
>> The chip's internal and external memories are memory mapped to the
>> CPU
>>
>
>
>> address space.
>> For reason that is beyond the discussion here, the DMA request
>> line on
>>
>
>
>> the PCI card is not connected although the PCI card has DMA
>> capabilities.
>> So what are my options?
>> Could I still do DMA transfer from the Host to the device?
>>
>> Many thanks in advance,
>> Bizhan
>>
>> <ATT293768.txt>
>>
>
^ permalink raw reply
* Re: MPC8245 reboot
From: Daniel Ann @ 2005-08-04 0:16 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20050803183932.GA13789@mag.az.mvista.com>
Mark,
Guess I'll have to walk the uncharted area again :P
Thanks anyway tho. I'll start by looking at what that port 92
mechanism is first, and see where in our hw designer have put that in.
On 8/4/05, Mark A. Greer <mgreer@mvista.com> wrote:
> On Wed, Aug 03, 2005 at 03:40:18PM +0900, Daniel Ann wrote:
> > Absolutely not. Very much like sandpoint except, we dont use SIO at all=
.
> > FYI, most of sandpoint code from the kernel is function the board very
> > well at the moment. Only big issue lies with REBOOT at this stage:(
>=20
> Daniel,
>=20
> IIRC, the sandpoint uses the PC style port 92 mechanism to reset the boar=
d.
> You need to look at your hardware docs to see how your board can be reset=
.
> Don't expect the sandpoint reset code to work for you.
>=20
> Mark
>=20
--=20
Daniel
^ permalink raw reply
* Re: [PATCH 0/10] Cleanup iSeries msChunks handling, and lmb code.
From: Michael Ellerman @ 2005-08-04 0:17 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1123095705.8638.14.camel@cashmere.sps.mot.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Thu, 4 Aug 2005 05:01, Jon Loeliger wrote:
> On Wed, 2005-08-03 at 05:21, Michael Ellerman wrote:
> > This series of patches cleans up the iSeries msChunks structure, and
> > associated macros and functions.
> >
> > It also removes CONFIG_MSCHUNKS from the lmb code, and eventually removes
> > CONFIG_MSCHUNKS entirely.
> >
> > The final patch rely's on Stephen's FW_FEATURE_ISERIES patches.
> >
> > Booted on Power3, G5, Power5 LPAR and iSeries.
>
> Excellent. This patch, especially the LMB simplification
> and removal of the physbase bits, greatly simplifies the
> notion of merging LMB form 64 land and the mem_pieces.
Cool. I wasn't really thinking of 32 <-> 64 merging when I did the patches,
but it's good to be heading in the right direction.
> I have previously submitted patches against the ppc32 code
> that enhance the mem_pieces towards the LMB structure as well.
>
> Given an eventual merger of the two bodies of code, I'd
> like to make the merger of these two structures more complete.
> I'll work towards that goal if that's a Good Idea.
I don't know the ppc32 code (guess I'll need to soon), so I can't comment on
specifics, but it sounds like a "Good Idea" to me.
cheers
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8245 reboot
From: Mark A. Greer @ 2005-08-04 0:26 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca6570508031716786e73b0@mail.gmail.com>
On Thu, Aug 04, 2005 at 09:16:23AM +0900, Daniel Ann wrote:
> Mark,
>
> Guess I'll have to walk the uncharted area again :P
> Thanks anyway tho. I'll start by looking at what that port 92
> mechanism is first, and see where in our hw designer have put that in.
Personally, I wouldn't waste my time on the port 92 stuff. I really doubt the
hw engr did that unless your board is very PC-ish. Does your board have any
"board" regs (e.g., some regs on a pld or something)? If so, look through
those for a bit in a register that resets the system.
Mark
^ permalink raw reply
* RE: Merging ppc32 and ppc64
From: Goodman, Brad @ 2005-08-04 2:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 126 bytes --]
As long as you keep the "legacy" directories around for a while - I'm happy.
Thanks,
-BKG
bgoodman et empirix und com
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2300 bytes --]
^ permalink raw reply
* Re: [PATCH] fix gcc4 warning in asm-ppc/time.h
From: Andrew Morton @ 2005-08-04 5:15 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20050802095509.GA32585@lst.de>
Christoph Hellwig <hch@lst.de> wrote:
>
> A function must not return a const value, instead use
> __attribute_const__.
>
>
> Index: linux-2.6/include/asm/time.h
> ===================================================================
> --- linux-2.6.orig/include/asm/time.h 2005-04-30 10:17:19.000000000 +0200
> +++ linux-2.6/include/asm/time.h 2005-08-01 11:57:12.000000000 +0200
> @@ -10,6 +10,7 @@
> #define __ASM_TIME_H__
>
> #include <linux/config.h>
> +#include <linux/compiler.h>
> #include <linux/types.h>
> #include <linux/rtc.h>
> #include <linux/threads.h>
> @@ -58,7 +59,7 @@
> /* Accessor functions for the timebase (RTC on 601) registers. */
> /* If one day CONFIG_POWER is added just define __USE_RTC as 1 */
> #ifdef CONFIG_6xx
> -extern __inline__ int const __USE_RTC(void) {
> +extern __inline__ int __attribute_const__ __USE_RTC(void) {
> return (mfspr(SPRN_PVR)>>16) == 1;
> }
> #else
Do we really want to do this? The above implies that mfspr(SPRN_PVR) will
return the same value across the entire uptime of the kernel. Is that
true?
Why is this function paying with const anyway?
^ permalink raw reply
* Re: [PATCH] fix gcc4 warning in asm-ppc/time.h
From: Andrew Morton @ 2005-08-04 5:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20050802095509.GA32585@lst.de>
Christoph Hellwig <hch@lst.de> wrote:
>
> A function must not return a const value, instead use
> __attribute_const__.
>
>
> Index: linux-2.6/include/asm/time.h
> ===================================================================
> --- linux-2.6.orig/include/asm/time.h 2005-04-30 10:17:19.000000000 +0200
> +++ linux-2.6/include/asm/time.h 2005-08-01 11:57:12.000000000 +0200
asm-ppc, please. That didn't apply very well on an x86 tree...
^ permalink raw reply
* Re: [PATCH] fix gcc4 warning in asm-ppc/time.h
From: Gabriel Paubert @ 2005-08-04 5:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20050803221517.21b54d7e.akpm@osdl.org>
On Wed, Aug 03, 2005 at 10:15:17PM -0700, Andrew Morton wrote:
> Christoph Hellwig <hch@lst.de> wrote:
> >
> > A function must not return a const value, instead use
> > __attribute_const__.
> >
> >
> > Index: linux-2.6/include/asm/time.h
> > ===================================================================
> > --- linux-2.6.orig/include/asm/time.h 2005-04-30 10:17:19.000000000 +0200
> > +++ linux-2.6/include/asm/time.h 2005-08-01 11:57:12.000000000 +0200
> > @@ -10,6 +10,7 @@
> > #define __ASM_TIME_H__
> >
> > #include <linux/config.h>
> > +#include <linux/compiler.h>
> > #include <linux/types.h>
> > #include <linux/rtc.h>
> > #include <linux/threads.h>
> > @@ -58,7 +59,7 @@
> > /* Accessor functions for the timebase (RTC on 601) registers. */
> > /* If one day CONFIG_POWER is added just define __USE_RTC as 1 */
> > #ifdef CONFIG_6xx
> > -extern __inline__ int const __USE_RTC(void) {
> > +extern __inline__ int __attribute_const__ __USE_RTC(void) {
> > return (mfspr(SPRN_PVR)>>16) == 1;
> > }
> > #else
>
> Do we really want to do this? The above implies that mfspr(SPRN_PVR) will
> return the same value across the entire uptime of the kernel. Is that
> true?
Yes, it is a read-only register. PVR means processor version register
and is linked to the revision of the silicon. Besides that it is
only used in this context to check for processors of the 601 family
(the very first PPC processors). Nobody expects them to be hotpluggable,
nor even used in SMP systems for the matter.
>
> Why is this function paying with const anyway?
I believe that it was originally to tell the compiler to be
able to cache it across several tests (a good compiler
on PPC would even cache the result of the test in a condition
register to allow branch prediction to work optimally).
Otherwise the compiler would never cache it since mfspr
is a volatile asm.
However this was written in pre gcc2.95 days so my
memory may be failing.
Gabriel
^ 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