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.
next prev parent 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).