Platform device style question

[Vitaly Bordug]

On Thu, 24 Aug 2006 13:53:17 -0400
Ben Warren  wrote:

> Hello,
> 
> A 'newbie-to-platform-devices' question:
> 
> In a patch that Kumar just sent for a compact flash device, the resource
> data (I/O addresses, IRQ # etc.) are retrieved from the platform system.
> I guess I can either modify the device tree in U-boot by adding
> additional nodes, or instantiate a platform device in Linux __init code
> based on static information.  The former gives the advantage of having
> the bootloader pass the info to the OS.  (Somebody please correct me if
> I'm off-base here!)  
> 
I'd suggest to make a look at LDD concerning linux device model...
For platform device, there's no need to cope with u-boot at all. You'll prolly 
need to 
register the respective platform device from the board-specific code, with 
proper name 
and driver's board-specific platform info. You may have a look at 
arch/ppc/syslib/ppc_sys.c about static
PD definitions usage.


> Are device trees meant to only contain information about the CPU and
> tightly-coupled peripherals, or is it considered OK-form to also include
> board-level hardware info?  I guess they can really hold anything, but
> I'm trying to figure out the original intent.
> 
I'd make sense to figure out the platform device bus before digging into device 
trees. It's slightly 
different stuff, for similar aim, but anyway... Actually you do not strictly 
need devtree to cope with 
your case afaiu.

> regards,
> Ben
> 
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 


-- 
Sincerely, 
Vitaly

communication with i2c client

[Frank]

--- Ladislav Klenovi?  wrote:

> Hi,
> I've create an i2c client and my questions is how to access it
> from userspace. This client is sitttng on adapter that  I was
> able to access via /dev interface. After the client were
> successfuly loaded and detected,
> ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work
> and  error messages like "device busy" or "ioctl error" have
> occured. Also my debug messages from i2c client didn't arise
> when I am accessing 
> device only adapter's.
> How to (standardly) access a an i2c client? 
> Do I need to create an ioctl interface or exports some helper
> function for access it from user space and also from kernel
> space?  
> 
> regards,
> Ladislav.

You might get an answer here:
http://www.lm-sensors.org/

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

I2C driver for SAA7121 on MPC855 and linux-2.4.25

[Li Yang-r58472]

> -Original Message-
> From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
Behalf Of
> Xu, Li (GE, Research)
> Sent: Thursday, August 24, 2006 4:02 PM
> To: linuxppc-embedded at ozlabs.org
> Subject: I2C driver for SAA7121 on MPC855 and linux-2.4.25
> 
> Hi,
> 
> I am trying to setup i2c driver for saa7121 on my mpc855 based board
> normally the address for saa7121 is 0x88, but when I enable i2c bus
> scan, the driver detect it's address is 0x34, so I just stick to 0x34.

Is it the only device on i2c bus? 
> 
> Anyway, I can write to saa7121via i2c bus successfully, but I can't
enable
> color bar, so I don't know whether the driver is working properly or
not?

Are you sure you are operating on the correct device?  What operation
can you do successfully on the device?  Can you read from the i2c bus?
> 
> BTW, I setup I2C driver for SAA7113 and it works fine.
> 
> Tim

atomic operations in user space

[Li Yang-r58472]

Why do you need atomic operations in user land?  IPC will be sufficient
to deal with race conditions between processes. 

Best Regards,
Leo
> -Original Message-
> From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
Behalf Of
> Terry Liang
> Sent: Thursday, August 24, 2006 3:04 AM
> To: linuxppc-embedded at ozlabs.org
> Subject: atomic operations in user space
> 
> Thanks. Arnd. My main concern is whether the operations are really
atomic as they
> are in the kernel space. I have read some discussion in another forum
that on other
> platforms, even if you are able to compile the atomic_add(),
atomic_set(), etc.
> from an user space application,  they don't guarantee to be atomic.
Thanks.
> 
> Regards,
> 
> Terry Liang

"ip=" command line strangeness...

[T Ziomek]

On my previous project, a 2.4 kernel on PPC, I frequently used 
"ip=w.x.y.z" on the kernel command line to specify a static IP address for
my target board (when booting with a flash- or RAM-based root filesystem).
Similarly, when using an NFS-mounted root fs, I would use
"ip=w.x.y.z:a.b.c.d", along with the appropriate "nfsroot=..." setting,
with my NFS server having IP a.b.c.d .

Now I am working with a 2.6.10-based kernel on ARM.  Using an NFS root fs
works fine when I use the expected "ip=w.x.y.z:a.b.c.d".  And booting off
with "root=/dev/hda1" works fine with "ip=dhcp".
I'd expect to be able to use "root=/dev/hda1 ip=w.x.y.z" if I want the
target using a static IP address.  But this fails, and in a VERY weird
way:  (1) It tries doing DHCP, which it shouldn't, and (2) the DHCP fails,
which it shouldn't because it works when I want DHCP to be used.
Here's a snippet of console output:
 .
 .
 .
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests .. timed out!
EMAC: TX Complete: Starting queue
IP-Config: Reopening network devices...
Sending DHCP requests ...

Okay, that's two weird things.  There is a third -- this problem goes a-
way if I change the command line to something like
"root=/dev/hda1 ip=w.x.y.z:a.b.c.d".  The only change is adding an NFS
server IP address to the "ip=" command, which should have no effect be-
cause NFS is not being used.  Yet when I do that the board boots as ex-
pected -- it does not try to do DHCP, it does use /dev/hda1 for its root
fs, and it does take the specified IP address.

In fact, it works even if I use a command line with, literally,
"root=/dev/hda1 ip=199.5.233.72:gobbledygook":
 .
 .
 .
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
  device=eth0, addr=199.5.233.72, mask=255.255.255.0, 
gw=255.255.255.255,
 host=199.5.233.72, domain=, nis-domain=(none),
 bootserver=232.0.0.0, rootserver=232.0.0.0, rootpath=
 .
 .
 .

This isn't a big problem, but can anybody explain what the heck is going
on?

Thanks, Tom
-- 
   /"\  ASCII Ribbon Campaign   |
   \ /  |   Email to user 'CTZ001'
XAgainst HTML   | at 'email.mot.com'
   / \ in e-mail & news |

Help with booting with very large initrd

[Howard, Marc]

Hi,

I'm developing a PPC440GX based board that uses U-Boot to boot a
multi-file boot image composed of the kernel and a very large (> 96MB
uncompressed) initrd file.  The board has 512MB of RAM of which the
upper 16MB is reserved for dedicated hardware.  The 16MB block is
reserved via "mem=496M" and U-Boot is told to stay out of that area by
setting "initrd_high=1f00".

Before anyone asks there are several reasons for doing things this way.
NFS is not an option in the target environment.

I can tftp the combined boot image to my board.  I checked the crc with
the crc32 command and it agrees exactly with the result obtained on the
host machine using the boot file.  Therefore there is not a "TFTP >32MB"
problem here.

If I boot I get the following:

=> boot
Waiting for PHY auto negotiation to complete... done
ENET Speed is 1000 Mbps - FULL duplex connection
Using ppc_4xx_eth2 device
TFTP from server 192.168.168.108; our IP address is 192.168.168.111
Filename 'pMulti-ramdisk'.
Load address: 0x40
Loading: *
done
Bytes transferred = 38825407 (2506dbf hex)
Automatic boot of image at addr 0x0040 ...
## Booting image at 0040 ...
   Image Name:   Linux-2.6.10_mvl401-440gx_eval-I
   Created:  2006-08-25   1:01:29 UTC
   Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
   Data Size:38825343 Bytes = 37 MB
   Load Address: 
   Entry Point:  
   Contents:
   Image 0:  1137986 Bytes =  1.1 MB
   Image 1: 37687343 Bytes = 35.9 MB
   Verifying Checksum ... OK
   Uncompressing Multi-File Image ... OK
   Loading Ramdisk to 1cc0e000, end 1efff02f ... OK
Linux version 2.6.10_mvl401-440gx_eval (cram at toaster.kla-tencor.com)
(gcc version 3.4.3 (MontaVista 3.4.3-25.0.107.0601076 2006-07-21)) #46
Thu Aug 24 17:28:09 PDT 2006
IBM Ocotea port (MontaVista Software, Inc. )
Built 1 zonelists
Kernel command line: ramdisk_size=262144 root=/dev/ram rw
console=ttyS0,115200
ip=192.168.168.111:192.168.168.108::255.255.255.0:scpu2:eth0: off
mem=496M
PID hash table entries: 2048 (order: 11, 32768 bytes)

..stuff deleted..

RAMDISK driver initialized: 8 RAM disks of 262144K size 1024 blocksize
loop: loaded (max 8 devices)

..more stuff deleted..

eth0: link is down
eth0: link is up, 1000 FDX, pause enabled
IP-Config: Complete:
  device=eth0, addr=192.168.168.111, mask=255.255.255.0,
gw=255.255.255.255, host=scpu2, domain=, nis-domain=(none),
 bootserver=192.168.168.108, rootserver=192.168.168.108, rootpath=
RAMDISK: Compressed image found at block 0
crc error (orig 0x9a278d64, CRC_VALUE 0xa7bcd2e3 -- ignoring!
length error (orig = 0x0c00, bytes_out = 0x0c15 -- ignored
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found.  Try passing init= option to
kernel.
 <0>Rebooting in 180 seconds..

(I modified lib/inflate.c so that the crc and length checks would
provide more info).

Since the overall file CRC is good and U-Boot checksums are also okay
this looks like some sort of size limitation with the inflate routine.
BTW, The kerenel was made assuming a 256MB ramdisk; likewise the command
line specs one as well.  The initrd image would fit easily in that
space.

Have any of you worked on this problem before and come up with a
solution?

Thanks,

Marc Howard

MontaVista 2.6 Kernel support for Xilinx ML40x

[Wade Maxfield]

  sorry! ;)  See my reply at the right location!

On 8/24/06, T Ziomek  wrote:
>
> [top-posting fixed  :-) ]
>
>
> On Thu, 24 Aug 2006, Wade Maxfield wrote:
> >
> > On 8/24/06, Peter Ryser  wrote:
> >>
> >>  Wade,
> >>
> >> are you sure that you did not build your hardware with evaluation cores
> of
> >> the licenses? If you are using the evaluation licenses the hardware
> (FPGA
> >> design) will stop working after a certain amount of time and you will
> see a
> >> lock-up.
> >
> > Good question.  How long before lockup?  The only core that should be
> > licensed is the ethernet, and I know it was sysgened on a system with a
> > license.  This is the Xilinx reference design for the ml403 board.
>
> When we were using the eval version of Xilinx's 10/100 EMAC it would time-
> out after 8 hours (and the kernel would panic since our root fs was NFS-
> mounted).
>
> If your only [to-be-]licensed core is Ethernet, then I take it you're
> using
> the UARTLite, or a non-Xilinx UART?  We used Xilinx's 16550-compatible
> UART,
> which is licensed, but I never ran with the eval version of that IP block
> and so have no idea how long it will function before shutting down.



 We are doing an evaluation right now.  We have operational 8 hours 55
minutes so far and counting on the Xilinx 16550 compatible uart.  I think
that is the cause of the problem for us, but not sure so far.


Tom
> --
> A: Because it breaks the logical|
>  flow of the message.|   Email to user 'CTZ001'
>  | at 'email.mot.com'
> Q: Why is top posting frowned upon? |


x<>y
 A2. but only for algebraic.  RPN likes it that way.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/98b158bc/attachment.htm
 

MontaVista 2.6 Kernel support for Xilinx ML40x

[Claus Gindhart]

Frank,

due to my understanding of the GPL (and i have already invested some time
in understanding the various flavours of open source licences), you should
contact Montavista, and ask them for the sources.

This board adaption is derivative work of the GPL Kernel, so the result of
this work also falls under the GPL, and has to be made freely available 
under the terms of the GPL.

-- 
Mit freundlichen Gruessen / Best regards

Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart at kontron-modular.com
http://www.kontron.com

-BEGIN GEEK CODE BLOCK-
  Version: 3.1
  GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
  K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
  D-- G e++> h--- !r x+++
--END GEEK CODE BLOCK--
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org]
On Behalf Of Frank D Lombardo
Sent: Donnerstag, 24. August 2006 15:59
To: linuxppc-embedded at ozlabs.org
Subject: MontaVista 2.6 Kernel support for Xilinx ML40x


I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) 
available for the Xilinx ML40x series of boards.  I would assume that 
means driver support for at least most of the hardware on the boards.  
Is this code that should be freely available?  How would one get a copy 
of these drivers?  I am interested in drivers for the ML403.

