* Re: Some embedded topics
From: Tim Bird @ 2008-05-30 22:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Landley, T Ziomek, Mike Frysinger, David VomLehn,
linux-embedded
In-Reply-To: <Pine.LNX.4.64.0805291130580.16206@vixen.sonytel.be>
Geert Uytterhoeven wrote:
> Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
> passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
>
Wow! If tidbits like these are going to keep surfacing,
I feel like maybe CELF should get someone to just
permanently monitor this list and take interesting
info like the above and put it on the elinux wiki.
There's a lot of interesting stuff flowing out of
people's brains onto the list in the last few
days.... It's great!
-- Tim
P.S. Is debug=mem something specific to Amiga? I find
no mention of it in Documentation/kernel-parameters.txt
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Some embedded topics
From: Tim Bird @ 2008-05-30 22:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: vb, David VomLehn, linux-embedded
In-Reply-To: <20080527180200.56ffc588@vader.jdub.homelinux.org>
Josh Boyer wrote:
> lttng can trace quite a few events. Interrupts, system calls, etc.
> Might be worth a look, and it's quite well maintained against various
> kernel versions.
It's pretty heavyweight, but you could use filters to cut down on
the events traced. By default output goes to the file system, which
could be on pramfs. (Or NFS - I'm sorry I lost track of the original
request - don't know if this is an option or not.)
I'm not sure, however, that the buffers are pushed to user-space,
through the daemon, and back to the file system in an expedient manner.
I agree it might be worth a look for this use case. We use it at
Sony quite a bit and it's valuable.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Fwd: Some embedded topics
From: Tim Bird @ 2008-05-30 22:21 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Joe MacDonald, linux-embedded
In-Reply-To: <483D7355.5050803@coritel.it>
Marco Stornelli wrote:
> There's a MontaVista patent on PRAMFS and I think that most of times
> when a company hears this thing it skips quickly this solution.
Hmmm. I don't recall anything about a patent on PRAMFS.
There are lots of issues here, but I think it's OK to use.
At a minimum, MontaVista's PRAMFS was submitted to the CE Linux Forum
in an older kernel (2.4.20-based). MontaVista was well-aware
of this submission (although it did not come directly from them).
MV was under an IP agreement with CELF which required them to
disclose such patents to the forum, and none was received.
In any event (and without wanting to start a large off-topic legal
thread here), some lawyers would interpret the knowing publication
of an implementation embodying a patent under the GPL to be an
implicit license of use for the patent.
YMMV. IANAL. Seek your own counsel on this.
> Sometimes ago I sent a porting to 2.6.24, but I didn't receive any
> response.
I'd love to see this. Did this go to LKML? If so, about when?
(Alternatively, could you make it available somewhere?)
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Embedded Linux power management
From: Tim Bird @ 2008-05-30 22:05 UTC (permalink / raw)
To: J Sevy; +Cc: linux-embedded
In-Reply-To: <483B5F0D.9060302@cs.drexel.edu>
J Sevy wrote:
> Hi,
> kind of a general question for the list concerning the current "state of
> the art" in power management for handheld embedded Linux devices. In
> particular:
> - What are the standards in common use for power management on
> handhelds? APM, ACPI, or something else?
> - Is there a general consensus on the "best" approach for power management?
> - Is Dynamic Power Management (i.e., "speed-stepping") widely used?
> Thanks for any input.
In general, PM on handhelds is heavily dependent on chip features.
Many SOCs used in these devices have elaborate clock hardware,
allowing you to adjust the voltage and frequency of various parts
of the chip (or chipsets) dynamically.
For some good overviews of different PM features relevant to embedded,
you may want to look at the following papers:
Every Microamp is Sacred - A Dynamic Voltage and Current Control
Interface for the Linux Kernel - Liam Girdwood
http://www.celinux.org/elc08_presentations/regulator-api-celf.pdf
Power Management Quality of Service and How You Could Use it in
Your Embedded Application - Mark Gross
http://www.celinux.org/elc08_presentations/elc2008_pm_qos_slides.pdf
Building Blocks for Embedded Power Management - Kevin Hilman
http://www.celinux.org/elc08_presentations/PM_Building_Blocks1.pdf
Linux Suspend-to-Disk Objectives for Consumer Electronic Devices -
Vitaly Wool
http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=std.pdf
Linux Clock Management Framework - Siarhei Yermalayeu
http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2007Presentations?action=AttachFile&do=view&target=ELC_2007_Linux_clock_fmw.pdf
These links should probably be added to the Power Management
page on the elinux wiki (http://elinux.org/Power_Management),
which at the moment is fairly light on content.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Possible NetFilter Bug (2.4.27 and 2.6.20 kernel)
From: Glenn Henshaw @ 2008-05-30 17:52 UTC (permalink / raw)
To: linux-net, linux-embedded
I'm running into a problem with uCLinux 3.2 (2.4.17 kernel) router.
I can also reproduce the problem on 2.6.20 kernel (Debian 4.0). I
suspect that it still exists in more recent versions, but can't create
the environment to test this easily.
The router is running a NAT (MASQUERADE) firewall. After a few days
of operation with a number of clients , the ip_dst_cache fills and
overflows, stopping the router. This is most noticeable with a large
number of hosts behind the router doing UDP transactions (although it
appears that ICMP and TCP connections produce the same effect).
The culprit seems to be traffic passing through the NAT connections
in the router. Each new packet creates a new entry in the rt_cache, or
increases the ref count. These entries are never cleared away.
Eventually, no more entries can be allocated as the entries in the
cache are locked (refcount>0). I traced the issue back to the packets
returning to the router from the outside host, where the destination
of the packet is changed. This appears to be a netfilter bug?
Reproducing the problem is simple. Given a host (192.168.4.2)
behind the router (192.168.4.3 to 192.168.1.161) and a host on the
other side of the router, ping between the hosts. The (edited) results
of the route -Cn command on the router are shown below.
### starting state
# route -Cn
Kernel IP routing cache
Source Destination Gateway Flags Metric Ref
Use Iface
192.168.4.3 192.168.4.2 192.168.4.2 0 1
0 eth0
192.168.1.161 206.191.32.163 192.168.1.2 0 0
0 eth1
# route -Cn
### ping 25x
# route -Cn
Kernel IP routing cache
Source Destination Gateway Flags Metric Ref
Use Iface
192.168.1.161 192.168.1.1 192.168.1.1 0 0
24 eth1
192.168.4.2 192.168.1.1 192.168.1.1 i 0 25
24 eth1
192.168.1.1 192.168.4.2 192.168.4.2 i 0 25
24 eth0
192.168.4.3 192.168.4.2 192.168.4.2 0 1
0 eth0
#
I've searched most of the lists, and added some patches (which
corrected lost ip_dst_cache entries). I'm looking for pointers on how
to resolve this. I must fix this in the 2.4 stream as this is an
embedded application and a kernel upgrade means recertifying with al
of our customers. Is there a better list to post to? Is there a bug
tracker somewhere to log this into?
--
Glenn Henshaw Logical Outcome Ltd.
e: thraxisp@logicaloutcome.ca w: www.logicaloutcome.ca
^ permalink raw reply
* Re: Some embedded topics
From: Mike Frysinger @ 2008-05-29 18:20 UTC (permalink / raw)
To: Rob Landley; +Cc: T Ziomek, David VomLehn, linux-embedded
In-Reply-To: <200805291231.11529.rob@landley.net>
On Thu, May 29, 2008 at 1:31 PM, Rob Landley wrote:
> On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
>> > On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
>> >> If I understand correctly David is talking about logging some trace-like
>> >> info (so it exists before a HW watchdog expires), and having it
>> >> somewhere "safe" from being disturbed by a HW reset.
>> >
>> > The standard way of doing this is to use the mem= kernel command line
>> > parameter to tell the system it has less memory than it does, and using
>> > what's left as a ramdisk. Years ago I saw some userspace thing running
>> > as root mmap() /dev/mem (or whatever they're calling it these days) and
>> > log to it. In theory you could even set the dmesg buffer up at the end
>> > of physical memory with a smallish kernel patch, make it big, and set the
>> > kernel to doing verbose printks.
>> >
>> > The trick is A) knowing the absolute physical address at which your debug
>> > buffer lives so you can find it after the reboot, B) convincing the
>> > system to do something useful with it on reboot rather than just
>> > overwriting it with fresh log data.
>>
>> how about the fact that when the core resets, the memory controller is
>> often reset as well ? that external memory is going to degrade. or
>> do we just bite our thumb and weather the few random bit errors ?
>> -mike
>
> Mostly it isn't a problem because DRAM lasts longer than you think it does:
> http://www.securityfocus.com/brief/686
ive read that article before and i'm aware of real degradation times.
it also points out that "the colder the better" which certainly doesnt
line up with many realistic cases of machines sitting in hot rooms or
in closests. working off of "well it should be fine most of the time"
isnt nearly as good as "this always works", and all it takes is 1 or 2
bits to be corrupt to significantly change the meaning of a cpu state
dump ...
but as long as things are prefaced this way and people are aware ...
it's better than nothing
> Your memory controller init has to go out of its way to screw it up with a
> memory test or some such. (That said, some of 'em do...)
as soon as the memory controller stops refreshing, it's a problem.
> This of course assumes you have spare ram for a while second kernel to sit
> around and do nothing until you pass control to it to fetch your diagnostics.
> Most embedded systems don't.
if you communicate the kernel log buffer pointer to u-boot, then you
can just read that directly.
-mike
^ permalink raw reply
* Re: Some embedded topics
From: Rob Landley @ 2008-05-29 17:31 UTC (permalink / raw)
To: Mike Frysinger; +Cc: T Ziomek, David VomLehn, linux-embedded
In-Reply-To: <8bd0f97a0805282121j10a99bb7ve92efc6a8dc8bbb1@mail.gmail.com>
On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote:
> On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
> > On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> >> If I understand correctly David is talking about logging some trace-like
> >> info (so it exists before a HW watchdog expires), and having it
> >> somewhere "safe" from being disturbed by a HW reset.
> >
> > The standard way of doing this is to use the mem= kernel command line
> > parameter to tell the system it has less memory than it does, and using
> > what's left as a ramdisk. Years ago I saw some userspace thing running
> > as root mmap() /dev/mem (or whatever they're calling it these days) and
> > log to it. In theory you could even set the dmesg buffer up at the end
> > of physical memory with a smallish kernel patch, make it big, and set the
> > kernel to doing verbose printks.
> >
> > The trick is A) knowing the absolute physical address at which your debug
> > buffer lives so you can find it after the reboot, B) convincing the
> > system to do something useful with it on reboot rather than just
> > overwriting it with fresh log data.
>
> how about the fact that when the core resets, the memory controller is
> often reset as well ? that external memory is going to degrade. or
> do we just bite our thumb and weather the few random bit errors ?
> -mike
Mostly it isn't a problem because DRAM lasts longer than you think it does:
http://www.securityfocus.com/brief/686
Your memory controller init has to go out of its way to screw it up with a
memory test or some such. (That said, some of 'em do...)
The people who pioneered this stuff many moons ago were the big iron guys, and
when they had that kind of problem they'd use kexec to avoid going back
through brain-dead firmware that did stupid things to memory:
http://lwn.net/Articles/108595
This of course assumes you have spare ram for a while second kernel to sit
around and do nothing until you pass control to it to fetch your diagnostics.
Most embedded systems don't.
I'd probably start reading at http://lkcd.sf.net/doc/index.html if I wanted to
come back up to speed on this area. The "leave a bit of memory free at the
end with mem=" trick is the easy way to avoid having to include actual
_infrastructure_ for this stuff. If you have the memory budget for
infrastructure, there are people happily to deliver forklifts full...
This doesn't come up much for me. During development I put /dev/console on a
serial port and log stuff to that, so I still have it after the box has gone
south. By the time a device running from flash winds up in the end user's
hands, I usually don't even know who they _are_, let alone have enough of a
relationship with them that they'd want their appliance to spontaneously send
info to me even if it did start malfunctioning.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: Some embedded topics
From: Geert Uytterhoeven @ 2008-05-29 9:31 UTC (permalink / raw)
To: Rob Landley; +Cc: T Ziomek, Mike Frysinger, David VomLehn, linux-embedded
In-Reply-To: <200805282201.48746.rob@landley.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1751 bytes --]
On Wed, 28 May 2008, Rob Landley wrote:
> On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> > If I understand correctly David is talking about logging some trace-like
> > info (so it exists before a HW watchdog expires), and having it somewhere
> > "safe" from being disturbed by a HW reset.
>
> The standard way of doing this is to use the mem= kernel command line
> parameter to tell the system it has less memory than it does, and using
> what's left as a ramdisk. Years ago I saw some userspace thing running as
> root mmap() /dev/mem (or whatever they're calling it these days) and log to
> it. In theory you could even set the dmesg buffer up at the end of physical
> memory with a smallish kernel patch, make it big, and set the kernel to doing
> verbose printks.
>
> The trick is A) knowing the absolute physical address at which your debug
> buffer lives so you can find it after the reboot, B) convincing the system to
> do something useful with it on reboot rather than just overwriting it with
> fresh log data.
Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · BIC GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Some embedded topics
From: Wolfgang Denk @ 2008-05-29 5:38 UTC (permalink / raw)
To: Mike Frysinger
Cc: Rob Landley, T Ziomek, David VomLehn,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8bd0f97a0805282121j10a99bb7ve92efc6a8dc8bbb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
In message <8bd0f97a0805282121j10a99bb7ve92efc6a8dc8bbb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> you wrote:
>
> how about the fact that when the core resets, the memory controller is
> often reset as well ? that external memory is going to degrade. or
> do we just bite our thumb and weather the few random bit errors ?
It depends. In all cases we tested so far we have never seen a
corrupton because the hardware and U-Boot were quick enough to get at
least refresh running again in time.
If you are really concerned, there are other options. For example on
systems that have OCM or SRAM you can put the log buffer there. We
did this in a project on 440EPx.
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-ynQEQJNshbs@public.gmane.org
To be awake is to be alive. - Henry David Thoreau, in "Walden"
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Some embedded topics
From: Wolfgang Denk @ 2008-05-29 5:34 UTC (permalink / raw)
To: Rob Landley
Cc: T Ziomek, Mike Frysinger, David VomLehn,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805282201.48746.rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
In message <200805282201.48746.rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> you wrote:
>
> The standard way of doing this is to use the mem= kernel command line
> parameter to tell the system it has less memory than it does, and using
> what's left as a ramdisk. Years ago I saw some userspace thing running as
> root mmap() /dev/mem (or whatever they're calling it these days) and log to
> it. In theory you could even set the dmesg buffer up at the end of physical
> memory with a smallish kernel patch, make it big, and set the kernel to doing
> verbose printks.
That's not theory, but a standard feature in U-Boot. It's called
shared log buffer, as U-Boot can also use this buffer for example for
POST results.
> The trick is A) knowing the absolute physical address at which your debug
> buffer lives so you can find it after the reboot, B) convincing the system to
> do something useful with it on reboot rather than just overwriting it with
> fresh log data.
There is no trickery involved.
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-ynQEQJNshbs@public.gmane.org
My brother sent me a postcard the other day with this big sattelite
photo of the entire earth on it. On the back it said: "Wish you were
here". - Steven Wright
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: problems bringing up CF based file system (2.6.25)
From: vb @ 2008-05-29 4:55 UTC (permalink / raw)
To: Rob Landley
Cc: Adrian Bunk, linux-embedded-u79uwXL29TY76Z2rM5mHXA,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ
In-Reply-To: <200805282217.49143.rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
On Wed, May 28, 2008 at 8:17 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
>
> Is it even possible to use just _parts_ of the SCSI layer, without sucking in
> the whole thing?
>
> I think the fact it's called a "layer" is a bit of a hint, actually. Don't
> embedded folks generally try to _avoid_ unnecessary layering, and pulling in
> large code libraries to perform a small task?
>
Good questions, it does seem quite excessive. Interestingly enough,
there is a platform option for the IDE driver as well
(CONFIG_BLK_DEV_PLATFORM): could it be the a better way to drive the
CF card in true IDE mode?
I must be missing something very basic, but can't get over this hurdle:
if I enable PATA platofrm, and define the card local bus/card in the
dts file, the card gets detected and properly recognized, but no
device seems to be created in /dev, so the card does not get mounted
when the board comes up.
If I enable CONFIG_BLK_DEV_PLATFORM instead (and no dts file
definitions), I can't get the probe function to be invoked, so the
card does not even get detected.
People, does anyone have CF card up and running in 2.6.25 - please,
share your secrets! :-)
Seriously, it is quite frustrating, I would really appreciate any extra hints,
TIA,
vadim
> Rob
> --
> "One of my most productive days was throwing away 1000 lines of code."
> - Ken Thompson.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Some embedded topics
From: Mike Frysinger @ 2008-05-29 4:21 UTC (permalink / raw)
To: Rob Landley
Cc: T Ziomek, David VomLehn, linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805282201.48746.rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
> On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
>> If I understand correctly David is talking about logging some trace-like
>> info (so it exists before a HW watchdog expires), and having it somewhere
>> "safe" from being disturbed by a HW reset.
>
> The standard way of doing this is to use the mem= kernel command line
> parameter to tell the system it has less memory than it does, and using
> what's left as a ramdisk. Years ago I saw some userspace thing running as
> root mmap() /dev/mem (or whatever they're calling it these days) and log to
> it. In theory you could even set the dmesg buffer up at the end of physical
> memory with a smallish kernel patch, make it big, and set the kernel to doing
> verbose printks.
>
> The trick is A) knowing the absolute physical address at which your debug
> buffer lives so you can find it after the reboot, B) convincing the system to
> do something useful with it on reboot rather than just overwriting it with
> fresh log data.
how about the fact that when the core resets, the memory controller is
often reset as well ? that external memory is going to degrade. or
do we just bite our thumb and weather the few random bit errors ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: problems bringing up CF based file system (2.6.25)
From: Rob Landley @ 2008-05-29 3:17 UTC (permalink / raw)
To: Adrian Bunk; +Cc: vb, linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080527230457.GH11310-Aar9JVdAhcRoA3hw4S0G5QR5/fbUUdgG@public.gmane.org>
On Tuesday 27 May 2008 18:04:57 Adrian Bunk wrote:
> > I am not really worried about saving memory, I just am trying to
> > understand the reason the SCSI driver is included in the first place -
> > SCSI is a much heavier protocol than what is needed here - isn't it?
> >...
>
> ATAPI uses the SCSI command set, so using parts of the SCSI layer for
> implementing ATA support is not unreasonable.
The SCSI layer is actually _three_ layers (upper, mid, and lower). It's a
large and heavyweight solution that (last I checked) reimplements lots of
stuff in the kernel's block layer. It unnecessarily mixes together different
types of transports so that plugging in a USB device can move where the
kernel decides to put your compact flash device on the next boot, and then
passes responsibility to udev to untangle the mess the kernel made by
commingling different transport types in the first place.
Is it even possible to use just _parts_ of the SCSI layer, without sucking in
the whole thing?
I think the fact it's called a "layer" is a bit of a hint, actually. Don't
embedded folks generally try to _avoid_ unnecessary layering, and pulling in
large code libraries to perform a small task?
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Some embedded topics
From: Rob Landley @ 2008-05-29 3:01 UTC (permalink / raw)
To: T Ziomek
Cc: Mike Frysinger, David VomLehn,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080527223142.GU26837-qbu1+ugcRq/by3iVrkZq2A@public.gmane.org>
On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> If I understand correctly David is talking about logging some trace-like
> info (so it exists before a HW watchdog expires), and having it somewhere
> "safe" from being disturbed by a HW reset.
The standard way of doing this is to use the mem= kernel command line
parameter to tell the system it has less memory than it does, and using
what's left as a ramdisk. Years ago I saw some userspace thing running as
root mmap() /dev/mem (or whatever they're calling it these days) and log to
it. In theory you could even set the dmesg buffer up at the end of physical
memory with a smallish kernel patch, make it big, and set the kernel to doing
verbose printks.
The trick is A) knowing the absolute physical address at which your debug
buffer lives so you can find it after the reboot, B) convincing the system to
do something useful with it on reboot rather than just overwriting it with
fresh log data.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Paul Gortmaker @ 2008-05-29 2:25 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290859.54396.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Wed, May 28, 2008 at 4:59 PM, Charles Manning
<manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org> wrote:
> Hi
>
> I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to
> integrate by just pulling a tarball and running patch-in script.
>
> I am curious as to whether people consider the current mechanism "good enough"
> or whether it is worth the effort trying to get YAFFS into the kernel tree.
>
> Pros I can see:
> * In tree means better testing (maybe).
> * Keeping current with kernel API changes.
* exposes your code to folks who otherwise might not be
aware it even exists.
>
> Cons:
> * More effort for YAFFS maintainers (me mostly).
It may look like this is the case initially, but really it becomes a case of
less effort for maintainers (you), once you get over the initial blip/hump of
knocking things into shape and getting it merged. If you are out of tree,
you have to be aware of all the API changes and subtle dependencies that
may lurk from a side effect of some other changeset. If you are in-tree and
Al Viro discovers some wide-sweeping bug, he will most likely fix your stuff
for you before you were even aware there was a problem.... :-)
> * Effort getting code into kernel coding style (unless I can get a waiver on
> this).
No get out of jail free card here, for anyone. Sorry.
Paul.
>
> Thoughts??
>
> -- CHarles
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Some embedded topics
From: Paul Gortmaker @ 2008-05-29 2:09 UTC (permalink / raw)
To: David VomLehn; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <483C83DE.3040604-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Tue, May 27, 2008 at 5:57 PM, David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> Since I'm at least partially to blame for creation of this mailing list (I
> asked Andrew Morton for one at the CELF Conference), I thought I might as
> well stir things up by throwing a few features out there that I think would
> improve the Linux kernel for use in the embedded world:
>
[...]
>
> On-line Disk Partitioning
> -------------------------
> Server and desktop systems partition their disks at installation time, but
> some applications require that partitioning be done after we are already
> using a root filesystem on disk. We only have one disk and the driver
> specifically prevents changing the partitioning while a disk partition is in
> use. Note that we don't want to change the root partition, just other
> partitions. This drives the need for some sort of on-line partitioning that
> allows changing partitions that aren't in use.
Interestingly enough, I remember when this sort of thing used to just
simply work as-is. Meaning that if you weren't shuffling partitions that
were actively in use, then all was well. I've no idea when it became
"broken", but there have been times when I've wanted to do just this
sort of thing, and it hasn't been specific to an embedded target. It sounds
like a reasonable thing to have on the radar.
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: James Chapman @ 2008-05-28 22:40 UTC (permalink / raw)
To: Charles Manning; +Cc: Mike Frysinger, linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290934.28232.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
Charles Manning wrote:
> On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
>>> I'm the author of YAFFS. This is not in the kernel tree, but is fairly
>>> easy to integrate by just pulling a tarball and running patch-in script.
>>>
>>> I am curious as to whether people consider the current mechanism "good
>>> enough" or whether it is worth the effort trying to get YAFFS into the
>>> kernel tree.
>>>
>>> Pros I can see:
>>> * In tree means better testing (maybe).
>>> * Keeping current with kernel API changes.
>>>
>>> Cons:
>>> * More effort for YAFFS maintainers (me mostly).
>>> * Effort getting code into kernel coding style (unless I can get a waiver
>>> on this).
>> i'm pretty sure you're going to have to cull all of the
>> LINUX_VERSION_CODE checks. that means the in tree yaffs code is only
>> going to track mainline kernel versions. i dont know whether you
>> consider that a pro or con (i say it's a pro), but if you want/need
>> those checks, you're basically going to have to maintain two forked
>> versions ...
>> -mike
>
> The main reason for those version checks is that YAFFS tries to acknowledge
> that not everyone just uses the latest kernel. Many embedded developers are
> using older kernels (for various valid reasons) (though this practice is
> probably on the decline) and I would like to continue supporting that.
>
> I would expect that this would make for two versions of yaffs_fs.c: the CVS
> one for all comers and the in-tree version which is cleaned.
Submitting code into the kernel doesn't mean you have to maintain both
in-tree and out-of-tree versions. Once the code is accepted into the
tree, I suggest that all subsequent development is done on the in-tree
version. Leave the CVS version for people who run older kernels - don't
try to keep the two in step. If users of older kernels want a new
feature or bugfix from the in-tree version, let them backport it; they
probably do so routinely already for other kernel components anyway.
I maintained some kernel code out of tree for a while. In my experience,
once code is accepted in the mainline kernel tree, the effort in
supporting and maintaining it dropped dramatically. It can take a lot of
work to get it accepted but the effort is well worth it if you're
successful.
I say yes, work on submitting yaffs. :)
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Alexey Zaytsev @ 2008-05-28 22:15 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290859.54396.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Thu, May 29, 2008 at 12:59 AM, Charles Manning
<manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org> wrote:
> Hi
>
> I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to
> integrate by just pulling a tarball and running patch-in script.
>
> I am curious as to whether people consider the current mechanism "good enough"
> or whether it is worth the effort trying to get YAFFS into the kernel tree.
>
> Pros I can see:
> * In tree means better testing (maybe).
> * Keeping current with kernel API changes.
>
> Cons:
> * More effort for YAFFS maintainers (me mostly).
> * Effort getting code into kernel coding style (unless I can get a waiver on
> this).
>
> Thoughts??
We at protei (protei.ru) are using yaffs for over a year now, switched from
jffs2, mostly because of the huge mount time difference. Have yet to
see any serious problems.
The process of patching the kernel with yaffs is quite smooth, but you
loose the ability to track the changes made in yaffs. We've got a git
kernel tree, to which we add our stuff, and also periodically repatch it
with a fresh yaffs. The problem is, all you can see later is a commit
labelled "A Yaffs update", revealing little details on the contents. Not cool.
If anything, I'd ask for merging this files sytem rather sooner than later,
as it should be useful for many embedded developers and touches
nothing outside the fs/yaffs2 directory.
The only thing that bothers me, is the licensing. Currently is seems
like Apleph1 is selling license exceptions for yaffs. Either this should
become impossible after yaffs gets any commits from the community,
or you will have to maintain a separate version without such commits.
> -- CHarles
> --
And thank you for working on yaffs and being positive about merging it
into the mainline kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: David Woodhouse @ 2008-05-28 22:00 UTC (permalink / raw)
To: Charles Manning; +Cc: Mike Frysinger, linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290934.28232.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Thu, 2008-05-29 at 09:34 +1200, Charles Manning wrote:
> The main reason for those version checks is that YAFFS tries to acknowledge
> that not everyone just uses the latest kernel. Many embedded developers are
> using older kernels (for various valid reasons)
The only vaguely valid reason I've ever heard is that they've already
been through QA and are shipping a product based on the old kernel, and
now they need some minor bug fixes. Even for a more serious product
update adding new features, it should be able to switch to a newer
kernel unless you've made some horrendous mistakes in the original
deployment, like not getting everything you use merged upstream.
And still -- if they choose to use an ancient and known-broken version
of the rest of the kernel, why would they want to combine that with the
newest, shiniest version of YAFFS? It just doesn't make sense.
I used to keep JFFS2 building for older kernels; I don't for a moment
regret abandoning that effort. Far from being helpful, I actually think
it was counter-productive, because it made people think that was a
_sane_ thing for them to be doing. It just isn't.
> I would expect that this would make for two versions of yaffs_fs.c:
> the CVS one for all comers and the in-tree version which is cleaned.
It's not even that hard to maintain those in parallel with a modern
version control system like git, pulling changes from one tree to the
other. We export JFFS2 for use in eCos that way.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Rob Landley @ 2008-05-28 21:52 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1209582709.25560.441.camel-ZP4jZrcIevRpWr+L1FloEB2eb7JE58TQ@public.gmane.org>
On Wednesday 30 April 2008 14:11:49 David Woodhouse wrote:
> > There are simply already far too many of them and they make the
> > kernel harder and harder to change.
>
> I agree. And if we do want to pay attention to pure code size, there are
> other approaches -- like --gc-sections and/or building with '--combine
> -fwhole-program' which I was playing with for OLPC a while back. I must
> dust that off now that the GCC fixes should mostly have made it into
> current distributions.
I like simplicity. I like _simple_. Half my attraction to embedded systems
is that they're simpler than big desktop systems where you have to figure out
how udev interacts with dbus to figure out why knetworkmanager convinced
Konqueror that your network doesn't exist when you can wget from the command
line just fine...
I submitted a patch to remove the use of perl to build the linux kernel (which
HPA added in 2.6.25) not because it affected the result, but because it
unnecessarily complicates the build system. (And perl tends to metasticize.
Nothing says "maintainability" like perl...)
Yes, Perl was used for some debugging tools before, things like the
check-patch script. But until 2.6.25 you never needed Perl to configure and
build a kernel...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Mike Frysinger @ 2008-05-28 21:48 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290934.28232.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Wed, May 28, 2008 at 5:34 PM, Charles Manning wrote:
> On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
>> > I'm the author of YAFFS. This is not in the kernel tree, but is fairly
>> > easy to integrate by just pulling a tarball and running patch-in script.
>> >
>> > I am curious as to whether people consider the current mechanism "good
>> > enough" or whether it is worth the effort trying to get YAFFS into the
>> > kernel tree.
>> >
>> > Pros I can see:
>> > * In tree means better testing (maybe).
>> > * Keeping current with kernel API changes.
>> >
>> > Cons:
>> > * More effort for YAFFS maintainers (me mostly).
>> > * Effort getting code into kernel coding style (unless I can get a waiver
>> > on this).
>>
>> i'm pretty sure you're going to have to cull all of the
>> LINUX_VERSION_CODE checks. that means the in tree yaffs code is only
>> going to track mainline kernel versions. i dont know whether you
>> consider that a pro or con (i say it's a pro), but if you want/need
>> those checks, you're basically going to have to maintain two forked
>> versions ...
>
> The main reason for those version checks is that YAFFS tries to acknowledge
> that not everyone just uses the latest kernel.
i know
> Many embedded developers are
> using older kernels (for various valid reasons)
and for plenty of invalid reasons ;)
> (though this practice is probably on the decline)
i hope so
> I would like to continue supporting that.
honestly, this is the only bit that matters ... if someone wants to
run an older kernel but you're only interested in maintaining
mainline, then those people be damned. stop using older kernels.
> I would expect that this would make for two versions of yaffs_fs.c: the CVS
> one for all comers and the in-tree version which is cleaned.
as long as you're completely aware and OK with the situation, then
let's stop talking about proposing for inclusion and post for review
already
wrt coding style, ive seen plenty of proposed things that were much
worse ... i dont think it'd take too much work to fix it ... you
should start with:
sed -i 's:[[:space:]]*$::' fs/yaffs*/*.c
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Charles Manning @ 2008-05-28 21:34 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8bd0f97a0805281424g2ceae455x774e8d66aba4ec2b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday 29 May 2008 09:24:14 Mike Frysinger wrote:
> On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
> > I'm the author of YAFFS. This is not in the kernel tree, but is fairly
> > easy to integrate by just pulling a tarball and running patch-in script.
> >
> > I am curious as to whether people consider the current mechanism "good
> > enough" or whether it is worth the effort trying to get YAFFS into the
> > kernel tree.
> >
> > Pros I can see:
> > * In tree means better testing (maybe).
> > * Keeping current with kernel API changes.
> >
> > Cons:
> > * More effort for YAFFS maintainers (me mostly).
> > * Effort getting code into kernel coding style (unless I can get a waiver
> > on this).
>
> i'm pretty sure you're going to have to cull all of the
> LINUX_VERSION_CODE checks. that means the in tree yaffs code is only
> going to track mainline kernel versions. i dont know whether you
> consider that a pro or con (i say it's a pro), but if you want/need
> those checks, you're basically going to have to maintain two forked
> versions ...
> -mike
The main reason for those version checks is that YAFFS tries to acknowledge
that not everyone just uses the latest kernel. Many embedded developers are
using older kernels (for various valid reasons) (though this practice is
probably on the decline) and I would like to continue supporting that.
I would expect that this would make for two versions of yaffs_fs.c: the CVS
one for all comers and the in-tree version which is cleaned.
-- CHarles
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Mike Frysinger @ 2008-05-28 21:24 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290859.54396.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Wed, May 28, 2008 at 4:59 PM, Charles Manning wrote:
> I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to
> integrate by just pulling a tarball and running patch-in script.
>
> I am curious as to whether people consider the current mechanism "good enough"
> or whether it is worth the effort trying to get YAFFS into the kernel tree.
>
> Pros I can see:
> * In tree means better testing (maybe).
> * Keeping current with kernel API changes.
>
> Cons:
> * More effort for YAFFS maintainers (me mostly).
> * Effort getting code into kernel coding style (unless I can get a waiver on
> this).
i'm pretty sure you're going to have to cull all of the
LINUX_VERSION_CODE checks. that means the in tree yaffs code is only
going to track mainline kernel versions. i dont know whether you
consider that a pro or con (i say it's a pro), but if you want/need
those checks, you're basically going to have to maintain two forked
versions ...
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Robert P. J. Day @ 2008-05-28 21:16 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290914.51814.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Thu, 29 May 2008, Charles Manning wrote:
> That would only be yaffs2 which has yaffs1 backward compatibility
> built in.
first things first -- make it available somewhere we can peruse it.
that would be a start.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: David Woodhouse @ 2008-05-28 21:15 UTC (permalink / raw)
To: Charles Manning; +Cc: linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200805290859.54396.manningc2-jEEI2ySEPisjAXWc8ALWsQ@public.gmane.org>
On Thu, 2008-05-29 at 08:59 +1200, Charles Manning wrote:
> I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to
> integrate by just pulling a tarball and running patch-in script.
>
> I am curious as to whether people consider the current mechanism "good enough"
> or whether it is worth the effort trying to get YAFFS into the kernel tree.
I've never paid close attention to YAFFS, and part of the reason for
that is that it's never been considered good enough to be merged into
the kernel tree. If it isn't even being posted for _review_, then it
might as well not exist.
There's a lot more to code review than the cosmetics of 'coding style'.
I would definitely encourage you to get the code into a shape where we
can consider merging it.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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