lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 4 Apr 2019 12:01:21 +0200
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Adam Ford <aford173@...il.com>
Cc:     Sekhar Nori <nsekhar@...com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Kevin Hilman <khilman@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        David Lechner <david@...hnology.com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 1/4] ARM: davinci: fix cpufreq registration on da850-evm

śr., 3 kwi 2019 o 17:49 Adam Ford <aford173@...il.com> napisał(a):
>
> On Wed, Apr 3, 2019 at 7:50 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> >
> > śr., 27 mar 2019 o 12:14 Sekhar Nori <nsekhar@...com> napisał(a):
> > >
> > > Hi Bart,
> > >
> > > On 26/03/19 11:21 PM, Bartosz Golaszewski wrote:
> > > > wt., 26 mar 2019 o 15:00 Adam Ford <aford173@...il.com> napisał(a):
> > > >>
> > > >> On Fri, Mar 22, 2019 at 8:31 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > > >>>
> > > >>> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> > > >>>
> > > >>> The system_rev variable is never set on davinci and is always 0, so
> > > >>> we're using the default max operating point of 300MHz. The cvdd supply
> > > >>> comes from the tps6507 pmic and the voltage can go all the way to 1.3V
> > > >>> so the maximum supported rate should be 456MHz.
> > > >>
> > > >> My understanding is that only certain revisions of the silicon can go
> > > >> to 456MHz.   The L138's Datasheet lists both a 456 and 375 version.  I
> > > >> cannot find a way to read a register to determine which version of the
> > > >> silicon is available. Maybe Sekhar can confirm.
> > > >>
> > > >
> > > > Commit 28bd2c341120 ("davinci: am18x/da850/omap-l138 evm: add support
> > > > for higher speed grades") mentions the following:
> > > >
> > > > ---
> > > > U-Boot on the EVM sets up ATAG_REVISION to inform the OS
> > > > regarding the speed grade supported by the silicon. We use
> > > > this information to pass on the speed grade information to
> > > > the SoC code.
> > > > ---
> > > >
> > > > Should the system_rev somehow reflect that revision? Any way I can check it?
> > >
> > > Can you check if the procedure in doc/README.davinci in U-Boot sources
> > > still works?
> > >
> > > Environment Variables
> > > =====================
> > >
> > > The DA850 EVM allows the user to specify the maximum cpu clock allowed by the
> > > silicon, in Hz, via an environment variable "maxcpuclk".
> > >
> > > The maximum clock rate allowed depends on the silicon populated on the EVM.
> > > Please make sure you understand the restrictions placed on this clock in the
> > > device specific datasheet before setting up this variable. This information is
> > > passed to the Linux kernel using the ATAG_REVISION atag.
> > >
> > > If "maxcpuclk" is not defined, the configuration CONFIG_DA850_EVM_MAX_CPU_CLK
> > > is used to obtain this information.
> > >
> > > Thanks,
> > > Sekhar
> >
> > Hi Sekhar,
> >
> > I built the current upstream u-boot and the get_board_rev() function
> > for da850-evm doesn't seem to be called at all. For instance the
> > lego-ev3 platform does this:
> >
> > ./lego/ev3/legoev3.c:108: board_rev = get_board_rev();
> >
> > but in davinci this function seems to be unused and I don't see it
> > called from any other core u-boot component. I don't see any commit
> > that would mention this function but there are a lot of commits
> > removing get_board_rev() for other boards in git log. Is it possible
> > it stopped being used at some point?
>
> Look for setup_revision_tag in arch/arm/lib/bootm.c
>
> The function appears to be called from there.
>
> There is a __weak reference in the header file which I think allows
> people to remove them without breaking bootm.
>
> adam
> >
> > Bart

Thanks, now verified that this still works in board file mode for
da850-evm. Now the questions is - what about DT mode? Should we only
enable the lowest possible mode (300MHz) and leave it to the user to
enable any higher frequencies?

Bart

Powered by blists - more mailing lists