Re: Some embedded topics

["Mike Frysinger" <vapier.adi@gmail.com>]

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