public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] logbuffer
@ 2006-06-30  2:01 Michael R. Hines
  2006-06-30  4:12 ` Frank
  2006-06-30  7:01 ` Wolfgang Denk
  0 siblings, 2 replies; 6+ messages in thread
From: Michael R. Hines @ 2006-06-30  2:01 UTC (permalink / raw)
  To: u-boot


I'd like to use the logbuffer functionality in u-boot...

After #define'ing CONFIG_LOGBUFFER, I can
successfully see our data getting printed to the reserved
16K region in dram. However, we want to grab that data
back out after linux has booted.

During the various initializations that linux does on boot,
(somewhere before init is actually run, I believe), the data
in the 16K buffer at the end of dram gets over-written
by somebody inside linux, and is lost.

I found a thread somewhere on the net where Wolfgang
mentioned that linux needed a patch to be told not to
intrude on those logbuffer pages, but nothing more than
that.

Is there a proper way to handle this?

Thanks,
- Michael R. Hines

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] logbuffer
  2006-06-30  2:01 [U-Boot-Users] logbuffer Michael R. Hines
@ 2006-06-30  4:12 ` Frank
  2006-06-30  4:56   ` Michael R. Hines
  2006-06-30  7:01 ` Wolfgang Denk
  1 sibling, 1 reply; 6+ messages in thread
From: Frank @ 2006-06-30  4:12 UTC (permalink / raw)
  To: u-boot



--- "Michael R. Hines" <mhines@google.com> wrote:

> 
> I'd like to use the logbuffer functionality in u-boot...
> 
> After #define'ing CONFIG_LOGBUFFER, I can
> successfully see our data getting printed to the reserved
> 16K region in dram. However, we want to grab that data
> back out after linux has booted.
> 
> During the various initializations that linux does on boot,
> (somewhere before init is actually run, I believe), the data
> in the 16K buffer at the end of dram gets over-written
> by somebody inside linux, and is lost.
> 
> I found a thread somewhere on the net where Wolfgang
> mentioned that linux needed a patch to be told not to
> intrude on those logbuffer pages, but nothing more than
> that.
> 
> Is there a proper way to handle this?
> 
> Thanks,
> - Michael R. Hines

I've never used the log buffer before, but I would think you
could just tell the kernel you have less memory then is
physically there. That way the kernel wouldn't touch the area
used by the log buffer...

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] logbuffer
  2006-06-30  4:12 ` Frank
@ 2006-06-30  4:56   ` Michael R. Hines
  2006-06-30  5:05     ` Frank
  0 siblings, 1 reply; 6+ messages in thread
From: Michael R. Hines @ 2006-06-30  4:56 UTC (permalink / raw)
  To: u-boot


That's what my first attempt tried to do, but it didn't seem to work.

I reduced mem_size (I think) inside the bd_info struct by 16K.

Just curious if there was a more properly intended way of going about it...

- Michael

Frank wrote:
> --- "Michael R. Hines" <mhines@google.com> wrote:
>
>   
>> I'd like to use the logbuffer functionality in u-boot...
>>
>> After #define'ing CONFIG_LOGBUFFER, I can
>> successfully see our data getting printed to the reserved
>> 16K region in dram. However, we want to grab that data
>> back out after linux has booted.
>>
>> During the various initializations that linux does on boot,
>> (somewhere before init is actually run, I believe), the data
>> in the 16K buffer at the end of dram gets over-written
>> by somebody inside linux, and is lost.
>>
>> I found a thread somewhere on the net where Wolfgang
>> mentioned that linux needed a patch to be told not to
>> intrude on those logbuffer pages, but nothing more than
>> that.
>>
>> Is there a proper way to handle this?
>>
>> Thanks,
>> - Michael R. Hines
>>     
>
> I've never used the log buffer before, but I would think you
> could just tell the kernel you have less memory then is
> physically there. That way the kernel wouldn't touch the area
> used by the log buffer...
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>   

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] logbuffer
  2006-06-30  4:56   ` Michael R. Hines
@ 2006-06-30  5:05     ` Frank
  2006-07-06 21:28       ` Michael R. Hines
  0 siblings, 1 reply; 6+ messages in thread
From: Frank @ 2006-06-30  5:05 UTC (permalink / raw)
  To: u-boot



--- "Michael R. Hines" <mhines@google.com> wrote:

> 
> That's what my first attempt tried to do, but it didn't seem
> to work.
> 
> I reduced mem_size (I think) inside the bd_info struct by 16K.
> 
> Just curious if there was a more properly intended way of
> going about it...
> 
> - Michael
> 
> Frank wrote:
> > --- "Michael R. Hines" <mhines@google.com> wrote:
> >
> >   
> >> I'd like to use the logbuffer functionality in u-boot...
> >>
> >> After #define'ing CONFIG_LOGBUFFER, I can
> >> successfully see our data getting printed to the reserved
> >> 16K region in dram. However, we want to grab that data
> >> back out after linux has booted.
> >>
> >> During the various initializations that linux does on boot,
> >> (somewhere before init is actually run, I believe), the
> data
> >> in the 16K buffer at the end of dram gets over-written
> >> by somebody inside linux, and is lost.
> >>
> >> I found a thread somewhere on the net where Wolfgang
> >> mentioned that linux needed a patch to be told not to
> >> intrude on those logbuffer pages, but nothing more than
> >> that.
> >>
> >> Is there a proper way to handle this?
> >>
> >> Thanks,
> >> - Michael R. Hines
> >>     
> >
> > I've never used the log buffer before, but I would think you
> > could just tell the kernel you have less memory then is
> > physically there. That way the kernel wouldn't touch the
> area
> > used by the log buffer...

Try reducing it on the kernel cmdline (mem=xxM) by 1Meg increments.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] logbuffer
  2006-06-30  2:01 [U-Boot-Users] logbuffer Michael R. Hines
  2006-06-30  4:12 ` Frank
