* Re: [ANNOUNCE] CELF open project proposal
From: Kyungmin Park @ 2009-12-04 14:22 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Wolfgang Denk, Aras Vaichas, linux-embedded
In-Reply-To: <8bd0f97a0912030550q5ea22b17w695318e8cd536abc@mail.gmail.com>
On Thu, Dec 3, 2009 at 10:50 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Thu, Dec 3, 2009 at 08:38, Kyungmin Park wrote:
>> On Thu, Dec 3, 2009 at 3:25 PM, Wolfgang Denk wrote:
>>> Aras Vaichas wrote:
>>>> Support for 2nd stage booting from NAND with newer filesystems such as
>>>> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
>>>> footprint.
>>>>
>>>> TFTP server in a boot loader (U-boot or other). i.e. allows you to
>>>> push a firmware upgrade image to a device. I do know of a few of these
>>>> but they are not open sourced.
>>>
>>> U-Boot supports both TFTP (and NFS) downlod, and UBI/UBIFS.
>>
>> How about the TFTP over USB? It's required feature for no ethernet devices
>
> you'll have to be more specific if you want a real answer. U-Boot has
> USB Ethernet gadget support already.
Yes I see the u-boot-usb cdc branch, but it doesn't support the RNDIS
feature. The real or wanted use case is that I receive the kernel and
system image from tftp over USB from tftpserver via windows.
Thank you,
Kyungmin Park
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Mark Brown @ 2009-12-04 14:17 UTC (permalink / raw)
To: Linus Walleij; +Cc: cbou, dwmw2, LKML, linux-embedded
In-Reply-To: <20091204104930.GA28625@sirena.org.uk>
On Fri, Dec 04, 2009 at 10:49:31AM +0000, Mark Brown wrote:
> Isn't the standard thing here to handle this voltage to capacity mapping
> in userspace if we're just extrapolating from experimental results?
> Even with the "smart" batteries in PCs there are some accuracy concerns
> and obviously the performance of the battery will change over time.
Actually, one further thing here - if this functionality is implemented
in kernel then shouldn't it be a generic feature rather than part of the
driver? The idea of mapping battery voltages to capacity percentages
isn't specific to a given charger and will apply to all batteries using
the same technology.
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Alexander Clouter @ 2009-12-04 11:34 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-embedded
In-Reply-To: <A6D19A13FE030A409EC4362C172E091F0E0495F6@eseldmw101.eemea.ericsson.se>
Linus Walleij <linus.walleij@stericsson.com> wrote:
>
> [snipped]
>
> Is probably not very elegant. (Or is it?) Would it be permissible to
> pass in a table like:
>
> cat >/sys/.../v_vs_cap <<EOF
> x0,y0
> x1,y1
> x2,y2
> EOF
>
> And have the kernel parse x,y pairs up to EOF?
>
> Or would it be preferable to do this thing by creating some
> misc device node like /dev/battery0 and a custom ioctl()?
>
> Or is there some other way I haven't thought of?
>
Although I'm a 'nobody' I would probably go for:
----
echo x0,y0:x1,y1:....
----
Pairs are seperated by ':' whilst values with ','. I guess you could
just use comma's all the way but I personally say that reduces
readability...also means that maybe one day you want to pass only one or
three values...the format could still work.
Easy to parse, a one liner, no fixed length, fits in with the existing
use, etc etc.
Cheers
--
Alexander Clouter
.sigmonster says: You'll be sorry...
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Mark Brown @ 2009-12-04 10:49 UTC (permalink / raw)
To: Linus Walleij; +Cc: cbou, dwmw2, LKML, linux-embedded
In-Reply-To: <A6D19A13FE030A409EC4362C172E091F0E0495F6@eseldmw101.eemea.ericsson.se>
On Fri, Dec 04, 2009 at 11:42:22AM +0100, Linus Walleij wrote:
> Most devices of this kind does not need the stuff we're doing so we're
> the odd bird here. Other batteries are "smart" (contain factory
> calibration inside of them) or get calibration from some BIOS or such.
> In our code we have a number of (x,y) pair tables like this:
> /* Vbat mV to Battery capacity % */
> struct voltage_vs_capacity {
> int voltage;
> int capacity;
> };
Isn't the standard thing here to handle this voltage to capacity mapping
in userspace if we're just extrapolating from experimental results?
Even with the "smart" batteries in PCs there are some accuracy concerns
and obviously the performance of the battery will change over time.
^ permalink raw reply
* [POWER] battery calibration parameters from sysfs
From: Linus Walleij @ 2009-12-04 10:42 UTC (permalink / raw)
To: cbou, dwmw2; +Cc: LKML, linux-embedded
Hi,
we're working on battery charging support for ST-Ericsson MFD ASICs
like AB3100 and later series. I have this issue about battery
calibration
parameters that I need advice on, and more specifically on how to use
sysfs to get that data in.
Most devices of this kind does not need the stuff we're doing so we're
the odd bird here. Other batteries are "smart" (contain factory
calibration inside of them) or get calibration from some BIOS or such.
In our code we have a number of (x,y) pair tables like this:
/* Vbat mV to Battery capacity % */
struct voltage_vs_capacity {
int voltage;
int capacity;
};
/*
* Default calibration table for voltage vs battery capacity.
* Voltage in millivolts, capacity given in permil.
*/
struct voltage_vs_capacity voltage_to_battery_capacity_init[] = {
{ 4177, 1000 },
{ 4070, 900 },
{ 3988, 800 },
{ 3834, 570 },
{ 3797, 470 },
{ 3768, 320 },
{ 3721, 190 },
{ 3633, 60 },
{ 3523, 30 },
{ 3200, 0 },
};
We then interpolate between two subsequent (xn,yn),(xn+1,yn+1)
pairs to get a calibrated capacity value from the voltage
level measured.
This is all good as long as you compile the calibration into the kernel
like this.
However we want to override the default table with one fed in
though e.g. sysfs, so calibration data for the battery can reside
in the file system. NOTE: this table is NOT of fixed length, i.e.
we don't know how many (x,y) pairs will be passed in.
Whereas the rule for sysfs is one value per file, creating an arbitrary
large hirarchy like this:
/sys/.../v_vs_cap/x0
/sys/.../v_vs_cap/y0
/sys/.../v_vs_cap/x1
/sys/.../v_vs_cap/y2
...
/sys/.../v_vs_cap/xN
/sys/.../v_vs_cap/yN
Is probably not very elegant. (Or is it?) Would it be permissible to
pass in a table like:
cat >/sys/.../v_vs_cap <<EOF
x0,y0
x1,y1
x2,y2
EOF
And have the kernel parse x,y pairs up to EOF?
Or would it be preferable to do this thing by creating some
misc device node like /dev/battery0 and a custom ioctl()?
Or is there some other way I haven't thought of?
Yours,
Linus Walleij
ST-Ericsson
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Robert Schwebel @ 2009-12-04 8:02 UTC (permalink / raw)
To: Aras Vaichas; +Cc: Kyungmin Park, linux-embedded
In-Reply-To: <ed62800912031929i59f9d136s31f135ae6f56a884@mail.gmail.com>
On Fri, Dec 04, 2009 at 02:29:12PM +1100, Aras Vaichas wrote:
> > In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible
> > way. Would that fit your needs?
>
> That would probably be better than TFTP over ethernet. A USB DFU
> upgrade would only require the microcontroller to be functioning for
> the upgrade to work and it doesn't require TCP/IP stack or ethernet
> chip drivers.
Yup. Barebox has Kconfig as it's configuration system, so you can make
components y/n/m. It follows the same module mechanism as the kernel, so
you can insmod drivers if you need them.
> I maintain a family of devices which can be built with or without
> ethernet. Currently we attach an ethernet daughterboard to the device
> to bootstrap it, and for development, but remove it for commercial
> use.
Sounds like a usecase for insmod :-)
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Aras Vaichas @ 2009-12-04 3:29 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Kyungmin Park, linux-embedded
In-Reply-To: <20091203205447.GJ22533@pengutronix.de>
2009/12/4 Robert Schwebel <r.schwebel@pengutronix.de>:
> On Thu, Dec 03, 2009 at 10:38:07PM +0900, Kyungmin Park wrote:
>> How about the TFTP over USB? It's required feature for no ethernet devices
>
> In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible
> way. Would that fit your needs?
That would probably be better than TFTP over ethernet. A USB DFU
upgrade would only require the microcontroller to be functioning for
the upgrade to work and it doesn't require TCP/IP stack or ethernet
chip drivers.
I maintain a family of devices which can be built with or without
ethernet. Currently we attach an ethernet daughterboard to the device
to bootstrap it, and for development, but remove it for commercial
use.
We are planning on using a PEEDI JTAG for production installation and
I have been working with the PEEDI developers to get UBI/UBIFS support
into the PEEDI (currently supports JFFS2). JTAG is good for production
installation but USB DFU is ideal for field upgrades or bricked-system
recovery.
Aras Vaichas
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Robert Schwebel @ 2009-12-03 20:54 UTC (permalink / raw)
To: Kyungmin Park; +Cc: linux-embedded
In-Reply-To: <9c9fda240912030538j14ea07bdr7fa2f4c1b902405c@mail.gmail.com>
On Thu, Dec 03, 2009 at 10:38:07PM +0900, Kyungmin Park wrote:
> How about the TFTP over USB? It's required feature for no ethernet devices
In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible
way. Would that fit your needs?
> I wish some filesystem to share between u-boot and kernel. Of course
> ext2 or fat is possbile. but current u-boot implementation depends on
> block device or NOR device. not for NAND/OneNAND devices.
That would indeed be interesting.
> Finally very very small jpeg or png library for u-boot (under 30KiB).
What's your use case for that, a splash screen?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Robert Schwebel @ 2009-12-03 20:51 UTC (permalink / raw)
To: David Woodhouse
Cc: Tim Bird, Mike Frysinger, Bird, Tim, CE Linux Developers List,
linux-embedded
In-Reply-To: <1259791190.3744.751.camel@macbook.infradead.org>
Hi David,
On Wed, Dec 02, 2009 at 09:59:50PM +0000, David Woodhouse wrote:
> On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote:
> > It applies to anything in the "embedded Linux" ecosystem. This
> > would very much include open source boot loaders like U-Boot.
>
> And coreboot.
>
> The world needs more coreboot.
Did you have a look at u-boot-v2 (which is just in the process of being
renamed to barebox)? We have it running on all kind of architectures
(even x86 is working here recently, but the patches are not ready for
mainline yet), and it feels much more linuxish than coreboot.
http://www.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=Hauer-U_BootV2.pdf
Robert
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: David Woodhouse @ 2009-12-03 14:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: Aras Vaichas, linux-embedded
In-Reply-To: <20091203144232.GN14279@hansolo.jdub.homelinux.org>
On Thu, 2009-12-03 at 09:42 -0500, Josh Boyer wrote:
> > Is it heretical to suggest a BSD licence for that too, to encourage
> > adoption into other bootloaders? Or at least LGPL or the "GPL with
> > linking exception" licence that libstdc++/eCos/JFFS2 have.
>
> Are you asking for a relicense of the existing UBI/UBIFS code?
I didn't think that would be reasonable. But if we're doing a simpler
version which can exist in a bootloader, it might be a good idea.
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Josh Boyer @ 2009-12-03 14:42 UTC (permalink / raw)
To: David Woodhouse; +Cc: Aras Vaichas, linux-embedded
In-Reply-To: <alpine.LFD.2.00.0912030713300.10116@macbook.infradead.org>
On Thu, Dec 03, 2009 at 07:17:30AM +0000, David Woodhouse wrote:
> On Thu, 3 Dec 2009, Aras Vaichas wrote:
>
>> 2009/12/3 Tim Bird <tim.bird@am.sony.com>
>>>
>>> Mike Frysinger wrote:
>>>> i know your e-mail intro states "embedded Linux" as does the wiki, but
>>>> i'm gonna take a stab anyways. does this apply to Linux only and not
>>>> open source boot loaders (like U-Boot) ?
>>>
>>> It applies to anything in the "embedded Linux" ecosystem. This
>>> would very much include open source boot loaders like U-Boot.
>>
>> I've got a list of "nice to haves"
>>
>> Any boot time speed up work.
>>
>> Support for 2nd stage booting from NAND with newer filesystems such as
>> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
>> footprint.
>
> Is it heretical to suggest a BSD licence for that too, to encourage
> adoption into other bootloaders? Or at least LGPL or the "GPL with
> linking exception" licence that libstdc++/eCos/JFFS2 have.
Are you asking for a relicense of the existing UBI/UBIFS code?
josh
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Mike Frysinger @ 2009-12-03 13:50 UTC (permalink / raw)
To: Kyungmin Park; +Cc: Wolfgang Denk, Aras Vaichas, linux-embedded
In-Reply-To: <9c9fda240912030538j14ea07bdr7fa2f4c1b902405c@mail.gmail.com>
On Thu, Dec 3, 2009 at 08:38, Kyungmin Park wrote:
> On Thu, Dec 3, 2009 at 3:25 PM, Wolfgang Denk wrote:
>> Aras Vaichas wrote:
>>> Support for 2nd stage booting from NAND with newer filesystems such as
>>> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
>>> footprint.
>>>
>>> TFTP server in a boot loader (U-boot or other). i.e. allows you to
>>> push a firmware upgrade image to a device. I do know of a few of these
>>> but they are not open sourced.
>>
>> U-Boot supports both TFTP (and NFS) downlod, and UBI/UBIFS.
>
> How about the TFTP over USB? It's required feature for no ethernet devices
you'll have to be more specific if you want a real answer. U-Boot has
USB Ethernet gadget support already.
-mike
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Kyungmin Park @ 2009-12-03 13:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Aras Vaichas, linux-embedded
In-Reply-To: <20091203062503.4300CE6D391@gemini.denx.de>
On Thu, Dec 3, 2009 at 3:25 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Aras Vaichas,
>
> In message <ed62800912021827s6f25f063ke836fe1482cec028@mail.gmail.com> you wrote:
>>
>> Support for 2nd stage booting from NAND with newer filesystems such as
>> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
>> footprint.
>>
>> TFTP server in a boot loader (U-boot or other). i.e. allows you to
>> push a firmware upgrade image to a device. I do know of a few of these
>> but they are not open sourced.
>
> U-Boot supports both TFTP (and NFS) downlod, and UBI/UBIFS.
How about the TFTP over USB? It's required feature for no ethernet devices
I wish some filesystem to share between u-boot and kernel. Of course
ext2 or fat is possbile. but current u-boot implementation depends on
block device or NOR device. not for NAND/OneNAND devices.
Finally very very small jpeg or png library for u-boot (under 30KiB).
Thank you,
Kyungmin Park
^ permalink raw reply
* Badness at net/sched/sch_generic.c:219
From: ladislav klenovic @ 2009-12-03 12:36 UTC (permalink / raw)
To: linux-embedded
Hi,
I am running on mpc8272 with 2.6.27.25 kernel and use freescale
ethernet driver.I got the following oops below after 2 days uptime.
It happened only once and doesn't seem to be reproducible. Any idea
what could happen there:
Badness at net/sched/sch_generic.c:219
NIP: c0199014 LR: c0025c68 CTR: 00000001
REGS: c02c3d90 TRAP: 0700 Tainted: P (2.6.27.25-eboard-r17)
MSR: 00029032 <EE,ME,IR,DR> CR: 88002082 XER: 00000000
TASK = c02a8578[0] 'swapper' THREAD: c02c2000
GPR00: 00000000 c02c3e40 c02a8578 cf89e800 c02caef0 012e18ea 00000000 ffffffff
GPR08: c02bd028 c02d0000 fffd2b0e 000d2f00 c3f2e7df 10090e0c 0fffb000 ffffffff
GPR16: 00000000 007fff00 00000000 00000000 00000000 0fff82e4 00000000 007ffeb0
GPR24: 00000000 00000000 c02cb060 c02d0000 c02c2000 c0198ee4 00000100 cf89e800
NIP [c0199014] dev_watchdog+0x130/0x204
LR [c0025c68] run_timer_softirq+0x12c/0x1b4
Call Trace:
[c02c3e40] [3fd54c78] 0x3fd54c78 (unreliable)
[c02c3e50] [c0025c68] run_timer_softirq+0x12c/0x1b4
[c02c3e80] [c0021494] __do_softirq+0x64/0xd4
[c02c3ea0] [c00060fc] do_softirq+0x40/0x58
[c02c3eb0] [c002132c] irq_exit+0x38/0x48
[c02c3ec0] [c000cb64] timer_interrupt+0x138/0x150
[c02c3ee0] [c000f708] ret_from_except+0x0/0x14
--- Exception: 901 at cpu_idle+0x94/0xd8
LR = cpu_idle+0x94/0xd8
[c02c3fa0] [c0009140] cpu_idle+0xd4/0xd8 (unreliable)
[c02c3fb0] [c0206c00] __got2_end+0x58/0x68
[c02c3fc0] [c028181c] start_kernel+0x2b0/0x2c4
[c02c3ff0] [00003438] 0x3438
Instruction dump:
48000050 801f0198 3d20c02b 817f019c 8129abd4 7c005a14 7d490051 40a00034
3d20c02d 80099930 2f800000 40be0014 <0fe00000> 38000001 3d20c02d 90099930
--
Ladislav
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: David Woodhouse @ 2009-12-03 7:17 UTC (permalink / raw)
To: Aras Vaichas; +Cc: linux-embedded
In-Reply-To: <ed62800912021827s6f25f063ke836fe1482cec028@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1483 bytes --]
On Thu, 3 Dec 2009, Aras Vaichas wrote:
> 2009/12/3 Tim Bird <tim.bird@am.sony.com>
>>
>> Mike Frysinger wrote:
>>> i know your e-mail intro states "embedded Linux" as does the wiki, but
>>> i'm gonna take a stab anyways. does this apply to Linux only and not
>>> open source boot loaders (like U-Boot) ?
>>
>> It applies to anything in the "embedded Linux" ecosystem. This
>> would very much include open source boot loaders like U-Boot.
>
> I've got a list of "nice to haves"
>
> Any boot time speed up work.
>
> Support for 2nd stage booting from NAND with newer filesystems such as
> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
> footprint.
Is it heretical to suggest a BSD licence for that too, to encourage
adoption into other bootloaders? Or at least LGPL or the
"GPL with linking exception" licence that libstdc++/eCos/JFFS2 have.
> TFTP server in a boot loader (U-boot or other). i.e. allows you to
> push a firmware upgrade image to a device. I do know of a few of these
> but they are not open sourced.
OpenFirmware copes with this quite nicely (or with http download, for that
matter). You can even flash a whole bunch of devices at once with
multicast over the wireless. Somewhere there's a photo of me with a few
hundred OLPC laptops laid out across the floor of main hall in a Mongolian
school, all sucking up their NAND image over the wireless.
The world needs more OpenFirmware :)
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Wolfgang Denk @ 2009-12-03 6:25 UTC (permalink / raw)
To: Aras Vaichas; +Cc: linux-embedded
In-Reply-To: <ed62800912021827s6f25f063ke836fe1482cec028@mail.gmail.com>
Dear Aras Vaichas,
In message <ed62800912021827s6f25f063ke836fe1482cec028@mail.gmail.com> you wrote:
>
> Support for 2nd stage booting from NAND with newer filesystems such as
> UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
> footprint.
>
> TFTP server in a boot loader (U-boot or other). i.e. allows you to
> push a firmware upgrade image to a device. I do know of a few of these
> but they are not open sourced.
U-Boot supports both TFTP (and NFS) downlod, and UBI/UBIFS.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
[Braddock:] Mr. Churchill, you are drunk.
[Churchill:] And you madam, are ugly. But I shall be sober tomorrow.
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Aras Vaichas @ 2009-12-03 2:27 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4B16E03D.3000202@am.sony.com>
2009/12/3 Tim Bird <tim.bird@am.sony.com>
>
> Mike Frysinger wrote:
> > i know your e-mail intro states "embedded Linux" as does the wiki, but
> > i'm gonna take a stab anyways. does this apply to Linux only and not
> > open source boot loaders (like U-Boot) ?
>
> It applies to anything in the "embedded Linux" ecosystem. This
> would very much include open source boot loaders like U-Boot.
I've got a list of "nice to haves"
Any boot time speed up work.
Support for 2nd stage booting from NAND with newer filesystems such as
UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small
footprint.
TFTP server in a boot loader (U-boot or other). i.e. allows you to
push a firmware upgrade image to a device. I do know of a few of these
but they are not open sourced.
Just my 2 cents.
Aras
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Tim Bird @ 2009-12-02 23:30 UTC (permalink / raw)
To: David Woodhouse
Cc: Bird, Tim, Mike Frysinger, CE Linux Developers List,
linux-embedded
In-Reply-To: <1259791190.3744.751.camel@macbook.infradead.org>
David Woodhouse wrote:
> On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote:
>> It applies to anything in the "embedded Linux" ecosystem. This
>> would very much include open source boot loaders like U-Boot.
>
> And coreboot.
>
> The world needs more coreboot.
If coreboot were on ARM, it would be more interesting.
That would make an interesting proposal, I suppose. :-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: David Woodhouse @ 2009-12-02 21:59 UTC (permalink / raw)
To: Tim Bird
Cc: Mike Frysinger, Bird, Tim, CE Linux Developers List,
linux-embedded
In-Reply-To: <4B16E03D.3000202@am.sony.com>
On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote:
> It applies to anything in the "embedded Linux" ecosystem. This
> would very much include open source boot loaders like U-Boot.
And coreboot.
The world needs more coreboot.
--
dwmw2
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Tim Bird @ 2009-12-02 21:46 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Bird, Tim, CE Linux Developers List, linux-embedded
In-Reply-To: <8bd0f97a0912021336xf1ef7ebmfb502efabec187cb@mail.gmail.com>
Mike Frysinger wrote:
> i know your e-mail intro states "embedded Linux" as does the wiki, but
> i'm gonna take a stab anyways. does this apply to Linux only and not
> open source boot loaders (like U-Boot) ?
It applies to anything in the "embedded Linux" ecosystem. This
would very much include open source boot loaders like U-Boot.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Mike Frysinger @ 2009-12-02 21:36 UTC (permalink / raw)
To: Tim Bird; +Cc: CE Linux Developers List, linux-embedded
In-Reply-To: <4B15AAFE.4030705@am.sony.com>
On Tue, Dec 1, 2009 at 18:47, Tim Birdwrote:
> Hey embedded Linux developers...
>
> Are you itching to see some feature developed for embedded
> Linux? Would you like to suggest that CELF spend their
> money on some specific project? Would you like CELF to
> sponsor a project you are working on?
>
> Well, now is your chance! This is the official announcement
> of a new plan by CELF, called the "Open Project Proposal".
i know your e-mail intro states "embedded Linux" as does the wiki, but
i'm gonna take a stab anyways. does this apply to Linux only and not
open source boot loaders (like U-Boot) ?
-mike
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Tim Bird @ 2009-12-02 1:05 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Bird, Tim, CE Linux Developers List, linux-embedded
In-Reply-To: <8bd0f97a0912011644g169f7309ubf893902698eb810@mail.gmail.com>
Mike Frysinger wrote:
> maybe i missed it, but there doesnt seem to be too much emphasis on
> working with the respective projects and getting merged. that seems
> like one of the most important aspects of doing any enhancement work
> as anything not merged means it'll quickly be left behind and largely
> go to waste.
I agree.
Many of our contracts have a financial incentive built in to
get "mainlined". Some of our projects' sole objective is to
mainline already existing stuff (like Linux-tiny and SquashFS).
If anyone has a feature that already exists, but that they
think should be merged with the relevant upstream project,
that's a good candidate for a proposal.
One obvious project, which I'm waiting to see if someone else
submits, is to pay someone to mainline some of the outstanding
Android patches into the Linux kernel.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [ANNOUNCE] CELF open project proposal
From: Mike Frysinger @ 2009-12-02 0:44 UTC (permalink / raw)
To: Tim Bird; +Cc: CE Linux Developers List, linux-embedded
In-Reply-To: <4B15AAFE.4030705@am.sony.com>
On Tue, Dec 1, 2009 at 18:47, Tim Bird wrote:
> The CELF Open Project Proposal is a process whereby members
> of the public submit to the CE Linux Forum ideas and
> proposals for projects that they think should be worked on
> to enhance embedded Linux. Â The plan is to solicit ideas for
> our 2010 contract work projects. Areas of work can
> include the Linux kernel, graphics systems, toolchain work,
> or anything else that will help enhance Linux for use in
> embedded systems.
>
> Each year, CELF spends money on contract work to improve
> Linux for use in embedded systems. Some of the projects we
> have sponsored in the past include Linux-tiny, DirectFB
> enhancements, smem, and Squashfs mainlining.
>
> Usually, our process involves querying forum members about
> their desires and building a project list from that. This
> year, we are opening up the process and asking for your ideas
> and proposals as well.
maybe i missed it, but there doesnt seem to be too much emphasis on
working with the respective projects and getting merged. that seems
like one of the most important aspects of doing any enhancement work
as anything not merged means it'll quickly be left behind and largely
go to waste.
-mike
^ permalink raw reply
* [ANNOUNCE] CELF open project proposal
From: Tim Bird @ 2009-12-01 23:47 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded
Hey embedded Linux developers...
Are you itching to see some feature developed for embedded
Linux? Would you like to suggest that CELF spend their
money on some specific project? Would you like CELF to
sponsor a project you are working on?
Well, now is your chance! This is the official announcement
of a new plan by CELF, called the "Open Project Proposal".
The CELF Open Project Proposal is a process whereby members
of the public submit to the CE Linux Forum ideas and
proposals for projects that they think should be worked on
to enhance embedded Linux. The plan is to solicit ideas for
our 2010 contract work projects. Areas of work can
include the Linux kernel, graphics systems, toolchain work,
or anything else that will help enhance Linux for use in
embedded systems.
Each year, CELF spends money on contract work to improve
Linux for use in embedded systems. Some of the projects we
have sponsored in the past include Linux-tiny, DirectFB
enhancements, smem, and Squashfs mainlining.
Usually, our process involves querying forum members about
their desires and building a project list from that. This
year, we are opening up the process and asking for your ideas
and proposals as well.
For details, see:
http://elinux.org/CELF_Open_Project_Proposal_2010
Proposal are welcome immediately...
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 0/6] Generic PWM API implementation
From: David Brownell @ 2009-11-28 21:59 UTC (permalink / raw)
To: Grant Likely; +Cc: Bill Gatliff, Mike Frysinger, linux-embedded
In-Reply-To: <fa686aa40911230939q3c65c681jee8c4098331f70ee@mail.gmail.com>
On Monday 23 November 2009, Grant Likely wrote:
> I take issue
> with all the common code behind the API to make it work and to allow
> GPIOs or PWMs to be registered at runtime. The overlap is the code
> and behaviour used to register pins and to obtain a reference to a
> pin.
>
> On the PWM side; it's the code backing pwm_register().
> pwm_unregister(), pwm_request(), pwm_free(), and the sysfs hooks.
>
> For GPIO; it's gpiochip_add(), gpiochip_remove(), gpio_request(),
> gpio_free(), the sysfs hooks, and the device tree bindings.
>
> They perform exactly the same task. The difference is that PWM
> devices implement the PWM API and GPIO devices implement the GPIO API;
> but the behaviour needed to manage them is identical. I don't like
> the fact that it will be implemented twice with subtle differences
> between them.
Most of that stuff sits inside sysfs. What's actually sharable?
> The argument has been made that the split is appropriate because the
> use case between GPIO and PWM is considerably different, and to a
> point I agree. The PWM use case definitely requires a different API.
> However, the argument also makes the assumption that what is a GPIO
> and what is a PWM can easily be pinned down. For example, I've got
> output only GPIOs, input only GPIOs, and a device that implements both
> PWM and GPIO behaviour (not pin muxing).
In object oriented programming there's this thing called an "interface",
and its application here is: you write a driver implementing both
the "gpio" and "pwm" interfaces. Someone wanting a given behavior
goes through that interface.
> If a hard distinction is
> made now to manage GPIO and PWM pins separately, what then do we do
> with other similar-yet-different pin controllers? What about a
> multi-voltage output GPIO pin? Or a Frequency generator pin? Is it
> appropriate to create a new subsystem for managing each one?
None of those are particularly common. The Linux approach is to come
up with interfaces as needed ... then generalize once there's enough
data, if indeed there is enough. Just because you *can* come up with
hardware doesn't mean it's widespread enough to need a shared API.
> What an API can do is capture the common use cases, but it can never
> capture the full range of behaviour implemented by a particular
> device.
Right, so you need to become accustomed to the notion that there
can be platform-specific capabilities. Kitchen-sink APIs are bad.
^ 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