Thanks,
Frank
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Cache coherency question

[Martin, Tim]

I'm using an MVME6100 with Linux 2.6.14 and experiencing what I think is
a cache coherency problem.  An external PCIX master performs a DMA
transfer of a well known data pattern into SDRAM, but when the device
driver goes to look at the data it is mostly okay, but occasionally has
garbage.

I'm allocating the memory using alloc_skb, then giving a PCI translated
pointer to the PCIX master.  Since I think it is a cache coherency
problem, I tried to use the dma_cache_inv macro to invalidate the cache
before looking at the data, but realized that for this board, that
function does nothing since CONFIG_NOT_COHERENT_CACHE is undefined.  So
questions:

1) Should the processor bus cache snooping actually work on an MVME6100?
E.g. is it correct that CONFIG_NOT_COHERENT_CACHE is undefined?
1a) Does this type of bus snooping work when a bus master physically
external to the PowerPC chip is doing the transfer?

2) If this really is a cache coherency problem, are there other cache
management functions available in ppc linux besides the dma_cache_inv,
dma_cache_wback, dma_cache_wback_inv macros I should be looking at?

Tim

I2C driver for SAA7121 on MPC855 and linux-2.4.25

[Xu, Li (GE, Research)]

Hi,

I am trying to setup i2c driver for saa7121 on my mpc855 based board
normally the address for saa7121 is 0x88, but when I enable i2c bus
scan, the driver detect it's address is 0x34, so I just stick to 0x34.

Anyway, I can write to saa7121via i2c bus successfully, but I can't enable
color bar, so I don't know whether the driver is working properly or not?

BTW, I setup I2C driver for SAA7113 and it works fine.

Tim

MontaVista 2.6 Kernel support for Xilinx ML40x

[Frank D Lombardo]

The ml403 reference design has several evaluation cores: opb_uart16550, 
opb_iic and opb_ethernet.  They seem to time-out after about eight hours.

Frank

Wade Maxfield wrote:
> Good question.  How long before lockup?  The only core that should be 
> licensed is the ethernet, and I know it was sysgened on a system with 
> a license.  This is the Xilinx reference design for the ml403 board.
>
>
> On 8/24/06, *Peter Ryser*  > wrote:
>
> Wade,
>
> are you sure that you did not build your hardware with evaluation
> cores of the licenses? If you are using the evaluation licenses
> the hardware (FPGA design) will stop working after a certain
> amount of time and you will see a lock-up.
>
> - Peter
>
>
> Wade Maxfield wrote:
>
>   I've got the LSP, and have booted it on the ML40X.
>  
>   In my opinion it is currently unstable, but that is my opinion. 
> I've not been able to keep it powered up for 24 hours without it
> locking up on the RS232 serial terminal.  Also, running updatedb
> over nfs causes it to abort with a kernel panic, although that
> might be an interraction with the nfs server.  (Although even if
> the nfs server dies (which it did not), I don't expect a kernel
> panic).
>
>I have had it run over 6 hours without issue, so I expect
> subtle memory leaks, not serious problems.
>
>
>
> On 8/24/06, *Claus Gindhart* < claus.gindhart at kontron.com
> > wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already
> invested some time
> in understanding the various flavours of open source
> licences), you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so
> the result of
> this work also falls under the GPL, and has to be made freely
> available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart at kontron-modular.com
> 
> http://www.kontron.com
>
> -BEGIN GEEK CODE BLOCK-
>   Version: 3.1
>   GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
>   K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
>   D-- G e++> h--- !r x+++
> --END GEEK CODE BLOCK--
>
>
> -Original Message-
> From:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> 
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
>  ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded at ozlabs.org
> 
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6
> Kernel)
> available for the Xilinx ML40x series of boards.  I would
> assume that
> means driver support for at least most of the hardware on the
> boards.
> Is this code that should be freely available?  How would one
> get a copy
> of these drivers?  I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org  ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org  ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
>
>
> 
>
> ___ Linuxppc-embedded
> mailing list Linuxppc-embedded at ozlabs.org
> 
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> 
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

communication with i2c client

[Ladislav Klenovič]

Hi,
I've create an i2c client and my questions is how to access it from userspace. 
This client is sitttng on adapter that  I was able to access via /dev 
interface. After the client were successfuly loaded and detected,
ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work and  error 
messages like "device busy" or "ioctl error" have occured. Also my debug 
messages from i2c client didn't arise when I am accessing 
device only adapter's.
How to (standardly) access a an i2c client? 
Do I need to create an ioctl interface or exports some helper function for 
access it from user space and also from kernel space?  

regards,
Ladislav.

communication with i2c client

[Ladislav Klenovič]

Hi,
I've create an i2c client and my questions is how to access it from userspace. 
This client is sitttng on adapter that  I was able to access via /dev 
interface. After the client were successfuly loaded and detected,
ioctl(fd,I2C_SLAVE,...) and read/write functions didn't work and  error 
messages like "device busy" or "ioctl error" have occured. Also my debug 
messages from i2c client didn't arise when I am accessing 
device only adapter's.
How to (standardly) access a an i2c client? 
Do I need to create an ioctl interface or exports some helper function for 
access it from user space and also from kernel space?  

regards,
Ladislav.

ARCH=ppc or ARCH=powerpc

[Benjamin Delagoutte]

Le jeudi 24 ao?t 2006 ? 07:49 -0500, Josh Boyer a ?crit :
> On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote:
> > ppc = 32bit.
> > powerpc= 64bit.
> > Correct me if I am wrong.
> 
> Yes, you're wrong.  Some 32 bit boards are also under arch/powerpc now.
> 
> >  
> > I am not sure why community didn't adopt the name ppc and ppc64 just
> > like ia-32 and ia64.
> 
> They did originally.
> 
> The new direction is to have everything under arch/powerpc, both 32 and
> 64 bit.  The reason arch/ppc still exists is because some 32 bit
> platforms have not been fully migrated to the requirements to be merged
> into arch/powerpc.  Namely, the code has to boot from an OpenFirmware
> like flattened device tree.  The PPC 4xx family of processors, as an
> example, does not do this yet though there is work going on to adapt it.

I'm currently working on a PPC 405 based developement card. Does it mean
I have to work using the arch/ppc tree ? 

What about the includes ? Do I have to use only include/asm-ppc or are
include/asm-powerpc necessary as well ?

> Eventually, arch/ppc will go away and all of PowerPC will be under
> arch/powerpc.  That's the goal anyway.
> 
> josh
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Platform device style question

[Ben Warren]

Thanks Vitaly,

On Thu, 2006-08-24 at 22:06 +0400, Vitaly Bordug wrote:

> I'd suggest to make a look at LDD concerning linux device model...
Thanks.  I'll read it again.  My little brain absorbs this stuff very
slowly.
> For platform device, there's no need to cope with u-boot at all. You'll 
> prolly need to 
> register the respective platform device from the board-specific code, with 
> proper name 
> and driver's board-specific platform info. You may have a look at 
> arch/ppc/syslib/ppc_sys.c about static
> PD definitions usage.

My particular platform (MPC8349) gets its hardware info (CPU, IMMBAR,
PCI, I2C, SPI resources etc.) from an OF device tree that is generated
alongside U-boot and I guess embedded in the uImage file.  (I apologize
if I'm getting my jargon mixed up here)  The OF device tree idea seemed
like a slick way to abstract away some HW settings from Linux.  I was
imagining writing board-side platform device registration that gets its
settings from the device tree, allowing a bit of re-use between similar
but not identical boards.
> 

> I'd make sense to figure out the platform device bus before digging into 
> device trees. It's slightly 
> different stuff, for similar aim, but anyway... Actually you do not strictly 
> need devtree to cope with 
> your case afaiu.

I definitely have much learning to do.  Thanks very much for the
pointers!

regards,
Ben

MontaVista 2.6 Kernel support for Xilinx ML40x

[T Ziomek]

[top-posting fixed  :-) ]


On Thu, 24 Aug 2006, Wade Maxfield wrote:
>
> On 8/24/06, Peter Ryser  wrote:
>> 
>>  Wade,
>> 
>> are you sure that you did not build your hardware with evaluation cores of
>> the licenses? If you are using the evaluation licenses the hardware (FPGA
>> design) will stop working after a certain amount of time and you will see a
>> lock-up.
>
> Good question.  How long before lockup?  The only core that should be
> licensed is the ethernet, and I know it was sysgened on a system with a
> license.  This is the Xilinx reference design for the ml403 board.

When we were using the eval version of Xilinx's 10/100 EMAC it would time-
out after 8 hours (and the kernel would panic since our root fs was NFS-
mounted).

If your only [to-be-]licensed core is Ethernet, then I take it you're using
the UARTLite, or a non-Xilinx UART?  We used Xilinx's 16550-compatible UART,
which is licensed, but I never ran with the eval version of that IP block
and so have no idea how long it will function before shutting down.

Tom
-- 
A: Because it breaks the logical|
 flow of the message.|   Email to user 'CTZ001'
 | at 'email.mot.com'
Q: Why is top posting frowned upon? |

CompactFlash on PQII Pro

[Ben Warren]

Kumar,

On Thu, 2006-08-24 at 13:25 -0500, Kumar Gala wrote:

> The only code in u-boot was the UPM setup code, I'm happy to send  
> that to you.
> 
If it's no trouble, that would be great.  My HW guy is calculating the
settings, but this stuff can be frustrating to debug.  BTW - was the
system bus speed for your CPU 33 or 66 MHz?  We're targeting for a
400MHz 8349 which has a 33MHz system bus.

Platform device style question

[Ben Warren]

Hello,

A 'newbie-to-platform-devices' question:

In a patch that Kumar just sent for a compact flash device, the resource
data (I/O addresses, IRQ # etc.) are retrieved from the platform system.
I guess I can either modify the device tree in U-boot by adding
additional nodes, or instantiate a platform device in Linux __init code
based on static information.  The former gives the advantage of having
the bootloader pass the info to the OS.  (Somebody please correct me if
I'm off-base here!)  

Are device trees meant to only contain information about the CPU and
tightly-coupled peripherals, or is it considered OK-form to also include
board-level hardware info?  I guess they can really hold anything, but
I'm trying to figure out the original intent.

regards,
Ben

CompactFlash on PQII Pro

[Kumar Gala]

On Aug 24, 2006, at 9:44 AM, Ben Warren wrote:

> Thanks Kumar,
>
> As always, you're several steps ahead of me.
>
> On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote:
>
>> I know I posted a patch for cf-ide.c to lkml some time ago, this was
>> to do a CF in true ide mode using the 83xx localbus.
>>
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=113877891224982&w=2
>>
>> We did some UPM setup in u-boot to use two CS on Localbus for this.
> In our case, we only have one CS available but it's going to a CPLD  
> that
> will decode and provide two CSs to the CF.  This will work as long as
> the UPM setup is identical for the two chip selects.  Should be...
> Off-topic to this list, but do you have the U-boot code that you can
> share?  If not, no worries.

The only code in u-boot was the UPM setup code, I'm happy to send  
that to you.

- kumar

MontaVista 2.6 Kernel support for Xilinx ML40x

[Wade Maxfield]

Good question.  How long before lockup?  The only core that should be
licensed is the ethernet, and I know it was sysgened on a system with a
license.  This is the Xilinx reference design for the ml403 board.


On 8/24/06, Peter Ryser  wrote:
>
>  Wade,
>
> are you sure that you did not build your hardware with evaluation cores of
> the licenses? If you are using the evaluation licenses the hardware (FPGA
> design) will stop working after a certain amount of time and you will see a
> lock-up.
>
> - Peter
>
>
> Wade Maxfield wrote:
>
>
>   I've got the LSP, and have booted it on the ML40X.
>
>   In my opinion it is currently unstable, but that is my opinion.  I've
> not been able to keep it powered up for 24 hours without it locking up on
> the RS232 serial terminal.  Also, running updatedb over nfs causes it to
> abort with a kernel panic, although that might be an interraction with the
> nfs server.  (Although even if the nfs server dies (which it did not), I
> don't expect a kernel panic).
>
>I have had it run over 6 hours without issue, so I expect subtle memory
> leaks, not serious problems.
>
>
>
> On 8/24/06, Claus Gindhart < claus.gindhart at kontron.com> wrote:
> >
> > Frank,
> >
> > due to my understanding of the GPL (and i have already invested some
> > time
> > in understanding the various flavours of open source licences), you
> > should
> > contact Montavista, and ask them for the sources.
> >
> > This board adaption is derivative work of the GPL Kernel, so the result
> > of
> > this work also falls under the GPL, and has to be made freely available
> > under the terms of the GPL.
> >
> > --
> > Mit freundlichen Gruessen / Best regards
> >
> > Claus Gindhart
> > SW R&D
> > Kontron Modular Computers
> > phone :++49 (0)8341-803-374
> > mailto:claus.gindhart at kontron-modular.com
> > http://www.kontron.com
> >
> > -BEGIN GEEK CODE BLOCK-
> >   Version: 3.1
> >   GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
> >   K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
> >   D-- G e++> h--- !r x+++
> > --END GEEK CODE BLOCK--
> >
> >
> > -Original Message-
> > From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> > [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> > ]
> > On Behalf Of Frank D Lombardo
> > Sent: Donnerstag, 24. August 2006 15:59
> > To: linuxppc-embedded at ozlabs.org
> > Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
> >
> >
> > I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> > available for the Xilinx ML40x series of boards.  I would assume that
> > means driver support for at least most of the hardware on the boards.
> > Is this code that should be freely available?  How would one get a copy
> > of these drivers?  I am interested in drivers for the ML403.
> >
> > Thanks,
> > Frank
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > ___
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded at ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> --
>
> ___ Linuxppc-embedded mailing
> list Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/d020126a/attachment.htm
 

ARCH=ppc or ARCH=powerpc

[Benjamin Delagoutte]

Hello,

I'm new to Linux PowerPC platform, and I'm wondering what ARCH we should
use to build the kernel. There seems to be 'ppc' and 'powerpc'. What's
the difference between the two ?

Thank you !

Benjamin

ioremap() fails for >64 MB

[alva]

I think 64MB limitation of ioremap() is due to the kernel's page size.
When compiling kernel, it has an option to choose the memory page size
which is default 64MB. To use memory greater than 64MB, there is two
methods. One is to make the kernel's page size larger as Phil Nitschke
said. Another is to modify ioremap() a little bit --- just make it use
another file for "mmap" while larger than 64MB. Since the central
concept of linux is file-based, I think more files are not harmful that
only waste a little bit inode structure. And it is much more feasible
that one can choose to use file in memory or harddisk or mounted device
harddisk/memory ... ...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-bounces+vows_siu=yahoo.com.hk at ozlabs.org] On
Behalf Of Phil Nitschke
Sent: Wednesday, August 23, 2006 6:01 PM
To: Matt Porter
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: ioremap() fails for >64 MB

On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote:
> On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote:
> > Hi all,
> > 
> > I have 2 GB memory on a 7448 processor, and want to reserve a huge
chunk
> > of it at boot-time, then ioremap() it into the kernel space inside a
> > device driver.  So far I've succeeded with 64 MB, but can't go any
> > higher, as mm/vmalloc.c tells me: "allocation failed: out of vmalloc
> > space - use vmalloc= to increase size."
> > 
> > So I tried adding a vmalloc line to the kernel command line as
follows:
> > Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M
nfsroot=... 
>  
> Yeah, that suggestion is bogus. That option can't help with getting
> more vmalloc space in this case.
> 
> > So the vmalloc= argument has made no difference.  What do I
need
> > to do to make this work?
> 
> Go to the "Advanced setup" menu. There's a number of options to
provide
> fine-grained control of the PPC kernel virtual address space.



Thanks Matt (and others) for your suggestions.  Matt has given me the
answers I was looking for.

Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit
processor, why do I need high memory at all?  

Are there performance implications on this platform from having a non
optimal low/high ratio?

> That said, why don't you just use alloc_bootmem() to reserve memory
> for your driver at boot time? 

I avoided this simply because I wanted to load/unload my driver (during
development), and alloc_bootmem() seemed better suited to drivers
compiled into the kernel.  But I'll look again at this idea if further
problems arise with the approach above.

Thanks again,

-- 
Phil

___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/425 - Release Date:
2006/8/22
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date:
2006/8/23
 

CompactFlash on PQII Pro

[Ben Warren]

Thanks Kumar,

As always, you're several steps ahead of me.

On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote:

> I know I posted a patch for cf-ide.c to lkml some time ago, this was  
> to do a CF in true ide mode using the 83xx localbus.
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113877891224982&w=2
> 
> We did some UPM setup in u-boot to use two CS on Localbus for this.
In our case, we only have one CS available but it's going to a CPLD that
will decode and provide two CSs to the CF.  This will work as long as
the UPM setup is identical for the two chip selects.  Should be...  
Off-topic to this list, but do you have the U-boot code that you can
share?  If not, no worries.

thanks,
Ben

MontaVista 2.6 Kernel support for Xilinx ML40x

[Wade Maxfield]

  I've got the LSP, and have booted it on the ML40X.

  In my opinion it is currently unstable, but that is my opinion.  I've not
been able to keep it powered up for 24 hours without it locking up on the
RS232 serial terminal.  Also, running updatedb over nfs causes it to abort
with a kernel panic, although that might be an interraction with the nfs
server.  (Although even if the nfs server dies (which it did not), I don't
expect a kernel panic).

   I have had it run over 6 hours without issue, so I expect subtle memory
leaks, not serious problems.



On 8/24/06, Claus Gindhart  wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already invested some time
> in understanding the various flavours of open source licences), you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so the result of
> this work also falls under the GPL, and has to be made freely available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart at kontron-modular.com
> http://www.kontron.com
>
> -BEGIN GEEK CODE BLOCK-
>   Version: 3.1
>   GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
>   K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
>   D-- G e++> h--- !r x+++
> --END GEEK CODE BLOCK--
>
>
> -Original Message-
> From: linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> [mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded at ozlabs.org
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> available for the Xilinx ML40x series of boards.  I would assume that
> means driver support for at least most of the hardware on the boards.
> Is this code that should be freely available?  How would one get a copy
> of these drivers?  I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/053fa0d2/attachment.htm
 

MontaVista 2.6 Kernel support for Xilinx ML40x

[Frank D Lombardo]

I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) 
available for the Xilinx ML40x series of boards.  I would assume that 
means driver support for at least most of the hardware on the boards.  
Is this code that should be freely available?  How would one get a copy 
of these drivers?  I am interested in drivers for the ML403.

Thanks,
Frank

MontaVista 2.6 Kernel support for Xilinx ML40x

[Peter Ryser]

Wade,

are you sure that you did not build your hardware with evaluation cores 
of the licenses? If you are using the evaluation licenses the hardware 
(FPGA design) will stop working after a certain amount of time and you 
will see a lock-up.

- Peter


Wade Maxfield wrote:

>
>   I've got the LSP, and have booted it on the ML40X.
>  
>   In my opinion it is currently unstable, but that is my opinion.  
> I've not been able to keep it powered up for 24 hours without it 
> locking up on the RS232 serial terminal.  Also, running updatedb over 
> nfs causes it to abort with a kernel panic, although that might be an 
> interraction with the nfs server.  (Although even if the nfs server 
> dies (which it did not), I don't expect a kernel panic).
>
>I have had it run over 6 hours without issue, so I expect subtle 
> memory leaks, not serious problems.
>
>
>
> On 8/24/06, Claus Gindhart < claus.gindhart at kontron.com 
> <mailto:claus.gindhart at kontron.com>> wrote:
>
> Frank,
>
> due to my understanding of the GPL (and i have already invested
> some time
> in understanding the various flavours of open source licences),
> you should
> contact Montavista, and ask them for the sources.
>
> This board adaption is derivative work of the GPL Kernel, so the
> result of
> this work also falls under the GPL, and has to be made freely
> available
> under the terms of the GPL.
>
> --
> Mit freundlichen Gruessen / Best regards
>
> Claus Gindhart
> SW R&D
> Kontron Modular Computers
> phone :++49 (0)8341-803-374
> mailto:claus.gindhart at kontron-modular.com
> <mailto:claus.gindhart at kontron-modular.com>
> http://www.kontron.com
>
> -BEGIN GEEK CODE BLOCK-
>   Version: 3.1
>   GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
>   K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
>   D-- G e++> h--- !r x+++
> --END GEEK CODE BLOCK--
>
>
> -Original Message-
> From:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> <mailto:kontron.com at ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com at ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com at 
> ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded at ozlabs.org <mailto:linuxppc-embedded at 
> ozlabs.org>
> Subject: MontaVista 2.6 Kernel support for Xilinx ML40x
>
>
> I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel)
> available for the Xilinx ML40x series of boards.  I would assume that
> means driver support for at least most of the hardware on the boards.
> Is this code that should be freely available?  How would one get a
> copy
> of these drivers?  I am interested in drivers for the ML403.
>
> Thanks,
> Frank
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org <mailto:Linuxppc-embedded at ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org <mailto:Linuxppc-embedded at ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
>----
>
>___
>Linuxppc-embedded mailing list
>Linuxppc-embedded at ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/05ebc36d/attachment.htm
 

MontaVista 2.6 Kernel support for Xilinx ML40x

[Rick Moleres]

Note that Xilinx plans to update the MV drivers to support the latest IP
in EDK 8.2.2 (due out around October), and these drivers would be part
of the BSP generation process of Platform Studio.  Sorry, the timing of
the MV ML40x work and our EDK 8.1.x release was such that MV had no
choice but to use older IP and drivers.

-Rick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On
Behalf Of Michael Galassi
Sent: Thursday, August 24, 2006 9:18 AM
To: Frank D Lombardo
Cc: linuxppc-embedded at ozlabs.org
Subject: Re: MontaVista 2.6 Kernel support for Xilinx ML40x 

I too had high hopes when I heard an LSP for the ML40x was imminent, I
nabbed it and was disappointed to find that their drivers still only
support relatively old versions of the Xilinx IP.  It would seem that
they are still creating the design they ported to with EDK/ISE v7.2
rather than the newer 8.1 or 8.2 with updated IP libraries.  This is
from the xparameters_ml40x.h file they distribute.

/***
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 7.1.2 EDK_H.12.5.1
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
*
* Description: Driver parameters
*
***/

Sigh.

-michael

>I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) 
>available for the Xilinx ML40x series of boards.  I would assume that 
>means driver support for at least most of the hardware on the boards.  
>Is this code that should be freely available?  How would one get a copy