@ 2006-06-30  7:01 ` Wolfgang Denk
  1 sibling, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2006-06-30  7:01 UTC (permalink / raw)
  To: u-boot

In message <44A485E9.7050905@google.com> you wrote:
> 
> I'd like to use the logbuffer functionality in u-boot...

OK.

> I found a thread somewhere on the net where Wolfgang
> mentioned that linux needed a patch to be told not to
> intrude on those logbuffer pages, but nothing more than
> that.

Corresponding code can be found in our linux-2.4 kernel tree.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Boss, n.: According to the Oxford English Dictionary, in  the  Middle
Ages  the  words  "boss"  and "botch" were largely synonymous, except
that boss, in addition to meaning  "a  supervisor  of  workers"  also
meant "an ornamental stud."

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot-Users] logbuffer
  2006-06-30  5:05     ` Frank
@ 2006-07-06 21:28       ` Michael R. Hines
  0 siblings, 0 replies; 6+ messages in thread
From: Michael R. Hines @ 2006-07-06 21:28 UTC (permalink / raw)
  To: u-boot


That's exactly what I needed. Thank. Instead, however I reduced
it by exactly 16 KB, the size of the logbuffer.

Frank wrote:
> --- "Michael R. Hines" <mhines@google.com> wrote:
>
>   
>> That's what my first attempt tried to do, but it didn't seem
>> to work.
>>
>> I reduced mem_size (I think) inside the bd_info struct by 16K.
>>
>> Just curious if there was a more properly intended way of
>> going about it...
>>
>> - Michael
>>
>> Frank wrote:
>>     
>>> --- "Michael R. Hines" <mhines@google.com> wrote:
>>>
>>>   
>>>       
>>>> I'd like to use the logbuffer functionality in u-boot...
>>>>
>>>> After #define'ing CONFIG_LOGBUFFER, I can
>>>> successfully see our data getting printed to the reserved
>>>> 16K region in dram. However, we want to grab that data
>>>> back out after linux has booted.
>>>>
>>>> During the various initializations that linux does on boot,
>>>> (somewhere before init is actually run, I believe), the
>>>>         
>> data
>>     
>>>> in the 16K buffer at the end of dram gets over-written
>>>> by somebody inside linux, and is lost.
>>>>
>>>> I found a thread somewhere on the net where Wolfgang
>>>> mentioned that linux needed a patch to be told not to
>>>> intrude on those logbuffer pages, but nothing more than
>>>> that.
>>>>
>>>> Is there a proper way to handle this?
>>>>
>>>> Thanks,
>>>> - Michael R. Hines
>>>>     
>>>>         
>>> I've never used the log buffer before, but I would think you
>>> could just tell the kernel you have less memory then is
>>> physically there. That way the kernel wouldn't touch the
>>>       
>> area
>>     
>>> used by the log buffer...
>>>       
>
> Try reducing it on the kernel cmdline (mem=xxM) by 1Meg increments.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20060706/b4d905cd/attachment.pgp 

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2006-07-06 21:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-30  2:01 [U-Boot-Users] logbuffer Michael R. Hines
2006-06-30  4:12 ` Frank
2006-06-30  4:56   ` Michael R. Hines
2006-06-30  5:05     ` Frank
2006-07-06 21:28       ` Michael R. Hines
2006-06-30  7:01 ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox