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] [day] [month] [year] [list]
Date: Thu, 2 May 2024 15:39:53 +0800
From: Jingbao Qiu <qiujingbao.dlmu@...il.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc: Inochi Amaoto <inochiama@...look.com>, robh+dt@...nel.org, 
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, 
	paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu, 
	linux-rtc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, dlan@...too.org
Subject: Re: [PATCH v8 2/2] rtc: sophgo: add rtc support for Sophgo CV1800 SoC

On Wed, May 1, 2024 at 7:20 PM Alexandre Belloni
<alexandre.belloni@...tlin.com> wrote:
>
> On 01/05/2024 17:14:43+0800, Jingbao Qiu wrote:
> > On Wed, May 1, 2024 at 3:43 PM Inochi Amaoto <inochiama@...lookcom> wrote:
> > >
> > > On Wed, May 01, 2024 at 01:03:58PM GMT, Jingbao Qiu wrote:
> > > > Hi, Inochi
> > > >
> > > > On Wed, May 1, 2024 at 10:19 AM Inochi Amaoto <inochiama@...look.com> wrote:
> >
> > > > > Another thing is that I do not think is a good way to let the
> > > > > rtc driver access RTC_CTRL area directly. You have already
> > > > > know there is a 8051 device in the 0x05025000. It is necessary
> > > > > to make some room for this device. Maybe you want to implement
> > > > > them all in the rtc driver? If so, I do think it is a bad idea.
> > > >
> > > >
> > > > Do you mean that RTC drivers should not directly access the 0x05025000 address?
> > > > Because there is an 8051 subsystem on this address.
> > >
> > > Yes. At least we need some mechanism to share these address between
> > > this devices.
> > >
> > > > Firstly, I do not intend to implement 8051 in the RTC driver,
> > > > but the 8051 subsystem is located within a module independently
> > > > powered by the RTC.
> > > > So if we want to implement the 8051 subsystem in the future, it can be
> > > > used as a node in RTC? I'm not sure.
> > >
> > > Yes, this is what I care about.
> > >
> > > > Then, Alexandre told me that there are operations related to PM in
> > > > RTC, such as the following files.
> > > > This matches the description of address 0x05025000.
> > > >
> > > > drivers/rtc/rtc jz4740. c
> > > >
> > >
> > > I do not think this is something related to the PM. 8051 is more
> > > like remoteproc. So it is necessary to arrange them carefully.
> > >
> >
> > You are right.
> > I learned from official documents that 8051 works in the RTC domain.
> > Linux does not provide relevant interfaces to operate 8051,
> > Just providing a mailbox for communication between them, or through
> > interruptions.
> > I don't understand how 8051 works, so I shouldn't write to the
> > corresponding registers in RTC.
> >
> > https://milkv.io/docs/duo/getting-started/8051core
>
> Then you will have to have a driver for the 8051 firmware before being
> able to access registers that are outside of the RTC range. However, I
> se the firmware is using RTC_INFOx without any form of locking but I
> guess this just means Linux will have to ensure it never writes to
> those.
>

Yes, you are right. Not only are the registers on 0x05025000 used by 8051,
but some of the registers on 0x05026000 are shared by the C906 and 8051 cores,
such as the RTC_INFOx you mentioned. The reference link is as follows.
So it is necessary to ensure that registers that implement RTC
functions can be read and written,
registers that are accessed together with 8051 can only be read but
not written, and registers
that are private to 8051 cannot be read or written.


https://github.com/milkv-duo/duo-8051/blob/main/sdcc/mars/include/chip_cv1822.h

Best regards
Jingbao Qiu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