* Re: Device tree and /proc/iomem question
From: robert lazarski @ 2007-11-28 21:45 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <7793CF97-2634-4EB2-B354-F842605BE2E6@kernel.crashing.org>
On Nov 28, 2007 2:02 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> Take a look at the device trees in the kernel source. You'll see we
> moved PCI around so its at the root level. Not sure if that's your
> issue.
>
> > I see all the above in /proc/device-tree/soc8548@e0000000 when booting
> > the kernel. I double checked my memory mapping in u-boot and it
> > appears to match my device tree. Yet I don't see any pci here:
> >
> > root:~> cat /proc/iomem
> > e0004500-e0004507 : serial
> > e0004600-e0004607 : serial
> > e0024000-e0024fff : ethernet
> > e0024520-e002453f : mdio
> > e0025000-e0025fff : ethernet
> > e0026000-e0026fff : ethernet
> > e0027000-e0027fff : ethernet
> >
> > cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
> > and all I see from dmesg is "PCI: Probing PCI hardware" . Any ideas?
>
> It seems like its not even really probing or finding the buses.
>
> Can you post what your board/platform code looks like?
>
> - k
>
Indeed, for 2.6.24RC2 I had to move PCI to the root level and I also
had some problems in my board/platform code. I still seem to have
problems though - I have a common intel pro 100 card in PCI1 that
doesn't seem to be detected. Here's what I have now:
bash-3.00# lspci -v
00:00.0 Class 0b20: 1057:0012 (rev 20)
Flags: bus master, 66Mhz, fast devsel, latency 128, IRQ 19
Memory at <unassigned> (32-bit, prefetchable)
Memory at <unassigned> (64-bit, non-prefetchable)
Memory at <unassigned> (64-bit, non-prefetchable)
Capabilities: [60] #00 [0000]
I need to run the bus at 33MHZ. The devices seem to mapped correctly now:
bash-3.00# cat /proc/iomem
80000000-9fffffff : /pci@e0008000
a0000000-bfffffff : /pcie@e000a000
c0000000-dfffffff : /pci@e000c000
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0024000-e0024fff : ethernet
e0024520-e002453f : mdio
e0025000-e0025fff : ethernet
e0026000-e0026fff : ethernet
e0027000-e0027fff : ethernet
bash-3.00# cat /proc/ioports
00000000-000fffff : /pci@e0008000
feefc000-ffefbfff : /pcie@e000a000
ffefe000-ffffdfff : /pci@e000c000
This is a custom 8548 board we are trying to bring PCI up on and I'm
not sure if the hardware has issues, or my code is the issue. Here's
my current PCI tree which is now at the root level. My u-boot memory
map matches this AFAICT. Any further ideas greatly appreciated:
pci@e0008000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 &mpic 2 1
8800 0 0 2 &mpic 3 1
8800 0 0 3 &mpic 4 1
8800 0 0 4 &mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 &mpic 3 1
9000 0 0 2 &mpic 4 1
9000 0 0 3 &mpic 2 1
9000 0 0 4 &mpic 1 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 ff>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <1fca055>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e0008000 1000>;
compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
device_type = "pci";
};
pci@e000c000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 &mpic 2 1
8800 0 0 2 &mpic 3 1
8800 0 0 3 &mpic 4 1
8800 0 0 4 &mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 &mpic 3 1
9000 0 0 2 &mpic 4 1
9000 0 0 3 &mpic 2 1
9000 0 0 4 &mpic 1 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 ff>;
ranges = <02000000 0 c0000000 c0000000 0 20000000
01000000 0 00000000 e2800000 0 00100000>;
clock-frequency = <1fca055>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e000c000 1000>;
compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
device_type = "pci";
};
pcie@e000a000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 (PEX) */
00000 0 0 1 &mpic 0 1
00000 0 0 2 &mpic 1 1
00000 0 0 3 &mpic 2 1
00000 0 0 4 &mpic 3 1>;
interrupt-parent = <&mpic>;
interrupts = <1a 2>;
bus-range = <0 ff>;
ranges = <02000000 0 a0000000 a0000000 0 20000000
01000000 0 00000000 e3000000 0 08000000>;
clock-frequency = <1fca055>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e000a000 1000>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <02000000 0 a0000000
02000000 0 a0000000
0 20000000
01000000 0 00000000
01000000 0 00000000
0 08000000>;
};
};
Thanks!
Robert
^ permalink raw reply
* Re: Why are CONFIG_LOCKDEP_SUPPORT, CONFIG_TRACE_IRQFLAGS_SUPPORT, and CONFIG_STACKTRACE_SUPPORT not defined for PowerPC?
From: Johannes Berg @ 2007-11-28 21:41 UTC (permalink / raw)
To: Tim Pepper; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <eada2a070711281336i41a7f149i2c1db7cd49c0fd69@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
> These work for me, but I don't think they're finalised yet so your
> mileage may vary:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=14171
> http://patchwork.ozlabs.org/linuxppc/patch?id=14172
FWIW, the second one doesn't work on my quad G5 but I have a version
that works... Haven't figured out yet what's wrong with this one.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Why are CONFIG_LOCKDEP_SUPPORT, CONFIG_TRACE_IRQFLAGS_SUPPORT, and CONFIG_STACKTRACE_SUPPORT not defined for PowerPC?
From: Tim Pepper @ 2007-11-28 21:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <474DC7D0.4080907@freescale.com>
On Nov 28, 2007 11:56 AM, Timur Tabi <timur@freescale.com> wrote:
> These three Kconfig options:
>
> CONFIG_LOCKDEP_SUPPORT
> CONFIG_TRACE_IRQFLAGS_SUPPORT
> CONFIG_STACKTRACE_SUPPORT
>
> Are not defined for ppc or powerpc, but they are defined for several other
> architectures. I'm trying to debug some semaphore locks in ALSA, and these
> defines are necessary to enable some other Kconfig features.
These work for me, but I don't think they're finalised yet so your
mileage may vary:
http://patchwork.ozlabs.org/linuxppc/patch?id=14171
http://patchwork.ozlabs.org/linuxppc/patch?id=14172
Tim
^ permalink raw reply
* Re: [RFC/PATCH 5/14] powerpc: Fix 440/440A machine check handling
From: Olof Johansson @ 2007-11-28 21:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1195675525.6970.100.camel@pasglop>
On Thu, Nov 22, 2007 at 07:05:25AM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-11-21 at 13:51 -0600, Josh Boyer wrote:
> > > Hrm... it's per processor, not per board. I didn't feel like digging
> > > which board uses which processor and go fixup all the ppc_md's
> >
> > Sounds like something a generic function could probe for from the DTS.
> > I'll look at doing something here when I start making 44x
> > multiplatform
> > (soon).
>
> Well... we already probe the CPU type.... from cputable.
>
> So if there was a place to put that, it would be the cputable.
It could make sense to have _both_ platform (ppc_md) and cputable
functions, since some info is likely to be core-specific, other might
be board/chipset/SoC-specific.
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Geoff Levand @ 2007-11-28 21:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mel Gorman, linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <200711281730.40907.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 28 November 2007, Mel Gorman wrote:
>> On (28/11/07 08:26), Arnd Bergmann didst pronounce:
>> > On Wednesday 28 November 2007, Jon Tollefson wrote:
>> > > This patch adds the hugepagesz boot-time parameter for ppc64 that lets
>> > > you pick the size for your huge pages. The choices available are 64K
>> > > and 16M. It defaults to 16M (previously the only choice) if nothing or
>> > > an invalid choice is specified. Tested 64K huge pages with the
>> > > libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
>> > > invocations.
>> >
>> > How hard would it be to add the 1MB page size that some CPUs support
>> > as well? On systems with small physical memory like the PS3, that
>> > sounds very useful to me.
>> >
>>
>> Does the PS3 support 1M pages in hardware? When I last looked, the magic
>> ibm,segment-page-sizes file that described the supported pagesizes was
>> missing from the device tree. In this situation, the default sizes
>> become 4K and 16M because no other ones are advertised.
>
> I think you can select the page size using a hypercall on the PS3.
> The CPU supports any two of (64k, 1M, 16M) simultaneously.
The PS3's hypervisor allows you to create the lpar's virtual address
space with two page sizes. I currently have this hard coded to 64K
and 16M. Within the address space you create memory regions. I have
the hot-plug memory mapped in as a single region that is hard coded
as 16M pages.
The current HV implementation only allows you to create an htab of
at maximum 1M, so that influences how you can configure page sizes.
Just as a note, since the amount of memory available to the Linux lpar
is not a multiple of 16M, some of the available hot-plug memory is not
mapped into the address space. For firmware 1.90, 8M is unused. I
was thinking to create another region for that memory and put things
like the storage bounce buffers in there. Maybe I'll use 1M pages
for that memory.
-Geoff
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Alessandro Zummo @ 2007-11-28 20:34 UTC (permalink / raw)
To: rtc-linux; +Cc: linuxppc-embedded
In-Reply-To: <474DC326.6070209@anagramm.de>
On Wed, 28 Nov 2007 20:36:06 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:
> My current
> .config as well as the dmesg is attached with your
> suggested changes.
one more test, please. can you try compiling rtc-ds1307 as
a module and then kick it in via modprobe?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: MPC5200 I2C and 2.6 kernel
From: Wolfgang Denk @ 2007-11-28 20:22 UTC (permalink / raw)
To: Oliver Rutsch; +Cc: Linuxppc-dev
In-Reply-To: <474BEC4F.3080800@sympatec.com>
In message <474BEC4F.3080800@sympatec.com> you wrote:
>
> Regardless what I'm doing in the 2.6 kernel configuration I can't get
> this RTC running (I activated RTC support and the driver for the M41T00
> in the configuration).
> hwclock --debug tells me:
> hwclock: Open of /dev/rtc failed, errno=19: No such device.
Well... did you check how your /dev/rtc is set up? It used to be a
misc device with MAJ=10 MIN=135 in old kernel versions, but now it's
MAJ=254 MIN=4, i. e. it should look like this:
crw-r--r-- 1 root root 254, 0 Jun 22 18:30 /dev/rtc
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
For every complex problem, there is a solution that is simple, neat,
and wrong. -- H. L. Mencken
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-11-28 20:18 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1196208960.11297.26.camel@farscape.rchland.ibm.com>
On Tue, Nov 27, 2007 at 06:15:59PM -0600, Will Schmidt wrote:
> (resending with the proper "from" addr this time).
>
>
> I'm seeing some funky behavior on power5/power6 partitions with this
> patch. A "/sbin/reboot" is now behaving much more like a
> "/sbin/halt".
>
> Anybody else seeing this, or is it time for me to call an exorcist for
> my boxes?
I beleive the patch
http://www.nabble.com/-PATCH--powerpc-pseries:-tell-phyp-to-auto-restart-t4847604.html
will cure this problem.
>From that patch:
+/**
+ * pSeries_auto_restart - tell hypervisor that boot succeeded.
+ *
+ * The pseries hypervisor attempts to detect and prevent an
+ * infinite loop of kernel crashes and auto-reboots. It does
+ * so by refusing to auto-reboot unless we indicate that the
+ * current boot was sucessful. So, indicate success late in
+ * the boot sequence.
+ */
FYI, I am leaving IBM in just a few days now, and won't really
have much of a chance to debug this, if there are other problems.
This pair of patches was required to make hypervisor-assisted
dump work, viz, we need to tell the hypervisor about when we
crashed, or didn't crash, so that if we crashed, the dump can
be taken appropriately.
It occurs to me that, as I write this, that maybe xmon 'zr'
command should be modified to call pSeries_auto_restart just
in case, so that it actually reboots. There might be another
funky code path that I can't think of right now.
--linas
^ permalink raw reply
* Re: FW: CRS - #454833 is assigned to Amit Kasat for review by eliasd
From: John Bonesio @ 2007-11-28 20:16 UTC (permalink / raw)
To: Simon George; +Cc: linuxppc-embedded
In-Reply-To: <100AE4142881A8489779BF55E1832B3A06E98200@XIR-EXCHVS1.xlnx.xilinx.com>
Hi all,
Sorry for the spam. This was not intended for this list. Please ignore.
- John
On Wednesday 28 November 2007 12:11, Simon George wrote:
> Hi John
>
> Id you mean to send that to the linuxppc alias?
>
> Looks a rather internal email!
>
> Regards
>
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ---
>
> Simon George
> Embedded Specialist (Northern Europe)
>
> XILINX (UK) - Benchmark House, 203 Brooklands Road, WEYBRIDGE, Surrey
> KT13 0RH (UK)
> Office: +44 (0)870 7350 557 Mobile: +44 (0)7901 551704
> FAX: +44 (0)707 5023179
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> ---
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+simon.george=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+simon.george=xilinx.com@ozlabs.org] On
> Behalf Of John Bonesio
> Sent: 28 November 2007 19:49
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by
> eliasd
>
> Hi Rick,
>
> I just checked more closely. The linux 2.6 mld uses the following
> directories:
> $XILINX_EDK/sw/ThirdParty/bsp/$MLD_version
> $XILINX_EDK/sw/XilinxProcessorIPLib/drivers
> <project directory>/bsp/$MLD_version
>
> If 'edk_user_repository', is an actual directory name, then it is not
> used in the Linux MLD.
>
> - John
>
>
> On Wednesday 28 November 2007 10:15, Rick Moleres wrote:
> >
> > John,
> >
> > So, the Linux MLD does use the edk_repository to search for drivers
> > etc...?
> >
> > Thanks,
> > Rick
> >
> > -----Original Message-----
> > From: John Bonesio [mailto:jbonesio@xilinx.com]
> > Sent: Wednesday, November 28, 2007 10:54 AM
> > To: Rick Moleres
> > Cc: embedded_ip_sw
> > Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> >
> > Hi Rick,
> >
> > It's possible we may need to change some (all?) of our mld's, but the
> > change should be small (on the order of 1-5 lines).
> >
> > - John
> >
> > On Wednesday 28 November 2007 08:20, Rick Moleres wrote:
> > > All,
> > >
> > >
> > >
> > > Does this impact any of our MLDs?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Rick
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: Chang Sun
> > > Sent: Tuesday, November 27, 2007 6:13 PM
> > > To: Amit Kasat; Randy Robinson; Rick Moleres
> > > Subject: RE: CRS - #454833 is assigned to Amit Kasat for review by
> > > eliasd
> > >
> > >
> > >
> > > Hi Amit,
> > >
> > >
> > >
> > > I included Rick for this comment/suggestion, since Rick's team has
> > been
> > > doing most of the RTOS MLD integration work (Linux and VxWorks).
> Rick
> > > should be able to suggest the level of impact by this change.
> > >
> > > We also have some partners, e.g. Mentor Graphics supporting the MLD
> > > integration directly, so I hope this change has no major impact on
> > them,
> > > assuming we provide them well documented instructions.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Chang
> > >
> > > ________________________________
> > >
> > > From: Amit Kasat
> > > Sent: Tuesday, November 27, 2007 2:30 PM
> > > To: Randy Robinson; Chang Sun
> > > Subject: FW: CRS - #454833 is assigned to Amit Kasat for review by
> > > eliasd
> > >
> > >
> > >
> > > Hi Randy, Chang:
> > >
> > >
> > >
> > > I would like to deprecate this mechanism of automatically reading
> > > edk_user_repository if this directory exists at the same level at
> EDK
> > > installation. I believe some of our Board and MLD partners use this
> > > mechanism. Going forward, we would like them to use the setting in
> XPS
> > > Gui's
> > >
> > >
> > >
> > > Edit -> Preferences -> Application Preferences -> Global Peripheral
> > > Repository
> > >
> > >
> > >
> > > This is a much better, documented and GUI-supported way of
> specifiying
> > > peripheral repository path that's picked up automatically for all
> > > projects.
> > >
> > >
> > >
> > > We will need to tell the partners to start using the new mechanism.
> > This
> > > mechanism gives them the flexibility to use any directory to install
> > > their XBD/MLDs and point to it using this setting.
> > >
> > >
> > >
> > > The edk_cr_review_team did not have any concerns about it. I just
> > wanted
> > > to make sure you guys are ok with it too.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Amit
> > >
> > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: crs@xilinx.com [mailto:crs@xilinx.com]
> > >
> > > > Sent: Tuesday, November 27, 2007 2:19 PM
> > >
> > > > To: Amit Kasat
> > >
> > > > Subject: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> > >
> > > >
> > >
> > > > http://governator:9089/itg/html/kintanaHome.html
> > >
> > > >
> > >
> > > >
> > >
> > > > CR #: 454833
> > >
> > > > CR Link:
> > >
> > > >
> > >
> >
> http://governator:9089/itg//web/knta/crt/RequestDetail.jsp?REQUEST_ID=45
> > > 48
> > >
> > > > 33
> > >
> > > > Created By: Amit Kasat
> > >
> > > > Creation Date: 20-NOV-07
> > >
> > > > Description: Deprecate and then remove support of
> > > built in
> > >
> > > > reposiotry - $XILINX_EDK/../edk_user_repository
> > >
> > > > Status: New
> > >
> > > > Application: EDK_General
> > >
> > > > Assigned Group: EDK
> > >
> > > > Assigned To: Amit Kasat
> > >
> > > > Priority: 3
> > >
> > > > Version Found: EDK_K.9
> > >
> > > > To Be Fixed Version:
> > >
> > > > Apps Priority: NA
> > >
> > > > Details: Currently, If a directory named
> > >
> > > > edk_user_repository is present at the same level as EDK
> > isntallation,
> > > then
> > >
> > > > it is automaticaly added to the search path for pcores, drivers
> etc.
> > >
> > > > However, in EDK 9.1, we added concept of Global Peripheral
> > Repository
> > >
> > > > which allows users to add such a setting as a preference through
> the
> > > GUI
> > >
> > > > and make it applicable to all thier projects.
> > >
> > > >
> > >
> > > > This is a much cleaner mechanism of handling these search paths. I
> > > would
> > >
> > > > like to deprecate usage of the edk_user_repository from tools in
> > EDK_K
> > >
> > > > (issue a warning) and stop reading it in EDK_L.
> > >
> > > >
> > >
> > > > These options are not used much and we woud like to cleanup to
> > reduce
> > >
> > > > testing and corner case issues.
> > >
> > > >
> > >
> >
> ------------------------------------------------------------------------
> > > --
> > >
> > > > ---------------------------
> > >
> > > > Notes:
> > >
> > > > Elias Dabbagh(eliasd) November 27, 2007 02:18 PM:
> > >
> > > > Assigned To to Amit Kasat
> > >
> > > >
> > >
> > > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> > >
> > > > Public Data Directory /public/bugcases to
> > >
> > > > http://governator:1111/public/bugcases/454000-454999/454833/
> > >
> > > >
> > >
> > > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> > >
> > > > Owner to akasat
> > >
> > > >
> > >
> > > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> > >
> > > > Request Status Not Submitted to New
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> > > >
> > >
> >
> ========================================================================
> > > ==
> > >
> > > > ==
> > >
> > > >
> > >
> > >
> > >
> > >
> >
> > --
> > +-------------------------------+
> > | This space for rent
> > +-------------------------------+
> >
>
> --
> +-------------------------------+
> | This space for rent
> +-------------------------------+
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
+-------------------------------+
| This space for rent
+-------------------------------+
^ permalink raw reply
* Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Benjamin Herrenschmidt @ 2007-11-28 20:15 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <20071128194727.GA22325@gate.ebshome.net>
On Wed, 2007-11-28 at 11:47 -0800, Eugene Surovegin wrote:
> On Tue, Nov 27, 2007 at 10:41:46AM +1100, Benjamin Herrenschmidt wrote:
> > BTW... Do you know why we can't just enable HW snoop ? The 440SPe
> > documentation seems to indicate that this is supported by the L2 cache
> > via snooping on the PLB.
>
> Unless something has been changed significantly in the 44x port, but
> L2 cache code I wrote for 440GX did exactly this - we never needed any
> manual L2 cache management at all.
Ah good. So we should port that code over instead.
Thanks !
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Linas Vepstas @ 2007-11-28 20:09 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071128110037.GB31217@aepfle.de>
On Wed, Nov 28, 2007 at 12:00:37PM +0100, Olaf Hering wrote:
> On Tue, Nov 27, Will Schmidt wrote:
>
> > > -void rtas_os_term(char *str)
> > > +void rtas_panic_msg(char *str)
>
> > > - if (panic_timeout)
> > > - return;
>
> This change is wrong. Booting with panic=123 really means the system
> has to reboot in 123 seconds after a panic.
And it does.
> But, maybe this panic_timeout check was moved elsewhere.
It was *always* somewhere else; the check here was always wrong.
This change makes the os-term call happen after the the panic
timeout amount of time has elapsed.
--linas
^ permalink raw reply
* Re: [PATCH 0/2] [PPC 4xx] L2-cache synchronization for ppc44x
From: Eugene Surovegin @ 2007-11-28 19:50 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <7310408706.20071107014010@emcraft.com>
On Wed, Nov 07, 2007 at 01:40:10AM +0300, Yuri Tikhonov wrote:
>
> Hello all,
>
> Here is a patch-set for support L2-cache synchronization routines for
> the ppc44x processors family. I know that the "ppc" branch is for bug-fixing only, thus
> the patch-set is just FYI [though enabled but non-coherent L2-cache may appear as a bug for
> someone who uses one of the boards listed below :)].
>
> [PATCH 1/2] [PPC 4xx] invalidate_l2cache_range() implementation for ppc44x;
> [PATCH 2/2] [PPC 44x] enable L2-cache for the following ppc44x-based boards: ALPR,
> Katmai, Ocotea, and Taishan.
Why is this all needed?
IIRC ibm440gx_l2c_enable() configures 64G snoop region for L2C.
Did AMCC made non-only-coherent L2C chips recently?
--
Eugene
^ permalink raw reply
* [PATCH] Stop phy code from returning success to unknown ioctls.
From: David Woodhouse @ 2007-11-28 19:56 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, Domen Puncer, netdev
In-Reply-To: <1196273071.30806.46.camel@pmac.infradead.org>
This kind of sucks, and prevents the Fedora installer from using the
device for network installs...
[root@efika phy]# iwconfig eth0
Warning: Driver for device eth0 has been compiled with an ancient version
of Wireless Extension, while this program support version 11 and later.
Some things may be broken...
eth0 ESSID:off/any Nickname:""
NWID:0 Channel:0 Access Point: 00:00:BF:81:14:E0
Bit Rate:-1.08206e+06 kb/s Sensitivity=0/0
RTS thr:off Fragment thr:off
Encryption key:<too big>
Power Management:off
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9bc1177..7c9e6e3 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -406,6 +406,9 @@ int phy_mii_ioctl(struct phy_device *phydev,
&& phydev->drv->config_init)
phydev->drv->config_init(phydev);
break;
+
+ default:
+ return -ENOTTY;
}
return 0;
--
dwmw2
^ permalink raw reply related
* Why are CONFIG_LOCKDEP_SUPPORT, CONFIG_TRACE_IRQFLAGS_SUPPORT, and CONFIG_STACKTRACE_SUPPORT not defined for PowerPC?
From: Timur Tabi @ 2007-11-28 19:56 UTC (permalink / raw)
To: linuxppc-dev
These three Kconfig options:
CONFIG_LOCKDEP_SUPPORT
CONFIG_TRACE_IRQFLAGS_SUPPORT
CONFIG_STACKTRACE_SUPPORT
Are not defined for ppc or powerpc, but they are defined for several other
architectures. I'm trying to debug some semaphore locks in ALSA, and these
defines are necessary to enable some other Kconfig features.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Eugene Surovegin @ 2007-11-28 19:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, sr, dzu
In-Reply-To: <1196120506.7157.18.camel@pasglop>
On Tue, Nov 27, 2007 at 10:41:46AM +1100, Benjamin Herrenschmidt wrote:
> BTW... Do you know why we can't just enable HW snoop ? The 440SPe
> documentation seems to indicate that this is supported by the L2 cache
> via snooping on the PLB.
Unless something has been changed significantly in the 44x port, but
L2 cache code I wrote for 440GX did exactly this - we never needed any
manual L2 cache management at all.
--
Eugene
^ permalink raw reply
* Re: dtc: RFC: Fix some lexical problems with references
From: Jon Loeliger @ 2007-11-28 19:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Benjamin Herrenschmidt @ 2007-11-28 19:52 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: netdev, Kok, Auke-jan H, Jeff Garzik, linuxppc-dev
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203DF7871@orsmsx418.amr.corp.intel.com>
On Wed, 2007-11-28 at 10:47 -0800, Brandeburg, Jesse wrote:
>
> > The side effect is that I removed the assignments to the netdev
> > fields mem_start, mem_end and base_addr, which are totally useless
> > for PCI devices.
>
> also, concerning this, ifconfig shows the output of these variables, I
> don't think we want to blatantly remove them, as it is actually removing
> information that is, if not used, at least displayed to user space.
It's not the right place to have that information and there is no
room in the user space field to fit more than 32 bits on 32 bits
platforms so I'd rather remove it. It's really only for ISA drivers that
have user configurable addresses.
Ben.
^ permalink raw reply
* Re: FW: CRS - #454833 is assigned to Amit Kasat for review by eliasd
From: John Bonesio @ 2007-11-28 19:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C0565CBFB@XCO-EXCHVS1.xlnx.xilinx.com>
Hi Rick,
I just checked more closely. The linux 2.6 mld uses the following directories:
$XILINX_EDK/sw/ThirdParty/bsp/$MLD_version
$XILINX_EDK/sw/XilinxProcessorIPLib/drivers
<project directory>/bsp/$MLD_version
If 'edk_user_repository', is an actual directory name, then it is not used in the Linux MLD.
- John
On Wednesday 28 November 2007 10:15, Rick Moleres wrote:
>
> John,
>
> So, the Linux MLD does use the edk_repository to search for drivers
> etc...?
>
> Thanks,
> Rick
>
> -----Original Message-----
> From: John Bonesio [mailto:jbonesio@xilinx.com]
> Sent: Wednesday, November 28, 2007 10:54 AM
> To: Rick Moleres
> Cc: embedded_ip_sw
> Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by
> eliasd
>
> Hi Rick,
>
> It's possible we may need to change some (all?) of our mld's, but the
> change should be small (on the order of 1-5 lines).
>
> - John
>
> On Wednesday 28 November 2007 08:20, Rick Moleres wrote:
> > All,
> >
> >
> >
> > Does this impact any of our MLDs?
> >
> >
> >
> > Thanks,
> >
> > Rick
> >
> >
> >
> > ________________________________
> >
> > From: Chang Sun
> > Sent: Tuesday, November 27, 2007 6:13 PM
> > To: Amit Kasat; Randy Robinson; Rick Moleres
> > Subject: RE: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> >
> >
> >
> > Hi Amit,
> >
> >
> >
> > I included Rick for this comment/suggestion, since Rick's team has
> been
> > doing most of the RTOS MLD integration work (Linux and VxWorks). Rick
> > should be able to suggest the level of impact by this change.
> >
> > We also have some partners, e.g. Mentor Graphics supporting the MLD
> > integration directly, so I hope this change has no major impact on
> them,
> > assuming we provide them well documented instructions.
> >
> >
> >
> > Thanks,
> >
> > Chang
> >
> > ________________________________
> >
> > From: Amit Kasat
> > Sent: Tuesday, November 27, 2007 2:30 PM
> > To: Randy Robinson; Chang Sun
> > Subject: FW: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> >
> >
> >
> > Hi Randy, Chang:
> >
> >
> >
> > I would like to deprecate this mechanism of automatically reading
> > edk_user_repository if this directory exists at the same level at EDK
> > installation. I believe some of our Board and MLD partners use this
> > mechanism. Going forward, we would like them to use the setting in XPS
> > Gui's
> >
> >
> >
> > Edit -> Preferences -> Application Preferences -> Global Peripheral
> > Repository
> >
> >
> >
> > This is a much better, documented and GUI-supported way of specifiying
> > peripheral repository path that's picked up automatically for all
> > projects.
> >
> >
> >
> > We will need to tell the partners to start using the new mechanism.
> This
> > mechanism gives them the flexibility to use any directory to install
> > their XBD/MLDs and point to it using this setting.
> >
> >
> >
> > The edk_cr_review_team did not have any concerns about it. I just
> wanted
> > to make sure you guys are ok with it too.
> >
> >
> >
> > Thanks,
> >
> > Amit
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: crs@xilinx.com [mailto:crs@xilinx.com]
> >
> > > Sent: Tuesday, November 27, 2007 2:19 PM
> >
> > > To: Amit Kasat
> >
> > > Subject: CRS - #454833 is assigned to Amit Kasat for review by
> eliasd
> >
> > >
> >
> > > http://governator:9089/itg/html/kintanaHome.html
> >
> > >
> >
> > >
> >
> > > CR #: 454833
> >
> > > CR Link:
> >
> > >
> >
> http://governator:9089/itg//web/knta/crt/RequestDetail.jsp?REQUEST_ID=45
> > 48
> >
> > > 33
> >
> > > Created By: Amit Kasat
> >
> > > Creation Date: 20-NOV-07
> >
> > > Description: Deprecate and then remove support of
> > built in
> >
> > > reposiotry - $XILINX_EDK/../edk_user_repository
> >
> > > Status: New
> >
> > > Application: EDK_General
> >
> > > Assigned Group: EDK
> >
> > > Assigned To: Amit Kasat
> >
> > > Priority: 3
> >
> > > Version Found: EDK_K.9
> >
> > > To Be Fixed Version:
> >
> > > Apps Priority: NA
> >
> > > Details: Currently, If a directory named
> >
> > > edk_user_repository is present at the same level as EDK
> isntallation,
> > then
> >
> > > it is automaticaly added to the search path for pcores, drivers etc.
> >
> > > However, in EDK 9.1, we added concept of Global Peripheral
> Repository
> >
> > > which allows users to add such a setting as a preference through the
> > GUI
> >
> > > and make it applicable to all thier projects.
> >
> > >
> >
> > > This is a much cleaner mechanism of handling these search paths. I
> > would
> >
> > > like to deprecate usage of the edk_user_repository from tools in
> EDK_K
> >
> > > (issue a warning) and stop reading it in EDK_L.
> >
> > >
> >
> > > These options are not used much and we woud like to cleanup to
> reduce
> >
> > > testing and corner case issues.
> >
> > >
> >
> ------------------------------------------------------------------------
> > --
> >
> > > ---------------------------
> >
> > > Notes:
> >
> > > Elias Dabbagh(eliasd) November 27, 2007 02:18 PM:
> >
> > > Assigned To to Amit Kasat
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Public Data Directory /public/bugcases to
> >
> > > http://governator:1111/public/bugcases/454000-454999/454833/
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Owner to akasat
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Request Status Not Submitted to New
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> ========================================================================
> > ==
> >
> > > ==
> >
> > >
> >
> >
> >
> >
>
> --
> +-------------------------------+
> | This space for rent
> +-------------------------------+
>
--
+-------------------------------+
| This space for rent
+-------------------------------+
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 19:36 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071128194321.0804b3aa@i1501.lan.towertech.it>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
>
> mmm. I've been told it should work ;)
>
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
>
> this one must be deselected.
>
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
>
> ditto.
>
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
>
> maybe the wrong driver is kicking in here.
> the fact that there is no rtc class
> related output in dmesg should and that
> there is no /dev/rtc0 could be a sign that the whole class
> is not going in.
>
> do you have full dmesg?
My current
.config as well as the dmesg is attached with your
suggested changes.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: dmesg-fail.txt --]
[-- Type: text/plain, Size: 15334 bytes --]
DEV: registering device: ID = 'tty47'
DEV: registering device: ID = 'tty48'
DEV: registering device: ID = 'tty49'
DEV: registering device: ID = 'tty50'
DEV: registering device: ID = 'tty51'
DEV: registering device: ID = 'tty52'
DEV: registering device: ID = 'tty53'
DEV: registering device: ID = 'tty54'
DEV: registering device: ID = 'tty55'
DEV: registering device: ID = 'tty56'
DEV: registering device: ID = 'tty57'
DEV: registering device: ID = 'tty58'
DEV: registering device: ID = 'tty59'
DEV: registering device: ID = 'tty60'
DEV: registering device: ID = 'tty61'
DEV: registering device: ID = 'tty62'
DEV: registering device: ID = 'tty63'
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
Registering platform device 'serial8250'. Parent at platform
DEV: registering device: ID = 'serial8250'
bus platform: add device serial8250
DEV: registering device: ID = 'ttyS0'
DEV: registering device: ID = 'ttyS1'
DEV: registering device: ID = 'ttyS2'
DEV: registering device: ID = 'ttyS3'
bus platform: add driver serial8250
platform: Matched Device serial8250.0 with Driver serial8250
platform: Probing driver serial8250 with device serial8250.0
DEV: Unregistering device. ID = 'ttyS0'
device_create_release called for ttyS0
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
DEV: registering device: ID = 'ttyS0'
DEV: Unregistering device. ID = 'ttyS1'
device_create_release called for ttyS1
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
DEV: registering device: ID = 'ttyS1'
bound device 'serial8250.0' to driver 'serial8250'
platform: Bound Device serial8250.0 to Driver serial8250
platform: Matched Device serial8250 with Driver serial8250
platform: Probing driver serial8250 with device serial8250
bound device 'serial8250' to driver 'serial8250'
platform: Bound Device serial8250 to Driver serial8250
bus pci: add driver serial
loop: module loaded
bus platform: add driver fsl-gianfar_mdio
platform: Matched Device fsl-gianfar_mdio.-5 with Driver fsl-gianfar_mdio
platform: Probing driver fsl-gianfar_mdio with device fsl-gianfar_mdio.-5
DEV: registering device: ID = 'e0024520:00'
bus mdio_bus: add device e0024520:00
DEV: registering device: ID = 'e0024520:1f'
bus mdio_bus: add device e0024520:1f
Gianfar MII Bus: probed
bound device 'fsl-gianfar_mdio.-5' to driver 'fsl-gianfar_mdio'
platform: Bound Device fsl-gianfar_mdio.-5 to Driver fsl-gianfar_mdio
bus platform: add driver fsl-gianfar
platform: Matched Device fsl-gianfar.0 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.0
DEV: registering device: ID = 'eth0'
eth0: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c4
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.0' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.0 to Driver fsl-gianfar
platform: Matched Device fsl-gianfar.1 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.1
DEV: registering device: ID = 'eth1'
eth1: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c5
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.1' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.1 to Driver fsl-gianfar
platform: Matched Device fsl-gianfar.2 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.2
DEV: registering device: ID = 'eth2'
eth2: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c6
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.2' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.2 to Driver fsl-gianfar
bus mdio_bus: add driver Marvell 88E1101
bus mdio_bus: add driver Marvell 88E1112
bus mdio_bus: add driver Marvell 88E1111
mdio_bus: Matched Device e0024520:00 with Driver Marvell 88E1111
mdio_bus: Probing driver Marvell 88E1111 with device e0024520:00
bound device 'e0024520:00' to driver 'Marvell 88E1111'
mdio_bus: Bound Device e0024520:00 to Driver Marvell 88E1111
bus mdio_bus: add driver Marvell 88E1145
bus mdio_bus: add driver Marvell 88E1240
bus mdio_bus: add driver LXT970
bus mdio_bus: add driver LXT971
DEV: registering device: ID = 'dummy0'
device class 'scsi_disk': registering
bus scsi: add driver sd
bus pci: add driver sata_promise
pci: Matched Device 0000:00:12.0 with Driver sata_promise
pci: Probing driver sata_promise with device 0000:00:12.0
sata_promise 0000:00:12.0: version 2.11
scsi0 : sata_promise
DEV: registering device: ID = 'host0'
CLASS: registering class device: ID = 'host0'
class_uevent - name = host0
scsi1 : sata_promise
DEV: registering device: ID = 'host1'
CLASS: registering class device: ID = 'host1'
class_uevent - name = host1
scsi2 : sata_promise
DEV: registering device: ID = 'host2'
CLASS: registering class device: ID = 'host2'
class_uevent - name = host2
ata1: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000200 irq 18
ata2: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000280 irq 18
ata3: PATA max UDMA/133 mmio m4096@0x80000000 port 0x80000300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
DEV: registering device: ID = 'target0:0:0'
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
DEV: registering device: ID = '0:0:0:0'
bus scsi: add device 0:0:0:0
scsi: Matched Device 0:0:0:0 with Driver sd
scsi: Probing driver sd with device 0:0:0:0
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
bound device '0:0:0:0' to driver 'sd'
scsi: Bound Device 0:0:0:0 to Driver sd
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
bound device '0000:00:12.0' to driver 'sata_promise'
pci: Bound Device 0000:00:12.0 to Driver sata_promise
bus pci: add driver pata_pdc2027x
usbmon: debugfs is not available
bus pci: add driver ehci_hcd
pci: Matched Device 0000:00:14.2 with Driver ehci_hcd
pci: Probing driver ehci_hcd with device 0000:00:14.2
ehci_hcd 0000:00:14.2: EHCI Host Controller
CLASS: registering class device: ID = 'usb_host1'
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
ehci_hcd 0000:00:14.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:14.2: irq 20, io mem 0x81202000
ehci_hcd 0000:00:14.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
DEV: registering device: ID = 'usb1'
bus usb: add device usb1
usb: Matched Device usb1 with Driver usb
usb: Probing driver usb with device usb1
device class 'usb_endpoint': registering
DEV: registering device: ID = 'usbdev1.1_ep00'
usb usb1: configuration #1 chosen from 1 choice
DEV: registering device: ID = '1-0:1.0'
bus usb: add device 1-0:1.0
usb: Matched Device 1-0:1.0 with Driver hub
usb: Probing driver hub with device 1-0:1.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
bound device '1-0:1.0' to driver 'hub'
usb: Bound Device 1-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev1.1_ep81'
DEV: registering device: ID = 'usbdev1.1'
bound device 'usb1' to driver 'usb'
usb: Bound Device usb1 to Driver usb
bound device '0000:00:14.2' to driver 'ehci_hcd'
pci: Bound Device 0000:00:14.2 to Driver ehci_hcd
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
bus of_platform: add driver ppc-of-ohci
bus pci: add driver ohci_hcd
pci: Matched Device 0000:00:14.0 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.0
ohci_hcd 0000:00:14.0: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host2'
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
ohci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:14.0: irq 20, io mem 0x81200000
DEV: registering device: ID = 'usb2'
bus usb: add device usb2
usb: Matched Device usb2 with Driver usb
usb: Probing driver usb with device usb2
DEV: registering device: ID = 'usbdev2.1_ep00'
usb usb2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '2-0:1.0'
bus usb: add device 2-0:1.0
usb: Matched Device 2-0:1.0 with Driver hub
usb: Probing driver hub with device 2-0:1.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
bound device '2-0:1.0' to driver 'hub'
usb: Bound Device 2-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev2.1_ep81'
DEV: registering device: ID = 'usbdev2.1'
bound device 'usb2' to driver 'usb'
usb: Bound Device usb2 to Driver usb
bound device '0000:00:14.0' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.0 to Driver ohci_hcd
pci: Matched Device 0000:00:14.1 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.1
ohci_hcd 0000:00:14.1: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host3'
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
ohci_hcd 0000:00:14.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:14.1: irq 20, io mem 0x81201000
DEV: registering device: ID = 'usb3'
bus usb: add device usb3
usb: Matched Device usb3 with Driver usb
usb: Probing driver usb with device usb3
DEV: registering device: ID = 'usbdev3.1_ep00'
usb usb3: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-0:1.0'
bus usb: add device 3-0:1.0
usb: Matched Device 3-0:1.0 with Driver hub
usb: Probing driver hub with device 3-0:1.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
bound device '3-0:1.0' to driver 'hub'
usb: Bound Device 3-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev3.1_ep81'
DEV: registering device: ID = 'usbdev3.1'
bound device 'usb3' to driver 'usb'
usb: Bound Device usb3 to Driver usb
bound device '0000:00:14.1' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.1 to Driver ohci_hcd
Initializing USB Mass Storage driver...
bus usb: add driver usb-storage
usb 3-2: new low speed USB device using ohci_hcd and address 2
DEV: registering device: ID = '3-2'
bus usb: add device 3-2
usb: Matched Device 3-2 with Driver usb
usb: Probing driver usb with device 3-2
DEV: registering device: ID = 'usbdev3.2_ep00'
usb 3-2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-2:1.0'
bus usb: add device 3-2:1.0
DEV: registering device: ID = 'usbdev3.2_ep81'
DEV: registering device: ID = 'usbdev3.2'
bound device '3-2' to driver 'usb'
usb: Bound Device 3-2 to Driver usb
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
bus type 'usb-serial' registered
bus usb: add driver usbserial
usbcore: registered new interface driver usbserial
bus usb-serial: add driver generic
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
bus usb: add driver usbserial_generic
usb: Matched Device 3-2:1.0 with Driver usbserial_generic
usb: Probing driver usbserial_generic with device 3-2:1.0
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
bus usb-serial: add driver ftdi_sio
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
bus usb: add driver ftdi_sio
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
bus usb-serial: add driver pl2303
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
bus usb: add driver pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
DEV: registering device: ID = 'mice'
DEV: registering device: ID = 'psaux'
mice: PS/2 mouse device common for all mice
bus usb: add driver usbtouchscreen
usb: Matched Device 3-2:1.0 with Driver usbtouchscreen
usb: Probing driver usbtouchscreen with device 3-2:1.0
DEV: registering device: ID = 'input0'
input: TSC-10 DM as /devices/pci0000:00/0000:00:14.1/usb3/3-2/3-2:1.0/input/input0
DEV: registering device: ID = 'mouse0'
DEV: registering device: ID = 'event0'
bound device '3-2:1.0' to driver 'usbtouchscreen'
usb: Bound Device 3-2:1.0 to Driver usbtouchscreen
usbcore: registered new interface driver usbtouchscreen
bus i2c: add driver rtc-ds1307
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
bus usb: add driver usbhid
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
DEV: registering device: ID = 'sit0'
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
driver_probe_done: probe_count = 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 120k init
class_uevent - name = 0000:00
class_uevent - name = 0:0:0:0
class_uevent - name = 0:0:0:0
class_uevent - name = host0
class_uevent - name = host1
class_uevent - name = host2
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
EXT3 FS on sda1, internal journal
Adding 2939884k swap on /dev/sda2. Priority:-1 extents:1 across:2939884k
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: registering device: ID = 'vcs2'
DEV: registering device: ID = 'vcsa2'
DEV: registering device: ID = 'vcs3'
DEV: registering device: ID = 'vcsa3'
DEV: registering device: ID = 'vcs5'
DEV: registering device: ID = 'vcsa5'
DEV: registering device: ID = 'vcs6'
DEV: registering device: ID = 'vcsa6'
DEV: registering device: ID = 'vcs4'
DEV: registering device: ID = 'vcsa4'
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present
[-- Attachment #3: .config --]
[-- Type: application/x-config, Size: 27428 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
From: Davide Libenzi @ 2007-11-28 19:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael Kerrisk, Arnd Bergmann, Linux Kernel Mailing List,
Kamalesh Babulal, linuxppc-dev, Paul Mackerras, Balbir Singh
In-Reply-To: <20071128104345.9474025e.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1248 bytes --]
On Wed, 28 Nov 2007, Andrew Morton wrote:
> On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > > Kernel build fails, with build error
> > >
> > > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > > make: *** [arch/powerpc/platforms] Error 2
> > >
> >
> > I guess all architectures except x86 are currently broken because they
> > reference the old sys_timerfd function.
>
> None of them were broken in my testing and I'm unsure why powerpc broke
> here.
>
> > This patch should add the missing
> > bits to powerpc.
> >
>
> Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
> _should_ have (incorrectly) picked those up.
My fault. I forgot to update sys_ni.c with the new functions (and with the
sys_timerfd->sys_timerfd_create name change).
Do you want a patch Andrew?
- Davide
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 19:20 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071128194321.0804b3aa@i1501.lan.towertech.it>
Hi, Alessandro!
Thank you for your quick response... I'll just follow your
ideas and provide you with the dmesg output ASAP.
If you are online for some more time, I will accelerate
this debugging session... Just let me know.
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
>
> mmm. I've been told it should work ;)
>
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
>
> this one must be deselected.
>
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
>
> ditto.
Will do.
>
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
>
> maybe the wrong driver is kicking in here.
> the fact that there is no rtc class
> related output in dmesg should and that
> there is no /dev/rtc0 could be a sign that the whole class
> is not going in.
>
> do you have full dmesg?
Not a full one from the 2.6.24 right now...
But I'll disable above stuff and get you a full one.
(in 5..10 minutes).
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Brandeburg, Jesse @ 2007-11-28 18:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kok, Auke-jan H; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071116073821.548CCDDDF4@ozlabs.org>
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>=20
> This fixes it by removing those temporary variables and passing
> directly the result of pci_resource_start/len to ioremap.
the patch is mostly fine, but looking through the tree, doesn't every
driver that has 64 bit capable resources have this problem?
in fact, skeleton module has this problem, if I'm not mistaken. e1000
isn't the only one. :-)
=20
> The side effect is that I removed the assignments to the netdev
> fields mem_start, mem_end and base_addr, which are totally useless
> for PCI devices.
also, concerning this, ifconfig shows the output of these variables, I
don't think we want to blatantly remove them, as it is actually removing
information that is, if not used, at least displayed to user space.
eth6 Link encap:Ethernet HWaddr 00:0E:01:0C:02:03
inet addr:134.134.3.121 Bcast:134.134.3.255
Mask:255.255.255.0
inet6 addr: fe80::20e:1ff:fe0c:203/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9022519 errors:0 dropped:0 overruns:0 frame:0
TX packets:1303701 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4044613454 (3857.2 Mb) TX bytes:118365109 (112.8 Mb)
Base address:0xf000 Memory:feac0000-feae0000
^^^^^^^^^^^^^^^^^
^ permalink raw reply
* Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
From: Andrew Morton @ 2007-11-28 18:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Kerrisk, linux-kernel, Kamalesh Babulal, linuxppc-dev,
Paul Mackerras, Davide Libenzi, Balbir Singh
In-Reply-To: <200711281432.09178.arnd@arndb.de>
On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > Kernel build fails, with build error
> >
> > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
> >
>
> I guess all architectures except x86 are currently broken because they
> reference the old sys_timerfd function.
None of them were broken in my testing and I'm unsure why powerpc broke
here.
> This patch should add the missing
> bits to powerpc.
>
Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
_should_ have (incorrectly) picked those up.
Odd.
>
> ---
>
> Disclaimer: Not tested at all, just applied common sense.
> Disclaimer2: conflicts with the sys_indirect kernel implementation
> sent by paulus last week.
>
> diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
> index 11d5383..b029368 100644
> --- a/include/asm-powerpc/systbl.h
> +++ b/include/asm-powerpc/systbl.h
> @@ -309,7 +309,9 @@ SYSCALL_SPU(getcpu)
> COMPAT_SYS(epoll_pwait)
> COMPAT_SYS_SPU(utimensat)
> COMPAT_SYS_SPU(signalfd)
> -COMPAT_SYS_SPU(timerfd)
> +COMPAT_SYS_SPU(timerfd_create)
> SYSCALL_SPU(eventfd)
> COMPAT_SYS_SPU(sync_file_range2)
> COMPAT_SYS(fallocate)
> +COMPAT_SYS_SPU(sys_timerfd_settime)
> +COMPAT_SYS_SPU(sys_timerfd_gettime)
> diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
> index 97d82b6..4ba2d20 100644
> --- a/include/asm-powerpc/unistd.h
> +++ b/include/asm-powerpc/unistd.h
> @@ -328,14 +328,16 @@
> #define __NR_epoll_pwait 303
> #define __NR_utimensat 304
> #define __NR_signalfd 305
> -#define __NR_timerfd 306
> +#define __NR_timerfd_create 306
> #define __NR_eventfd 307
> #define __NR_sync_file_range2 308
> #define __NR_fallocate 309
> +#define __NR_sys_timerfd_settime 310
> +#define __NR_sys_timerfd_gettime 311
>
> #ifdef __KERNEL__
>
> -#define __NR_syscalls 310
> +#define __NR_syscalls 312
>
> #define __NR__exit __NR_exit
> #define NR_syscalls __NR_syscalls
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Alessandro Zummo @ 2007-11-28 18:43 UTC (permalink / raw)
To: Clemens Koller; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <474DB27C.7020909@anagramm.de>
On Wed, 28 Nov 2007 19:25:00 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:
> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
> on my MPC8540(ads like) PowerPC working properly on
> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
> as well as a 2.6.22-rc6-gb75ae860 is working fine.
> (mainstream's console is broken, so cannot test these, yet.)
>
>
> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
> and it also breaks the deprecated SENSORS_DS1337. :-(
mmm. I've been told it should work ;)
> Here is a snippet from my .config which is similar among my kernels.
> CONFIG_GEN_RTC=y
this one must be deselected.
> CONFIG_SENSORS_DS1337=y
> CONFIG_SENSORS_DS1374=y
ditto.
> DEV: registering device: ID = '0-0068'
> bus i2c: add device 0-0068
> bound device '0-0068' to driver 'ds1337'
maybe the wrong driver is kicking in here.
the fact that there is no rtc class
related output in dmesg should and that
there is no /dev/rtc0 could be a sign that the whole class
is not going in.
do you have full dmesg?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 18:25 UTC (permalink / raw)
To: linuxppc-embedded, rtc-linux, a.zummo
Hi, there!
(Only subscribed to linuxppc-embedded and lkml; otherwise, please CC)
Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
on my MPC8540(ads like) PowerPC working properly on
latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
as well as a 2.6.22-rc6-gb75ae860 is working fine.
(mainstream's console is broken, so cannot test these, yet.)
My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
and it also breaks the deprecated SENSORS_DS1337. :-(
Before I start bisecting and digging in the code (I'm booting from
flash, so it isn't fun to change kernels on the fly), I just want
to verify that my configuration is correct.
I am using hwclock-2.31 from Bryan Henderson since the one
which comes with util-linux doesn't support to choose another
rtc device than /dev/rtc.
Here is a snippet from my .config which is similar among my kernels.
CONFIG_GEN_RTC=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SENSORS_DS1337=y
CONFIG_SENSORS_DS1374=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_M41T00=y
CONFIG_HWMON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DEBUG=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_LIB=y
So, I enabled both, the new rtc-lib DS1307 (which is compatible to the DS1337)
and the deprecated SENSORS_DS1337.
Deselecting SENSORS_* doesn't help.
My /etc/udev/rules.d/50-udev-default.rules contains the line:
KERNEL=="rtc[0-9]*", MODE="0666"
When the RTC is working, I get the following:
dmesg:
------
i2c /dev entries driver
ds1307 0-0068: rtc core: registered ds1307 as rtc0
ds1307 0-0068: setting the system clock to 2007-11-28 18:56:33 (1196276193)
and I get:
root@fox_1:/dev$ l rtc*
crw-r--r-- 1 root root 10, 135 Jan 1 2000 rtc
crw-rw---- 1 root root 239, 0 Jan 1 2000 rtc0
(Jan 1 2000 is the default date when the rtc chip was powered down, so the
rtc was read successfully.)
$hwclock --systohc --rtc /dev/rtc0
is working properly...
When it's NOT working (2.6.24-rc2-git with some debugging enabled) I get:
dmesg:
------
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
bus i2c: add driver ds1337
DEV: registering device: ID = '0-0068'
bus i2c: add device 0-0068
bound device '0-0068' to driver 'ds1337'
bus i2c: add driver lm75
DEV: registering device: ID = '0-0048'
bus i2c: add device 0-0048
bound device '0-0048' to driver 'lm75'
DEV: registering device: ID = 'hwmon0'
bus i2c: add driver max6650
$ ls /dev/rt*
crw-r--r-- 1 root root 10, 135 Jan 1 1970 rtc
and
$ cat /proc/driver/rtc
rtc_time : 00:00:570426440
rtc_date : 269131772-01-00
rtc_epoch : 1900
alarm : 00:00:00
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 0
batt_status : okay
shows up but these values never seem to get an update.
(==stable among reboots) :-(
My /etc/udev/50-udev-default.rules
contains
KERNEL=="rtc", MODE="0644"
Any ideas to debug?
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ 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