[U-Boot] am33xx board with no external RTC crystal issue

[Alex Kiernan]

On Fri, Nov 9, 2018 at 7:09 AM Belisko Marek <marek.belisko at gmail.com> wrote:
>
> Hi Alex,
>
> On Tue, Oct 30, 2018 at 7:12 AM Alex Kiernan <alex.kiernan at gmail.com> wrote:
> >
> > On Mon, Oct 29, 2018 at 11:36 PM Belisko Marek <marek.belisko at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm working on custome am33xx based HW which have no external 32KHz
> > > crystal. Anyway I want to use bootcount feature. I was trying to use
> > > internal PRCM CLK_32KHZ clock as source for RTCSS but still when want
> > > to read RTC registers I get data abort.
> > >
> > > I adapted this method :
> > >
> > > static void rtc32k_enable(void)
> > >  {
> > >         struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
> > >
> > >         /*
> > >          * Unlock the RTC's registers.  For more details please see the
> > >          * RTC_SS section of the TRM.  In order to unlock we need to
> > > @@ -287,9 +288,8 @@ static void rtc32k_enable(void)
> > >         writel(RTC_KICK1R_WE, &rtc->kick1r);
> > >
> > >         /* Enable the RTC 32K OSC by setting bits 3 and 6. */
> > > -       writel((1 << 3) | (1 << 6), &rtc->osc);
> > > +       writel((1 << 6), &rtc->osc);
> > >  }
> > >
> > > to not use external crystal 32KHz clock but internal. Anyway when
> > > doing that board just hangs and thats it. Any ideas or suggestions?
> >
> > I've a board exactly like that... check you're driving RTC_PORz
> > correctly, if you hold it in reset, that's the behaviour I see.
> OK thanks for info. I think it's hold in reset.
> >
> > > It
> > > is even possible to have something like that? I just seen that
> > > include/configs/siemens-am33x-common.h (using also am335x cpu without
> > > external 32KHz crystal) storing bootcount to env. Thanks a lot for any
> > > pointers.
> > >
> >
> > FWIW I gave up trying to use the internal clock as I couldn't get it
> > to tick reliably (my suspicion was my hand modified board wasn't
> > actually driving the reset correctly) and instead switched to keeping
> > the bootcounter in SRAM.
> I'm using bootcount stored in env. I'm using 2017.09 and didn't see
> option to store bootcount in RAM (maybe overlooked something).
> So you mean bootcount is stored in internal cpu SRAM? Thanks.

That's what I'm doing. I can't find the source referred to in this
post, but this is the address we're using:

https://e2e.ti.com/support/processors/f/791/t/204956

--
Alex Kiernan