9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bitsy bootldr
Date: Wed, 30 Oct 2002 12:10:38 +0100	[thread overview]
Message-ID: <200210301110.g9UBAdf04160@zamenhof.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Wed, 30 Oct 2002 09:20:13 +0100." <d6773be2a08ab59126a6e94a12bcc5a3@plan9.escet.urjc.es>

> :  One things that has changed that could cause a problem based on the
> :  amount of time that went by: the bootldr is resetting RTTR to 0x8000
> :  for non-windows operating systems to avoid huge time drift.
> :
> :  Jamey
>
> I think that's not the problem. In fact, our clockpower routine
> sets rttr to 0x8000 after power resume.

Yes, I noticed. Added some debugging print statements and played a bit.
(and while looking at debugging output it took me an embarrasing
 amount of time to realize that 0x8000 is 32768. sigh.)

> There has to be something else in the bootldr.  Perhaps the part that
> turns on dram is doing it in a different way, or something else permits
> our bugs to show up.
>
> If I get some time, I could diff the 2.18.x with my 2.14.y to see what
> changed.  But don't hold your breath.

I'll try myself, if I find the time, but it is likely that I overlook
the culprit -- essentially I'm learning by doing (playing) here.

While playing and learning, looking at syntax is easier than
understanding semantics. Two syntactical things confused me.

1) the declaration ofRTCregs in your clock.c:
I added the offset of the fields in the comment.
Shouldn't there be a ``hole /* 0x0c */'' between trim and status?
	typedef struct RTCregs
	{
		ulong	rtar;	/* 0x00 alarm */
		ulong	rcnr;	/* 0x04 count */
		ulong	rttr;	/* 0x08 trim */
		ulong	rtsr;	/* 0x10 status */
	} RTCregs;

I added a ``ulong hole;'' in between, set rtar to 0x05
in clockinit() (next to setting of rttr and rcnr fields)
and saw the debug print statement of clockintr many many times.

2) I'm trying to understand (a bit) mapspecial.
is its parameter the register size in bytes?
How important is the exact value of this parameter?
(I see that in some cases the mapped register(set) is part
 of a bigger block that is mapped special, I suppose that
 in that case size does not matter so much)

Reason I'm asking is that I noticed that this parameter
is hardcoded in many places (which seems potentially dangerous?)
(see example below, isn't sizeof(MemConfRegs) > 32?)

Just wondering: is there a stylistic or other reason to use
the numbers, instead of e.g. using sizeof?

in main.c:
	/* memory configuraton */
	memconfregs = mapspecial(MEMCONFREGS, 32);

in io.h:
typedef struct MemConfRegs MemConfRegs;
struct MemConfRegs
{
	ulong	mdcnfg;		/* 0x00	dram */
	ulong	mdcas00;		/* 0x04	dram banks 0/1 */
	ulong	mdcas01;		/* 0x08 */
	ulong	mdcas02;		/* 0x0c */
	ulong	msc0;		/* 0x10	static */
	ulong	msc1;		/* 0x14 */
	ulong	mecr;		/* 0x18	pcmcia */
	ulong	mdrefr;		/* 0x1c	dram refresh */
	ulong	mdcas20;		/* 0x20	dram banks 2/3 */
	ulong	mdcas21;		/* 0x24 */
	ulong	mdcas22;		/* 0x28 */
	ulong	msc2;		/* 0x2c	static */
	ulong	smcnfg;		/* 0x30	SMROM config */
};

Just trying to learn, (and hoping to stumble over the suspend/resume
problem - you never know :-)
Axel.



  reply	other threads:[~2002-10-30 11:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-30  8:20 Fco.J.Ballesteros
2002-10-30 11:10 ` Axel Belinfante [this message]
2002-10-30 11:47 Fco.J.Ballesteros
2002-10-30 12:42 ` Axel Belinfante
2002-10-30 13:40 Fco.J.Ballesteros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210301110.g9UBAdf04160@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).