Re: [9fans] bitsy bootldr

Re: [9fans] bitsy bootldr

[Fco.J.Ballesteros]

I already did a grep for mapspecial and changed those that
map a struct to use sizeof struct.

I'll drop a line to the list if I make any progress other than
that (get the rtc working, for example). You could then test that
kernel to see if the bug for suspend went away.

Re: [9fans] bitsy bootldr

[Axel Belinfante]

> > 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?)
>
> The map is done in mmu.c by _map(). Probably it's being mapped
> anyway. But I think that's just another bug you've found.

Just to repeat: there are _many_ places with hardcoded numbers,
and for example, with ``hole'' added, also the rtc clock regs
gets too big (but it is in the OneMeg range of 0x9000whatever,
so probably gets mapped anyway).

> Now that you've found the stupid reason why I didn't get rtc interrupts
> I'll try to build a new kernel soon and fix those things to see what
> happens.

I played a bit, but what I did did not ``magically'' make
suspend/resume work (I even browsed Intel's SA1100 doc, but really
don't know enough about these things).

I think it's best if I wait for your work, try it, and if it works,
fold in the (somewhat revised) dual pcmcia hacks, and see
what happens then.
(do we also have to think about sleeve support in general --
 sleeve identification, software concept of sleeve as they
 have in bootldr and probably also in linux?
 or can it just be (hidden) part of the  pcmcia card support etc.
)
FYI: On friday I will be going on a one-and-half weeks vacation
in (of all places) Spain, during which I won't have net.access
(so, don't hurry only for my sake -- unless you would be able to
build something to play with before/during thursday evening :-)

Re: [9fans] bitsy bootldr

[Fco.J.Ballesteros]

> I added the offset of the fields in the comment.
> Shouldn't there be a ``hole /* 0x0c */'' between trim and status?

Hmm. Not sure, but if there's a hole there, then that's the bug that
prevents me from sending RTC interrupts, ugh.

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


thanks a lot. I'm an idiot. We can probably wake up the bitsy while
suspended with your fix.


> 2) I'm trying to understand (a bit) mapspecial.
> is its parameter the register size in bytes?

Yes. Unless I'm very mistaken.

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

The map is done in mmu.c by _map(). Probably it's being mapped
anyway. But I think that's just another bug you've found.

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

I think it'd be better to use sizeof.

Now that you've found the stupid reason why I didn't get rtc interrupts
I'll try to build a new kernel soon and fix those things to see what
happens.

If you do it before I could, it'd be great to merge our versions.
I wouldn't like to end up with three different versions of the bitsy
kernel.

thanks a lot.

Re: [9fans] bitsy bootldr

[Axel Belinfante]

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

[9fans] bitsy bootldr

[Fco.J.Ballesteros]

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

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.