>of these drivers?  I am interested in drivers for the ML403.
>
>Thanks,
>Frank
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

atomic operations in user space

[Brent Cook]

On Thursday 24 August 2006 05:39, Li Yang-r58472 wrote:
> Why do you need atomic operations in user land?  IPC will be sufficient
> to deal with race conditions between processes.
>
> Best Regards,
> Leo

What about multiple threads within a process updating a counter?

Of course, if you look at these functions in the kernel header, they're just 2 
or 3 inline assembly calls - you could easily rewrite them. Google for 'PowerPC 
atomic increment' and grab one of the unencumbered implementations if you need 
to use it in a non-GPL program.

On the other hand, I see no license at the top of my 
/usr/include/asm-i386/atomic.h file at all, same for PowerPC - are Linux header 
files actually GPL or are they more like the glibc headers, with exceptions 
made for userspace programs?

The atomic operations on x86 were accidentally exported early on, so they have 
to hang around apparently for compatibility (there are some mailing list 
threads out there to this effect.) Currently, you just have to assume in Linux 
that if you include something from /usr/include/linux or asm that it will not 
necessarily be cross-version or cross-architecture compatible. Not every arch 
in Linux even has atomic operations of this nature, which I guess is the main 
reason why they are not exported in general.

 - Brent

> > -Original Message-
> > From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org
> > [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On
>
> Behalf Of
>
> > Terry Liang
> > Sent: Thursday, August 24, 2006 3:04 AM
> > To: linuxppc-embedded at ozlabs.org
> > Subject: atomic operations in user space
> >
> > Thanks. Arnd. My main concern is whether the operations are really
>
> atomic as they
>
> > are in the kernel space. I have read some discussion in another forum
>
> that on other
>
> > platforms, even if you are able to compile the atomic_add(),
>
> atomic_set(), etc.
>
> > from an user space application,  they don't guarantee to be atomic.
>
> Thanks.
>
> > Regards,
> >
> > Terry Liang
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/4f60ee9d/attachment.htm
 

ioremap() fails for >64 MB

[Matt Porter]

On Wed, Aug 23, 2006 at 07:30:37PM +0930, Phil Nitschke wrote:
> On Tue, 2006-08-22 at 09:22 -0500, Matt Porter wrote:
> > On Tue, Aug 22, 2006 at 05:11:09PM +0930, Phil Nitschke wrote:
> > > Hi all,
> > > 
> > > I have 2 GB memory on a 7448 processor, and want to reserve a huge chunk
> > > of it at boot-time, then ioremap() it into the kernel space inside a
> > > device driver.  So far I've succeeded with 64 MB, but can't go any
> > > higher, as mm/vmalloc.c tells me: "allocation failed: out of vmalloc
> > > space - use vmalloc= to increase size."
> > > 
> > > So I tried adding a vmalloc line to the kernel command line as follows:
> > > Kernel cmd line: root=/dev/nfs rw mem=1920M vmalloc=1024M nfsroot=... 
> >  
> > Yeah, that suggestion is bogus. That option can't help with getting
> > more vmalloc space in this case.
> > 
> > > So the vmalloc= argument has made no difference.  What do I need
> > > to do to make this work?
> > 
> > Go to the "Advanced setup" menu. There's a number of options to provide
> > fine-grained control of the PPC kernel virtual address space.
> 
> 
> 
> Thanks Matt (and others) for your suggestions.  Matt has given me the
> answers I was looking for.
> 
> Since my (2 GB) memory is within the (4 GB) addressable by a 32-bit
> processor, why do I need high memory at all?  

Dan answered this one...
 
> Are there performance implications on this platform from having a non
> optimal low/high ratio?
 
It "depends". In PPC, we've always has kernelbase at 0xc000, however,
the dirty secret is that we still haven't have a 3:1 user:kernel split
like some other arches.  We've always had TASK_SIZE at 0x8000 which
really results in a 1:1 split.  So, as long as you don't modify
TASK_SIZE, there's no chance of starving memory hungry user space
applications. There's already this waste space from 0x8000-0xbfff
that was left due to legacy PReP reasons.

Even if you do modify TASK_SIZE down to something like 0x4000,
for a 1:3 split, many embedded apps are perfectly happy with this
space, YMMV.

It's important that you understand how the userspace works at the
low level, plus VSIDs (on classic PPC), and the general concepts
of the virtual memory organization between kernel and userspace before
you mess with all these advanced options.  They are under advanced
options since they can easily make your system inoperable with the
improper settings.

> > That said, why don't you just use alloc_bootmem() to reserve memory
> > for your driver at boot time? 
> 
> I avoided this simply because I wanted to load/unload my driver (during
> development), and alloc_bootmem() seemed better suited to drivers
> compiled into the kernel.  But I'll look again at this idea if further
> problems arise with the approach above.

I see. It doesn't have any bearing on using a loadable module since
alloc_bootmem() is only called by your board port code. Your loadable
module just uses that reserved area and manages it on its own.

In any case, either approach will work.

-Matt

ARCH=ppc or ARCH=powerpc

[Matt Porter]

On Thu, Aug 24, 2006 at 08:07:20AM -0500, Josh Boyer wrote:
> On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote:
> > What about the includes ? Do I have to use only include/asm-ppc or are
> > include/asm-powerpc necessary as well ?
> 
> I believe there are some hacks in the makefiles to pull common asm files
> from include/asm-powerpc when needed.  Basically, you should be able to
> just do:
> 
> #include 
> 
> and it should work.  If you're adding new .h files, I suppose asm-ppc is
> the place to add them for now.  That's just my opinion though :)

That's what I would recommend too. If this is for an out-of-tree custom
port then there's no real concern anyway.

-Matt

ioremap() fails for >64 MB

[Matt Porter]

On Thu, Aug 24, 2006 at 10:54:23AM +0800, alva wrote:
> I think 64MB limitation of ioremap() is due to the kernel's page size.
> When compiling kernel, it has an option to choose the memory page size
> which is default 64MB. To use memory greater than 64MB, there is two
> methods. One is to make the kernel's page size larger as Phil Nitschke
> said. Another is to modify ioremap() a little bit --- just make it use
> another file for "mmap" while larger than 64MB. Since the central
> concept of linux is file-based, I think more files are not harmful that
> only waste a little bit inode structure. And it is much more feasible
> that one can choose to use file in memory or harddisk or mounted device
> harddisk/memory ... ...

This is incorrect. There is no "64MB page size". Unless you are ioremapping
a region overed by a BAT/CAM, the mapping is composed of default 4KB PTEs.
The reason it fails is because of what I explained earlier. Just wanted to
clarify so nobody was confused by these statements. We can map arbitrary
sizes to the limit of what the kernel virtual address space settings
allow. This varies from platform to platform.

-Matt

ARCH=ppc or ARCH=powerpc

[Matt Porter]

On Thu, Aug 24, 2006 at 02:58:15PM +0200, Benjamin Delagoutte wrote:
> Le jeudi 24 ao?t 2006 ? 07:49 -0500, Josh Boyer a ?crit :
> > On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote:
> > > ppc = 32bit.
> > > powerpc= 64bit.
> > > Correct me if I am wrong.
> > 
> > Yes, you're wrong.  Some 32 bit boards are also under arch/powerpc now.
> > 
> > >  
> > > I am not sure why community didn't adopt the name ppc and ppc64 just
> > > like ia-32 and ia64.
> > 
> > They did originally.
> > 
> > The new direction is to have everything under arch/powerpc, both 32 and
> > 64 bit.  The reason arch/ppc still exists is because some 32 bit
> > platforms have not been fully migrated to the requirements to be merged
> > into arch/powerpc.  Namely, the code has to boot from an OpenFirmware
> > like flattened device tree.  The PPC 4xx family of processors, as an
> > example, does not do this yet though there is work going on to adapt it.
> 
> I'm currently working on a PPC 405 based developement card. Does it mean
> I have to work using the arch/ppc tree ? 

PPC405 is only supported in the arch/ppc tree currenty. Unless you
want to contribute to the effort to move to arch/powerpc, you'll
have to work with arch/ppc/

> What about the includes ? Do I have to use only include/asm-ppc or are
> include/asm-powerpc necessary as well ?

When you do an arch/ppc build it automagically includes shared
includes from asm-powerpc as necessary. There's nothing to worry
about there.

The goal is to have the new 4xx arch/powerpc support not break 4xx
arch/ppc support. So as boards are merged and verified working,
we'll remove the equivalent support from arch/ppc...

Some boards/chips may just die if no maintainer step up to port
them over...but all the important stuff should get an interested
party once we get the initial 4xx support in arch/powerpc working.

-Matt

MontaVista 2.6 Kernel support for Xilinx ML40x

[Michael Galassi]

I too had high hopes when I heard an LSP for the ML40x was imminent, I
nabbed it and was disappointed to find that their drivers still only
support relatively old versions of the Xilinx IP.  It would seem that
they are still creating the design they ported to with EDK/ISE v7.2
rather than the newer 8.1 or 8.2 with updated IP libraries.  This is
from the xparameters_ml40x.h file they distribute.

/***
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 7.1.2 EDK_H.12.5.1
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
*
* Description: Driver parameters
*
***/

Sigh.

-michael

>I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) 
>available for the Xilinx ML40x series of boards.  I would assume that 
>means driver support for at least most of the hardware on the boards.  
>Is this code that should be freely available?  How would one get a copy 
>of these drivers?  I am interested in drivers for the ML403.
>
>Thanks,
>Frank

ARCH=ppc or ARCH=powerpc

[Josh Boyer]

On Thu, 2006-08-24 at 14:58 +0200, Benjamin Delagoutte wrote:
> 
> I'm currently working on a PPC 405 based developement card. Does it mean
> I have to work using the arch/ppc tree ? 

For now, yes.  Set ARCH=ppc when you compile the kernel.

> What about the includes ? Do I have to use only include/asm-ppc or are
> include/asm-powerpc necessary as well ?

I believe there are some hacks in the makefiles to pull common asm files
from include/asm-powerpc when needed.  Basically, you should be able to
just do:

#include 

and it should work.  If you're adding new .h files, I suppose asm-ppc is
the place to add them for now.  That's just my opinion though :)

josh

ARCH=ppc or ARCH=powerpc

[Josh Boyer]

On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote:
> ppc = 32bit.
> powerpc= 64bit.
> Correct me if I am wrong.

Yes, you're wrong.  Some 32 bit boards are also under arch/powerpc now.

>  
> I am not sure why community didn't adopt the name ppc and ppc64 just
> like ia-32 and ia64.

They did originally.

The new direction is to have everything under arch/powerpc, both 32 and
64 bit.  The reason arch/ppc still exists is because some 32 bit
platforms have not been fully migrated to the requirements to be merged
into arch/powerpc.  Namely, the code has to boot from an OpenFirmware
like flattened device tree.  The PPC 4xx family of processors, as an
example, does not do this yet though there is work going on to adapt it.

Eventually, arch/ppc will go away and all of PowerPC will be under
arch/powerpc.  That's the goal anyway.

josh

ARCH=ppc or ARCH=powerpc

[Parav Pandit]

Thanks for correcting my understanding.
  We would also move our code to powerpc from ppc next release onwards.
   
  Parav
   
   
  
Josh Boyer  wrote:
  On Thu, 2006-08-24 at 05:38 -0700, Parav Pandit wrote:
> ppc = 32bit.
> powerpc= 64bit.
> Correct me if I am wrong.

Yes, you're wrong. Some 32 bit boards are also under arch/powerpc now.

> 
> I am not sure why community didn't adopt the name ppc and ppc64 just
> like ia-32 and ia64.

They did originally.

The new direction is to have everything under arch/powerpc, both 32 and
64 bit. The reason arch/ppc still exists is because some 32 bit
platforms have not been fully migrated to the requirements to be merged
into arch/powerpc. Namely, the code has to boot from an OpenFirmware
like flattened device tree. The PPC 4xx family of processors, as an
example, does not do this yet though there is work going on to adapt it.

Eventually, arch/ppc will go away and all of PowerPC will be under
arch/powerpc. That's the goal anyway.

josh





-
Stay in the know. Pulse on the new Yahoo.com.  Check it out. 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/54a92665/attachment.htm
 

MPC8555 PCI interrupts are not coming

[Parav Pandit]

Hi,
   
  Can someone give light on PCI interrupts routing to the OS from the openPIC?
   
  Basically I am able to talk to PCI end device connected on MPC8555 board in 
2.6.13 but not getting interrupts reported by my device.
   
  When I read the INTERRUPT_LINE byte, it comes as 0. pdev->irq is also 
reporting 0.
  Due to that request_irq() fails. But now I request for IRQ line 8 + openPIC 
offset.
  Handler gets registered but still not getting the interrupts. (PCI interrupt 
line is 8,9 in case of MPC8555).
   
  Can anyone please guide me, what are the different things need be configure 
in the platform code to receive the PCI interrupts in the driver?
   
  I don't understand the pci_irq_table, and what it should represent?
  Currrently no one is writing the INTERRUPT LINE value in the config space.
  In which function I should configure that value? pcibios_fixup??
   
  Regards,
  Parav Pandit
   


-
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/068788be/attachment.htm
 

ARCH=ppc or ARCH=powerpc

[Parav Pandit]

ppc = 32bit.
  powerpc= 64bit.
  Correct me if I am wrong.
   
  I am not sure why community didn't adopt the name ppc and ppc64 just like 
ia-32 and ia64.
   
  Parav
  

Benjamin Delagoutte  wrote:
  Hello,

I'm new to Linux PowerPC platform, and I'm wondering what ARCH we should
use to build the kernel. There seems to be 'ppc' and 'powerpc'. What's
the difference between the two ?

Thank you !

Benjamin

___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded



-
Do you Yahoo!?
 Everyone is raving about the  all-new Yahoo! Mail.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060824/8ce76255/attachment.htm