Some embedded topics

Joe MacDonald ha scritto:

Quoted 3 lines

Resending to the whole list since the last time it looks like gmail had decided I wanted to send HTML.

Quoted 4 lines

That, and pramfs seems to be largely untouched these days, but since I haven't used it recently, I don't know if the lack of activity is due to neglect or stability.

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. Sometimes ago I sent a porting to 2.6.24, but I didn't receive any response.

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.

Sometimes ago I sent a porting to 2.6.24, but I didn't receive any response.

Quoted 2 lines · Marco Stornelli

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.

Quoted 1 line · Marco Stornelli

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.

Quoted 1 line

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
=============================

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.

Quoted 3 lines · 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 ?

Quoted 13 lines · Rob Landley

Quoted 3 lines · 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.

Quoted 4 lines

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

Quoted 19 lines · On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote:

Quoted 17 lines · Rob Landley

Quoted 3 lines · 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.

Quoted 4 lines

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...)

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.

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.

Quoted 3 lines · 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.

P.S. Is debug=mem something specific to Amiga? I find no mention of it in Documentation/kernel-parameters.txt

Quoted 3 lines · Geert Uytterhoeven

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.

Quoted 3 lines · Geert Uytterhoeven

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

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.

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.

Quoted 3 lines · Josh Boyer

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.

Quoted 4 lines

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.

With a little bit of work, you could have it trace into a circular buffer in DRAM. Then you can preserve that via mem= reservations, etc.