* communication with i2c client
From: Ladislav Klenovič @ 2006-08-24 13:15 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've create an i2c client and my questions is how to access it from use=
rspace=2E This client is sitttng on adapter that I was able to access =
via /dev interface=2E After the client were successfuly loaded and dete=
cted,
ioctl(fd,I2C_SLAVE,=2E=2E=2E) and read/write functions didn't work and =
error messages like "device busy" or "ioctl error" have occured=2E Als=
o my debug messages from i2c client didn't arise when I am accessing=20
device only adapter's=2E
How to (standardly) access a an i2c client?=20
Do I need to create an ioctl interface or exports some helper function =
for access it from user space and also from kernel space? =20
regards,
Ladislav=2E
^ permalink raw reply
* "ip=" command line strangeness...
From: T Ziomek @ 2006-08-24 23:38 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tomz
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'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Cache coherency question
From: Martin, Tim @ 2006-08-24 23:08 UTC (permalink / raw)
To: ppc
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
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-24 22:56 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <44EE0173.9060403@s5r6.in-berlin.de>
On Thu, Aug 24, 2006 at 09:43:47PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote:
> ...
> >Because i hate to burden my lousy memory with what I did to produce
> >the logs above, I scrambled together my admittedly marginal bash
> >knowledge and ran the tests with 4 scripts to produce the logs.
> >
> >All the following below is to give you control on how these logs were
> >created.
> ...
>
> Thanks, I will look at them as soon as I have my lookup table for the
> hex codes and the mental capacity available. :-) BTW, a convenient way
> to annotate the syslog is the command "logger". E.g.
> $ logger "hello world"
> $ ./hello_world 2>&1 | logger -t hi_world
I'll keep that on my radar for the next time I could use 'logger' ...
But after reading the - how do I say that without becoming offensive,
- err .. possibly slightly esoteric explanations in "man logger" I'm
not that much enthusiastic to use the tool ... but let's see .. :)
Note: Please ignore most of the ugly explanations on how I created the
logs for ieee1394 in my previous mail. Some should be nothing more
than a reference if (and only if) the ieee logs I put on my home page
don't help to debug the FW issue ...
Thanks
Best regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 22:13 UTC (permalink / raw)
To: T Ziomek; +Cc: ppc
In-Reply-To: <Pine.WNT.4.61.0608241432311.200@holyoke.labs.mot.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
sorry! ;) See my reply at the right location!
On 8/24/06, T Ziomek <ctz001@email.mot.com> wrote:
>
> [top-posting fixed :-) ]
>
>
> On Thu, 24 Aug 2006, Wade Maxfield wrote:
> >
> > On 8/24/06, Peter Ryser <peter.ryser@xilinx.com> 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.
[-- Attachment #2: Type: text/html, Size: 2928 bytes --]
^ permalink raw reply
* communication with i2c client
From: Ladislav Klenovič @ 2006-08-24 13:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've create an i2c client and my questions is how to access it from use=
rspace=2E This client is sitttng on adapter that I was able to access =
via /dev interface=2E After the client were successfuly loaded and dete=
cted,
ioctl(fd,I2C_SLAVE,=2E=2E=2E) and read/write functions didn't work and =
error messages like "device busy" or "ioctl error" have occured=2E Als=
o my debug messages from i2c client didn't arise when I am accessing=20
device only adapter's=2E
How to (standardly) access a an i2c client?=20
Do I need to create an ioctl interface or exports some helper function =
for access it from user space and also from kernel space? =20
regards,
Ladislav=2E
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-24 19:43 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060824192200.GA2715@localhost>
Wolfgang Pfeiffer wrote:
...
> Because i hate to burden my lousy memory with what I did to produce
> the logs above, I scrambled together my admittedly marginal bash
> knowledge and ran the tests with 4 scripts to produce the logs.
>
> All the following below is to give you control on how these logs were
> created.
...
Thanks, I will look at them as soon as I have my lookup table for the
hex codes and the mental capacity available. :-) BTW, a convenient way
to annotate the syslog is the command "logger". E.g.
$ logger "hello world"
$ ./hello_world 2>&1 | logger -t hi_world
--
Stefan Richter
-=====-=-==- =--- ==---
http://arcgraph.de/sr/
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: T Ziomek @ 2006-08-24 19:38 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608241057j4ebe519drd1e431a2275ccdde@mail.gmail.com>
[top-posting fixed :-) ]
On Thu, 24 Aug 2006, Wade Maxfield wrote:
>
> On 8/24/06, Peter Ryser <peter.ryser@xilinx.com> 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? |
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Frank D Lombardo @ 2006-08-24 19:27 UTC (permalink / raw)
To: Wade Maxfield; +Cc: ppc
In-Reply-To: <45a1b53e0608241057j4ebe519drd1e431a2275ccdde@mail.gmail.com>
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* <peter.ryser@xilinx.com
> <mailto:peter.ryser@xilinx.com>> 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@kontron.com
> <mailto:claus.gindhart@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@kontron-modular.com
> <mailto:claus.gindhart@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@ozlabs.org
> <mailto:kontron.com@ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org
> <mailto:linuxppc-embedded@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@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________ Linuxppc-embedded
> mailing list Linuxppc-embedded@ozlabs.org
> <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-24 19:22 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060823002801.GA2709@localhost>
On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
>
> Hi Stefan,
> Hi All
>
> On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:
>
> [ ... ]
>
> > The fact that Linux on the AlBook gets at least as far as "ieee1394:
> > Error parsing configrom for node 0-00:1023" indicates that not all hope
> > is lost. If you have got the time, compile the 1394 drivers for verbose
> > logging and send the log. Don't crosspost the log if it gets too big.
>
> Some tests on the Alubook:
.. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
created:
www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
Because i hate to burden my lousy memory with what I did to produce
the logs above, I scrambled together my admittedly marginal bash
knowledge and ran the tests with 4 scripts to produce the logs.
All the following below is to give you control on how these logs were
created. I'll try to be as verbose as possible. This because, as I
already made clear, I'm anything else but a bash expert. And because I
want to make sure the logs are not spoiled.
And please:
If you think the following is not necessary and instead only burdens
everyone else's mail box with KB that are not needed please let me
know ... :)
###########################################################
*** How
disable-irm.kern.log.when.fw.disk.is.switched.on.txt
was made
###########################################################
First the main script I run to get
disable-irm.kern.log.when.fw.disk.is.switched.on.txt
/home/shorty/scripts/ieee.test.sh:
------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \
sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \
cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
fi
-------------------------------------------------
As you can see above 2 more scripts are (hopefully :) executed inside
the latter script:
#1: /home/shorty/scripts/scsi.stop.sh:
-----------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.stop.sh; \
rmmod raw1394; \
rmmod eth1394;
rmmod ohci1394; \
rmmod sbp2; \
rmmod ieee1394
---------------------------------------
and #2: /home/shorty/scripts/scsi.start.sh:
------------------------------------------
#!/bin/sh -x
/bin/sh -n /home/shorty/scripts/scsi.start.sh; \
modprobe ieee1394 disable_irm=1; \
sleep 2; \
modprobe ohci1394; \
sleep 2; \
modprobe sbp2; \
sleep 2; \
modprobe raw1394; \
sleep 2
chown root.shorty /dev/raw1394
--------------------------------------------
This is what the shell was saying when running ieee.test.sh:
-----------------------------------------------------------
[root@ 20:39:50]# /home/shorty/scripts/ieee.test.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.sh
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.sh; \
/home/shorty/scripts/scsi.stop.sh; \
/home/shorty/scripts/scsi.start.sh; \
sleep 2; \
/home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux; \
cat /dev/null > /var/log/kern.log; \
echo "===> NOW SWITCH ON THE FW DISK <===="; \
sleep 70; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ]; t
hen
rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switch
ed.on.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switc
hed.on.txt
fi
+ /home/shorty/scripts/scsi.stop.sh
+ /bin/sh -n /home/shorty/scripts/scsi.stop.sh
+ rmmod raw1394
ERROR: Module raw1394 does not exist in /proc/modules
+ rmmod eth1394
+ rmmod ohci1394
+ rmmod sbp2
+ rmmod ieee1394
+ /home/shorty/scripts/scsi.start.sh
+ /bin/sh -n /home/shorty/scripts/scsi.start.sh
+ modprobe ieee1394 disable_irm=1
+ sleep 2
+ modprobe ohci1394
+ sleep 2
+ modprobe sbp2
+ sleep 2
+ modprobe raw1394
+ sleep 2
+ chown root.shorty /dev/raw1394
+ sleep 2
+ /home/shorty/kernel-factory/git.060822/linux-2.6/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux debby1-6 2.6.18-rc4-ieeeverbose-gef7d1b24-dirty #1 Tue Aug 22 22:18:50 CES
T 2006 ppc GNU/Linux
Gnu C 4.1.2
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
pcmcia-cs 3.2.8
Linux C Library 2.3.6
Dynamic linker (ldd) 2.3.6
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
udev 097
Modules Loaded raw1394 sbp2 eth1394 ohci1394 ieee1394 bluetooth radeon d
rm nfs nfsd exportfs lockd nfs_acl sunrpc ipv6 therm_adt746x sr_mod cpufreq_powe
rsave cpufreq_performance scsi_mod apm_emu joydev appletouch snd_aoa_codec_onyx
usbhid snd_aoa_fabric_layout snd_aoa pcmcia firmware_class snd_aoa_i2sbus snd_pc
m_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc sungem sungem_phy pmac_zilo
g serial_core snd ehci_hcd ide_cd evdev uninorth_agp agpgart i2c_powermac ohci_h
cd yenta_socket rsrc_nonstatic pcmcia_core cdrom soundcore snd_aoa_soundbus usbc
ore
+ cat /dev/null
+ echo '===> NOW SWITCH ON THE FW DISK <===='
===> NOW SWITCH ON THE FW DISK <====
+ sleep 70
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.when.fw.disk.is.switche
d.on.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.when.fw.disk.is.switched
.on.txt
[root@ 20:42:36]#
------------------------------------------------------------
########################################################################
*** How
disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
was made
########################################################################
disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
covers one of at least 2 instances when I started gscanbus a few
minutes after failing to connect the firewire disk to the alubook with
the very first script, i.e. ieee.test.sh.
I turned on a bus reset from within gscanbus.
/home/shorty/scripts/ieee.test.with.gscanbus.sh:
-----------------------------------------------------
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \
echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
fi
---------------------------
Shell output when running ieee.test.with.gscanbus.sh:
-----------------------------------------
# /home/shorty/scripts/ieee.test.with.gscanbus.sh
+ /bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh
#!/bin/sh -x
/bin/sh -nv /home/shorty/scripts/ieee.test.with.gscanbus.sh; \
echo "====> NOW RUN gscanbus ... <====="; \
cat /dev/null > /var/log/kern.log; \
sleep 120; \
ls /dev/sda*; \
if [ -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti
on.txt ]; then
rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connec
tion.txt
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
else
cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.f
ailed.fw.connection.txt
fi
+ echo '====> NOW RUN gscanbus ... <====='
====> NOW RUN gscanbus ... <=====
+ cat /dev/null
+ sleep 120
+ ls '/dev/sda*'
ls: /dev/sda*: No such file or directory
+ '[' -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connect
ion.txt ']'
+ rm -f /home/shorty/disable-irm.kern.log.with.gscanbus.after.failed.fw.connecti
on.txt
+ cp /var/log/kern.log /home/shorty/disable-irm.kern.log.with.gscanbus.after.fai
led.fw.connection.txt
+ chown shorty.shorty /home/shorty/disable-irm.kern.log.with.gscanbus.after.fail
ed.fw.connection.txt
[root@ 20:52:04]#
------------------------------------------
3 nodes inside the gscanbus window:
#1:
--------------------------
SelfID Info
-----------
Physical ID: 0
Link active: Yes
Gap Count: 63
PHY Speed: Unknown
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Port 2: Not connected
Init. reset: Yes
CSR ROM Info
------------
GUID: 0x001451FFFE3148BE
Node Capabilities: 0x000083C0
Vendor ID: 0x00001451
Unit Spec ID: 0x0000005E
Unit SW Version: 0x00000001
Model ID: 0x00000000
Nr. Textual Leafes: 1
Vendor: Unknown
Textual Leafes:
Linux - ohci1394
AV/C Subunits
-------------
N/A
-------------------------
#2:
---------------------
SelfID Info
-----------
Physical ID: 1
Link active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: None
Port 0: Connected to parent node
Port 1: Not connected
Port 2: Not connected
Init. reset: No
CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0
Vendor: (null)
Textual Leafes:
AV/C Subunits
-------------
N/A
-------------------------
#3
-----------------------------
SelfID Info
-----------
Physical ID: 2
Link active: No
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: No
Power Class: -1W
Port 0: Not connected
Port 1: Connected to child node
Port 2: Connected to child node
Init. reset: No
CSR ROM Info
------------
GUID: 0x0000000000000000
Node Capabilities: 0x00000000
Vendor ID: 0x00000000
Unit Spec ID: 0x00000000
Unit SW Version: 0x00000000
Model ID: 0x00000000
Nr. Textual Leafes: 0
Vendor: (null)
Textual Leafes:
AV/C Subunits
-------------
N/A
--------------------------------
And this was what the xterm was telling from where I ran gscanbus:
------------------------------------------
$ gscanbus
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000494: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000428: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff000042c: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000464: read failed
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
Error while reading from IEEE1394: : Resource temporarily unavailable
1/0x0000fffff0000400: read failed
1/0x0000fffff0000400: wrong bus info block length
--------------------------------------------
HTH
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: Platform device style question
From: Ben Warren @ 2006-08-24 18:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060824220625.515d9b3c@vitb.ru.mvista.com>
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
^ permalink raw reply
* [2.6.18-rc2] Oops in load_elf_binary...
From: Guennadi Liakhovetski @ 2006-08-24 18:39 UTC (permalink / raw)
To: linuxppc-dev
Hi,
my Kurobox crashes randomly at startup with
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 128k init
Oops: Exception in kernel mode, sig: 4 [#1]
NIP: 00000388 LR: C008D464 CTR: C003D5A0
REGS: c044fc30 TRAP: 0700 Not tainted (2.6.18-rc2-kuroboxHG)
MSR: 00081002 <ME> CR: 24048448 XER: 20000000
TASK = c0449b40[1] 'init' THREAD: c044e000
GPR00: 0000092F C044FCE0 C0449B40 00000000 00000930 00000000 100196CC 10000000
GPR08: 00000930 00009032 00001002 0044FCE0 C000FD9C 1003B600 10019E6C 100196D0
GPR16: C05B38E0 C044FEC0 10000000 00000001 00000007 C05A77C0 00000001 00000000
GPR24: C06A8D00 C0250000 00000000 100193A0 C059C200 00000000 C05B39C0 C06AA980
NIP [00000388] 0x388
LR [C008D464] padzero+0x50/0x9c
Call Trace:
[C044FCE0] [00101877] 0x101877 (unreliable)
[C044FDA0] [00000000] 0x0
[C044FDB0] [C008DD2C] load_elf_binary+0x7c0/0x12d8
[C044FE50] [C0069AC8] search_binary_handler+0x84/0x260
[C044FE70] [C0069DE0] do_execve+0x13c/0x1ec
[C044FE90] [C000BEBC] sys_execve+0x58/0x94
[C044FEB0] [C0004220] ret_from_syscall+0x0/0x38
[C044FF70] [C0070974] sys_dup+0x24/0x3c
[C044FF80] [C00038EC] init+0x1bc/0x2e4
[C044FFF0] [C0006554] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
What can it be? IDE?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-24 18:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <9861097B-ACAD-45E6-9FA7-B86F0C1E8FA1@kernel.crashing.org>
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.
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Kumar Gala @ 2006-08-24 18:25 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1156430695.17977.28.camel@saruman.qstreams.net>
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
^ permalink raw reply
* Re: Platform device style question
From: Vitaly Bordug @ 2006-08-24 18:06 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
In-Reply-To: <1156441997.17977.44.camel@saruman.qstreams.net>
On Thu, 24 Aug 2006 13:53:17 -0400
Ben Warren <bwarren@qstreams.com> 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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 17:57 UTC (permalink / raw)
To: Peter Ryser, ppc
In-Reply-To: <44EDD947.3000105@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
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 <peter.ryser@xilinx.com> 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@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@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@ozlabs.org
> > [mailto: linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> > ]
> > On Behalf Of Frank D Lombardo
> > Sent: Donnerstag, 24. August 2006 15:59
> > To: linuxppc-embedded@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@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> ------------------------------
>
> _______________________________________________ Linuxppc-embedded mailing
> list Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 6041 bytes --]
^ permalink raw reply
* Platform device style question
From: Ben Warren @ 2006-08-24 17:53 UTC (permalink / raw)
To: linuxppc-embedded
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
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Peter Ryser @ 2006-08-24 16:52 UTC (permalink / raw)
To: Wade Maxfield; +Cc: linuxppc-embedded
In-Reply-To: <45a1b53e0608240836l52ed51b5u309e31dd8486cc5b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
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@kontron.com
> <mailto:claus.gindhart@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@kontron-modular.com
> <mailto:claus.gindhart@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@ozlabs.org
> <mailto:kontron.com@ozlabs.org>
> [mailto:
> linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org
> <mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org>]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@ozlabs.org <mailto:linuxppc-embedded@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@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 4744 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Segher Boessenkool @ 2006-08-24 15:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, arnd, segher
In-Reply-To: <17645.18647.720814.903612@cargo.ozlabs.ibm.com>
> Also it would be really nice if you could figure out a way to
> avoid doing the unnecessary 64-bit logical operations on 32-bit
> machines
Like I asked before -- should we run this emulation on 32-bit
machines at all? The instruction only exists in the 64-bit
architecture after all.
Segher
^ permalink raw reply
* RE: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Rick Moleres @ 2006-08-24 15:40 UTC (permalink / raw)
To: Michael Galassi, Frank D Lombardo; +Cc: linuxppc-embedded
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: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of Michael Galassi
Sent: Thursday, August 24, 2006 9:18 AM
To: Frank D Lombardo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MontaVista 2.6 Kernel support for Xilinx ML40x=20
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.
=20
/*******************************************************************
*
* 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)=20
>available for the Xilinx ML40x series of boards. I would assume that=20
>means driver support for at least most of the hardware on the boards. =20
>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@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Wade Maxfield @ 2006-08-24 15:36 UTC (permalink / raw)
To: Claus Gindhart; +Cc: linuxppc-embedded
In-Reply-To: <DADA32856852FC458E0F96B664A6F55E011E2423@kom-mailsrv1.kontron-modular.com>
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
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@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@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@ozlabs.org
> [mailto:linuxppc-embedded-bounces+claus.gindhart=kontron.com@ozlabs.org]
> On Behalf Of Frank D Lombardo
> Sent: Donnerstag, 24. August 2006 15:59
> To: linuxppc-embedded@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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 3528 bytes --]
^ permalink raw reply
* Re: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Michael Galassi @ 2006-08-24 15:17 UTC (permalink / raw)
To: Frank D Lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44EDB0A8.4040200@mdivac.com>
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
^ permalink raw reply
* RE: MontaVista 2.6 Kernel support for Xilinx ML40x
From: Claus Gindhart @ 2006-08-24 15:02 UTC (permalink / raw)
To: Frank D Lombardo, linuxppc-embedded
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=20
under the terms of the GPL.
--=20
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@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------
=20
-----Original Message-----
From: linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+claus.gindhart=3Dkontron.com@ozlabs.org=
]
On Behalf Of Frank D Lombardo
Sent: Donnerstag, 24. August 2006 15:59
To: linuxppc-embedded@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)=20
available for the Xilinx ML40x series of boards. I would assume that=20
means driver support for at least most of the hardware on the boards. =20
Is this code that should be freely available? How would one get a copy=20
of these drivers? I am interested in drivers for the ML403.
Thanks,
Frank
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: CompactFlash on PQII Pro
From: Ben Warren @ 2006-08-24 14:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <AB150E9C-6BB3-46C1-980D-311D3277BFC1@kernel.crashing.org>
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
^ permalink raw reply
* Re: atomic operations in user space
From: Brent Cook @ 2006-08-24 14:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Terry Liang
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC380@zch01exm20.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
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@ozlabs.org
> > [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On
>
> Behalf Of
>
> > Terry Liang
> > Sent: Thursday, August 24, 2006 3:04 AM
> > To: linuxppc-embedded@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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 2875 bytes --]
^ 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