* CELF Project proposal: UBIFS mount-time speedups
From: Tim Bird @ 2009-12-15 1:56 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded
Summary: Improve UBIFS mounting time
Proposer: Tim Bird
Description:
UBIFS is a next-generation flash-based file system for Linux.
It is a read/write file system, which supports compression
and has good performance. However, it's mount times are not
very good. This affects overall Linux boot time, for a UBIFS-based
embedded system.
The purpose of this project would be to investigate mount performance
issues, and try to resolve them. One suggestion is to keep the
bad block table on flash, instead of re-scanning it on every boot.
It is not known if algorithms to do this are covered by existing
flash management patents.
Related work:
* UBIFS
** http://en.wikipedia.org/wiki/UBIFS
** http://lwn.net/Articles/276025/
* UBI2
** see portions of http://www.mjmwired.net/kernel/Documentation/filesystems/ubifs.txt
* Mount times
** http://osl.sed.hu/wiki/ubifs/index.php/Mount_results
** http://elinux.org/images/f/f8/CELFJamboree30-UBIFS_update.pdf
Scope: This project might take about 4 months
Notes:
Toshiba may already be working on this project.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Bill Gatliff @ 2009-12-15 3:02 UTC (permalink / raw)
To: Aras Vaichas
Cc: Pavel Machek, Mark Brown, Linus Walleij, cbou, dwmw2, LKML,
linux-embedded, Brian Swetland, rpurdie, lenz, Dirk, arminlitzel,
Cyril Hrubis, thommycheck, linux-arm-kernel, dbaryshkov,
omegamoon, eric.y.miao, utx, zaurus-devel
In-Reply-To: <ed62800912141543v2ab7ef63v4b6b2c33018b3296@mail.gmail.com>
Aras Vaichas wrote:
> Unfortunately the simple coulomb counting chips have the disadvantage
> that the CPU has to be running to accumulate the pulses. Of course,
> the pulses could wake the CPU from a suspend mode, but I'd rather not
> do that just to add "one" to a counter ...
>
Could you have the coulomb-counting chip connected to a tiny
microcontroller, or even a dedicated hardware counter? Then the main
CPU wouldn't need to wake as often, it could just ask the
microcontroller over I2C, or read/reset the hardware counter.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Aras Vaichas @ 2009-12-15 22:58 UTC (permalink / raw)
To: Bill Gatliff
Cc: thommycheck, Linus Walleij, linux-embedded, lenz, dbaryshkov,
Brian Swetland, arminlitzel, Mark Brown, LKML, Dirk, utx, cbou,
rpurdie, omegamoon, Pavel Machek, Cyril Hrubis, eric.y.miao,
dwmw2, zaurus-devel, linux-arm-kernel
In-Reply-To: <4B26FC52.6060307@billgatliff.com>
2009/12/15 Bill Gatliff <bgat@billgatliff.com>:
> Aras Vaichas wrote:
>> Unfortunately the simple coulomb counting chips have the disadvantage
>> that the CPU has to be running to accumulate the pulses. Of course,
>> the pulses could wake the CPU from a suspend mode, but I'd rather not
>> do that just to add "one" to a counter ...
>>
>
> Could you have the coulomb-counting chip connected to a tiny
> microcontroller, or even a dedicated hardware counter? Then the main
> CPU wouldn't need to wake as often, it could just ask the
> microcontroller over I2C, or read/reset the hardware counter.
>
> b.g.
Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)
Google for, say, "coulomb counter i2c" and you'll get something like
this: http://eu.st.com/stonline/products/literature/ds/15269.pdf as an
example
The only time we used a pulse-and-polarity-output coulomb counter was
with an ATmega128. The CPU had to run all the time in order to
maintain its RTC so we could use it to accumulate pulses as well. It
wasn't a Linux project though.
Aras
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Stanislav Brabec @ 2009-12-15 23:32 UTC (permalink / raw)
To: Aras Vaichas
Cc: Bill Gatliff, Pavel Machek, Mark Brown, Linus Walleij, cbou,
dwmw2, LKML, linux-embedded, Brian Swetland, rpurdie, lenz, Dirk,
arminlitzel, Cyril Hrubis, thommycheck, linux-arm-kernel,
dbaryshkov, omegamoon, eric.y.miao, zaurus-devel
In-Reply-To: <ed62800912151458p6bc1e551g54960af40c54facd@mail.gmail.com>
Aras Vaichas wrote:
> Yes, but in that case you might as well just purchase a coulomb
> counter with a built-in accumulator and an I2C/SPI/microwire interface
> save yourself some PCB space and cost (maybe)
Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
least "poor man's Ampere meter" for devices that are not equipped with
any of it.
- We know the time.
- We know the backlight power consumption, it's dependent only on
brightness.
- We know how much eats the HDD and how long it is on.
- We know how much eats the CPU and companion chips (it is not as
stable, but it eats less).
- We don't know, how much USB host eats, but we know how much USB
clients claim to eat.
- Well, and we don't know how much eats CF and SD.
=> We can guess how many Coulombs the device already consumed. If the
Coulomb counting would be inaccurate, we can at least correct voltage ->
remaining energy table using current power consumption guess.
________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Andy Green @ 2009-12-16 9:40 UTC (permalink / raw)
To: Stanislav Brabec
Cc: Aras Vaichas, Bill Gatliff, thommycheck, Linus Walleij,
linux-embedded, lenz, dbaryshkov, Brian Swetland, arminlitzel,
Mark Brown, LKML, Dirk, cbou, rpurdie, omegamoon, Pavel Machek,
Cyril Hrubis, eric.y.miao, dwmw2, zaurus-devel, linux-arm-kernel
In-Reply-To: <1260919938.10441.18.camel@utx.utx.cz>
On 12/15/09 23:32, Somebody in the thread at some point said:
Hi -
>> Yes, but in that case you might as well just purchase a coulomb
>> counter with a built-in accumulator and an I2C/SPI/microwire interface
>> save yourself some PCB space and cost (maybe)
>
> Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
> least "poor man's Ampere meter" for devices that are not equipped with
> any of it.
I think the "poor man's Coulomb counter" is a loser, the errors will
overwhelm you too rapidly. The estimated rate of discharge could work,
based on what clocks, regulators and so on are running, but I am not
sure how useful that number is really given you can't realistically
integrate it due to the big error it is bound to have.
I didn't see it mentioned yet but the biggest problem I saw with battery
state monitoring by voltage alone is what happens during charging: the
charger is artificially raising the voltage by an amount depending on
current limit in the charger and battery capacity level. That's what
you see when you go and look at battery voltage during charging.
Otherwise for L-ion batteries, looking at the voltage level alone,
filtered to remove GSM transmit slots etc, is really quite workable for
estimating charge status.
-Andy
^ permalink raw reply
* CELF Project Proposal - ALSA scenario/use case support
From: Liam Girdwood @ 2009-12-16 17:26 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded
Cc: Tim Bird, Stefan Schmidt, Mark Brown, Takashi Iwai,
Jaroslav Kysela, alsa-devel
Summary: Complete ALSA hardware scenario/use case support in alsa-lib
and salsa-lib
Proposer: Liam Girdwood
Description:
Modern mobile devices are increasingly required to provide a rich set of
audio functionality required by today's applications. ALSA currently
lacks a portable and high level API to configure audio hardware function
and signal routing.
e.g. there is no portable method atm to configure the audio hardware to
make a "handset gsm phone call" or "handset voip phone call", etc.
This purpose of this project would be to complete the ALSA scenario
manager API and get it accepted upstream in alsa-lib and salsa-lib. The
code is nearly ready for upstream, with some work required on it's file
format as the main piece of outstanding work.
More Info:
** http://www.slimlogic.co.uk/?p=40
API header:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/ascenario.h;h=b1395515b035629d09cd9b3d3a224743053aa159;hb=ascenario
Development branch now hosted as alsa-lib branch here :-
** http://git.alsa-project.org/?p=alsa-lib.git;a=shortlog;h=ascenario
Scope: This project will probably take between 2 - 4 weeks.
Thanks
Liam
^ permalink raw reply
* Re: CELF Project Proposal - ALSA scenario/use case support
From: Tim Bird @ 2009-12-16 22:35 UTC (permalink / raw)
To: Liam Girdwood
Cc: CE Linux Developers List, linux-embedded, Bird, Tim,
Stefan Schmidt, Mark Brown, Takashi Iwai, Jaroslav Kysela,
alsa-devel
In-Reply-To: <1260984413.3525.351.camel@odin>
Liam Girdwood wrote:
> Summary: Complete ALSA hardware scenario/use case support in alsa-lib
> and salsa-lib
This looks like an interesting proposal. I created a page for it at:
http://elinux.org/CELF_Project_Proposal/Complete_hardware,_use-case_handling_in_ALSA
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Project Proposal: add sleeping spinlocks to mainline kernel
From: Tim Bird @ 2009-12-16 22:47 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded
Summary: add sleeping spinlocks to the mainline kernel
Proposer: Tim Bird
Description:
One of the last major elements of the RT-preempt patch set that is
still not mainlined is the implementation of the so-called
"sleeping spinlocks". It would be good to mainline these,
addressing remaining issues to their inclusion in the standard
Linux kernel.
Thomas Gleixner discussed the status of RT-preempt at the
[http://lwn.net/Articles/354690/ realtime preemption mini-summit,
and the [http://lwn.net/Articles/357465/ 2009 kernel summit].
Related work:
* RT-preempt
** http://rt.wiki.kernel.org/index.php/Main_Page
Scope: unknown
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Pavel Machek @ 2009-12-16 22:53 UTC (permalink / raw)
To: Mark Brown
Cc: thommycheck-Re5JQEeQqe8AvxtiuMwx3w, Linus Walleij,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
lenz-hcNo3dDEHLuVc3sceRu5cw, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
Brian Swetland, arminlitzel-S0/GAf8tV78, LKML,
Dirk-RZHw+W3AUBHbFfAX06+HdQ, cbou-JGs/UdohzUI,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w, Cyril Hrubis,
eric.y.miao-Re5JQEeQqe8AvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
zaurus-devel-cunTk1MwBs/k6gDgw6ADrEB+6BGkLq7r, linux-arm-kernel
In-Reply-To: <20091214121247.GB22388-HF5t3jzXg/6ND3a5+9QAFujbO/Zr0HzV@public.gmane.org>
On Mon 2009-12-14 12:12:47, Mark Brown wrote:
> On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
>
> > > actual charger hardware. My main concern here is that battery
> > > performance monitoring has no pressing need to be in kernel and that
> > > pushing it into the kernel creates a barrier to implementing more
> > > advanced schemes in userspace, which is especially serious given how
> > > involved this needs to be in order to be accurate.
>
> > Well, kernel provides /proc/apm emulation and many systems still rely
> > on it. So it would be nice to provide something halfway-decent there.
>
> Unfortunately that's really painful in kernel since you really need to
> do state tracking over reboots, and even if you do that it's really
> not trivial.
No, I do not want to get _that_ advanced. But I'd really like to get
beyond "battery %age is linear function of measured battery voltage".
> > Plus you need to shutdown/suspend machine on battery critical. That
> > has to be in kernel and already needs those tricky parts.
>
> Power failure detection based on voltage drop is much more reasonable
> but it's a very different thing to general battery capacity
> estimation.
Not sure...
> Normally you'd want to do the power failure detection separately anyway,
> monitoring the system supply voltage rather than the battery voltage.
Well, that way you'll discharge batteries too much and kill them
rather quickly, no? What is "system supply voltage" for PDA class
system, anyway? I don't think zaurus has ADCs on anything else than
thermistor, AC in voltage, battery voltage...
> Something like "Measure Battery Capacity Precisely in Medical Design"
> by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
> useful here.
Thanks, it looks interesting. I'm not sure if it will be possible to
apply on zaurus, but... (While measuring voltage my underestimate the
old battery, I'm afraid they may overestimate it in bad conditions;
energy left is battery is useless if battery can't supply enough
current to keep CPU happy, because its too cold).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Matt Hsu @ 2009-12-17 8:31 UTC (permalink / raw)
To: celinux-dev, linux-embedded; +Cc: tim.bird, Andy Green
Summary: Refactoring Qi, lightweight bootloader.
Proposer: Matt Hsu
Description:
Qi (named by Alan Cox on Openmoko kernel list) is a minimal bootloader that
"breathes life" into Linux. Its goal is to stay close to the minimum
needed
to "load" and then "boot" Linux -- no boot menus, additional peripheral init
or private states.
Qi currently supports samsung s3c24xx series, s3c6410, TI omap3530. The
more support platforms are planned to add on. The purpose of this project
would be to improve Qi's maintainability, portability. Ideally, this would
make people spend less time on bootloader development but be more focus
on Linux system.
Project objectives:
- Make the hierarchy of source files more sensible and clean
- Generalize components which could be used in common such as I2C drivers.
Example: platform specific I2C driver -> GPIO bitbang driver.
- Remove duplicated, unused code, header definition. Keep Qi as minimum
as needed.
Related work:
http://wiki.openmoko.org/wiki/Qi
Development branches are hosted here:
http://git.warmcat.com/cgi-bin/cgit/qi/
http://gitorious.org/0xlab-bootloader
Scope:
Unknown.
Thanks.
Matt
^ permalink raw reply
* Re: CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Andy Green @ 2009-12-17 9:21 UTC (permalink / raw)
To: Matt Hsu; +Cc: celinux-dev, linux-embedded, tim.bird
In-Reply-To: <4B29EC68.1040109@0xlab.org>
On 12/17/09 08:31, Somebody in the thread at some point said:
Hi -
Just read about this a little late :-)
I wrote the bulk of Qi while at Openmoko.
> Qi currently supports samsung s3c24xx series, s3c6410, TI omap3530. The
I also ported it to iMX31.
> - Generalize components which could be used in common such as I2C drivers.
> Example: platform specific I2C driver -> GPIO bitbang driver.
I wrote a generic bitbang I2C "driver" for Qi back in 2007, it's used on
the GTA02 build IIRC to talk to the PMU:
http://git.warmcat.com/cgi-bin/cgit/qi/tree/src/drivers/i2c-bitbang.c?h=txtr
> - Remove duplicated, unused code, header definition. Keep Qi as minimum
> as needed.
What I can suggest would be worthwhile goals are:
- extending the targeted CPU arches
- folding the OMAP branch (written by Matt) back into the main tree
- improving the memory test to force burst mode
On the txtr branch (currently they are my customer and we use Qi on
their iMX31 e-book reader) there's already various tidying up and
advances like FAT filesystem, PRNG-based memory test.
http://git.warmcat.com/cgi-bin/cgit/qi/log/?h=txtr
Here is a bit more about the reasoning for bothering with another
bootloader and the philosophy behind Qi.
While working at Openmoko maintaining their kernel, it became obvious
that U-Boot was turning into a mini-me for Linux. Many cut-down Linux
drivers were appearing there, there was a shell with an environment
holding private states like booting action commands. This led to a
situation where two identical devices with same patchlevel of everything
including bootloader may act differently according to what's in that
hidden environment. Wanting a "boot menu" meant supporting graphics and
some of the drivers like for Glamo were complex and always forked from
their Linux counterparts.
The burden of maintaining forked drivers in two places (the U-Boot ones
had to be "dumbed down" to the point it can't share sources) and the
additional complexity of trying to manage power and additional device
state in two places are all actually completely unnecessary. All the
bootloader needs is just enough to get hold of a kernel and boot it.
That is Qi's philosophy in a nutshell: "load [the kernel], then boot".
Linux is then the single place for good support of all assets on the device.
It can work from NAND or NOR but actually the existing support is
designed to work with SD Card boot. Recent devices like s3c6410 and
i.MX31 can completely boot from SD Card, including getting their
bootloader from there. On i.MX31 using this scheme, we are able to boot
to a bash prompt in 2.5s from cold.
Another big problem with U-Boot was the inability to update the
bootloader from the Linux world. Instead the bootloader was treated
special and had to be updated over USB with DFU (the exclusivity of it
enforced by an ECC policy disconnected from Linux, meaning U-Boot had to
write it in there). In Qi, the bootloader can be updated by a packaged
update like anything else in the rootfs.
There are no private environment / states, there are per-board
heuristics for where to look for a kernel, and filesystem files which
can append to kernel commandlines if present. Therefore identical
devices with the same Qi patchlevel will always act the same.
-Andy
^ permalink raw reply
* Re: Project Proposal: add sleeping spinlocks to mainline kernel
From: Linus Walleij @ 2009-12-17 9:54 UTC (permalink / raw)
To: Tim Bird; +Cc: CE Linux Developers List, linux-embedded
In-Reply-To: <4B296390.3090004@am.sony.com>
2009/12/16 Tim Bird <tim.bird@am.sony.com>:
> Summary: add sleeping spinlocks to the mainline kernel
If realtime performance overall is a big deal for CELF I would suggest
adding "Kill-the-BKL" to the suggested projects. There are still some
RTOS people using the BKL as an argument to flak the Linux kernel,
c.f.
http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf
(section 5.2)
Another item could be to go through some common embedded
arch drivers and switch them from request_irq() to request_threaded_irq()
just based on the observation that almost nobody actually use that
in the mainline kernel, though I'm sure they should,
if realtime is a desired feature.
(The wm8350-core driver is an excellent example of a situation where
it is used properly.)
NB: I'm not a member of the CE Linux Forum and nor is my company
so I'm just talking freely here. (linux-embedded is public, hehe.)
Yours,
Linus Walleij
^ permalink raw reply
* Re: Project Proposal: add sleeping spinlocks to mainline kernel
From: Tim Bird @ 2009-12-17 18:45 UTC (permalink / raw)
To: Linus Walleij; +Cc: CE Linux Developers List, linux-embedded
In-Reply-To: <63386a3d0912170154k6521433fl90b2ae96efb70a34@mail.gmail.com>
Linus Walleij wrote:
> 2009/12/16 Tim Bird <tim.bird@am.sony.com>:
>
>> Summary: add sleeping spinlocks to the mainline kernel
>
> If realtime performance overall is a big deal for CELF I would suggest
> adding "Kill-the-BKL" to the suggested projects. There are still some
> RTOS people using the BKL as an argument to flak the Linux kernel,
> c.f.
> http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf
> (section 5.2)
The only reference I could find in section 5.2 to BKL was
an OSE BKL. Maybe I missed the reference to the Linux BKL.
(I looked pretty quickly).
However, agree that BKL reduction is a worthy goal.
>
> Another item could be to go through some common embedded
> arch drivers and switch them from request_irq() to request_threaded_irq()
> just based on the observation that almost nobody actually use that
> in the mainline kernel, though I'm sure they should,
> if realtime is a desired feature.
> (The wm8350-core driver is an excellent example of a situation where
> it is used properly.)
Likely, CELF would be most interested in switching to using
threaded interrupts in places where the drivers were commonly
used in embedded devices. This would require some analysis.
But this is another good suggestion.
> NB: I'm not a member of the CE Linux Forum and nor is my company
> so I'm just talking freely here. (linux-embedded is public, hehe.)
The feedback is much appreciated!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* CELF Project Proposal: Create a watchdog framework for the Linux kernel
From: Wolfram Sang @ 2009-12-17 23:02 UTC (permalink / raw)
To: celinux-dev, linux-embedded
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
Proposer: Wolfram Sang
Summary: Create a watchdog framework for the Linux kernel
Description: The watchdog API of the Linux kernel is documented and used for
years. Yet, there is no abstraction for its common functionality (open, write,
ioctl, close), so every watchdog driver has to implement those methods on its
own. In addition to the vast amount of code duplication in the kernel source,
this is also error-prone as there are subtle corner-cases in handling the
watchdog and the userspace-input correctly. Although there is code review for
new drivers, it seems very desirable to improve the situation as a whole.
There have been two approaches for a generic watchdog framework, one from Alan
Cox and one from Wim van Sebroeck, the current watchdog maintainer. Sadly,
nothing from those have made it to mainline so far. This is a bit surprising;
although watchdogs are usually rather simple devices, they are crucial for the
stability concept of an enormous number of devices. The benefit of this
proposal is to have a rock-solid, well maintainable and trustworthy watchdog
framework, which makes writing new drivers faster and less error-prone.
Related work:
* Proposal by Alan Cox:
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-next.git;a=shortlog;h=refs/heads/alan-generic-watchdog
* Proposal by Wim van Sebroeck:
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-next.git;a=shortlog;h=refs/heads/wim-generic-watchdog
Scope:
My estimation would be 4 weeks of development and testing
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CELF Project Proposal: Create a watchdog framework for the Linux kernel
From: Tim Bird @ 2009-12-17 23:10 UTC (permalink / raw)
To: Wolfram Sang
Cc: celinux-dev@tree.celinuxforum.org, linux-embedded@vger.kernel.org
In-Reply-To: <20091217230215.GC23944@pengutronix.de>
Wolfram Sang wrote:
> Summary: Create a watchdog framework for the Linux kernel
Interesting. I've created a page for this proposal at:
http://elinux.org/CELF_Project_Proposal/Create_a_watchdog_framework_for_the_Linux_kernel
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Tim Bird @ 2009-12-17 23:13 UTC (permalink / raw)
To: Matt Hsu
Cc: celinux-dev@tree.celinuxforum.org, linux-embedded@vger.kernel.org,
Bird, Tim, Andy Green
In-Reply-To: <4B29EC68.1040109@0xlab.org>
Matt Hsu wrote:
> Summary: Refactoring Qi, lightweight bootloader.
I've created a page for this at:
http://elinux.org/CELF_Project_Proposal/Refactor_the_Qi_lightweight_bootloader
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [POWER] battery calibration parameters from sysfs
From: Pavel Machek @ 2009-12-18 8:48 UTC (permalink / raw)
To: Andy Green
Cc: Bill Gatliff, thommycheck-Re5JQEeQqe8AvxtiuMwx3w, Linus Walleij,
linux-embedded-u79uwXL29TY76Z2rM5mHXA, cbou-JGs/UdohzUI,
dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w, Brian Swetland,
arminlitzel-S0/GAf8tV78, Mark Brown, LKML,
Dirk-ngtJ1GK09nrbFfAX06+HdQ, lenz-hcNo3dDEHLuVc3sceRu5cw,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w, linux-arm-kernel, Cyril Hrubis,
eric.y.miao-Re5JQEeQqe8AvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
zaurus-devel-cunTk1MwBs/k6gDgw6ADrEB+6BGkLq7r, Aras Vaichas
In-Reply-To: <4B28AAFC.5010108-/Zus8d0mwwtBDgjK7y7TUQ@public.gmane.org>
Hi!1
>>> Yes, but in that case you might as well just purchase a coulomb
>>> counter with a built-in accumulator and an I2C/SPI/microwire interface
>>> save yourself some PCB space and cost (maybe)
Hardware is already given.
>> Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
>> least "poor man's Ampere meter" for devices that are not equipped with
>> any of it.
>
> I think the "poor man's Coulomb counter" is a loser, the errors will
> overwhelm you too rapidly. The estimated rate of discharge could
>> work,
Actually android phones do "poor man's Coulomb counter", and it seems
to mostly work.
> based on what clocks, regulators and so on are running, but I am not
> sure how useful that number is really given you can't realistically
> integrate it due to the big error it is bound to have.
...
> Otherwise for L-ion batteries, looking at the voltage level alone,
> filtered to remove GSM transmit slots etc, is really quite workable for
> estimating charge status.
Well, you have to compensate for backlight power; and yes, that's what
I'm trying to do.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
From: Raffaele Recalcati @ 2009-12-18 16:14 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded, elc10
Summary: Feasibility analisys of Android introduction in a completely
tested industrial device.
Description: By now Android has been ported to 600Mhz Cortex A8 cpu or similar.
The declared Android requirements are instead lower, about 200Mhz Arm9
cpu with 100Mhz Ram bus.
So I think the growing interest in this O.S. lacks some porting to
less powerful cpus.
The reasons to do this porting are commercial because of Google market
power, but are also technnical, because Android debugging environment
is very nice for not embedded developers.
This could help the diffusion of opensource embedded Linux.
The porting will be maybe against the 2.6.31 kernel for pxa270.
The idea is to preserve industrial tested development but adding
Android graphical interface.
The cpu dependency of the porting will be as small as possible.
Related work:
* Android Porting - http://www.kandroid.org/<wbr></wbr>android_pdk/
* Android Pxa270 - http://android-pxa270.sourceforge.net/
Scope:
This should take more than 1 month for feasibility analysis.
--
www.opensurf.it
^ permalink raw reply
* Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
From: Raffaele Recalcati @ 2009-12-19 15:46 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded, elc10
In-Reply-To: <ade1bdc0912180814m7fd3c02cp7d99a1943c2da37e@mail.gmail.com>
2009/12/18 Raffaele Recalcati <lamiaposta71@gmail.com>:
> Summary: Feasibility analisys of Android introduction in a completely
> tested industrial device.
>
> Description: By now Android has been ported to 600Mhz Cortex A8 cpu or similar.
> The declared Android requirements are instead lower, about 200Mhz Arm9
> cpu with 100Mhz Ram bus.
> So I think the growing interest in this O.S. lacks some porting to
> less powerful cpus.
> The reasons to do this porting are commercial because of Google market
> power, but are also technnical, because Android debugging environment
> is very nice for not embedded developers.
> This could help the diffusion of opensource embedded Linux.
>
> The porting will be maybe against the 2.6.31 kernel for pxa270.
> The idea is to preserve industrial tested development but adding
> Android graphical interface.
>
> The cpu dependency of the porting will be as small as possible.
>
> Related work:
> * Android Porting - http://www.kandroid.org/<wbr></wbr>android_pdk/
> * Android Pxa270 - http://android-pxa270.sourceforge.net/
>
> Scope:
> This should take more than 1 month for feasibility analysis.
>
>
> --
Anybody can give me his idea about this proposal?
Thx
Bye,
Recalcati
^ permalink raw reply
* Re: CELF Project proposal: UBIFS mount-time speedups
From: Kyungmin Park @ 2009-12-20 5:46 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded; +Cc: Tim Bird
In-Reply-To: <4B26ECBD.9030005@am.sony.com>
Summary: UBI block mapping on flash (UBI2 requirement)
Proposer: Kyungmin Park
Description: UBI scans all physical block at boot time. and maintain it at RAM.
Usually this scan time takes almost 2 or more seconds. To reduce the this time
UBI maintain block mapping information on flash and use it at next boot time.
Also it have to support or provide rescan mechanism at runtime to use
single image into another flash
* UBI2
** see portions of
http://www.mjmwired.net/kernel/Documentation/filesystems/ubifs.txt
Scope: This project might take about 2 months.
^ permalink raw reply
* Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Rob Landley @ 2009-12-21 2:45 UTC (permalink / raw)
To: celinux-dev; +Cc: Matt Hsu, linux-embedded, Andy Green
In-Reply-To: <4B29EC68.1040109@0xlab.org>
On Thursday 17 December 2009 02:31:36 Matt Hsu wrote:
> Summary: Refactoring Qi, lightweight bootloader.
>
> Proposer: Matt Hsu
>
>
> Description:
>
> Qi (named by Alan Cox on Openmoko kernel list) is a minimal bootloader that
> "breathes life" into Linux. Its goal is to stay close to the minimum
> needed
Which bits does it do?
Every piece of software needs something to initialize the DRAM controller.
After that, they could presumably just jump to a known location in flash that
the kernel lives at, and the kernel can decompress itself and so on. Doing
just that much can probably be done in 4k pretty easily. (I gloss over the
kernel command line and root filesystem location, which can be hardwired into
the image if you really don't care about providing the developer with a UI.)
However, if that's your minimum then you can't use the bootloader to re-flash
the device, which is kind of handy. (It gives you an un-bricking fallback
short of pulling out a jtag.) But doing that requires things like a network
driver, TCP/IP stack, tftp implementation, serial driver, command line
interpreter, and so on. And of course code to erase and write flash blocks for
your flash chip du jour, plus knowledge of the flash layout. (In theory, said
knowledge comes from parsing a device tree.)
I still live in hope that somebody will split the first part (coreboot) out
from the second part (grub) in embedded bootloaders. It's sad that the PC has
a tradition of orthogonality here but the embedded world treats it as a single
opaque lump.
> http://wiki.openmoko.org/wiki/Qi
Looking at the screen shot there, you've got code to parse ext2 filesystems.
What is your definition of "minimal"?
Rationale for not providing a boot menu is you don't want to mess with video
init. I don't think I've actually seen an embedded bootloader that messes
with video, they do serial console instead, and you have a screen shot of
serial console messages so apparently the serial driver part is there...
Confused,
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Matt Hsu @ 2009-12-21 5:51 UTC (permalink / raw)
To: Rob Landley; +Cc: celinux-dev, linux-embedded, Andy Green
In-Reply-To: <200912202045.37159.rob@landley.net>
Rob Landley wrote:
> However, if that's your minimum then you can't use the bootloader to re-flash
> the device, which is kind of handy. (It gives you an un-bricking fallback
> short of pulling out a jtag.)
Hi Rob,
Well, Boot from SD is your good friend.
If you look at the platform that Qi which is supported, most of them
all have this feature.
If you notice the trend of SoC, booting from peripherals becomes a
must.
Once you step into kernel via Qi, kernel provides you everything
such as mtd utils to re-flash device.
We don't need to support programming the device in the bootloader
anymore.
Don't reinvent the wheel.
>
> Looking at the screen shot there, you've got code to parse ext2 filesystems.
> What is your definition of "minimal"?
>
Enough to boot into Linux.
> Rationale for not providing a boot menu is you don't want to mess with video
> init.
Nope, the centric idea of Qi, is let kernel deal with everything it
could handle.
The video init should be handled by kernel stead of bootloader.
The following clip demonstrate the advantage of Qi bootloader:
http://www.youtube.com/watch?v=ol9LWBKXXwQ&feature=related
- Faster booting time
- Get rid of flash on display device when stepping into kernel
Hope these could clear your doubt.
Cheers,
Matt
^ permalink raw reply
* Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Rob Landley @ 2009-12-21 8:00 UTC (permalink / raw)
To: Matt Hsu; +Cc: celinux-dev, linux-embedded, Andy Green
In-Reply-To: <4B2F0CDB.3050305@0xlab.org>
On Sunday 20 December 2009 23:51:23 Matt Hsu wrote:
> Rob Landley wrote:
> > However, if that's your minimum then you can't use the bootloader to
> > re-flash the device, which is kind of handy. (It gives you an
> > un-bricking fallback short of pulling out a jtag.)
>
> Hi Rob,
>
> Well, Boot from SD is your good friend.
Ok, not aiming to be a generic bootloader then. You're only trying to support
hardware that has the flash equivalent of a floppy drive. Got it.
> If you look at the platform that Qi which is supported, most of them
> all have this feature.
Because if they didn't you wouldn't support them? Bit of a selection bias
there...
Life is a bit easier if you can stick a USB port on your device and boot from
a USB stick or cdrom. Most of the SoCs coming down the pipe support USB too,
but your wiki doesn't seem to consider this an interesting case...
> If you notice the trend of SoC, booting from peripherals becomes a
> must.
Depends how cheap you want your hardware to be, and whether you can afford
separate development and deployment boards.
Software development is a bit easier when you can spec adding a extra few
dollars worth of hardware to your device rather than redoing its software. I
tend to deal with people who repurpose existing cheap plastic crap already
being knocked out in huge quantities somewhere in china. (Their hardware
contribution _might_ be a different plastic case for the thing.) I've also
dealt with highly integrated little suckers that haven't got _space_ for an sd
card. Since I one day dream of following Moore's Law down to "disposable
computing", I'm reluctant to discard these cases as uninteresting.
> Once you step into kernel via Qi, kernel provides you everything
> such as mtd utils to re-flash device.
> We don't need to support programming the device in the bootloader
> anymore.
Depending on the kernel to reflash the device means that if you reflash the
device with a kernel that doesn't work, what you have is a brick. There's
lots and lots of reasons for a kernel not to work, and a 2.6 kernel kernel
takes up around a megabyte on a device that may only have 2 or 4 megs of ram
so keeping an old one around at all times isn't feasible. So without some
kind of fallback (such as a little ~32k bootloader at the start of flash that
you never overwrite, in its own little erase block), every time you install a
new kernel you risk bricking the device. (If you only care about devices that
have 2 gigs of flash, life is much easier.)
> Don't reinvent the wheel.
There are how many existing bootloaders out there already?
> > Looking at the screen shot there, you've got code to parse ext2
> > filesystems. What is your definition of "minimal"?
>
> Enough to boot into Linux.
You need to parse an ext2 filesystem to boot into linux? (I'm not saying it's
a _bad_ thing, I'm just not seeing how it's "minimal".)
> > Rationale for not providing a boot menu is you don't want to mess with
> > video init.
>
> Nope, the centric idea of Qi, is let kernel deal with everything it
> could handle.
So the fact the kernel can provide a serial console means you shouldn't?
> The video init should be handled by kernel stead of bootloader.
Oh agreed. What that has to do with a command line interpreter on the serial
console was my question.
Personally, i'm used to embedded devices being headless. (I tend to consider
the iPhone the next stage in the mainframe->micro->mini evolution and it'll
soon be "just another PC" target when they get the ergonomics worked out.
Heck, give those suckers a USB port and you could give 'em a big keyboard and
display today, and they could even charge themselves through the thing. Way
more powerful than my first 386 PC. Actually about as powerful as the laptop I
had circa 2002 or 2003.)
> The following clip demonstrate the advantage of Qi bootloader:
>
> http://www.youtube.com/watch?v=ol9LWBKXXwQ&feature=related
>
> - Faster booting time
I.E. you enable the cpu cache during kernel decompression.
I believe the u-boot guy just posted that as a todo item, and that falls on
the coreboot side of bootloading, which really should be broken out into its
own little project someday...
The other delay in something like u-boot is it pausing to see if it gets an
"esc" or similar from the serial console, so it can be interrupted and provide
a prompt. That's a configurable delay which can be removed if it really bugs
you.
> - Get rid of flash on display device when stepping into kernel
>
> Hope these could clear your doubt.
Your proposal confused me when it said things like "improve portability" and
"make people spend less time on bootloader development", so I thought you were
aiming at something more generic. But this bootloader is not intended to ever
apply to something like a hammer board, or any existing linksys-class router,
most current cell phones, devices like handheld game consoles where the sd
card stores data but not the operating system (due to the thing still needing
to work when you swap sd cards)...
My mistake. You're creating a bootloader specifically tailored to booting from
sd cards. Might want to make that clear on the web page.
> Cheers,
> Matt
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
From: Andy Green @ 2009-12-21 9:54 UTC (permalink / raw)
To: Rob Landley; +Cc: Matt Hsu, celinux-dev, linux-embedded
In-Reply-To: <200912210200.10047.rob@landley.net>
On 12/21/09 08:00, Somebody in the thread at some point said:
Hi Rob -
>>> However, if that's your minimum then you can't use the bootloader to
>>> re-flash the device, which is kind of handy. (It gives you an
>>> un-bricking fallback short of pulling out a jtag.)
There is a simple and much more flexible alternative to have a "recovery
rootfs" on the device that can be selected, by holding down a button or
somesuch which is understood by Qi. That gives you ALL the options
possible in Linux like network connectivity for your recovery without
doubling the support load in having a "smart" bootloader and its
different drivers to deal with.
>> Well, Boot from SD is your good friend.
>
> Ok, not aiming to be a generic bootloader then. You're only trying to support
> hardware that has the flash equivalent of a floppy drive. Got it.
No, Qi will boot from onboard NAND or NOR as well as SD.
For other reasons -- eg, unbrickability -- true boot from SD is very
powerful. By "true boot from SD" I mean the on-CPU ROM is pulling a
bootloader from SD so the entire software environment is coming from there.
>> If you look at the platform that Qi which is supported, most of them
>> all have this feature.
>
> Because if they didn't you wouldn't support them? Bit of a selection bias
> there...
Naturally enough we only added support for devices we are using in the
real world :-)
All the devices Qi target have what Samsung called "steppingstone", some
small SRAM on the die that can hold your core bootloader startup from
NAND or SD (since you cannot execute direct from NAND). That's probably
a better one-liner to describe the scope of it.
> Life is a bit easier if you can stick a USB port on your device and boot from
> a USB stick or cdrom. Most of the SoCs coming down the pipe support USB too,
> but your wiki doesn't seem to consider this an interesting case...
To be clear Openmoko Wiki isn't "our Wiki". Qi got started there to
solve the difficulties created by having basically a second Linux on the
device in the form of U-Boot. But the main work on Qi is done now at
warmcat and Matt's OMAP branch. Openmoko doesn't seem to be in the
phone business any more.
> Depending on the kernel to reflash the device means that if you reflash the
> device with a kernel that doesn't work, what you have is a brick. There's
That does not follow if you have a recovery kernel + initrd / rootfs in
another partition that can be selected by holding down a key.
> new kernel you risk bricking the device. (If you only care about devices that
> have 2 gigs of flash, life is much easier.)
>
>> Don't reinvent the wheel.
>
> There are how many existing bootloaders out there already?
So what?
As described the advantages of Qi's debloated and Linux-centric
philosophy came from having our noses pushed for months into the world
of crap coming from supporting multiple drivers and power behaviours
spread over U-Boot and Linux.
We did not find any existing open ARM bootloader that had a solid
internal structure and avoided the bloat.
Therefore we made one that proves that it is possible to push most of
the features of U-Boot and other heavy bootloaders to Linux.
>>> Looking at the screen shot there, you've got code to parse ext2
>>> filesystems. What is your definition of "minimal"?
Yes the main tenet is it has got to "load" and "boot" the kernel. If
the kernel is on ext* then that's part of its remit.
>> Enough to boot into Linux.
>
> You need to parse an ext2 filesystem to boot into linux? (I'm not saying it's
> a _bad_ thing, I'm just not seeing how it's "minimal".)
The ext* code is tight (taken from U-Boot and cleaned up).
With VFAT, ext*, memory test, all of the features Qi comes to 28KBytes
typical binary.
>>> Rationale for not providing a boot menu is you don't want to mess with
>>> video init.
>>
>> Nope, the centric idea of Qi, is let kernel deal with everything it
>> could handle.
>
> So the fact the kernel can provide a serial console means you shouldn't?
Qi provides serial output for diagnosis of the boot action. But not input.
But the answer to your rhetorical question is "yes". It costs mindspace
and support effort to support and work with these complex chunks of
software, it's real money.
Turn your question around, what is your rationale for duplicating the
stuff that Linux does great into a bloated bootloader with its own
shell? If you look at each of the features in a bootloader like U-Boot
that is not directly needed for "load" and "boot", they each have a more
powerful counterpart in Linux already. You have to support the Linux
version on your Linux box, just simplify it down to that alone.
>> The video init should be handled by kernel stead of bootloader.
>
> Oh agreed. What that has to do with a command line interpreter on the serial
> console was my question.
First maybe it's on you to explain why, other than habit, you think that
is worth the bloat.
> I.E. you enable the cpu cache during kernel decompression.
You are assuming wrongly that the kernel is compressed. On iMX31 I use
Qi with uncompressed 3MByte kernel from SD Card, it's booted to shell
from cold in 2.5s. In any event with compressed kernels, we use the
kernel uncompress, it's not done in Qi.
> aiming at something more generic. But this bootloader is not intended to ever
> apply to something like a hammer board, or any existing linksys-class router,
> most current cell phones, devices like handheld game consoles where the sd
> card stores data but not the operating system (due to the thing still needing
> to work when you swap sd cards)...
>
> My mistake. You're creating a bootloader specifically tailored to booting from
> sd cards. Might want to make that clear on the web page.
Apologies for throwing you back into confusion and doubt by the fact Qi
boots fine from NAND, NOR and SD.
Actually Qi will work fine on most current ARM-based cellphones and game
consoles with NAND or NOR.
-Andy
^ permalink raw reply
* Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
From: alucero @ 2009-12-21 9:55 UTC (permalink / raw)
To: CE Linux Developers List, linux-embedded, elc10
In-Reply-To: <ade1bdc0912190746h320ef36fpc01f3976d78aae65@mail.gmail.com>
I'm more interested in the debugging part based on QEMU than in
Android but I can see the importance Android is going to have in the
future.
I have been using QEMU for some embedded projects and for linux
embedded teaching. Having a wider micro/cpu coverage plus devices with
QEMU would be a great thing.
At this point I'm working in a QEMU port and I'd like to contribute in
the general effort to have QEMU as a main tool for embedded Linux.
Raffaele Recalcati <lamiaposta71@gmail.com> ha escrito:
> 2009/12/18 Raffaele Recalcati <lamiaposta71@gmail.com>:
>> Summary: Feasibility analisys of Android introduction in a completely
>> tested industrial device.
>>
>> Description: By now Android has been ported to 600Mhz Cortex A8 cpu
>> or similar.
>> The declared Android requirements are instead lower, about 200Mhz Arm9
>> cpu with 100Mhz Ram bus.
>> So I think the growing interest in this O.S. lacks some porting to
>> less powerful cpus.
>> The reasons to do this porting are commercial because of Google market
>> power, but are also technnical, because Android debugging environment
>> is very nice for not embedded developers.
>> This could help the diffusion of opensource embedded Linux.
>>
>> The porting will be maybe against the 2.6.31 kernel for pxa270.
>> The idea is to preserve industrial tested development but adding
>> Android graphical interface.
>>
>> The cpu dependency of the porting will be as small as possible.
>>
>> Related work:
>> * Android Porting - http://www.kandroid.org/<wbr></wbr>android_pdk/
>> * Android Pxa270 - http://android-pxa270.sourceforge.net/
>>
>> Scope:
>> This should take more than 1 month for feasibility analysis.
>>
>>
>> --
>
>
> Anybody can give me his idea about this proposal?
> Thx
>
> Bye,
> Recalcati
> --
> 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
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