* Re: Xilinx SystemACE driver for 2.6
From: David H. Lynch Jr. @ 2006-07-01 6:21 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <44A560D1.9050509@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Andrei Konovalov wrote:
>>
>> I use this version only because I want to implement the Temac driver in the
>> link of
>> http://ozlabs.org/pipermail/linuxppc-embedded/2006-March/022365.html It
>> looks that the patches are specific for that version.
>>
>
> There is nothing special in the TEMAC driver that binds it to 2.6.16-rc5.
> The patch was generated against and tested with that kernel version. That's all.
> The patch will probably not apply cleanly to the more recent kernels. But
> otherwise it should work.
>
> In other words, feel free to use that TEMAC patch with the recent kernel.
>
I am trying to get a local link version of the hard TEMAC that is
part of the V4 FX FPGA working against a 2.6 Kernel. Would this be an
appropriate patch for that ?
Is it even close ?
There are so many different Xilinx (and other) TEMACs floating
around and so many permutation of those that my head is fogged in.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 2167 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Linux powerpc @ 2006-07-01 6:35 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B07B36E@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
Yes, it was used for allocating dual port RAM for CPM. And now we are
adding QE support to powerpc arch which need to use rheap(QE is next
generation for CPM). Please see the patches I <leoli@freescale.com> just
posted for 8360epb support. Moreover, previous CPM support is adding to
powerpc arch too.
--
Leo
Freescale Semiconductor
On 7/1/06, Rune Torgersen <runet@innovsys.com> wrote:
>
> From: Benjamin Herrenschmidt
>
> >What is this used for ? This rheap allocator ?
>
> It is used for allocating dual port RAM on 8xx and 82xx. (and probably
> others that have a CPM)
> Most/all usage is still in ppc.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 1527 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Benjamin Herrenschmidt @ 2006-07-01 7:21 UTC (permalink / raw)
To: Linux powerpc; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <a0bc9bf80606302335p7ba227afwf69dc42e2eada64b@mail.gmail.com>
On Sat, 2006-07-01 at 14:35 +0800, Linux powerpc wrote:
> Yes, it was used for allocating dual port RAM for CPM. And now we are
> adding QE support to powerpc arch which need to use rheap(QE is next
> generation for CPM). Please see the patches I <leoli@freescale.com>
> just posted for 8360epb support. Moreover, previous CPM support is
> adding to powerpc arch too.
Ok, well, I don't have anything specifically against that code, I was
just wondering if it may not duplicate something we already have (yet
another space allocator basically)...
Ben.
^ permalink raw reply
* RE: [PATCH 1/7] powerpc: Add mpc8360epb platform support
From: Benjamin Herrenschmidt @ 2006-07-01 9:00 UTC (permalink / raw)
To: Li Yang-r58472
Cc: Phillips Kim-R1AAHA, Yin Olivia-r63875,
'linux-kernel@vger.kernel.org', linuxppc-dev,
'Paul Mackerras', Chu hanjin-r52514
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FF2@zch01exm40.ap.freescale.net>
On Fri, 2006-06-30 at 18:27 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > Sent: Thursday, June 29, 2006 12:59 AM
> > To: Li Yang-r58472
> > Cc: 'Paul Mackerras'; linuxppc-dev@ozlabs.org; Phillips Kim-R1AAHA; Chu
> > hanjin-r52514; Yin Olivia-r63875; 'linux-kernel@vger.kernel.org'
> > Subject: Re: [PATCH 1/7] powerpc: Add mpc8360epb platform support
> >
> > On Wed, 28 Jun 2006 22:23:03 +0800
> > Li Yang-r58472 <LeoLi@freescale.com> wrote:
> >
> [snip]
> >
> > >
> > > config MPC834x
> > > @@ -24,4 +31,10 @@ config MPC834x
> > > select PPC_INDIRECT_PCI
> > > default y if MPC834x_SYS
> > >
> > > +config MPC836x
> > > + bool
> > > + select PPC_UDBG_16550
> >
> > debug option made default?
>
> I'm afraid this is needed to boot. 83xx family platforms need it to initialize early console. And it does appear in several defconfigs of other platforms.
How so ? Why would having a serial console be mandatory ? Embedded might
want to boot without a console and use the serial port for other things.
This should be left as a config option (though you are welcome to put it
in the defconfig for your platform)
> > > + select PPC_INDIRECT_PCI
> > > + default y if MPC8360E_PB
> > > +
> > > endmenu
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: rs232 endianness on PPC
From: White @ 2006-07-01 8:53 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tauanna@tiscali.it
In-Reply-To: <13853799.1151694631780.JavaMail.root@ps13>
PowerPC is only Byte swaped, not bit-swaped :)
(I thought there are only some old mainly unused Architecturs, who swap
the Bits :)
The second: I think the bitorder on the rs232 is standarized :) and
should be the same ... :)
Am Fri, 30 Jun 2006 21:10:31 +0200 (CEST) schrieb "tauanna@tiscali.it"
<tauanna@tiscali.it> :
> Hi,
>
> when I write a byte on the SMC1 (MPC875) serial device (let us say
> 0x11) what should I expect on the output pin? First a 0 then 0, 0, 1,
> 0, 0, 0, 1 or the opposite. Is it different on a little endian CPU?
>
> Bye,
> Antonio.
>
>
>
>
>
> Hai voglia di fare un viaggio, ma non sai dove andare?
> Scegli una delle nostre offerte HOTEL IN ITALIA E IN EUROPA da 50 euro.
> Prenota subito su Expedia.it e... buona vacanza!
>
> http://expedia.viaggi.tiscali.it/default.aspx?eapid=330-8
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Problem with Lite5200B
From: Wolfgang Denk @ 2006-07-01 9:09 UTC (permalink / raw)
To: Alan Carvalho; +Cc: linuxppc-embedded
In-Reply-To: <dc70db7d0606301409y3dfd285dr880d2fa350edace5@mail.gmail.com>
In message <dc70db7d0606301409y3dfd285dr880d2fa350edace5@mail.gmail.com> you wrote:
>
> I am trying to run Linux on Lite5200B board with no success.
Please make sure to use the latest version of U-Boot, i. e. top of
tree in the git repo.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"If you'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson Space Center,
Houston July 20, 1969, 7:27 P.M.
^ permalink raw reply
* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2006-07-01 9:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, roger blofeld, linuxppc-embedded
In-Reply-To: <1151709367.27137.4.camel@localhost.localdomain>
In message <1151709367.27137.4.camel@localhost.localdomain> you wrote:
>
> > I don;t know - the patches were submitted to this list a long time
> > ago; we added them to our repository without any additional problems;
> > see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git
>
> Any reason why you keep that repository instead of submiting the patches
> for proper upstream inclusion or to linuxppc-dev at least ?
We submit patches every now and then, as time permits. My intention
is to keep the differences between our tree and kernel.org minimal.
But you know how this goes: just adding support for a new board means
sending patches to the linuxppc_dev, mtd, i2c, usb, lm_sensors, ...
mailing lists. Then you have to wait some time, then you resend. and
you have to keep track of all these things. And the board support
will not work before the last piece of the puzze has been accepted
and merged and pushed upstream. All this takes a lot of effort and
even more calendar time. We need a way to provide a solution to our
customers fast - that's why we maintain our own development branch.
I'd be happy if you could recommend a better approach to handle this.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The management question ... is not _whether_ to build a pilot system
and throw it away. You _will_ do that. The only question is whether
to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers. - Fred Brooks, "The Mythical Man Month"
^ permalink raw reply
* Re: Video Card to Lite5200
From: Benjamin Herrenschmidt @ 2006-07-01 9:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev list, roger blofeld, linuxppc-embedded
In-Reply-To: <20060701091507.EA1F4352681@atlas.denx.de>
On Sat, 2006-07-01 at 11:15 +0200, Wolfgang Denk wrote:
> In message <1151709367.27137.4.camel@localhost.localdomain> you wrote:
> >
> > > I don;t know - the patches were submitted to this list a long time
> > > ago; we added them to our repository without any additional problems;
> > > see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git
> >
> > Any reason why you keep that repository instead of submiting the patches
> > for proper upstream inclusion or to linuxppc-dev at least ?
>
> We submit patches every now and then, as time permits. My intention
> is to keep the differences between our tree and kernel.org minimal.
>
> But you know how this goes: just adding support for a new board means
> sending patches to the linuxppc_dev, mtd, i2c, usb, lm_sensors, ...
> mailing lists. Then you have to wait some time, then you resend. and
> you have to keep track of all these things. And the board support
> will not work before the last piece of the puzze has been accepted
> and merged and pushed upstream. All this takes a lot of effort and
> even more calendar time. We need a way to provide a solution to our
> customers fast - that's why we maintain our own development branch.
>
> I'd be happy if you could recommend a better approach to handle this.
Oh, it's fine to maintain a dev. branch, but I haven't seen you submit
stuff to linuxppc-dev for some time so I wanted to make sure you were
still on track :)
Ben.
^ permalink raw reply
* ppc vs. powerpc status update, please
From: Guennadi Liakhovetski @ 2006-07-01 10:20 UTC (permalink / raw)
To: linuxppc-dev
What's the _current_ trend with those 2 archs, specifically,respecting
embedded boards, the make ARCH=powerpc ***_defconfig for a board under ppc
"just should work" doesn't seem to hold and I didn't find any provisions
for that. (I read in an earlier post it "should"). Are ppc platforms still
supposed to migrate to under powerpc? I am not quite clear where to put
all board-specific stuff then, in that post it was told "you almost don't
need anything, just use device tree and a correct CPU support, and put
your specific _drivers_ somewhere". How is it in reality?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Christoph Hellwig @ 2006-07-01 10:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <1151738466.27137.24.camel@localhost.localdomain>
On Sat, Jul 01, 2006 at 05:21:06PM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2006-07-01 at 14:35 +0800, Linux powerpc wrote:
> > Yes, it was used for allocating dual port RAM for CPM. And now we are
> > adding QE support to powerpc arch which need to use rheap(QE is next
> > generation for CPM). Please see the patches I <leoli@freescale.com>
> > just posted for 8360epb support. Moreover, previous CPM support is
> > adding to powerpc arch too.
>
> Ok, well, I don't have anything specifically against that code, I was
> just wondering if it may not duplicate something we already have (yet
> another space allocator basically)...
Yepp. Without looking at the rheap allocator in deatail, any reason
it can't use lib/genalloc.c?
^ permalink raw reply
* faulty 64-bit resource printk fixup in macio_asic.c
From: Paul Collins @ 2006-07-01 13:30 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, linuxppc-dev
Hi Greg,
The patch titled "64bit resource: fix up printks for resources in misc
drivers", committed as e29419fffceb8ec36def3c922040e1ca7bcd3de5 in
Linus's tree, causes my PowerBook to Oops early in boot and udev to
not function.
Unable to handle kernel paging request for data at address 0x6f000000
Faulting instruction address: 0xc00c901c
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT
Modules linked in:
NIP: C00C901C LR: C00C901C CTR: C00C8F78
REGS: efed5db0 TRAP: 0300 Not tainted (2.6.17-g9262e914)
MSR: 00009032 <EE,ME,IR,DR> CR: 22000484 XER: 20000000
DAR: 6F000000, DSISR: 40000000
TASK = efe97240[378] 'udevtrigger' THREAD: efed4000
GPR00: C00C901C EFED5E60 EFE97240 00000000 CFC0BB40 00010001 CFC0BB40 C02E9754
GPR08: 00000000 00000001 EFFE8EA4 EFED4000 44000428 1001D140 100D0000 100D0000
GPR16: 00000000 100EBF08 100D0000 100B0000 100D0000 100B0000 100EBEA8 100EC068
GPR24: 00000000 EFEEDA20 C0DF7880 EFED4000 CFC0BB40 EFEEDA20 C0DF78D0 6F000000
NIP [C00C901C] sysfs_open_file+0xa4/0x284
LR [C00C901C] sysfs_open_file+0xa4/0x284
Call Trace:
[EFED5E60] [C00C901C] sysfs_open_file+0xa4/0x284 (unreliable)
[EFED5E90] [C007D6A8] __dentry_open+0x108/0x2a4
[EFED5EC0] [C007D988] do_filp_open+0x5c/0x78
[EFED5F20] [C007D9FC] do_sys_open+0x58/0xf8
[EFED5F40] [C000FDB8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff248d8
LR = 0xffb525c
Instruction dump:
3be0ffea 812b0050 83c90014 419e007c 2f9e0000 419e006c 83fe0004 2f9f0000
419e0080 38600001 4bf5b229 4809726d <801f0000> 3ba00000 2f800002 419e0024
<6>note: udevtrigger[378] exited with preempt_count 1
The only hunk of that commit affecting my configuration is this one,
which when reverted lets my machine work again.
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 431bd37..c687ac7 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -428,10 +428,10 @@ #endif
/* MacIO itself has a different reg, we use it's PCI base */
if (np == chip->of_node) {
- sprintf(dev->ofdev.dev.bus_id, "%1d.%08lx:%.*s",
+ sprintf(dev->ofdev.dev.bus_id, "%1d.%016llx:%.*s",
chip->lbus.index,
#ifdef CONFIG_PCI
- pci_resource_start(chip->lbus.pdev, 0),
+ (unsigned long long)pci_resource_start(chip->lbus.pdev, 0),
#else
0, /* NuBus may want to do something better here */
#endif
When applied, this hunk yields
/* MacIO itself has a different reg, we use it's PCI base */
if (np == chip->of_node) {
sprintf(dev->ofdev.dev.bus_id, "%1d.%016llx:%.*s",
chip->lbus.index,
#ifdef CONFIG_PCI
(unsigned long long)pci_resource_start(chip->lbus.pdev, 0),
#else
0, /* NuBus may want to do something better here */
#endif
MAX_NODE_NAME_SIZE, np->name);
Since dev->ofdev.dev is a struct device, bus_id is 20 bytes, of which
19 are consumed by "%1d.%016llx:". But the field width used by "%.*s"
is MAX_NODE_NAME_SIZE, which is 8.
drivers/macintosh/macio_asic.c:36:#define MAX_NODE_NAME_SIZE (BUS_ID_SIZE - 12)
So I think the sprintf overflows bus_id and clobbers the next few
bytes of struct device.
I'm not sure what the right thing to do is. Making bus_id bigger will
cost everyone, but right now with bus_id at 20 bytes, there's no room
after the colon for any of np->name.
--
Paul Collins
Melbourne, Australia
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Kumar Gala @ 2006-07-01 14:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pantelis Antoniou, Paul Mackerras,
linux-kernel@vger.kernel.org mailing list, linuxppc-dev list
In-Reply-To: <20060701102557.GA14013@lst.de>
On Jul 1, 2006, at 5:25 AM, Christoph Hellwig wrote:
> On Sat, Jul 01, 2006 at 05:21:06PM +1000, Benjamin Herrenschmidt
> wrote:
>> On Sat, 2006-07-01 at 14:35 +0800, Linux powerpc wrote:
>>> Yes, it was used for allocating dual port RAM for CPM. And now
>>> we are
>>> adding QE support to powerpc arch which need to use rheap(QE is next
>>> generation for CPM). Please see the patches I <leoli@freescale.com>
>>> just posted for 8360epb support. Moreover, previous CPM support is
>>> adding to powerpc arch too.
>>
>> Ok, well, I don't have anything specifically against that code, I was
>> just wondering if it may not duplicate something we already have (yet
>> another space allocator basically)...
>
> Yepp. Without looking at the rheap allocator in deatail, any reason
> it can't use lib/genalloc.c?
Doing a quick glance at lib/genalloc.c I dont see any reason we
couldn't use it. However, Panto will know best, since he wrote rheap.
- k
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Pantelis Antoniou @ 2006-07-01 14:50 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Paul Mackerras,
linux-kernel@vger.kernel.org mailing list
In-Reply-To: <C4F75531-D046-42EF-AAF7-D45B84DA1720@kernel.crashing.org>
On Saturday 01 July 2006 17:34, Kumar Gala wrote:
>
> On Jul 1, 2006, at 5:25 AM, Christoph Hellwig wrote:
>
> > On Sat, Jul 01, 2006 at 05:21:06PM +1000, Benjamin Herrenschmidt
> > wrote:
> >> On Sat, 2006-07-01 at 14:35 +0800, Linux powerpc wrote:
> >>> Yes, it was used for allocating dual port RAM for CPM. And now
> >>> we are
> >>> adding QE support to powerpc arch which need to use rheap(QE is next
> >>> generation for CPM). Please see the patches I <leoli@freescale.com>
> >>> just posted for 8360epb support. Moreover, previous CPM support is
> >>> adding to powerpc arch too.
> >>
> >> Ok, well, I don't have anything specifically against that code, I was
> >> just wondering if it may not duplicate something we already have (yet
> >> another space allocator basically)...
> >
> > Yepp. Without looking at the rheap allocator in deatail, any reason
> > it can't use lib/genalloc.c?
>
> Doing a quick glance at lib/genalloc.c I dont see any reason we
> couldn't use it. However, Panto will know best, since he wrote rheap.
>
> - k
>
Hi there,
RHEAP started life long before on 2.4 before genalloc was included in the kernel.
The difference is only in the implementation, rheap uses double linked lists
while genalloc uses per pool bitmaps. RHEAP is faster & conserves a bit more space
since it doesn't use a bitmap to track the chunks.
Since genalloc is the blessed linux thing it might be best to use that & remove
rheap completely. Oh well...
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] Documentation: correct values in MPC5848E SEC example node
From: Kumar Gala @ 2006-07-01 15:16 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060630185542.102af583.kim.phillips@freescale.com>
The patch still had typo issues in the comments. 5848 -> 8548.
- k
On Jun 30, 2006, at 6:55 PM, Kim Phillips wrote:
> (this patch had apparently slipped through the cracks)
>
> Documentation: correct values in MPC5848E SEC example node
>
> ---
> commit 27ef8f30208ceb62c5387e834a335558e7e88c70
> tree e96c74f732489115651ea00d0514e66e8050c60a
> parent 1f4a90670bacbf61f2fcc19a9e0e78748c932a25
> author Kim Phillips <kim.phillips@freescale.com> Tue, 02 May 2006
> 11:38:23 -0500
> committer Kim Phillips <kim.phillips@freescale.com> Tue, 02 May
> 2006 11:38:23 -0500
>
> Documentation/powerpc/booting-without-of.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index 217e517..3c62e66 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1436,9 +1436,9 @@ platforms are moved over to use the flat
> interrupts = <1d 3>;
> interrupt-parent = <40000>;
> num-channels = <4>;
> - channel-fifo-len = <24>;
> + channel-fifo-len = <18>;
> exec-units-mask = <000000fe>;
> - descriptor-types-mask = <073f1127>;
> + descriptor-types-mask = <012b0ebf>;
> };
>
>
^ permalink raw reply
* Murali N Iyer/Rochester/IBM is out of the office.
From: Murali N Iyer @ 2006-07-01 15:21 UTC (permalink / raw)
To: linuxppc-dev
I will be out of the office starting 07/01/2006 and will not return until
07/10/2006.
I will respond to your message(s) when I return. If you need immediate
assistance you may contact my Manager Jeremy Balster at (507) 253-2483 or
balster@us.ibm.com
^ permalink raw reply
* Re: ppc vs. powerpc status update, please
From: Jon Loeliger @ 2006-07-01 15:36 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0607011215260.7912@poirot.grange>
So, like, the other day Guennadi Liakhovetski mumbled:
> What's the _current_ trend with those 2 archs, specifically,respecting
> embedded boards, the make ARCH=powerpc ***_defconfig for a board under ppc
> "just should work" doesn't seem to hold and I didn't find any provisions
> for that. (I read in an earlier post it "should"). Are ppc platforms still
> supposed to migrate to under powerpc? I am not quite clear where to put
> all board-specific stuff then, in that post it was told "you almost don't
> need anything, just use device tree and a correct CPU support, and put
> your specific _drivers_ somewhere". How is it in reality?
The trend is still happening. Things should be migrated out
of arch/ppc and into arch/powerpc. For example, I just
introduced a new 86xx board port only under arch/powerpc.
Please feel free to help migrate support into arch/powerpc!
jdl
^ permalink raw reply
* Re: rs232 endianness on PPC
From: Dan Malek @ 2006-07-01 15:56 UTC (permalink / raw)
To: White; +Cc: tauanna@tiscali.it, linuxppc-embedded
In-Reply-To: <20060701105337.3fcd5f0f@White64>
On Jul 1, 2006, at 4:53 AM, White wrote:
> PowerPC is only Byte swaped, not bit-swaped :)
PowerPC isn't byte swapped, the other world is :-)
> The second: I think the bitorder on the rs232 is standarized :) and
> should be the same ... :)
RS-232 is LS bit first.
-- Dan
^ permalink raw reply
* Re: [linux-pm] release early... powermac g5 suspend to disk
From: Johannes Berg @ 2006-06-29 16:24 UTC (permalink / raw)
To: Pavel Machek; +Cc: linuxppc-dev list, linux-pm
In-Reply-To: <20060628214217.GC30373@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]
Hi,
> Congratulations! Hehe, you have nice testcase for xfs now :-).
Yeah, already posted to xfs list ;)
> [ext2 is the filesystem you proably want to use while hacking such code].
Mounting read-only hasn't wrecked it any further so far :) And I was too
lazy to install a second system... Should've, I guess, hd is large
enough anyway.
> > Half of the time I'll be told by the softlockup watchdog that it locked
> > up, but sometimes it actually works, that is, it suspends and resumes.
Obviously that was phrased wrongly -- the code hangs and the softlockup
watchdog indicates it. But I don't know why. Can writing the MSR hang?
> I believe this is gone in -git kernels for some other reasons.
I'm not even sure the hack I did there with marking the area as nosave
is good. At the very least the code shouldn't live in the MPIC file
since the code reserving the chunk doesn't either.
What about the page_is_ram() part? Doesn't any other platform have a RAM
hole between 2 and 4 GB? Or is that handled more generically with
discontig support? (and if yes, how does discontig support work?)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* sound connector detection
From: Johannes Berg @ 2006-06-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: linux-input, linuxppc-dev list, Richard Purdie, Linux Kernel list
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
Hi,
One Apple machines I have with snd-aoa the situation that the alsa
driver can detect changes in in/output connector state ("is headphone
plugged in" etc.) and currently surfaces it through a read-only alsa
mixer element. That isn't really ideal since nothing is prepared to
handle such events, hence I provide an additional control that allows an
in-kernel toggle from speakers to headphone on headphone plug (and vice
versa).
I'd really like to see this handled in userspace (additionally or
possibly event instead), since there are complications especially with
input (line-in) detection and user preferences of what should happen
then. The number of cases can become large, especially when throwing in
digital and combo connectors that aren't handled yet.
Now, is it appropriate to create an input device for the state of these
things and add new constants like SW_LINEIN_INSERTED,
SW_LINEOUT_INSERTED, SW_OPTICALOUT_INSERTED, SW_OPTICALIN_INSERTED and
if so, how do I reflect the fact that on some machines optical and
analog input/output is mutually exclusive, while on others it isn't?
That would probably require another SW_COMBO_IN/OUT set...
Or should I simply stick with (a) read-only mixer control(s), and for
the mutually exclusive case create a tristate (none, optical, analog)
one? But SW_HEADPHONE_INSERT already exists, so we may want to do this
identically on different machines.
Comments appreciated.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* FOSS, Science, and Public activism
From: proclus @ 2006-07-01 19:20 UTC (permalink / raw)
To: linuxppc64-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Sorry if you get more than one copy of this message, but I felt
that it was urgent to get this important info out.)
The values of freedom and openness are crucial to understanding
itself, so that civilization and public welfare now depend on
them, as I argue below. These values may find their best
expression in the free and open source software (FOSS) movement,
and the foresightful example of FOSS developers should now be
beneficially applied to many other disciplines in the context of a
global and public Internet.
It is crucial that we occasionally take time to discuss the
reasons _why_ we release our source code, and this is one of
those occasions. There are good reasons for the freedom and
openness which are characteristics of FOSS development, reasons
which should receive wider attention now that they can be readily
communicated to other arenas. The consequences of doing otherwise
are often catastrophic.
For example, it incomprehensible that Genentech could consider
withdrawing a cheap cure for blindness (ARMD) from the market.
http://lists.essential.org/pipermail/random-bits/2006-june/001374.html
The mechanism of this drug is public knowledge.
http://sourceforge.net/mailarchive/forum.php?thread_id=14183567&forum_id=6042
This abhorrent situation is a great example of the kind of thing
that will happen if people don't get behind the values of freedom
and openness that we are espousing. Please let Genentech know
that you find what they are doing offensive. Publicize the mechanism
so that new compounds can be obtained as replacements. For the
future, continued vociferous public activism is required to prevent
such outrages from occurring in the future.
It becomes clear that the compounds which come from common roots,
fruits, and vegetables are a shared human heritage and the free and
open source of the future. Tannins are another interesting case in
point, because as molecules, and as anti-oxidents, they are similar to
resveratrol (resV), and that molecular mechanism has been anchored to
the public domain via a prior art declaration. It is a so-called
CR-memetic, which may increase healthy human longevity by many
decades. Here are some links about it.
Resveratrol mechanism posts from GNU-Darwin list
http://proclus.gnu-darwin.org/gdposts.html
CR protocol for human bodies
http://proclus.gnu-darwin.org/bootstrap.html
Here is some important recent news about it.
http://www.imminst.org/forum/index.php?s=&act=print&client=printer&f=237&t=10749
It is exciting to suppose that people can get off the pharmaceuticals
that they are taking with calorie restriction or CR-memetics. I
personally am trying to get off the cholesterol drug Pravachol, a
statin compound, starting a few of weeks ago. Write me, and I'll let
you know how it turns out. From the article...
"Fontana says ... evidence of "younger" hearts in people on calorie
restriction, suggest that humans on CR have the same adaptive
responses as did animals whose rates of aging were slowed by CR."
I think that it is time to look at the tannins in tobacco leaves.
There may be other treasures lurking there too. As you may be
aware there is ample public research into any possible beneficial
compounds that may be obtained from tobacco leaves. The mechanisms
are there waiting to be discovered. If you want to post them, just
reply to me and I'd be delighted to host them.
The public establishment of prior art is a time-honed method of
entering inventions into the public domain. We now have other
methods at our disposal as well. If you are planning to establish
prior art against future CR-memetic related patents, you might want
to have a look at www.creativecommons.org. Perhaps it goes without
saying at this point that you should please choose a license that
provides for free and broad public access to your memetic.
In that way you will assure that the public health is served by
anchoring them to the public common, where they cannot be exploited
by those who would withhold them for their own profit. The DRM
situation is precisely analogous to this. Can you imagine doing
science in a world where your ability to read and write your data is
filtered through secret protocols that are hidden from you? I
recommend the Defective By Design campaign to fight the outrage of
DRM, which is incompatible with the scientific pursuit.
http://www.defectivebydesign.org/
It is clear that scientific tools must be demonstrably and
penetratingly understood, or else our claims will likely be skewed
and called into question. Free and open source software is
a great example of how to make your science verifiable to the
public. Establishing prior art against future patents is
another good one, which is precisely analogous in method,
making the result explicit to the public, free and open to all.
Thank goodness for the free and open software movement, which
gave us such a great example of how to serve the public in this
manner.
I am willing to grant that there are particular exceptions to
these rules of freedom and openness, and such exceptions may be
relatively harmless; however, let us posit the opposite, that
freedom and openness are _not_ crucial to understanding. Think of
the implications. When people are compelled to learn, they do not
receive the intended message. It is not understood correctly
or completely. When crucial facts are withheld from the people
you are trying to teach they become paranoid, possibly unteachable.
Freedom and openness are obviously the best approach to understanding.
This is not a metaphor for the pursuit of science, but a fact.
We are learning from nature, and it is ultimately required that
our tools be demonstrably and penetratingly understood, or else
we will receive incorrect lessons from nature. Clearly this
requires public access to the source code and more. This
is why many of us are pressing for public access to scientific
publications.
Moreover FOSS tools are becoming ever more important to the
pursuit of the scientific endeavor itself. In our biophysics
department we are obsolescing proprietary hardware and software
in favor of open standards and free software, which is a
widespread phenomenon in the science sector, and sure to continue.
We build most of the workstations ourselves with commodity hardware,
but we also have some clusters running Debian and FedoraCore.
Some of you will know that I am the lead developer for the
GNU-Darwin distribution. GNU-Darwin has a FOSS operating system,
which is getting alot of press these days. Here is an example
How Apple and Microsoft are advancing desktop Linux
http://www.desktopLinux.com/news/ns7294331817.html
I see the article as counter-productive against building a FOSS
coalition that includes democracy, freedom, and public access
activists, Apple, GNU-Darwin, GNU, and GNU/Linux all linked
together in spectrum.
It is important to alert the whole FOSS community that Darwin
cannot be classified as a free or open source operation system
as of the Darwin-8 revision, because AppleACPIplatform-39 which
is required to boot the system is proprietary. It is notable that
only the current version of Darwin from Apple is a non-free OS.
GNU-Darwin has a free version, an earlier revision that includes
the source code. It is FOSS, and we call upon Apple to maintain
Darwin as such, as it has been in the past. We hope that the
current situation with the kernel and ACPI driver will soon be
remedied so that Darwin will continue as a FOSS OS.
We are asking for free software developers to please write to the
*nix core of Darwin, which is the core OS for both Mac OS X and
GNU-Darwin OS. Darwin OS, which underlies both systems, comprises
parts from GNU, the BSD's, mach, plus Apple's substantial
contributions to the free software community. Be consistent with your
philosophy and avoid linkage to proprietary binaries, such as OpenGL
and CoreAudio, except when it is imperatively required in order to
lead users to the values of software freedom. Under that principle,
another reason to maintain compatibility with the *nix core, is so
that your code will be readily portable to new platforms and usable
by free-software-only aficionados too.
GNU-Darwin OS is not an obsolete implementation of Darwin OS, or to be
superseded by Mac OS X. We are trying to lead users to freedom, not
away from it. By maintaining Darwin core compatibility your code will
remain valuable as the marketplace and industry continues to evolve
(trust me here), particularly as DRM-related problems continue to come
forward. Of course, that means releasing your source code under a FOSS
license, such as APSL. Darwin OS is a free and open source operating
system that is not going away, so try to focus your coding towards
supporting that standard instead of proprietary software.
Here is the essence of the current problem with Darwin OS. Apple
replaced working boot code with the following proprietary drivers,
which are required for the system to boot.
Darwin-7:
AppleAPIC.kext/
Applei386genericplatform.kext/
Darwin-8:
AppleACPIplatform
In addition the kernel (xnu) has been taken proprietary in the
recent revisions. We are not asking for Apple to give away such
things, but rather to continue maintaining Darwin OS as FOSS, which
it already was.
After repeated attempts by many FOSS developers to get this
situation remedied, nothing has happened. It is now time for us to
better use the measures at our disposal in order to assure that
Darwin OS remains free and open. If you are unhappy that xnu and
the boot drivers have not been released, I would encourage you to
spread your dissatisfaction to other forums, so that Apple will take
notice and commit to a workable free and open Darwin OS from now on.
Moving on to coalition strategy now, some of you may not know that
GNU/Linux system administration is one of my day jobs. I manage a
wide range of systems. Here is a screen-shot of my work desktop, so
that you can see I use the same tools at work that I use at home at
night on GNU-Darwin. (weekends too, so please read I am your friend)
http://proclus.gnu-darwin.org/debian.html
The only time that I ever use proprietary software is when I am trying
to help other users learn free and open source free software. I'm a
long time Apple and GNU/Linux user, and here is the old proof doc ;-}.
http://proclus.tripod.com/indulge.html
Now, it is embarrassing but, I want you to have a look at my cv.
http://biophysics.med.jhmi.edu/love/thesis/cv6.html
In all my years I have never used Microsoft Windows. There are only
two exceptions to this statement, where I was helping Windows users to
access our servers at Hopkins. Clearly, you can get a few things done
without it ;-}.
One of the primary reasons for founding GNU-Darwin was to help people
to put Microsoft behind them, and it is definitely possible to do it
now. You have many resources at your disposal to help you leave
Microsoft behind. Look at the link below to see what you can do
with free software. Apple, GNU-Darwin, GNU.org, and GNU/Linux will
all help, and we are largely all helping together, because we have a
shared foundation of free software.
http://www.gnu-darwin.org/gdc/
Microsoft is only one example. That is why we are so insistent that
Apple keep true to free and open source software principles. We
should ultimately try to leave all proprietary software behind us, so
that we can participate fully in the freedom and openness of the
internet culture and public domain. What more do we need, when we
have such a rich store of information and so many capable people at
our sides?
Finally, as a scientist, it is obvious to me that this situation is
relevant current and ongoing discussion in the scientific community,
and as such, it is also clear that many members of the various lists
would be interested in the current state of Darwin with respect to
FOSS and with respect to science.
Here is the crucial point.
The principles of FOSS and scientific inquiry converge. In
practical terms, how else can you know is what happening in your
experiments? Free and open source software, open standards, best
promote the scientific endeavor by mirroring its method, but also
they assure that the work is accessible to the public.
Freedom and openness are crucial to understanding, and foundational
to the scientific endeavor, and they should not be compromised.
There are a few examples of exceptions, but clearly, this matter
will find further debate in the appropriate forums. We should not
quell debate because a few people are offended or complaining.
- From a scientific perspective that would be incorrect.
On that last point, I would suggest that Apple get on the right side
of the debate, and they will make tremendous headway. Now is the
time.
Some people will find this message annoying and divisive, and the
delete button is ready at hand for them, but other people will find
it interesting and engaging. All as you like. Let us not quell
discussion because a few people are annoyed.
Some will call this a troll, but I hope that folks will see through
such name-calling. Trolls are mythological creatures, so don't
believe in them. Everyone has a right to have their opinion
heard, even if those opinions are divisive or unpopular. It is
clear that the idea of trolls is being used to attack freedom of
expression. In fact, freedom of expression demands that we
listen to the so-called-trolls sometimes, and if you are civil, it
helps, so don't resort to name-calling.
On cross-posting; when there are matters of urgent importance that
affect a broad range of subscriber lists, courtesy must sometimes
take a back seat, and cross-posting is an example of that.
Cross-posting is to be encouraged when the subject of the post is on
topic. Each of the various lists will respond in the way that seems
appropriate to the people in that forum, and the threads on the
various lists will diverge accordingly. As the threads diverge, the
cross-posting addresses should be removed as needed. Relevance to
all people is an unattainable goal, but messages of the broadest
applicability should have the broadest reach, and discussion should
not be stymied because some find it irrelevant. I have given this
method due consideration; it is not trolling, not spam, not off-topic,
and cross-posting is an example of something that is sometimes
required according to the felt importance and relevance of a given
subject matter.
In summary, Freedom and openness are now the bedrock of our
civilization and public welfare depends on these values, so that we
should actively engage ourselves in preserving and making them happen.
In keeping with these principles it is crucial to note that there are
exceptions to etiquette, otherwise free expression will be overly
channeled, damped, and ultimately suppressed in our forums. This
notion of courtesy will certainly receive additional consideration,
but meanwhile, let us together get to work on the activism now.
Duly, I am amenable to valid criticism and able to respond, but please
reply with kindness. Obviously, feel free to write back, copy, or
send these comments along to anyone else as you see fit.
Regards,
Michael L. Love Ph.D
Department of Biophysics and Biophysical Chemistry
School of Medicine
Johns Hopkins University
725 N. Wolfe Street
Room 608B WBSB
Baltimore MD 21205-2185
Interoffice Mail: 608B WBSB, SoM
office: 410-614-2267
lab: 410-614-3179
fax: 410-502-6910
cell: 443-824-3451
http://www.gnu-darwin.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEpIl6u0oI3iz5oZcRAtpQAJ9X7D6kq1vmWKXkG/3LBvx3gGrK1QCZAbgI
8Ww6QABLiZtmFmS9Ekea5nI=
=a0Oy
-----END PGP SIGNATURE-----
^ permalink raw reply
* FOSS, Science, and Public activism
From: proclus @ 2006-07-01 19:20 UTC (permalink / raw)
To: linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Sorry if you get more than one copy of this message, but I felt
that it was urgent to get this important info out.)
The values of freedom and openness are crucial to understanding
itself, so that civilization and public welfare now depend on
them, as I argue below. These values may find their best
expression in the free and open source software (FOSS) movement,
and the foresightful example of FOSS developers should now be
beneficially applied to many other disciplines in the context of a
global and public Internet.
It is crucial that we occasionally take time to discuss the
reasons _why_ we release our source code, and this is one of
those occasions. There are good reasons for the freedom and
openness which are characteristics of FOSS development, reasons
which should receive wider attention now that they can be readily
communicated to other arenas. The consequences of doing otherwise
are often catastrophic.
For example, it incomprehensible that Genentech could consider
withdrawing a cheap cure for blindness (ARMD) from the market.
http://lists.essential.org/pipermail/random-bits/2006-june/001374.html
The mechanism of this drug is public knowledge.
http://sourceforge.net/mailarchive/forum.php?thread_id=14183567&forum_id=6042
This abhorrent situation is a great example of the kind of thing
that will happen if people don't get behind the values of freedom
and openness that we are espousing. Please let Genentech know
that you find what they are doing offensive. Publicize the mechanism
so that new compounds can be obtained as replacements. For the
future, continued vociferous public activism is required to prevent
such outrages from occurring in the future.
It becomes clear that the compounds which come from common roots,
fruits, and vegetables are a shared human heritage and the free and
open source of the future. Tannins are another interesting case in
point, because as molecules, and as anti-oxidents, they are similar to
resveratrol (resV), and that molecular mechanism has been anchored to
the public domain via a prior art declaration. It is a so-called
CR-memetic, which may increase healthy human longevity by many
decades. Here are some links about it.
Resveratrol mechanism posts from GNU-Darwin list
http://proclus.gnu-darwin.org/gdposts.html
CR protocol for human bodies
http://proclus.gnu-darwin.org/bootstrap.html
Here is some important recent news about it.
http://www.imminst.org/forum/index.php?s=&act=print&client=printer&f=237&t=10749
It is exciting to suppose that people can get off the pharmaceuticals
that they are taking with calorie restriction or CR-memetics. I
personally am trying to get off the cholesterol drug Pravachol, a
statin compound, starting a few of weeks ago. Write me, and I'll let
you know how it turns out. From the article...
"Fontana says ... evidence of "younger" hearts in people on calorie
restriction, suggest that humans on CR have the same adaptive
responses as did animals whose rates of aging were slowed by CR."
I think that it is time to look at the tannins in tobacco leaves.
There may be other treasures lurking there too. As you may be
aware there is ample public research into any possible beneficial
compounds that may be obtained from tobacco leaves. The mechanisms
are there waiting to be discovered. If you want to post them, just
reply to me and I'd be delighted to host them.
The public establishment of prior art is a time-honed method of
entering inventions into the public domain. We now have other
methods at our disposal as well. If you are planning to establish
prior art against future CR-memetic related patents, you might want
to have a look at www.creativecommons.org. Perhaps it goes without
saying at this point that you should please choose a license that
provides for free and broad public access to your memetic.
In that way you will assure that the public health is served by
anchoring them to the public common, where they cannot be exploited
by those who would withhold them for their own profit. The DRM
situation is precisely analogous to this. Can you imagine doing
science in a world where your ability to read and write your data is
filtered through secret protocols that are hidden from you? I
recommend the Defective By Design campaign to fight the outrage of
DRM, which is incompatible with the scientific pursuit.
http://www.defectivebydesign.org/
It is clear that scientific tools must be demonstrably and
penetratingly understood, or else our claims will likely be skewed
and called into question. Free and open source software is
a great example of how to make your science verifiable to the
public. Establishing prior art against future patents is
another good one, which is precisely analogous in method,
making the result explicit to the public, free and open to all.
Thank goodness for the free and open software movement, which
gave us such a great example of how to serve the public in this
manner.
I am willing to grant that there are particular exceptions to
these rules of freedom and openness, and such exceptions may be
relatively harmless; however, let us posit the opposite, that
freedom and openness are _not_ crucial to understanding. Think of
the implications. When people are compelled to learn, they do not
receive the intended message. It is not understood correctly
or completely. When crucial facts are withheld from the people
you are trying to teach they become paranoid, possibly unteachable.
Freedom and openness are obviously the best approach to understanding.
This is not a metaphor for the pursuit of science, but a fact.
We are learning from nature, and it is ultimately required that
our tools be demonstrably and penetratingly understood, or else
we will receive incorrect lessons from nature. Clearly this
requires public access to the source code and more. This
is why many of us are pressing for public access to scientific
publications.
Moreover FOSS tools are becoming ever more important to the
pursuit of the scientific endeavor itself. In our biophysics
department we are obsolescing proprietary hardware and software
in favor of open standards and free software, which is a
widespread phenomenon in the science sector, and sure to continue.
We build most of the workstations ourselves with commodity hardware,
but we also have some clusters running Debian and FedoraCore.
Some of you will know that I am the lead developer for the
GNU-Darwin distribution. GNU-Darwin has a FOSS operating system,
which is getting alot of press these days. Here is an example
How Apple and Microsoft are advancing desktop Linux
http://www.desktopLinux.com/news/ns7294331817.html
I see the article as counter-productive against building a FOSS
coalition that includes democracy, freedom, and public access
activists, Apple, GNU-Darwin, GNU, and GNU/Linux all linked
together in spectrum.
It is important to alert the whole FOSS community that Darwin
cannot be classified as a free or open source operation system
as of the Darwin-8 revision, because AppleACPIplatform-39 which
is required to boot the system is proprietary. It is notable that
only the current version of Darwin from Apple is a non-free OS.
GNU-Darwin has a free version, an earlier revision that includes
the source code. It is FOSS, and we call upon Apple to maintain
Darwin as such, as it has been in the past. We hope that the
current situation with the kernel and ACPI driver will soon be
remedied so that Darwin will continue as a FOSS OS.
We are asking for free software developers to please write to the
*nix core of Darwin, which is the core OS for both Mac OS X and
GNU-Darwin OS. Darwin OS, which underlies both systems, comprises
parts from GNU, the BSD's, mach, plus Apple's substantial
contributions to the free software community. Be consistent with your
philosophy and avoid linkage to proprietary binaries, such as OpenGL
and CoreAudio, except when it is imperatively required in order to
lead users to the values of software freedom. Under that principle,
another reason to maintain compatibility with the *nix core, is so
that your code will be readily portable to new platforms and usable
by free-software-only aficionados too.
GNU-Darwin OS is not an obsolete implementation of Darwin OS, or to be
superseded by Mac OS X. We are trying to lead users to freedom, not
away from it. By maintaining Darwin core compatibility your code will
remain valuable as the marketplace and industry continues to evolve
(trust me here), particularly as DRM-related problems continue to come
forward. Of course, that means releasing your source code under a FOSS
license, such as APSL. Darwin OS is a free and open source operating
system that is not going away, so try to focus your coding towards
supporting that standard instead of proprietary software.
Here is the essence of the current problem with Darwin OS. Apple
replaced working boot code with the following proprietary drivers,
which are required for the system to boot.
Darwin-7:
AppleAPIC.kext/
Applei386genericplatform.kext/
Darwin-8:
AppleACPIplatform
In addition the kernel (xnu) has been taken proprietary in the
recent revisions. We are not asking for Apple to give away such
things, but rather to continue maintaining Darwin OS as FOSS, which
it already was.
After repeated attempts by many FOSS developers to get this
situation remedied, nothing has happened. It is now time for us to
better use the measures at our disposal in order to assure that
Darwin OS remains free and open. If you are unhappy that xnu and
the boot drivers have not been released, I would encourage you to
spread your dissatisfaction to other forums, so that Apple will take
notice and commit to a workable free and open Darwin OS from now on.
Moving on to coalition strategy now, some of you may not know that
GNU/Linux system administration is one of my day jobs. I manage a
wide range of systems. Here is a screen-shot of my work desktop, so
that you can see I use the same tools at work that I use at home at
night on GNU-Darwin. (weekends too, so please read I am your friend)
http://proclus.gnu-darwin.org/debian.html
The only time that I ever use proprietary software is when I am trying
to help other users learn free and open source free software. I'm a
long time Apple and GNU/Linux user, and here is the old proof doc ;-}.
http://proclus.tripod.com/indulge.html
Now, it is embarrassing but, I want you to have a look at my cv.
http://biophysics.med.jhmi.edu/love/thesis/cv6.html
In all my years I have never used Microsoft Windows. There are only
two exceptions to this statement, where I was helping Windows users to
access our servers at Hopkins. Clearly, you can get a few things done
without it ;-}.
One of the primary reasons for founding GNU-Darwin was to help people
to put Microsoft behind them, and it is definitely possible to do it
now. You have many resources at your disposal to help you leave
Microsoft behind. Look at the link below to see what you can do
with free software. Apple, GNU-Darwin, GNU.org, and GNU/Linux will
all help, and we are largely all helping together, because we have a
shared foundation of free software.
http://www.gnu-darwin.org/gdc/
Microsoft is only one example. That is why we are so insistent that
Apple keep true to free and open source software principles. We
should ultimately try to leave all proprietary software behind us, so
that we can participate fully in the freedom and openness of the
internet culture and public domain. What more do we need, when we
have such a rich store of information and so many capable people at
our sides?
Finally, as a scientist, it is obvious to me that this situation is
relevant current and ongoing discussion in the scientific community,
and as such, it is also clear that many members of the various lists
would be interested in the current state of Darwin with respect to
FOSS and with respect to science.
Here is the crucial point.
The principles of FOSS and scientific inquiry converge. In
practical terms, how else can you know is what happening in your
experiments? Free and open source software, open standards, best
promote the scientific endeavor by mirroring its method, but also
they assure that the work is accessible to the public.
Freedom and openness are crucial to understanding, and foundational
to the scientific endeavor, and they should not be compromised.
There are a few examples of exceptions, but clearly, this matter
will find further debate in the appropriate forums. We should not
quell debate because a few people are offended or complaining.
- From a scientific perspective that would be incorrect.
On that last point, I would suggest that Apple get on the right side
of the debate, and they will make tremendous headway. Now is the
time.
Some people will find this message annoying and divisive, and the
delete button is ready at hand for them, but other people will find
it interesting and engaging. All as you like. Let us not quell
discussion because a few people are annoyed.
Some will call this a troll, but I hope that folks will see through
such name-calling. Trolls are mythological creatures, so don't
believe in them. Everyone has a right to have their opinion
heard, even if those opinions are divisive or unpopular. It is
clear that the idea of trolls is being used to attack freedom of
expression. In fact, freedom of expression demands that we
listen to the so-called-trolls sometimes, and if you are civil, it
helps, so don't resort to name-calling.
On cross-posting; when there are matters of urgent importance that
affect a broad range of subscriber lists, courtesy must sometimes
take a back seat, and cross-posting is an example of that.
Cross-posting is to be encouraged when the subject of the post is on
topic. Each of the various lists will respond in the way that seems
appropriate to the people in that forum, and the threads on the
various lists will diverge accordingly. As the threads diverge, the
cross-posting addresses should be removed as needed. Relevance to
all people is an unattainable goal, but messages of the broadest
applicability should have the broadest reach, and discussion should
not be stymied because some find it irrelevant. I have given this
method due consideration; it is not trolling, not spam, not off-topic,
and cross-posting is an example of something that is sometimes
required according to the felt importance and relevance of a given
subject matter.
In summary, Freedom and openness are now the bedrock of our
civilization and public welfare depends on these values, so that we
should actively engage ourselves in preserving and making them happen.
In keeping with these principles it is crucial to note that there are
exceptions to etiquette, otherwise free expression will be overly
channeled, damped, and ultimately suppressed in our forums. This
notion of courtesy will certainly receive additional consideration,
but meanwhile, let us together get to work on the activism now.
Duly, I am amenable to valid criticism and able to respond, but please
reply with kindness. Obviously, feel free to write back, copy, or
send these comments along to anyone else as you see fit.
Regards,
Michael L. Love Ph.D
Department of Biophysics and Biophysical Chemistry
School of Medicine
Johns Hopkins University
725 N. Wolfe Street
Room 608B WBSB
Baltimore MD 21205-2185
Interoffice Mail: 608B WBSB, SoM
office: 410-614-2267
lab: 410-614-3179
fax: 410-502-6910
cell: 443-824-3451
http://www.gnu-darwin.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEpIl6u0oI3iz5oZcRAtpQAJ9X7D6kq1vmWKXkG/3LBvx3gGrK1QCZAbgI
8Ww6QABLiZtmFmS9Ekea5nI=
=a0Oy
-----END PGP SIGNATURE-----
^ permalink raw reply
* Booting 2.4 RT-Linux build from FSMlabs
From: Hamid Marshall @ 2006-07-01 20:06 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
I am working on a Lite5200B board with the U-Boot build dated April-2006.
After loading of the uImage file which is 2.4 kernel RT-Linux build from FSM
labs the board get hang up right after the decompressing the kernel, never
getting to mach(). I looked at the memory dumps and with logic analyzer
peeked at the address bus as well. Look like after the decompressing the
kernel there is no entry to the main or init modules.
Has anyone encounter this problem before?
Thanks,
## Booting image at 00200000 ...
Image Name: Linux-2.6.16-rc1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 658050 Bytes = 642.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Hamid Marshall
Cyberwatch Communication
http://www.cyberwatch-security.com
[-- Attachment #2: Type: text/html, Size: 5384 bytes --]
^ permalink raw reply
* Re: sound connector detection
From: Dmitry Torokhov @ 2006-07-01 20:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-input, Richard Purdie, alsa-devel, Linux Kernel list,
linuxppc-dev list
In-Reply-To: <1151671786.13412.6.camel@localhost>
On Friday 30 June 2006 08:49, Johannes Berg wrote:
> Hi,
>
> One Apple machines I have with snd-aoa the situation that the alsa
> driver can detect changes in in/output connector state ("is headphone
> plugged in" etc.) and currently surfaces it through a read-only alsa
> mixer element. That isn't really ideal since nothing is prepared to
> handle such events, hence I provide an additional control that allows an
> in-kernel toggle from speakers to headphone on headphone plug (and vice
> versa).
>
> I'd really like to see this handled in userspace (additionally or
> possibly event instead), since there are complications especially with
> input (line-in) detection and user preferences of what should happen
> then. The number of cases can become large, especially when throwing in
> digital and combo connectors that aren't handled yet.
>
> Now, is it appropriate to create an input device for the state of these
> things and add new constants like SW_LINEIN_INSERTED,
> SW_LINEOUT_INSERTED, SW_OPTICALOUT_INSERTED, SW_OPTICALIN_INSERTED and
> if so, how do I reflect the fact that on some machines optical and
> analog input/output is mutually exclusive, while on others it isn't?
> That would probably require another SW_COMBO_IN/OUT set...
>
> Or should I simply stick with (a) read-only mixer control(s), and for
> the mutually exclusive case create a tristate (none, optical, analog)
> one? But SW_HEADPHONE_INSERT already exists, so we may want to do this
> identically on different machines.
>
Hi Johannes,
I am not too happy with putting this kind of switches into input layer,
it should be reserved for "real" buttons, ones that user can explicitely
push or toggle (lid switch is on the edge here but it and sleep button
are used for similar purposes so it makes sense to have it in input layer
too). But "cable X connected" kind of events is too much [for input layer,
there could well be a separate layer for it]. If we go this way we'd have
to move cable detection code from network to input layer as well ;)
--
Dmitry
^ permalink raw reply
* JFFS2 FS is read-only (not what I want)
From: Ben Warren @ 2006-07-01 21:13 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
When I boot from a JFFS2 file system on my eval board, the file system
is effectively read-only, and I can't figure out why. I'm pretty sure
the kernel's configured for R/W MTD block access. Any help is greatly
appreciated.
The hardware in use is:
Freescale MPC8349EMDS eval board.
8MB Q-flash with 64 uniform 128k sectors
Here are the symptoms:
# du -s
265492 . <-- only 265k of data
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock4 2048 2048 0 100% /
# mount
/dev/mtdblock4 on / type jffs2 (rw)
/proc on /proc type proc (rw)
Here's what the kernel spits out at boot-up:
***
physmap flash device: 800000 at fe000000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Command set type 1
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition definition
Creating 6 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "u-boot"
0x00040000-0x00080000 : "env"
0x00080000-0x00280000 : "kernel" <-- kernel boots
from here
0x00280000-0x00480000 : "initrd" <-- no initrd,
this is empty
0x00480000-0x00680000 : "jffs2" <-- 2MB partition
0x00680000-0x00800000 : "user" <-- empty
***
I created the MTD partitions in a u-boot image that was pulled from the
GIT tree about a week ago, and my kernel is 2.6.17-based. I wrote some
board init code that sets the MTD physical mappings.
Here are the MTD and JFFS2 parts of my .config file:
***
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xFE000000
CONFIG_MTD_PHYSMAP_LEN=0x800000
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_PLATRAM is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
***
The file system is the SELF that is included with DENX's ELDK, and built
as at:
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding
I used the following command to create the file system image, that was
then loaded at address 0xfe480000 via U-boot:
> mkfs.jffs2 -U -d rootfs -D rootfs_device.tab -b -e 0x20000 -o jffs2.img
I modified the table to name my serial devices /dev/ttyS0 and /dev/ttyS1
thanks for the help. Sorry if this is too verbose or includes the wrong
information.
regards,
Ben
^ permalink raw reply
* Re: faulty 64-bit resource printk fixup in macio_asic.c
From: Benjamin Herrenschmidt @ 2006-07-01 23:16 UTC (permalink / raw)
To: Paul Collins; +Cc: linuxppc-dev, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <878xndqwph.fsf@briny.internal.ondioline.org>
On Sat, 2006-07-01 at 23:30 +1000, Paul Collins wrote:
> Hi Greg,
>
> The patch titled "64bit resource: fix up printks for resources in misc
> drivers", committed as e29419fffceb8ec36def3c922040e1ca7bcd3de5 in
> Linus's tree, causes my PowerBook to Oops early in boot and udev to
> not function.
For now, I'd suggest reverting it. The MacIO resources always fit in 32
bits, thus we can "use" that knowledge here and only print 8 digits.
Ben.
> Unable to handle kernel paging request for data at address 0x6f000000
> Faulting instruction address: 0xc00c901c
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT
> Modules linked in:
> NIP: C00C901C LR: C00C901C CTR: C00C8F78
> REGS: efed5db0 TRAP: 0300 Not tainted (2.6.17-g9262e914)
> MSR: 00009032 <EE,ME,IR,DR> CR: 22000484 XER: 20000000
> DAR: 6F000000, DSISR: 40000000
> TASK = efe97240[378] 'udevtrigger' THREAD: efed4000
> GPR00: C00C901C EFED5E60 EFE97240 00000000 CFC0BB40 00010001 CFC0BB40 C02E9754
> GPR08: 00000000 00000001 EFFE8EA4 EFED4000 44000428 1001D140 100D0000 100D0000
> GPR16: 00000000 100EBF08 100D0000 100B0000 100D0000 100B0000 100EBEA8 100EC068
> GPR24: 00000000 EFEEDA20 C0DF7880 EFED4000 CFC0BB40 EFEEDA20 C0DF78D0 6F000000
> NIP [C00C901C] sysfs_open_file+0xa4/0x284
> LR [C00C901C] sysfs_open_file+0xa4/0x284
> Call Trace:
> [EFED5E60] [C00C901C] sysfs_open_file+0xa4/0x284 (unreliable)
> [EFED5E90] [C007D6A8] __dentry_open+0x108/0x2a4
> [EFED5EC0] [C007D988] do_filp_open+0x5c/0x78
> [EFED5F20] [C007D9FC] do_sys_open+0x58/0xf8
> [EFED5F40] [C000FDB8] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff248d8
> LR = 0xffb525c
> Instruction dump:
> 3be0ffea 812b0050 83c90014 419e007c 2f9e0000 419e006c 83fe0004 2f9f0000
> 419e0080 38600001 4bf5b229 4809726d <801f0000> 3ba00000 2f800002 419e0024
> <6>note: udevtrigger[378] exited with preempt_count 1
>
>
> The only hunk of that commit affecting my configuration is this one,
> which when reverted lets my machine work again.
>
> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
> index 431bd37..c687ac7 100644
> --- a/drivers/macintosh/macio_asic.c
> +++ b/drivers/macintosh/macio_asic.c
> @@ -428,10 +428,10 @@ #endif
>
> /* MacIO itself has a different reg, we use it's PCI base */
> if (np == chip->of_node) {
> - sprintf(dev->ofdev.dev.bus_id, "%1d.%08lx:%.*s",
> + sprintf(dev->ofdev.dev.bus_id, "%1d.%016llx:%.*s",
> chip->lbus.index,
> #ifdef CONFIG_PCI
> - pci_resource_start(chip->lbus.pdev, 0),
> + (unsigned long long)pci_resource_start(chip->lbus.pdev, 0),
> #else
> 0, /* NuBus may want to do something better here */
> #endif
>
>
> When applied, this hunk yields
>
> /* MacIO itself has a different reg, we use it's PCI base */
> if (np == chip->of_node) {
> sprintf(dev->ofdev.dev.bus_id, "%1d.%016llx:%.*s",
> chip->lbus.index,
> #ifdef CONFIG_PCI
> (unsigned long long)pci_resource_start(chip->lbus.pdev, 0),
> #else
> 0, /* NuBus may want to do something better here */
> #endif
> MAX_NODE_NAME_SIZE, np->name);
>
>
> Since dev->ofdev.dev is a struct device, bus_id is 20 bytes, of which
> 19 are consumed by "%1d.%016llx:". But the field width used by "%.*s"
> is MAX_NODE_NAME_SIZE, which is 8.
>
> drivers/macintosh/macio_asic.c:36:#define MAX_NODE_NAME_SIZE (BUS_ID_SIZE - 12)
>
> So I think the sprintf overflows bus_id and clobbers the next few
> bytes of struct device.
>
> I'm not sure what the right thing to do is. Making bus_id bigger will
> cost everyone, but right now with bus_id at 20 bytes, there's no room
> after the colon for any of np->name.
>
^ 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