* Re: mmap nocache on PPC, 2.4
From: Stephen Williams @ 2005-08-22 17:47 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <430A0AB9.20000@icarus.com>
Stephen Williams wrote:
> Dan Malek wrote:
> | Even if this did what you thought it should, I'm not sure you
> | would be happy with the results. The challenge is ensuring
> | anyone that touches these physical pages also does so
> | uncached. Depending upon the processor, this isn't something
> | that is trivial to change in the kernel, since we always map
> | all of memory as efficiently as possible with a cached mapping.
> | The caching of memory has many desirable performance
> | side effects, making the trade off the manage coherency in
> | software if needed an overall system gain.
>
> The processor is touching this memory only very briefly to put
> image headers around the data, and even at that it would need
> to be immediately flushed again so that it can be DMAed off the
> system.
>
> My problem is that I need a lot of memory that is mostly accessed
> by high performance devices that make lots of data, and only
> very occasionally accessed by the processor for minor fixups.
> Caching is very much getting in my way here in this specialized
> case, I think.
I would like to add that it is not exactly the cache that is
getting in my way, but *cache invalidation*. For the tests I'm
running the destination buffer is 16Meg. The PPC405GPr 266MHz
is taking 10ms to invalidate the cache for all that memory and
another 6ms to "map" it and get physical addresses for DMA, but
I need it to be turned around in more like 1ms.
Of the 16ms to turn the buffer around, I've eliminated 10ms
simply by treating the memory of the buffer as uncached. I'm
hoping to work on the remaining 6ms by premapping where I can.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: mmap nocache on PPC, 2.4
From: Stephen Williams @ 2005-08-22 17:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <20d4aca8d8032c5762deb047185d2c6e@embeddededge.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan Malek wrote:
|
| On Aug 22, 2005, at 10:35 AM, Stephen Williams wrote:
|
|> In an embedded system, I want a big chunk of virtual memory in the
|> user process to be uncached.
|
|
| Why? What processor it this? Who else touches this memory?
PPC405GPr. The only things touching the memory are a PCI compressor
chip that is writing the buffer, a user mode thread that is putting
some image headers around it, and another device that reads it out.
I believe that if the memory is mapped uncached in the user mode
process then I'm safe.
|> .... I've created a virtual device driver that
|> has this mmap method:
|
|
| Even if this did what you thought it should, I'm not sure you
| would be happy with the results. The challenge is ensuring
| anyone that touches these physical pages also does so
| uncached. Depending upon the processor, this isn't something
| that is trivial to change in the kernel, since we always map
| all of memory as efficiently as possible with a cached mapping.
| The caching of memory has many desirable performance
| side effects, making the trade off the manage coherency in
| software if needed an overall system gain.
The processor is touching this memory only very briefly to put
image headers around the data, and even at that it would need
to be immediately flushed again so that it can be DMAed off the
system.
My problem is that I need a lot of memory that is mostly accessed
by high performance devices that make lots of data, and only
very occasionally accessed by the processor for minor fixups.
Caching is very much getting in my way here in this specialized
case, I think.
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDCgq4rPt1Sc2b3ikRApqMAJ9IuHhK6mi92ysju18xyQJsKNG4qQCff9aV
4sTZ0uRyuPmNW+FQYJYfS10=
=z2iH
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: mmap nocache on PPC, 2.4
From: Dan Malek @ 2005-08-22 17:09 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <4309E2AC.9080404@icarus.com>
On Aug 22, 2005, at 10:35 AM, Stephen Williams wrote:
> In an embedded system, I want a big chunk of virtual memory in the
> user process to be uncached.
Why? What processor it this? Who else touches this memory?
> .... I've created a virtual device driver that
> has this mmap method:
Even if this did what you thought it should, I'm not sure you
would be happy with the results. The challenge is ensuring
anyone that touches these physical pages also does so
uncached. Depending upon the processor, this isn't something
that is trivial to change in the kernel, since we always map
all of memory as efficiently as possible with a cached mapping.
The caching of memory has many desirable performance
side effects, making the trade off the manage coherency in
software if needed an overall system gain.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Olof Johansson @ 2005-08-22 15:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, Stephen Rothwell, linuxppc-dev list, ppc64-dev
In-Reply-To: <0F51EC83-8969-4083-B0D7-9343D075B635@freescale.com>
On Mon, Aug 22, 2005 at 09:20:10AM -0500, Kumar Gala wrote:
> >Since the need is considered big enough to create a hierarchy for
> >the code under arch/powerpc/, wouldn't something corresponding be a
> >good idea for the include files? Or do we want to clutter them with
> >all platform-specific files in one directory?
>
> I'm in agreement, but am wondering how many of the pmac specific
> headers could end up in arch/powerpc/platforms/pmac in the future.
Yeah, not sure -- I was thinking the same while I wrote that reply. There
are some pSeries and iSeries files that could maybe be moved there too.
-Olof
^ permalink raw reply
* mmap nocache on PPC, 2.4
From: Stephen Williams @ 2005-08-22 14:35 UTC (permalink / raw)
To: linuxppc-embedded
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In an embedded system, I want a big chunk of virtual memory in the
user process to be uncached. I've created a virtual device driver that
has this mmap method:
static int heap_mmap(struct file*filp, struct vm_area_struct*vma)
{
/* Mark this whole region uncached. The setup of this
additional flag, and the VM_RESERVED, are the whole point
of this module. This hopefully will cause all pages mapped
into this vma to be uncached. */
~ pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
~ vma->vm_flags |= VM_RESERVED;
~ vma->vm_ops = &heap_vm_ops;
~ heap_vm_open(vma);
~ return 0;
}
I then allocate in the nopage from get_free_page as usual. My
question is, "Is this doing what I think it is doing?"
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDCeKrrPt1Sc2b3ikRAlsVAKDD6+O4ihBYkHreyqkNcQuuvKIK8wCg4b6v
jRBU8FJrOyczJJdPkicf22s=
=zMkX
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 3/3] Move all the very similar files
From: Kumar Gala @ 2005-08-22 14:20 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list, Stephen Rothwell, ppc64-dev
In-Reply-To: <20050822141235.GA7110@austin.ibm.com>
On Aug 22, 2005, at 9:12 AM, Olof Johansson wrote:
> On Mon, Aug 22, 2005 at 04:10:30PM +1000, Stephen Rothwell wrote:
>
>> This moves all the very similar files - either the ppc64 file
>> included
>> the ppc file or they differed in simple comments.
>>
>
> [...]
>
>> include/asm-powerpc/pmac_feature.h | 379
>>
> ++++++++++++++++++++++++++++++++++++
>
>> include/asm-powerpc/pmac_low_i2c.h | 43 ++++
>>
>
> Since the need is considered big enough to create a hierarchy for
> the code under arch/powerpc/, wouldn't something corresponding be a
> good idea for the include files? Or do we want to clutter them with
> all platform-specific files in one directory?
I'm in agreement, but am wondering how many of the pmac specific
headers could end up in arch/powerpc/platforms/pmac in the future.
- kumar
^ permalink raw reply
* AW: MPC5200 mmap, ioremap
From: Achim Machura @ 2005-08-22 14:12 UTC (permalink / raw)
To: 'Kunkel, Ulrich'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <D3524C0FFDC6A54F9D7B6BBEECD341D505618A78@hbmntx0.da.hbm.com>
Hello Ulrich,
> mem =12 M
i think it means the kernel knows about 12 MB
This code below works fine at our board, but we use only a few kb in the
protected ram.
I don't Know whats happen if size is bigger as one page.
int asi_common_mmap(struct file *filp, struct vm_area_struct *vma)
{
// unsigned long off = vma->vm_pgoff << PAGE_SHIFT;
unsigned long physical = ASI_IOMEM_BASE;
unsigned long vsize = vma->vm_end - vma->vm_start;
// unsigned long psize = ASI_IOMEM_SIZE - off;
// rt_printk("start : 0x%08lX\n", vma->vm_start);
// rt_printk("end : 0x%08lX\n", vma->vm_end);
// rt_printk("offset: 0x%08lX\n", off);
// rt_printk("phys : 0x%08lX\n", physical);
// rt_printk("vsize : 0x%08lX\n", vsize);
// rt_printk("psize : 0x%08lX\n", psize);
if (filp->f_flags & O_SYNC)
{
// rt_printk("I/O-Mem");
vma->vm_flags |= VM_IO;
}
vma->vm_flags |= VM_RESERVED;
//if (vsize > psize) return -EINVAL; /* spans too high */
if(remap_page_range(vma->vm_start, physical, vsize, vma->vm_page_prot))
{
return -EAGAIN;
}
return(0);
}
Achim
^ permalink raw reply
* Re: How NEC uPD720101 USB chip work well on linux2.6.12
From: Stefan Nickl @ 2005-08-22 13:54 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050822122645.7AE6867FBD@ozlabs.org>
On Fri, 2005-07-22 at 20:26 +0800, JohnsonCheng wrote:
> Dear All,
> =20
>=20
> I use NEC uPD720101 USB chip, 2 OHCI and 1 EHCI, I also have turn on
> the following options in kernel menuconfig:
[...]
> [*] USB Support / EHCI HCD (USB 2.0) support
[...]
> =20
>=20
> But when I plug-in a USB mouse, then Kernel Oops=85.
>=20
> I use MPC8241 CPU, and there are three USB ports sharing the same IRQ
> on my borad.
I recently came across similar trouble with a chip from this series, the
uPD720113 and another one in a off-the-shelf USB hub which I tried for
reference.
It may have been even the 101, but I'm not sure.
Anyways, I've also seen hard resets with 2.6.12 to 2.6.13-rc-something,
albeit in a x86-environment. The system would reset hard when plugging
something after the hub or the hub itself, in case of the 113 it crashed
100% as soon as the hub was attached or detected during bootup. With the
off-the-shelf hub, it was somewhat more random.
In my case, disabling the EHCI controller in the BIOS helped, so you may
try to disable the USB "2.0" support in the kernel config and see what
happens.
No problems running the system with only UHCI for some weeks now.
I've deferred this problem because Hi-Speed is not an issue to me now,
but I'd be curious to hear and test things if somebody had a take on
this.
Regards,
--=20
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Wolfgang Denk @ 2005-08-22 13:48 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <4309D3CF.4030201@246tNt.com>
In message <4309D3CF.4030201@246tNt.com> you wrote:
>
> But I'm not sure including that into the Documentation/ directory is
> such a good idea. Changing documentation that's there requires sending
> patch to Linus and get it processed etc ... And since It's mostly
> reverse engineering, it's probably going to change often as we get a
> better understanding.
Documentation/ is the first place to look for Linux kernel
documentation, so it seems the best place for such stuff to me.
> We could publish it as a Wiki (that's a tendency these days ;) so that
> everyone can contribute easily and post code examples etc ... What do
> you think ?
This is a good idea for collecting the information, but IMHO the
document itself should go (too) to Documentation/
Just my $ 0.02
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
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
"That we but teach bloody instructions,
which, being taught, return to plague the inventor..."
^ permalink raw reply
* Re: [00/02] MPC5200 Bestcomm platform driver
From: Sylvain Munaut @ 2005-08-22 13:41 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <4300AF41.9000807@varma-el.com>
Andrey Volkov wrote:
>> - I never really liked to have multiple "type" of buffer descriptors
>>depending of the number of pointers in them. "standard" task have
>>either 1 or 2 pointers true but I have custom tasks with 3 so I need a
>>subtmitbuffer3 ... Not very extensible imho. I think there is no problem
>>as defining the descriptor structure with an array of pointer and then
>>just allocate the good size at init. Whoever use them must anyway know
>>the number of pointer to fill.
>
> Accepted. But I think it will be better to start from another end:
> allow everyone to create him/here self task (variable buffers number
> will consequence of that).
Sure, see my comments about your bestcomm microcode doc in my preceing mail.
>> - When I started to clean up bescomm a while ago, the only thing I
>>really got done was a rewrite of the SRAM allocator that supports the
>>freeing of block at little overcost. I'll try to find it and send it to you.
>
> I agree with you, sram_free is required function, especially if
> sdma-depended drivers will loaded/unloaded as modules. But I also agree
> with Dale's comments: What to do with fragmentations? I could lightly
> imagine situation, when after some load/unload iterations we receive
> ENOMEM :(.
Sure, fragmentation is a problem but there is no 'easy' way to prevent
that ... It's not perfet but better than nothing IMHO.
>> - I like the separation of phys/virt ;)
>
> I'd like it too :), but I had a pa/va headache when setting up
> task/var/inc tables, so everyone, who will write sdma related code must
> be very careful.
Anyway, they must be careful ;)
Bestcomm is like a very fragile balance between numerous task competing
for some dma transfers. Without caution, one will starve the others ...
Sylvain
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Sylvain Munaut @ 2005-08-22 13:31 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <4304CE06.6080202@varma-el.com>
Hi Andrey,
Andrey Volkov wrote:
> Hello Sylvain,
>
> This a draft of Documentation/powerpc/bestcomm.txt,
> it was born since I couldn't find DRD/LCD description and
> "... graphical task builder are currently in development"
> (quotation from AN2604) :(, so I try write doco by myself.
> Here result of my reverse engineering.
>
> If you or somebody have more information or found some
> bugs, please, fix/expand my text, especially places marked by "?".
First, yes, it's definitly a good idea to work on some documentation on
how to write microcode.
But I'm not sure including that into the Documentation/ directory is
such a good idea. Changing documentation that's there requires sending
patch to Linus and get it processed etc ... And since It's mostly
reverse engineering, it's probably going to change often as we get a
better understanding.
We could publish it as a Wiki (that's a tendency these days ;) so that
everyone can contribute easily and post code examples etc ... What do
you think ?
See comments below for the "real" comments ;)
> +All instructions of Bestcomm microcode are divided on
> +two main types: LCD (Loop Control Descriptor) and
> +DRD (Data Routing Descriptor). Any Task must started from
> +LCD[EX] instruction and finished by DRD instruction (usually NOP).
> +Each of instruction types, in one's turn, are divided on two
> +and three subtypes accordingly, which are described below:
> +
> +1) DRD1A - load/store data, and, optionally, made some operation
> +on it (depend on what loaded to FDT). Here is fields description
> +of this DRD:
> +
> +Bits num. Name Desc.
> +[31:29] Reserved, must be 0
Well yes, the 3 first bits indicate what type of descriptor it is ;-
> +[28:28] MORE ?????, if set then idx/var
> + dst/src fields are changed. I.e.
> + [16:10] contain SOURCE,
> + and [09:03] contain DESTINATION.
What I got for this bit is that if it's set that means the next DRD is
in the same LCD context, if not, it goes one LCD context before (like a
closing brace for a for loop } ).
> +[27:27] TFD Transfer Frame Done. Assert frame
> + done Transfer Frame Done line of
> + selected (in INIT field) periphery.
> +[26:26] INT Interrupt. If set to 1,
> + then generate core interrupt
Generate the core interrupt when the bestcomm engine exits the current
LCD. Don't know why it's part of the DRD descriptors and from what a
Freescale engineer told me, he doesn't know either ;)
> +[25:21] INIT Initiator (aka requestor) number.
> +[20:19] RS Read Size (0 - 32bit word, 1 - byte,
> + 2 - 16 bit word, 3 - dynamic/reserved??
> + (masked in real time?))
IIRC, there is a field in the SDMA registers to specify what 3 means.
However, the bestcomm api replace all the 3 with the correct size in the
ucode itself. That functionnality may not work or just isn't practical.
Best to have the correct size specified when running the task anyway.
> +[18:17] WS Write Size (see above)
> +[16:16] ??????????????
> +[15:15] Destination index prefix,
> + if set (i.e. =1), then bitfield [13:10]
> + contain index number, and [14:14] have
> + meaning of indirect addressing flag.
> + If this field cleared then field
> + [14:10] contain index of VARIABLE.
> +[14:14] Indirect addressing by idx,
> + (and only by idx) flag, or high bit of
> + variable index.
> +[13:10] index of DESTINATION/SOURCE idx/var.
> +
> +[09:09] ???? For some cases 1, for another 0.????
> +
> +[08:08] Same as in [14:10], but for source.
> +[07:03] Same as in [14:10], but for source.
> +[02:00] EU3 Number of function, which will execute
> + on EU#3.
[2:0] is FN but what do you exactly mean it is. The only thing I notice
is that if it =1 then the source is "EU3()" ... whatever that means.
Also, I'm not sure it has something to do with the FDT since there is
only 3 bits.
> +Note: For DRD1A exist special case, aka NOP, which act as
> +task terminator. Fields, in this case, have next meanings:
> +
> +[31:28] Reserved must be 0.
> +[27:27] TFD Transfer Frame Done.
> +[26:26] INT Interrupt.
> +[25:21] INIT Initiator (aka requestor) number. Usually 0,
> + or ALWAYS INITIATOR.
> +[16:00] NOP code Must be 0x1f8
Where did you see that that you could use theses bit in NOP ?
> +Ex. Please, pay attention to first two lines: since MORE is set,
> +codes for idx2 and var13 are in different fields, then for case
> +where MORE is not set (var4 = var2).:
> + 0x10601010 -- DRD1A: var4 = var2; FN=0 MORE init=3 WS=0 RS=0
> + 0x00008868 -- DRD1A: idx2 = var13; FN=0 init=0 WS=0 RS=0
> + 0x0404c999 -- DRD1A: *idx2 = EU3(); FN=1 INT init=0 WS=2 RS=0
> + 0x000001f8 -- DRD1A: NOP
> + 0x040001f8 -- DRD1A: INT init=0
> +
> +Next two DRDs are ALWAYS coupled, i.e it is impossible to using
> +DRD2B1 without preceded DRD2A, but any (?fixme?) number DRD2B1
> +may followed by DRD2A.
? AFAIU it's either
DRD2A, DRD2B1
or
DRD2A, DRDF2B2
> +2) DRD2A - setup bestcomm Execution Unit (EU)
> +Bitfields encodings:
> +
> +Bits num. Name Desc
> +[31:31] MORE ?????????
> +[30:29] EXT must be always initialized
> + by 3 (binary 11)
What I have is that
[31:29] Always 011 - Indicates a DRD2A.
[28:28] MORE - Same meaning as before. Just tells if the following
(here that's the one that is after the corresponding DRD2B{1,2}) DRD is
in the same loop or if it's in the previous loop level ?
> +[27:27] TFD Transfer Frame Done.
> +[26:21] INIT Initiator number.
> +[20:19] RS Read Size
> +[18:17] WS Write Size
> +[16:04] reserved, must be 0
They are the function number to use in EU#{0,1,2} but in MPC5200, only
EU3 is implemented.
> +[03:00] EU3 Number of function, which will execute
> + on EU#3 at DRD2B1 time.
> +Ex:
> + 0x60140002 -- DRD2A: EU3=2 EXT init=0 WS=2 RS=2
> +
> +3) DRD2B1 - execute function and store result of it.
Can't find the piece if paper where I wrote about DRD2B1 ...
For DRD2B2 there is only 1 example I know of, so quite hard to deduce
anything.
> +4) LCD - run followed loop microcode, or may be used for checking
> +some conditions. LCD may be nested (only two levels are supported).
Two levels ? Didn't know that but sure there is no example with 3 levels.
> +
> +Bits num. Name Desc
> +[31:31] LOOP Loop prefix, always 1
> +[30:30] ???????????????????
> +[29:23] INIT1 ???Initializition part of first init expression.???
> +[22:11] ???????????????????
> +[10:06] CMP_VAR Variable to which idx compared. Part of
> + Termination control.
> +[05:03] INC1 increment1
> +[02:00] INC2 increment2, if unsused may be any value
What I got :
bits[31:30] : 10 - identify a LCD
bit [29 ] : d - Whether to dereferentiate init_a or not. idx_a =
deref ? *(init_a) : init_a
bits[28:27] : ta - Type of init_a : 00 -> var
11 -> idx
bits[26:23] : ia - init_a : Where to find initial value for idx_a
bits[22:21] : ?? - Unknow
bits[20:19] : tb - Type of init_b
bits[18:15] : ib - init_b
bits[14:13] : cc - condition_choice : 00 - use idx_a
01 - use idx_b
11 - no condition
bits[12:11] : ?? - Unknow always 00
bits[10: 6] : ca - condition_arg : What to do the comparaison against
bits[ 5: 3] : sa - step_a : What inc[] to use to increment idx_a (and
also where to look for the condition code)
bits[ 2: 0] : sb - step_b
Condition codes (first 4 bits of the increments)
>= c
> 4
once 0
!= 6
<= a
< 2
> +5) LCDEXT - If in yours loop used more then 2 indexes, then
> +this record MUST PRECEDED LCD. Also loop end condition MAY pointed HERE,
> +then it not pointed in LCD.
> +
> +Bits num. Name Desc
> +[31:31] LOOP Loop prefix, always 1
> +[30:30] ???????????????????
> +[29:23] INIT1 ???Initializition part of first init expression.???
> +[22:11] ???????????????????
> +[10:06] CMP_VAR Variable to which idx compared. Part of
> + Termination control.
> +[05:03] INC1 increment1
> +[02:00] INC2 increment2, if unsused may be any value
similar to LCD
Sylvain
^ permalink raw reply
* Re: Linux Kernel MTD question
From: Wolfgang Denk @ 2005-08-22 13:07 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050822104924.214ED429CB@denx.de>
In message <20050822104924.214ED429CB@denx.de> you wrote:
>
> How can I put the Environment variables or configurations in
> 0x00060000-0x00080000, or put User Data in 0x005C0000-0x1000000?
> Use U-boot command? Or....
It is up to you to define a memory map for your flash device(s) and
create appropriate partitions for this map in Linux (and probably in
U-Boot, too, using the new "mtdparts" command).
Then you can use standard commands in U-Boot (erase, cp) and in Linux
(erase_all, cp) to store any data you likein your flash.
It is *your* design. *You* must create it.
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
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
^ permalink raw reply
* Re: [PATCH] ppc32: Big-endian I/O memory accessors.
From: Arthur Othieno @ 2005-08-22 12:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1124659361.5197.121.camel@gaston>
On Mon, Aug 22, 2005 at 07:22:41AM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2005-08-20 at 21:16 -0400, Arthur Othieno wrote:
> > I/O memory accessors. Big-endian version. For those busses/devices
> > that do export big-endian I/O memory.
>
> No, that's not correct. You need to use the in_be/out_be variants which
> provide proper memory barriers.
>
> Ben.
Oops. Silly me. Updated patch inline.
Signed-Off-By: Arthur Othieno <a.othieno@bluewin.ch>
io.h | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+)
diff -uprN a/include/asm-ppc/io.h b/include/asm-ppc/io.h
--- a/include/asm-ppc/io.h 2005-08-21 17:49:44.000000000 -0400
+++ b/include/asm-ppc/io.h 2005-08-21 20:29:55.000000000 -0400
@@ -487,11 +487,21 @@ static inline unsigned int ioread16(void
return readw(addr);
}
+static inline unsigned int ioread16be(void __iomem *addr)
+{
+ return in_be16(addr);
+}
+
static inline unsigned int ioread32(void __iomem *addr)
{
return readl(addr);
}
+static inline unsigned int ioread32be(void __iomem *addr)
+{
+ return in_be32(addr);
+}
+
static inline void iowrite8(u8 val, void __iomem *addr)
{
writeb(val, addr);
@@ -502,11 +512,21 @@ static inline void iowrite16(u16 val, vo
writew(val, addr);
}
+static inline void iowrite16be(u16 val, void __iomem *addr)
+{
+ out_be16(addr, val);
+}
+
static inline void iowrite32(u32 val, void __iomem *addr)
{
writel(val, addr);
}
+static inline void iowrite32be(u32 val, void __iomem *addr)
+{
+ out_be32(addr, val);
+}
+
static inline void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
{
_insb(addr, dst, count);
^ permalink raw reply
* How NEC uPD720101 USB chip work well on linux2.6.12
From: JohnsonCheng @ 2005-08-22 12:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
Dear All,
I use NEC uPD720101 USB chip, 2 OHCI and 1 EHCI, I also have turn on the
following options in kernel menuconfig:
[*] USB Support / support for Host-side USB
[*] USB Support / USB device filesystem
[*] USB Support / EHCI HCD (USB 2.0) support
[*] USB Support / OHCI HCD support
[*] USB Support / USB HID Boot Protocol drivers / USB HIDBP Mouse (simple
Boot) support
But when I plug-in a USB mouse, then Kernel Oops..
I use MPC8241 CPU, and there are three USB ports sharing the same IRQ on my
borad.
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 3937 bytes --]
^ permalink raw reply
* RE: Linux Kernel MTD question
From: JohnsonCheng @ 2005-08-22 10:46 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: linuxppc-embedded
In-Reply-To: <20050822081708.74890352B0C@atlas.denx.de>
I have browsed the website, http://www.denx.de/twiki/bin/view/DULG/Manual.
For this example:
0x00000000-0x00060000 : "U-Boot"
0x00060000-0x00080000 : "Environment 1"
0x00080000-0x000A0000 : "Environment 2"
0x000A0000-0x000C0000 : "ASIC Images"
0x000C0000-0x001C0000 : "Linux Kernel"
0x001C0000-0x005C0000 : "Ramdisk Image"
0x005C0000-0x01000000 : "User Data"
How can I put the Environment variables or configurations in
0x00060000-0x00080000, or put User Data in 0x005C0000-0x1000000?
Use U-boot command? Or....
Best Regards,
Johnson Cheng
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Wolfgang Denk
Sent: Monday, August 22, 2005 4:17 PM
To: JohnsonCheng
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux Kernel MTD question
In message <20050822030032.4917442C7E@denx.de> you wrote:
>
> Actually, the range of my flash is from 0xFF000000 to 0xFFFFFFFF. My
> starting address of Kernel is 0xFF000000, and the starting address of
> ramdisk image is FF200000, so the partitions is as following:
> 0xFF000000 - 0xFF1FFFFF Kernel
> 0xFF200000 - 0xFF9FFFFF RamDisk Image ( also my Root File
System )
>
> And I found my RootFS image is so big that waste many time while write it
to
> flash.
Then avoid writing it that often. Use a more efficient setup for
developoment and test, like root file system mounted over NFS.
> I hope I can use MTD to distribute it into two parts, Simple RootFS and
> libraries, but I don't know how to implement it?
You can use MTD to provide an additional file system which can then
be mounted by one of your startup scripts. MTD configuration and file
system building is documented in the DULG, please see
http://www.denx.de/twiki/bin/view/DULG/Manual
It is not possible to give good advice how to split data into
separate file systems, or how exactly you can mount it without
precise knowledge of your system and it's requirements. For example,
do you use a SysV init with several run levels, or a simple setup for
example based on busybox? In the end this is something which you have
to design yourself.
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
Let the programmers be many and the managers few -- then all will be
productive. -- Geoffrey James, "The Tao of Programming"
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* mpc8247 restart
From: Mike Rapoport @ 2005-08-22 10:54 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi all,
I have a custom board based on mpc8247. I use u-boot-1.1.3 and linux
2.6.12.3. Each time there is some critical exception and the kernel
tries to reset the machine, I get machine check exception instead of
jumping to the u-boot code. What can be a reason of this?
The u-boot is in flash at offset 0x300000 from the flash start, the
flash is mapped to 0xff800000 and I set the BOOTROM_RESTART_ADDR to
0xffb00110.
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Víagrra Really Works Wonder
From: wfctwcw_98_bp5ucz @ 2005-08-22 9:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 2086 bytes --]
^ permalink raw reply
* MPC5200 mmap, ioremap
From: Kunkel, Ulrich @ 2005-08-22 8:47 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]
Hello,
I am using a Motorola PPC Hardware (MPC5200) with linux kernel 2.4.25 and 32
MB RAM.
I would like to map a large contiguous kernel memory buffer (6 MB) into
user space with mmap and remap_page_range. For this action I reserved memory
at the end of the phyiscal memory at boot time. (Kernel boot option mem =12
M) Now, the kernel only knows about 20 MB of memory. The high_memory border
is at 0x1400000 (physical address).
I have to do a ioremap() on the high_memory (0x1400000) to map the high
physical memory into a virtual kernel memory.
ioremap_ptr = ioremap_nocache (__pa(high_memory), 6*1024*1024); //6 MB
ioremap_ptr is a virtual kernel address.
Now I do a mem_map_reserve () on every page in this memory block.
On the ioremap ptr I do a memset to check the data in user space later.
memset(ioremap_ptr, 0xAB, 6*1024*1024);
With bdi2000 I looked to the memory values at 0x1400000 and everything is
ok, I see 0xABABABAB.
If I do a virt_to_phys() on ioremap_ptr, I get a really strange address. I
expected to get the physical address 0x1400000.
Example:
__pa(high_memory): 0x1400000
ioremap_ptr: 0xc22a4000
virt_to_phys(ioremap_ptr): 0x22a4000
virt_to_bus(ioremap_ptr): 0x22a4000
Now I want to map the buffer into to user space with mmap and
remap_page_range.
static int mmmap (struct file *file, struct vm_area_struct *vma)
{
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int error;
unsigned long start = (unsigned long)vma->vm_start;
unsigned long size = (unsigned long)(vma->vm_end - vma->vm_start);
if (offset != 0)
{
printk ("rt_iso1394_mmap: invalid offset: must be 0\n");
return -ENXIO;
}
if(size == PAGE_ALIGN(6*1024*1024)
{
start,virt_to_phys(shared_buffer_ptr), size, protect);
error = remap_page_range (vma->vm_start, 0x1400000 , size, PAGE_SHARED);
if (error)
{
printk ("rt_iso1394_mmap: remap_page_range failed\n");
return -EAGAIN;
}
}
else
{
printk ("rt_iso1394_mmap: invalid mmap size, size is: %d\n", (int) size);
return -EAGAIN;
}
return 0;
}
The function returned with no errors.
If I call mmap () in user space, the function returnes a virtual user
address. But if do a read on this memory, I don't see the data I have
written in the kernel data block in kernel space. I only get zeros. It seems
that remap_page_range maps a completely different data block.
Are the any ideas to solve the problem? What I am doing wrong? What is
missing? Where ist the problem with the addresses???
Thanks for your help
Ulrich Kunkel
Hottinger Baldwin Messtechnik GmbH
[-- Attachment #2: Type: text/html, Size: 13418 bytes --]
^ permalink raw reply
* Re: Linux Kernel MTD question
From: Wolfgang Denk @ 2005-08-22 8:17 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050822030032.4917442C7E@denx.de>
In message <20050822030032.4917442C7E@denx.de> you wrote:
>
> Actually, the range of my flash is from 0xFF000000 to 0xFFFFFFFF. My
> starting address of Kernel is 0xFF000000, and the starting address of
> ramdisk image is FF200000, so the partitions is as following:
> 0xFF000000 - 0xFF1FFFFF Kernel
> 0xFF200000 - 0xFF9FFFFF RamDisk Image ( also my Root File System )
>
> And I found my RootFS image is so big that waste many time while write it to
> flash.
Then avoid writing it that often. Use a more efficient setup for
developoment and test, like root file system mounted over NFS.
> I hope I can use MTD to distribute it into two parts, Simple RootFS and
> libraries, but I don't know how to implement it?
You can use MTD to provide an additional file system which can then
be mounted by one of your startup scripts. MTD configuration and file
system building is documented in the DULG, please see
http://www.denx.de/twiki/bin/view/DULG/Manual
It is not possible to give good advice how to split data into
separate file systems, or how exactly you can mount it without
precise knowledge of your system and it's requirements. For example,
do you use a SysV init with several run levels, or a simple setup for
example based on busybox? In the end this is something which you have
to design yourself.
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
Let the programmers be many and the managers few -- then all will be
productive. -- Geoffrey James, "The Tao of Programming"
^ permalink raw reply
* [PATCH 3/3] Move all the very similar files
From: Stephen Rothwell @ 2005-08-22 6:10 UTC (permalink / raw)
To: ppc64-dev
In-Reply-To: <20050822160519.51d065fe.sfr@canb.auug.org.au>
This moves all the very similar files - either the ppc64 file included
the ppc file or they differed in simple comments.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
This patch is too large for the list, so it is available at
http://ozlabs.org/~sfr/0003-This-moves-all-the-very-similar-files-either-the-ppc64-file-included.txt
include/asm-powerpc/dbdma.h | 102 ++++++++++
include/asm-powerpc/errno.h | 11 +
include/asm-powerpc/ioctl.h | 69 +++++++
include/asm-powerpc/ioctls.h | 107 ++++++++++
include/asm-powerpc/keylargo.h | 248 ++++++++++++++++++++++++
include/asm-powerpc/local.h | 1
include/asm-powerpc/macio.h | 141 +++++++++++++
include/asm-powerpc/namei.h | 20 ++
include/asm-powerpc/of_device.h | 62 ++++++
include/asm-powerpc/parport.h | 18 ++
include/asm-powerpc/percpu.h | 1
include/asm-powerpc/pmac_feature.h | 379 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/pmac_low_i2c.h | 43 ++++
include/asm-powerpc/poll.h | 23 ++
include/asm-powerpc/resource.h | 1
include/asm-powerpc/shmparam.h | 6 +
include/asm-powerpc/string.h | 32 +++
include/asm-powerpc/unaligned.h | 18 ++
include/asm-powerpc/uninorth.h | 229 ++++++++++++++++++++++
include/asm-ppc/dbdma.h | 102 ----------
include/asm-ppc/errno.h | 11 -
include/asm-ppc/ioctl.h | 69 -------
include/asm-ppc/ioctls.h | 107 ----------
include/asm-ppc/keylargo.h | 248 ------------------------
include/asm-ppc/local.h | 6 -
include/asm-ppc/macio.h | 141 -------------
include/asm-ppc/namei.h | 20 --
include/asm-ppc/of_device.h | 62 ------
include/asm-ppc/parport.h | 18 --
include/asm-ppc/percpu.h | 6 -
include/asm-ppc/pmac_feature.h | 379 ------------------------------------
include/asm-ppc/pmac_low_i2c.h | 43 ----
include/asm-ppc/poll.h | 23 --
include/asm-ppc/resource.h | 6 -
include/asm-ppc/shmparam.h | 6 -
include/asm-ppc/string.h | 32 ---
include/asm-ppc/unaligned.h | 18 --
include/asm-ppc/uninorth.h | 229 ----------------------
include/asm-ppc64/dbdma.h | 2
include/asm-ppc64/errno.h | 18 --
include/asm-ppc64/ioctl.h | 74 -------
include/asm-ppc64/ioctls.h | 114 -----------
include/asm-ppc64/keylargo.h | 2
include/asm-ppc64/local.h | 1
include/asm-ppc64/macio.h | 2
include/asm-ppc64/namei.h | 23 --
include/asm-ppc64/of_device.h | 2
include/asm-ppc64/parport.h | 18 --
include/asm-ppc64/percpu.h | 6 -
include/asm-ppc64/pmac_feature.h | 2
include/asm-ppc64/pmac_low_i2c.h | 2
include/asm-ppc64/poll.h | 32 ---
include/asm-ppc64/resource.h | 6 -
include/asm-ppc64/shmparam.h | 13 -
include/asm-ppc64/string.h | 35 ---
include/asm-ppc64/unaligned.h | 21 --
include/asm-ppc64/uninorth.h | 2
57 files changed, 1511 insertions(+), 1901 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* [PATCH 2/3] Move the identical files from include/asm-ppc{,64}
From: Stephen Rothwell @ 2005-08-22 6:05 UTC (permalink / raw)
To: ppc64-dev
In-Reply-To: <20050822160254.2dc59b25.sfr@canb.auug.org.au>
Move the identical files from include/asm-ppc{,64}/ to
include/asm-powerpc/. Remove hdreg.h completely as it is unused in
the tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/8253pit.h | 10 ++++++++++
include/asm-powerpc/agp.h | 23 +++++++++++++++++++++++
include/asm-powerpc/cputime.h | 1 +
include/asm-powerpc/div64.h | 1 +
include/asm-powerpc/emergency-restart.h | 1 +
include/asm-powerpc/ipc.h | 1 +
include/asm-powerpc/xor.h | 1 +
include/asm-ppc/8253pit.h | 10 ----------
include/asm-ppc/agp.h | 23 -----------------------
include/asm-ppc/cputime.h | 6 ------
include/asm-ppc/div64.h | 1 -
include/asm-ppc/emergency-restart.h | 6 ------
include/asm-ppc/hdreg.h | 1 -
include/asm-ppc/ipc.h | 1 -
include/asm-ppc/xor.h | 1 -
include/asm-ppc64/8253pit.h | 10 ----------
include/asm-ppc64/agp.h | 23 -----------------------
include/asm-ppc64/cputime.h | 6 ------
include/asm-ppc64/div64.h | 1 -
include/asm-ppc64/emergency-restart.h | 6 ------
include/asm-ppc64/hdreg.h | 1 -
include/asm-ppc64/ipc.h | 1 -
include/asm-ppc64/xor.h | 1 -
23 files changed, 38 insertions(+), 98 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/include/asm-powerpc/8253pit.h b/include/asm-powerpc/8253pit.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/8253pit.h
@@ -0,0 +1,10 @@
+/*
+ * 8253/8254 Programmable Interval Timer
+ */
+
+#ifndef _8253PIT_H
+#define _8253PIT_H
+
+#define PIT_TICK_RATE 1193182UL
+
+#endif
diff --git a/include/asm-powerpc/agp.h b/include/asm-powerpc/agp.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/agp.h
@@ -0,0 +1,23 @@
+#ifndef AGP_H
+#define AGP_H 1
+
+#include <asm/io.h>
+
+/* nothing much needed here */
+
+#define map_page_into_agp(page)
+#define unmap_page_from_agp(page)
+#define flush_agp_mappings()
+#define flush_agp_cache() mb()
+
+/* Convert a physical address to an address suitable for the GART. */
+#define phys_to_gart(x) (x)
+#define gart_to_phys(x) (x)
+
+/* GATT allocation. Returns/accepts GATT kernel virtual address. */
+#define alloc_gatt_pages(order) \
+ ((char *)__get_free_pages(GFP_KERNEL, (order)))
+#define free_gatt_pages(table, order) \
+ free_pages((unsigned long)(table), (order))
+
+#endif
diff --git a/include/asm-powerpc/cputime.h b/include/asm-powerpc/cputime.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/cputime.h
@@ -0,0 +1 @@
+#include <asm-generic/cputime.h>
diff --git a/include/asm-powerpc/div64.h b/include/asm-powerpc/div64.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/div64.h
@@ -0,0 +1 @@
+#include <asm-generic/div64.h>
diff --git a/include/asm-powerpc/emergency-restart.h b/include/asm-powerpc/emergency-restart.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/emergency-restart.h
@@ -0,0 +1 @@
+#include <asm-generic/emergency-restart.h>
diff --git a/include/asm-powerpc/ipc.h b/include/asm-powerpc/ipc.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/ipc.h
@@ -0,0 +1 @@
+#include <asm-generic/ipc.h>
diff --git a/include/asm-powerpc/xor.h b/include/asm-powerpc/xor.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/xor.h
@@ -0,0 +1 @@
+#include <asm-generic/xor.h>
diff --git a/include/asm-ppc/8253pit.h b/include/asm-ppc/8253pit.h
deleted file mode 100644
--- a/include/asm-ppc/8253pit.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
-
-#ifndef _8253PIT_H
-#define _8253PIT_H
-
-#define PIT_TICK_RATE 1193182UL
-
-#endif
diff --git a/include/asm-ppc/agp.h b/include/asm-ppc/agp.h
deleted file mode 100644
--- a/include/asm-ppc/agp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-#ifndef AGP_H
-#define AGP_H 1
-
-#include <asm/io.h>
-
-/* nothing much needed here */
-
-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
-#define flush_agp_mappings()
-#define flush_agp_cache() mb()
-
-/* Convert a physical address to an address suitable for the GART. */
-#define phys_to_gart(x) (x)
-#define gart_to_phys(x) (x)
-
-/* GATT allocation. Returns/accepts GATT kernel virtual address. */
-#define alloc_gatt_pages(order) \
- ((char *)__get_free_pages(GFP_KERNEL, (order)))
-#define free_gatt_pages(table, order) \
- free_pages((unsigned long)(table), (order))
-
-#endif
diff --git a/include/asm-ppc/cputime.h b/include/asm-ppc/cputime.h
deleted file mode 100644
--- a/include/asm-ppc/cputime.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __PPC_CPUTIME_H
-#define __PPC_CPUTIME_H
-
-#include <asm-generic/cputime.h>
-
-#endif /* __PPC_CPUTIME_H */
diff --git a/include/asm-ppc/div64.h b/include/asm-ppc/div64.h
deleted file mode 100644
--- a/include/asm-ppc/div64.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/div64.h>
diff --git a/include/asm-ppc/emergency-restart.h b/include/asm-ppc/emergency-restart.h
deleted file mode 100644
--- a/include/asm-ppc/emergency-restart.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_EMERGENCY_RESTART_H
-#define _ASM_EMERGENCY_RESTART_H
-
-#include <asm-generic/emergency-restart.h>
-
-#endif /* _ASM_EMERGENCY_RESTART_H */
diff --git a/include/asm-ppc/hdreg.h b/include/asm-ppc/hdreg.h
deleted file mode 100644
--- a/include/asm-ppc/hdreg.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/hdreg.h>
diff --git a/include/asm-ppc/ipc.h b/include/asm-ppc/ipc.h
deleted file mode 100644
--- a/include/asm-ppc/ipc.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/ipc.h>
diff --git a/include/asm-ppc/xor.h b/include/asm-ppc/xor.h
deleted file mode 100644
--- a/include/asm-ppc/xor.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/xor.h>
diff --git a/include/asm-ppc64/8253pit.h b/include/asm-ppc64/8253pit.h
deleted file mode 100644
--- a/include/asm-ppc64/8253pit.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/*
- * 8253/8254 Programmable Interval Timer
- */
-
-#ifndef _8253PIT_H
-#define _8253PIT_H
-
-#define PIT_TICK_RATE 1193182UL
-
-#endif
diff --git a/include/asm-ppc64/agp.h b/include/asm-ppc64/agp.h
deleted file mode 100644
--- a/include/asm-ppc64/agp.h
+++ /dev/null
@@ -1,23 +0,0 @@
-#ifndef AGP_H
-#define AGP_H 1
-
-#include <asm/io.h>
-
-/* nothing much needed here */
-
-#define map_page_into_agp(page)
-#define unmap_page_from_agp(page)
-#define flush_agp_mappings()
-#define flush_agp_cache() mb()
-
-/* Convert a physical address to an address suitable for the GART. */
-#define phys_to_gart(x) (x)
-#define gart_to_phys(x) (x)
-
-/* GATT allocation. Returns/accepts GATT kernel virtual address. */
-#define alloc_gatt_pages(order) \
- ((char *)__get_free_pages(GFP_KERNEL, (order)))
-#define free_gatt_pages(table, order) \
- free_pages((unsigned long)(table), (order))
-
-#endif
diff --git a/include/asm-ppc64/cputime.h b/include/asm-ppc64/cputime.h
deleted file mode 100644
--- a/include/asm-ppc64/cputime.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __PPC_CPUTIME_H
-#define __PPC_CPUTIME_H
-
-#include <asm-generic/cputime.h>
-
-#endif /* __PPC_CPUTIME_H */
diff --git a/include/asm-ppc64/div64.h b/include/asm-ppc64/div64.h
deleted file mode 100644
--- a/include/asm-ppc64/div64.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/div64.h>
diff --git a/include/asm-ppc64/emergency-restart.h b/include/asm-ppc64/emergency-restart.h
deleted file mode 100644
--- a/include/asm-ppc64/emergency-restart.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _ASM_EMERGENCY_RESTART_H
-#define _ASM_EMERGENCY_RESTART_H
-
-#include <asm-generic/emergency-restart.h>
-
-#endif /* _ASM_EMERGENCY_RESTART_H */
diff --git a/include/asm-ppc64/hdreg.h b/include/asm-ppc64/hdreg.h
deleted file mode 100644
--- a/include/asm-ppc64/hdreg.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/hdreg.h>
diff --git a/include/asm-ppc64/ipc.h b/include/asm-ppc64/ipc.h
deleted file mode 100644
--- a/include/asm-ppc64/ipc.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/ipc.h>
diff --git a/include/asm-ppc64/xor.h b/include/asm-ppc64/xor.h
deleted file mode 100644
--- a/include/asm-ppc64/xor.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <asm-generic/xor.h>
^ permalink raw reply
* [PATCH 1/3] Create include/asm-powerpc
From: Stephen Rothwell @ 2005-08-22 6:02 UTC (permalink / raw)
To: ppc64-dev
Hopefully, we can gree to start like this ...
Create include/asm-powerpc (and move linkage.h into it since we don't
like empty directories). Modify the Makefiles to cope.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/ppc/Makefile | 11 ++++++++++-
arch/ppc64/Makefile | 9 +++++++++
include/asm-powerpc/linkage.h | 6 ++++++
include/asm-ppc/linkage.h | 6 ------
include/asm-ppc64/linkage.h | 6 ------
5 files changed, 25 insertions(+), 13 deletions(-)
create mode 100644 include/asm-powerpc/linkage.h
delete mode 100644 include/asm-ppc/linkage.h
delete mode 100644 include/asm-ppc64/linkage.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile
+++ b/arch/ppc/Makefile
@@ -21,11 +21,13 @@ CC := $(CC) -m32
endif
LDFLAGS_vmlinux := -Ttext $(KERNELLOAD) -Bstatic
-CPPFLAGS += -Iarch/$(ARCH)
+CPPFLAGS += -Iarch/$(ARCH) -Iinclude3
AFLAGS += -Iarch/$(ARCH)
CFLAGS += -Iarch/$(ARCH) -msoft-float -pipe \
-ffixed-r2 -mmultiple
CPP = $(CC) -E $(CFLAGS)
+# Temporary hack until we have migrated to asm-powerpc
+LINUXINCLUDE += -Iinclude3
CHECKFLAGS += -D__powerpc__
@@ -101,6 +103,7 @@ endef
archclean:
$(Q)$(MAKE) $(clean)=arch/ppc/boot
+ $(Q)rm -rf include3
prepare: include/asm-$(ARCH)/offsets.h checkbin
@@ -110,6 +113,12 @@ arch/$(ARCH)/kernel/asm-offsets.s: inclu
include/asm-$(ARCH)/offsets.h: arch/$(ARCH)/kernel/asm-offsets.s
$(call filechk,gen-asm-offsets)
+# Temporary hack until we have migrated to asm-powerpc
+include/asm: include3/asm
+include3/asm:
+ $(Q)if [ ! -d include3 ]; then mkdir -p include3; fi
+ $(Q)ln -fsn $(srctree)/include/asm-powerpc include3/asm
+
# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
# to stdout and these checks are run even on install targets.
TOUT := .tmp_gas_check
diff --git a/arch/ppc64/Makefile b/arch/ppc64/Makefile
--- a/arch/ppc64/Makefile
+++ b/arch/ppc64/Makefile
@@ -55,6 +55,8 @@ LDFLAGS := -m elf64ppc
LDFLAGS_vmlinux := -Bstatic -e $(KERNELLOAD) -Ttext $(KERNELLOAD)
CFLAGS += -msoft-float -pipe -mminimal-toc -mtraceback=none \
-mcall-aixdesc
+# Temporary hack until we have migrated to asm-powerpc
+CPPFLAGS += -Iinclude3
GCC_VERSION := $(call cc-version)
GCC_BROKEN_VEC := $(shell if [ $(GCC_VERSION) -lt 0400 ] ; then echo "y"; fi ;)
@@ -112,6 +114,7 @@ all: $(KBUILD_IMAGE)
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
+ $(Q)rm -rf include3
prepare: include/asm-ppc64/offsets.h
@@ -121,6 +124,12 @@ arch/ppc64/kernel/asm-offsets.s: include
include/asm-ppc64/offsets.h: arch/ppc64/kernel/asm-offsets.s
$(call filechk,gen-asm-offsets)
+# Temporary hack until we have migrated to asm-powerpc
+include/asm: include3/asm
+include3/asm:
+ $(Q)if [ ! -d include3 ]; then mkdir -p include3; fi;
+ $(Q)ln -fsn $(srctree)/include/asm-powerpc include3/asm
+
define archhelp
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' zImage.initrd- Compressed kernel image with initrd attached,'
diff --git a/include/asm-powerpc/linkage.h b/include/asm-powerpc/linkage.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/linkage.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+/* Nothing to see here... */
+
+#endif
diff --git a/include/asm-ppc/linkage.h b/include/asm-ppc/linkage.h
deleted file mode 100644
--- a/include/asm-ppc/linkage.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-/* Nothing to see here... */
-
-#endif
diff --git a/include/asm-ppc64/linkage.h b/include/asm-ppc64/linkage.h
deleted file mode 100644
--- a/include/asm-ppc64/linkage.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-/* Nothing to see here... */
-
-#endif
^ permalink raw reply
* Re: [PATCH] cpm_uart: Fix dpram allocation and non-console uarts
From: Nishanth Aravamudan @ 2005-08-22 4:14 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Andrew Morton, Kumar Gala, Nish Aravamudan, linux-kernel,
linuxppc-embedded
In-Reply-To: <20050821211235.GD6746@dmt.cnet>
On 21.08.2005 [18:12:35 -0300], Marcelo Tosatti wrote:
> Hi,
>
> On Wed, Aug 17, 2005 at 10:42:36PM -0700, Nish Aravamudan wrote:
> > On 8/8/05, Kumar Gala <galak@freescale.com> wrote:
> > > (A believe Marcelo would like to see this in 2.6.13, but I'll let him
> > > fight over that ;)
> > >
> > > * Makes dpram allocations work
> > > * Makes non-console UART work on both 8xx and 82xx
> > > * Fixed whitespace in files that were touched
> > >
> > > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > > Signed-off-by: Pantelis Antoniou <panto@intracom.gr>
> > > Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> > >
> > > ---
> > > commit 1de80554bcae877dce3b6d878053eb092ef65c72
> > > tree aba124824607fea1070e86501ddccc9decce362d
> > > parent ad81111fd554c9d3c14c0a50885e076af2f9ac9b
> > > author Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> > > committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 08 Aug 2005 22:35:39 -0500
> >
> > <snip>
> >
> > > diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> > > --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> > > +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> >
> > <snip>
> >
> > > @@ -376,9 +396,19 @@ static int cpm_uart_startup(struct uart_
> > > pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> > > }
> > >
> > > + if (!(pinfo->flags & FLAG_CONSOLE))
> > > + cpm_line_cr_cmd(line,CPM_CR_INIT_TRX);
> > > return 0;
> > > }
> > >
> > > +inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> > > +{
> > > + unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> > > +
> > > + while (!time_after(jiffies, target_jiffies))
> > > + schedule();
> > > +}
> >
> > Not sure about that call here. Does the state need to be set so that
> > you won't be run again immediately? In any case, I think direct
> > schedule() callers are discouraged? Do you want to call a yield() or
> > schedule_timeout({0,1}) instead maybe?
>
> Yep, schedule_timeout(pinfo->wait_closing) looks much better.
>
> > > /*
> > > * Shutdown the uart
> > > */
> > > @@ -394,6 +424,12 @@ static void cpm_uart_shutdown(struct uar
> > >
> > > /* If the port is not the console, disable Rx and Tx. */
> > > if (!(pinfo->flags & FLAG_CONSOLE)) {
> > > + /* Wait for all the BDs marked sent */
> > > + while(!cpm_uart_tx_empty(port))
> > > + schedule_timeout(2);
> >
> > <snip>
> >
> > I think you are using 2 jiffies to guarantee that at least one jiffy
> > elapses, which is fine. But, if you do not set the state beforehand,
> > schedule_timeout() returns immediately, so you have a busy-wait here.
>
> Right, what about the following untested patch.
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -403,10 +403,9 @@ static int cpm_uart_startup(struct uart_
>
> inline void cpm_uart_wait_until_send(struct uart_cpm_port *pinfo)
> {
> - unsigned long target_jiffies = jiffies + pinfo->wait_closing;
> -
> - while (!time_after(jiffies, target_jiffies))
> - schedule();
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_timeout(pinfo->wait_closing);
> + set_current_state(TASK_RUNNING);
> }
Both changes look correct/better. Except you shouldn't need to set the
state back to TASK_RUNNING in either case, as schedule_timeout()
guarantees the task will return in that state.
Thanks,
Nish
^ permalink raw reply
* RE: Linux Kernel MTD question
From: JohnsonCheng @ 2005-08-22 2:56 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: linuxppc-embedded
In-Reply-To: <20050821205851.66E52353D18@atlas.denx.de>
Very Thanks for your reply.
I am sorry that this data is copied from Building Embedded Linux Systems
book.
Actually, the range of my flash is from 0xFF000000 to 0xFFFFFFFF. My
starting address of Kernel is 0xFF000000, and the starting address of
ramdisk image is FF200000, so the partitions is as following:
0xFF000000 - 0xFF1FFFFF Kernel
0xFF200000 - 0xFF9FFFFF RamDisk Image ( also my Root File System )
And I found my RootFS image is so big that waste many time while write it to
flash.
I hope I can use MTD to distribute it into two parts, Simple RootFS and
libraries, but I don't know how to implement it?
My CPU is MPC8241, and my kernel configure is base on Sandpoint_defconfig.
Thanks,
Johnson Cheng
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Wolfgang Denk
Sent: Monday, August 22, 2005 4:59 AM
To: JohnsonCheng
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux Kernel MTD question
In message <20050821080936.DA55167F92@ozlabs.org> you wrote:
>
> Just as I know, we can have many partitions for our flash if we turn on
MTD
> in Kernel. For example:
Right.
> How could I distribute my RootFS into initrd1 and initrd2?
You cannot. The *root* filesystem is always just a single file system.
You can mount additional file systems on top of the directory
hierarchy provided by your root file system, but this is something
completely different.
> In U-Boot command, bootcmd, I set it to "bootm 40000 100000". 40000 is
> Kernel address, and 100000 is RootFS1 address. But where to set RootRS2
> address?
There are several errors in this text.
First, the kernel download address 0x40000 = 256kB is much too low
and can never work.
Second, the "100000" parameter is not a "RootFS1 address". It is the
start address of a ramdisk image. This may or may not be your root
file system, and it is usually NOT the address as seen by the kernel.
And, 100000 = 1 MB is a much too low address and can never work.
And finally: all this has absolutely NOTHING to do with MTD partitions.
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
Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing. - Dick Brandon
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx pq platform system descriptions
From: Dan Malek @ 2005-08-22 1:28 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <20050821235524.GE6746@dmt.cnet>
On Aug 21, 2005, at 7:55 PM, Marcelo Tosatti wrote:
> - Do you have any plans on actually using device model information by
> drivers (as was done in the mpc8xxx/gianfar) on m8xx? Its not very
> clear
> to me what are the the practical advantages of that?
It may be nice if we can do that. We have to be careful about sharing
CPM drivers between the 8xx and CPM2 (82xx/83xx/85xx). It's tempting,
but I still believe the differences outweigh the similarities. The
overhead
of trying to use common drivers would be quite costly on the 8xx.
> - I don't know whether its possible to retrieve 8xx CPUID information
> (if there is any). Can't find anything in the manual.
We really can't. The PVR only represents the processor core
information,
and for the most part they are all the same. It used to be we could use
the CPM microcode version, but these are now nearly the same. Some
attempts have been made to probe for CPM peripherals that don't exist,
but it seems on some parts the CPM is the same and the signals just
aren't
bonded out of the chip.
For the most part, the person doing the kernel configuration just simply
has to know what part they are using. You have to select the proper
peripherals, and you need the board support for the IO pin routing.
In an embedded environment where resources still need to be
carefully managed, I don't think this is unrealistic.
Thanks.
-- Dan
^ 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