[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

some newbie questions



> Anybody out there a 68360 whiz?
> I've never used it, just did a quick scan of the UM.
> Just thinking about some general 68k stuff...
> Are you in supervisor mode when you attempt to write this?
> Is it possible that your monitor is running at user level when
> you attempt to run this code? (keep in mind, that I'm not even
> sure you NEED to be in supv mode, just making some suggestions).

hhmm ... i dont know. i looked into the board spec but havnt found any
relevant info.

the other question is: why do we have to set the mbar ? 
i mean: we have an app which runs without any rtos on this hardware.
this code doesnt handle mbar in any way.
if i understand it correctly: we set the mbar to the addr of the m360
struct which wraps all the memory mapped registers of the 68360, right ?
why not just "bind" the m360 struct to the "correct" addr ?
e.g. out app (without rtos) "binds" theses structs to 0xffc00000 via c
pointers:

#define DPR_BASE 0xffc00000
#define CPIC_REGS (DPR_BASE + 0x1540)

cp_regs_t *cp = (cp_regs_t*) CP_REGS;

just an idea, too ...

regards,
seb


> Ed
> 
> sebastian ssmoller wrote:
> > 
> > section 6.8.1 in 68360 users manual says
> > "second, the MBAR, newly located at address $0003ff04, can only be
> > enabled for access after a keyed write operation is performed" and
> > later
> > on there is described that one has to write FFFFFFFE to MBARE before
> > MBAR could be set. even if that section talks about multiple QUICC
> > slaves : could this be the problem ?
> > 
> > regards,
> > seb
> > 
> > On Thu, 19 Feb 2004 14:35:53 -0500
> > Ed Sutter <els at emailbox.hdtv.lucent.com> wrote:
> > 
> > > Nevermind!!!
> > > I just scanned futher through the manual and it appears that the
> > > first
> > > instance of the MBAR address has a typo.  All other references in
> > > the
> > > manual use 0x3ff04, not 0x33ff04.
> > > Sorry about that!
> > > Ed
> > >
> > > sebastian ssmoller wrote:
> > > >
> > > > hi,
> > > > finally i used the approach: incrementing a variable an see
> > > > where it
> > > > stops.
> > > >
> > > > > Seb,
> > > > > Just reset the board (don't powercycle).  In most cases this
> > > > > doesn't
> > > > > corrupt memory.  Usually, assuming you have a reset or NMI
> > > > > type
> > > > > of button, you can get yourself back to the monitor, then in
> > > > > RAM
> > > > > space you essentially have the equivalent of a core dump.
> > > >
> > > > i did so and it worked perfectly well.
> > > >
> > > > i started debugging at
> > > > c/src/lib/libbsp/m68k/gen68360/start/start.S
> > > > where the start symbol which i call is defined. i found out that
> > > > the
> > > > board hangs immediately at step 4 where mbar is set.
> > > >
> > > >   /*
> > > >    * Step 4: Write the MBAR
> > > >    */
> > > >     movec   dfc,d1          | Save destination register
> > > >     moveq   #7,d0           | CPU-space funcction code
> > > >     movec   d0,dfc          | Set destination function code
> > > >     register
> > > >     movel   #m360+0x101,d0  | MBAR value (mask CPU space
> > > >     accesses)
> > > > /* with the execution of the next line the board will hang */
> > > >     movesl  d0,0x3FF04     | Set MBAR
> > > >     movec   d1,dfc          | Restore destination register
> > > >
> > > > the original addr of the MBAR was 0x3ff00 as described in the
> > > > 68360
> > > > manual (which failed). i read again the doc of my board and it
> > > > says
> > > > that
> > > > MBAR is at 0x3ff04. so i changed the value but nothing happens -
> > > > the
> > > > board still hangs :(
> > > >
> > > > thx
> > > >
> > > > regards,
> > > > seb
> > > >
> > > > (...)--
> > > > Microsoft: Where do you want to go today?
> > > > Linux: Where do you want to go tomorrow?
> > > > FreeBSD: Are you guys coming or what?
> > > > OpenBSD: Hey guys you left some holes out there!
> > >
> > 
> > --
> > Microsoft: Where do you want to go today?
> > Linux: Where do you want to go tomorrow?
> > FreeBSD: Are you guys coming or what?
> > OpenBSD: Hey guys you left some holes out there!
> 


-- 
Microsoft: Where do you want to go today?
Linux: Where do you want to go tomorrow?
FreeBSD: Are you guys coming or what?
OpenBSD: Hey guys you left some holes out there!