* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-09-15 19:43 UTC (permalink / raw)
To: Jamie Lokier
Cc: Greg Ungerer, Linux-kernel, linux-embedded, linux-mtd,
Jörn Engel, tim.bird, cotte, nickpiggin
In-Reply-To: <20080915163421.GA13631@shareable.org>
>> >> I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
>>
>> If you are using a GL, you'll probably find our P33 a good fit and at
>> competitive prices to GL as I understand it. That's I think 50Mhz.
>
> What's a GL? Never heard of it - all I can think of is OpenGL :-)
S29_GL_128N
> I'm not sure if cache is an option with this device - but would it
> make a difference anyway?
Well the first read takes 100ns (plus the other chipset overhead
300ns) but other reads in a page are only an extra 25ns each. So your
benefit is not from having the entire executable in cache it's from
having the next 7 instructions in the cacheline for only an extra 25ns
each instead of 400ns.
> Interesting, thanks. I'm not sure it's possible to change the way NOR
> is being used with this chip, and it'll be a while before it's
> economical to replace the board with a new design.
Usually these things can be fixed in the bootloader or by hacking the
kernel to tweak the relevant chipset registers.
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Ricard Wanderlof @ 2008-09-16 6:57 UTC (permalink / raw)
To: Jamie Lokier
Cc: cotte@de.ibm.com, Greg Ungerer, linux-embedded@vger.kernel.org,
nickpiggin@yahoo.com.au, Jörn Engel,
Linux-kernel@vger.kernel.org, linux-mtd, tim.bird@am.sony.com
In-Reply-To: <20080915163421.GA13631@shareable.org>
On Mon, 15 Sep 2008, Jamie Lokier wrote:
> This is all very interesting - I had no prior experience with NOR, so
> didn't know that 0.6MB/s was slow. It's fast compared with older
> EEPROMs after all, and had imagined that people wanting fast flash
> would use NAND.
>
NAND is significantly faster when writing than NOR, read speed is of the
same magnitude, possibly slower in many cases.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
"With Free Software you are employing the best programmers on the planet"
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Jared Hulbert @ 2008-09-16 15:30 UTC (permalink / raw)
To: Ricard Wanderlof
Cc: Jamie Lokier, cotte@de.ibm.com, Greg Ungerer,
linux-embedded@vger.kernel.org, nickpiggin@yahoo.com.au,
Jörn Engel, Linux-kernel@vger.kernel.org, linux-mtd,
tim.bird@am.sony.com
In-Reply-To: <Pine.LNX.4.64.0809160856190.5966@lnxricardw.se.axis.com>
> NAND is significantly faster when writing than NOR, read speed is of the
> same magnitude, possibly slower in many cases.
Right.
Specifically, read bandwidth is on the same order of magnitude.
However the read latency of NAND is a couple orders of magnitude
higher (100ns vs 20,000ns) so it depends on what you are doing.
^ permalink raw reply
* Marvel 88E6063-RCJ1 driver
From: linux-embedded-owner @ 2008-09-17 4:33 UTC (permalink / raw)
To: Linux embedded; +Cc: Linux embedded owner
Hi,
I'm not sure, if my posting goes to the right list, but before I'll start
hacking away, I would like to ask if someone already has a driver for a
Marvel Linkstreet 88E6063 Integrated 7-Port QoS, 802.1Q 10/100 Ethernet
Switch for a 2.6 kernel handy or can point me to where this can be found.
Regards,
Robert
--
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30 210) 684 7881
URL: http://www.reliableembeddedsystems.com
--
...One test is worth a thousand opinions.-Jack Ganssle
^ permalink raw reply
* ELBS mindshare
From: Grant Likely @ 2008-09-17 18:13 UTC (permalink / raw)
To: Behan Webster; +Cc: Michelle Konzack, linux-embedded
In-Reply-To: <48B188CE.1030006@websterwood.com>
Hey Behan,
BTW, I was talking with a guy from TI last night (Mike Turquette; works
on the OMAP) and I asked him my standard question about what he thinks
about the state of building root filesystems for embedded systems.
When he listed the toolkits he knows about and is interested in, ELBS
was either the 2nd or 3rd tool that he mentioned.
Word is getting around dude.
g.
^ permalink raw reply
* Re: ELBS mindshare
From: Robert Schwebel @ 2008-09-17 18:23 UTC (permalink / raw)
To: Grant Likely; +Cc: Behan Webster, Michelle Konzack, linux-embedded
In-Reply-To: <20080917181323.GD7913@secretlab.ca>
On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote:
> BTW, I was talking with a guy from TI last night (Mike Turquette; works
> on the OMAP) and I asked him my standard question about what he thinks
> about the state of building root filesystems for embedded systems.
>
> When he listed the toolkits he knows about and is interested in, ELBS
> was either the 2nd or 3rd tool that he mentioned.
>
> Word is getting around dude.
What is ELBS? If it is somehow better than ptxdist, I'll have to apply a
few patches there 8-)
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: ELBS mindshare
From: Bill Traynor @ 2008-09-17 19:48 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20080917182333.GO9852@pengutronix.de>
> On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote:
>> BTW, I was talking with a guy from TI last night (Mike Turquette; works
>> on the OMAP) and I asked him my standard question about what he thinks
>> about the state of building root filesystems for embedded systems.
>>
>> When he listed the toolkits he knows about and is interested in, ELBS
>> was either the 2nd or 3rd tool that he mentioned.
>>
>> Word is getting around dude.
>
> What is ELBS? If it is somehow better than ptxdist, I'll have to apply a
> few patches there 8-)
Embedded Linux Build System
http://debian.websterwood.com/elbs/
Article on LinuxDevices:
http://www.linuxdevices.com/news/NS5894411715.html
>
> rsc
> --
> Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: ELBS mindshare
From: Robert Schwebel @ 2008-09-17 20:27 UTC (permalink / raw)
To: Bill Traynor; +Cc: linux-embedded
In-Reply-To: <5763a8949cead468dd505137165e8e65.squirrel@www.geekisp.com>
On Wed, Sep 17, 2008 at 03:48:57PM -0400, Bill Traynor wrote:
> > On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote:
> >> BTW, I was talking with a guy from TI last night (Mike Turquette; works
> >> on the OMAP) and I asked him my standard question about what he thinks
> >> about the state of building root filesystems for embedded systems.
> >>
> >> When he listed the toolkits he knows about and is interested in, ELBS
> >> was either the 2nd or 3rd tool that he mentioned.
> >>
> >> Word is getting around dude.
> >
> > What is ELBS? If it is somehow better than ptxdist, I'll have to apply a
> > few patches there 8-)
>
> Embedded Linux Build System
> http://debian.websterwood.com/elbs/
>
> Article on LinuxDevices:
> http://www.linuxdevices.com/news/NS5894411715.html
Ok, you do native building, that's not what we do for ptxdist's standard
root filesystems.
But note that ptxdist itself is only a system to manage configurable
rules which are being executed in a dependency-defined order; so in the
end, it can built whatever it likes.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Marvel 88E6063-RCJ1 driver
From: Kumar Gala @ 2008-09-17 22:02 UTC (permalink / raw)
To: <linux-embedded-owner@reliableembeddedsystems.com>; +Cc: Linux embedded
In-Reply-To: <d7555edbde4d54b0693fa7bddb894cfe@reliableembeddedsystems.com>
One place to look is the WRT projects.. Some of them have drivers for
various switches.
- k
On Sep 16, 2008, at 11:33 PM, <linux-embedded-owner@reliableembeddedsystems.com
> <linux-embedded-owner@reliableembeddedsystems.com> wrote:
> Hi,
>
> I'm not sure, if my posting goes to the right list, but before I'll
> start
> hacking away, I would like to ask if someone already has a driver
> for a
> Marvel Linkstreet 88E6063 Integrated 7-Port QoS, 802.1Q 10/100
> Ethernet
> Switch for a 2.6 kernel handy or can point me to where this can be
> found.
>
> Regards,
>
> Robert
>
> --
> Robert Berger
> Embedded Software Specialist
>
> Reliable Embedded Systems
> Consulting Training Engineering
> Tel.: (+30) 697 593 3428
> Fax.:(+30 210) 684 7881
> URL: http://www.reliableembeddedsystems.com
> --
> ...One test is worth a thousand opinions.-Jack Ganssle
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ELBS mindshare
From: Grant Likely @ 2008-09-17 22:09 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Behan Webster, Michelle Konzack, linux-embedded
In-Reply-To: <20080917182333.GO9852@pengutronix.de>
On Wed, Sep 17, 2008 at 08:23:33PM +0200, Robert Schwebel wrote:
> On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote:
> > BTW, I was talking with a guy from TI last night (Mike Turquette; works
> > on the OMAP) and I asked him my standard question about what he thinks
> > about the state of building root filesystems for embedded systems.
> >
> > When he listed the toolkits he knows about and is interested in, ELBS
> > was either the 2nd or 3rd tool that he mentioned.
> >
> > Word is getting around dude.
>
> What is ELBS? If it is somehow better than ptxdist, I'll have to apply a
> few patches there 8-)
Oops, I forgot to remove the linux-embedded from the to: list. I had
intended to this to be a private email to Behan; Oh well, now even more
people have probably heard about it. :-)
ELBS is a set of tools for bootstrapping an embedded root filesystem
using existing Debian or Ubuntu packages.
g.
^ permalink raw reply
* Re: Marvel 88E6063-RCJ1 driver
From: Pawel Pastuszak @ 2008-09-17 22:29 UTC (permalink / raw)
To: linux-embedded; +Cc: <linux-embedded-owner@reliableembeddedsystems.com>
In-Reply-To: <8ff29df80809171524k415583b1x62ee2106ec0b1bd8@mail.gmail.com>
You don't need any driver for the 88E6063 it uses phy id to talk to
all its ports.. so all you have to do is make sure you set up your
board to not to bind to any phy address then you can uses it as a
switch..
Which Processor is this for...I created couple tool for the marvell
switch i uses 3 different type in that family of switch's
Pawel
^ permalink raw reply
* local_save_flags(flags)
From: Fundu @ 2008-09-18 18:48 UTC (permalink / raw)
To: linux embedded
Hi,
From my understanding the local_irq_save(flags) saves the current irq state and disables the interrupts.
My question is what happens to those interrupts that arriving while the interrupts are disabled.
is the following understanding correct ...
if they are edge triggered they would be lost,
only level triggered interrupts would be serviced after interrupts are enabled.
TIA
Fundu.
^ permalink raw reply
* RE: local_save_flags(flags)
From: Fundu @ 2008-09-18 21:09 UTC (permalink / raw)
To: linux embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C098AABE6@USA0300MS03.na.xerox.net>
> turning off interrupts just masks them. the interrupt
> hardware should
> "latch" them and they fire when you reenable
> interrupts.
>
> You loose track of "how many" not if any
> happened...
>
> marty
Thanks Marty,
a follow up question,
why do we need to save the flags then ? if the interrupt hardware would
latch them ?
can we not just disable all interrupts ?
TIA,
Fundo
^ permalink raw reply
* Re: local_save_flags(flags)
From: Mike Frysinger @ 2008-09-18 21:15 UTC (permalink / raw)
To: fundu_1999; +Cc: linux embedded
In-Reply-To: <896951.4734.qm@web63401.mail.re1.yahoo.com>
On Thu, Sep 18, 2008 at 17:09, Fundu wrote:
>> turning off interrupts just masks them. the interrupt
>> hardware should
>> "latch" them and they fire when you reenable
>> interrupts.
>>
>> You loose track of "how many" not if any
>> happened...
>
> a follow up question,
> why do we need to save the flags then ? if the interrupt hardware would
> latch them ?
> can we not just disable all interrupts ?
you really should just read a book on the topic. LDD3 covers these
intricacies (and a lot more), as does Essential Linux Device Drivers.
-mike
^ permalink raw reply
* Re: local_save_flags(flags)
From: Fundu @ 2008-09-18 22:05 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux embedded
In-Reply-To: <8bd0f97a0809181415y2def310h73d83a455615b8ff@mail.gmail.com>
> you really should just read a book on the topic. LDD3
> covers these
> intricacies (and a lot more), as does Essential Linux
> Device Drivers.
i'm actually reading essential linux device drivers. And to get some clarification i made the post.
^ permalink raw reply
* Re: local_save_flags(flags)
From: Mike Frysinger @ 2008-09-18 22:07 UTC (permalink / raw)
To: fundu_1999; +Cc: linux embedded
In-Reply-To: <732333.54005.qm@web63404.mail.re1.yahoo.com>
On Thu, Sep 18, 2008 at 18:05, Fundu wrote:
>> you really should just read a book on the topic. LDD3
>> covers these
>> intricacies (and a lot more), as does Essential Linux
>> Device Drivers.
>
> i'm actually reading essential linux device drivers. And to get some clarification i made the post.
that book explicitly covers your question. read chapter 2 where it
covers these irq functions.
-mike
^ permalink raw reply
* Re: local_save_flags(flags)
From: Fundu @ 2008-09-18 22:45 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux embedded
In-Reply-To: <8bd0f97a0809181507u265ec60eu597500ab6187e211@mail.gmail.com>
> that book explicitly covers your question. read chapter 2
> where it
> covers these irq functions.
as i said i'm reading the book and actully i did read that chapter.
for me, here's the exact line that needs clarification,
In chapter 2, page 42 last paragraph(starts with "However, if ..." )
here's the code snippet he's talking about.
Point A:
local_irq_disable();
/* critical section ...*/
local_irq_enable();
Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state.
1) first what's the difference between re-enabling and restoring interrupt state.
2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.
hope i have made myself clear enough for you to respond.
TIA
^ permalink raw reply
* Re: local_save_flags(flags)
From: Mike Frysinger @ 2008-09-18 22:51 UTC (permalink / raw)
To: fundu_1999; +Cc: linux embedded
In-Reply-To: <545834.68406.qm@web63405.mail.re1.yahoo.com>
On Thu, Sep 18, 2008 at 18:45, Fundu wrote:
>> that book explicitly covers your question. read chapter 2
>> where it
>> covers these irq functions.
>
> as i said i'm reading the book and actully i did read that chapter.
>
> for me, here's the exact line that needs clarification,
> In chapter 2, page 42 last paragraph(starts with "However, if ..." )
>
> here's the code snippet he's talking about.
> Point A:
> local_irq_disable();
> /* critical section ...*/
> local_irq_enable();
>
>
> Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state.
this was the section i referred to ... but i guess it made perfect
sense to me since i'm familiar with the details
> 1) first what's the difference between re-enabling and restoring interrupt state.
many irq controllers have a global enable bit. you can restore the
interrupt mask state without toggling that bit.
> 2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.
both are a problem. the non-state saving version cannot be used
recursively nor in parallel to the state-saving version.
-mike
^ permalink raw reply
* Re: local_save_flags(flags)
From: Daniel THOMPSON @ 2008-09-19 9:52 UTC (permalink / raw)
To: fundu_1999; +Cc: Mike Frysinger, linux embedded
In-Reply-To: <545834.68406.qm@web63405.mail.re1.yahoo.com>
Fundu wrote:
>
>> that book explicitly covers your question. read chapter 2
>> where it
>> covers these irq functions.
> as i said i'm reading the book and actully i did read that chapter.
>
> for me, here's the exact line that needs clarification,
> In chapter 2, page 42 last paragraph(starts with "However, if ..." )
>
> here's the code snippet he's talking about.
> Point A:
> local_irq_disable();
> /* critical section ...*/
> local_irq_enable();
>
>
> Author say, if irg are already disabled at Point A (see snippet above) then local_irq_enable() creates an unpleasant side effect of re-enabling interrupts rather than restoring interrupt state.
>
> 1) first what's the difference between re-enabling and restoring interrupt state.
> 2) so is disable interrupts twice a problem, or just enabling them when after they are diabled (which sounds like how it should be ) a problem.
>
> hope i have made myself clear enough for you to respond.
I think you are confused by the term 'flags'. In this case 'flags' is
not the interrupts that are pending, there are the interrupts that where
enabled before calling local_irq_save().
Does an example help? Consider driver A that calls 'library' code B.
void driver_A()
{
local_irq_disable();
/* do something critical */
library_code_B();
/* do something else critical */
local_irq_enable();
/* NO BUG - if interrupts are not locked when local_irq_disable()
* was called.
*/
}
void library_code_B(void)
{
#if BUGGY_CODE_COMES_FIRST
local_irq_disable();
/* do something critical */
local_irq_enable();
/* BUG HERE - driver A thinks interrupts are still disabled but
* they are not
*/
#else
flags = local_irq_save();
/* do something critical */
local_irq_restore(flags);
/* NO BUG - interrupts are still locked (flags is used to remember
* that interrupts were locked when we called local_irq_save().
*/
#endif
}
In fewer words: use local_irq_save/restore() if you don't know whether
interrupts where locked or not when your function was called.
PS There are only a small number of drivers that should use the
local_irq_... family of functions anyway. Normally you should use
create a spin lock and use spin_lock_irq() and spin_lock_irqsave()
instead.
--
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659
If a car is a horseless carriage then is a motorcycle a horseless horse?
^ permalink raw reply
* Re: Marvel 88E6063-RCJ1 driver
From: linux-embedded-owner @ 2008-09-19 14:27 UTC (permalink / raw)
To: Pawel Pastuszak; +Cc: linux-embedded
In-Reply-To: <8ff29df80809171529o7b83dafft30edf4c7217a04e@mail.gmail.com>
Thanks Pawel,
It's for a Sigma SMP8634 (MIPS 4KEc) chipset.
In the meantime we got it working.
And yes, no special driver is needed for it.
Regards,
Robert
--
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30 210) 684 7881
URL: http://www.reliableembeddedsystems.com
--
...If you've found 3 bugs in a program, best estimate is that there are 3
more.-Jack Ganssle
On Wed, 17 Sep 2008 18:29:04 -0400, "Pawel Pastuszak"
<pawelpastuszak@gmail.com> wrote:
> You don't need any driver for the 88E6063 it uses phy id to talk to
> all its ports.. so all you have to do is make sure you set up your
> board to not to bind to any phy address then you can uses it as a
> switch..
>
> Which Processor is this for...I created couple tool for the marvell
> switch i uses 3 different type in that family of switch's
>
> Pawel
^ permalink raw reply
* Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
From: Trent Piepho @ 2008-09-19 19:20 UTC (permalink / raw)
To: Jared Hulbert
Cc: Jamie Lokier, cotte, Greg Ungerer, linux-embedded, nickpiggin,
Jörn Engel, Linux-kernel, linux-mtd, tim.bird
In-Reply-To: <6934efce0809151243h60a6e48bpf0c7600d4badf3c4@mail.gmail.com>
On Mon, 15 Sep 2008, Jared Hulbert wrote:
>>>>> I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
>>>
>>> If you are using a GL, you'll probably find our P33 a good fit and at
>>> competitive prices to GL as I understand it. That's I think 50Mhz.
>>
>> What's a GL? Never heard of it - all I can think of is OpenGL :-)
>
> S29_GL_128N
I'm using a S29GL064N chip. Going through linux and /dev/mtd I get 13.5
MB/sec and reading directly from the chips give 15 MB/sec. I've not mapped
the chip cached and I'm not using the page burst mode. That would help a lot
certainly, but the current flash speed isn't much of a bottleneck.
^ permalink raw reply
* Re: ELBS mindshare
From: Michelle Konzack @ 2008-09-20 19:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Robert Schwebel, Behan Webster, linux-embedded
In-Reply-To: <20080917220953.GB7453@secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
Hi Grand,
Fortunateley you have forgoten to remove my E-Mail...
...otherwise I had to kill you! ;-)
Am 2008-09-17 15:09:53, schrieb Grant Likely:
> Oops, I forgot to remove the linux-embedded from the to: list. I had
> intended to this to be a private email to Behan; Oh well, now even more
> people have probably heard about it. :-)
>
> ELBS is a set of tools for bootstrapping an embedded root filesystem
> using existing Debian or Ubuntu packages.
Thanks for the Info.
Since my Evaluation Kit for AT91SAM9G20 has 64 MByte SDRAM and 256 MByte
NAND Flash I like to try it out...
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Merge linuxppc-embedded with linuxppc-dev
From: Grant Likely @ 2008-09-22 22:08 UTC (permalink / raw)
To: Jeremy Kerr, linuxppc-dev, linux-embedded, Paul Mackerras
Jeremy,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev? I don't think we need two separate lists anymore and
patches to linuxppc-embedded don't always get dealt with.
Anyone have any objections to eliminating linuxppc-embedded?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Merge linuxppc-embedded with linuxppc-dev
From: Mike Frysinger @ 2008-09-22 22:11 UTC (permalink / raw)
To: Grant Likely; +Cc: Jeremy Kerr, linuxppc-dev, linux-embedded, Paul Mackerras
In-Reply-To: <fa686aa40809221508q22e23e53s2140b17de83bcb1a@mail.gmail.com>
On Mon, Sep 22, 2008 at 18:08, Grant Likely <grant.likely@secretlab.ca> wrote:
> Jeremy,
>
> Can we eliminate the linuxppc-embedded mailing list and merge it with
> linuxppc-dev? I don't think we need two separate lists anymore and
> patches to linuxppc-embedded don't always get dealt with.
>
> Anyone have any objections to eliminating linuxppc-embedded?
you sent this e-mail to "linux-embedded" instead of "linuxppc-embedded"
-mike
^ permalink raw reply
* Re: Merge linuxppc-embedded with linuxppc-dev
From: Grant Likely @ 2008-09-22 22:20 UTC (permalink / raw)
To: Mike Frysinger
Cc: Jeremy Kerr, linuxppc-dev, linux-embedded, Paul Mackerras,
linuxppc-embedded
In-Reply-To: <8bd0f97a0809221511v1aba47eemb1630f7e64412e4@mail.gmail.com>
On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Mon, Sep 22, 2008 at 18:08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Jeremy,
>>
>> Can we eliminate the linuxppc-embedded mailing list and merge it with
>> linuxppc-dev? I don't think we need two separate lists anymore and
>> patches to linuxppc-embedded don't always get dealt with.
>>
>> Anyone have any objections to eliminating linuxppc-embedded?
>
> you sent this e-mail to "linux-embedded" instead of "linuxppc-embedded"
> -mike
See! My point proven! That list just causes confusion. :-)
Oops. I've cc'd the linuxppc-embedded list now. Sorry to all the
non-powerpc linux-embedded folks for the noise.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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