devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Bee <knaerzche@gmail.com>
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: devicetree@vger.kernel.org, heiko@sntech.de, jonas@kwiboo.se,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	ziyao@disroot.org
Subject: Re: [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and NanoPi Zero2
Date: Sat, 26 Jul 2025 13:07:06 +0200	[thread overview]
Message-ID: <6f62d1a8-0e5b-4e66-bbe2-53a355df3c1e@gmail.com> (raw)
In-Reply-To: <20250723134019.1076352-1-amadeus@jmu.edu.cn>


> Hi,
>
>> Nope.
>>
>> Are you really questioning my picture? Ridiculous ... see [0]
> No, I mean some boards of this model have SoC silkscreen RK3528 and
> others have RK3528A. The same is true for another Hinlink H28K SBC.
>
>> I'm sort of impressed on with which conviction you continue to claim
>> plain wrong things: [1], [2], [3].
> If you spend a few minutes running mainline u-boot or BSP kernel
> on your RK3528 board before blaming me:
I can't see the point here: I don't think it matters wether you or I
actually have this version on any of our boards. It exists: you may like it
or not.

This picture was actually a reply to your claim "... so we have never seen
the silk screen printed with RK3528 ... "  in your mail dated 2025/07/19.

Initially my only question was, why we don't use "rockchip,rk3528a" as
compatible when working on boards where the silkscreens says exactly that.
It was obviously copied from vendor and now it's "too late", "too
complicated" or something, idk and I'm fine with it.
> BL31:
> INFO:    rk_otp_init finish!
> INFO:    RK3528 SoC (0x101)
>
> mainline u-boot:
> ------
> U-Boot 2025.07-...
>
> Model: Generic RK3528
> SoC:   RK3528A
> ------
>
> BSP kernel:
> [    0.768514] rockchip-cpuinfo cpuinfo: SoC            : 35281000
> [    0.768990] rockchip-cpuinfo cpuinfo: Serial         : ...
>
>> I'm fine if upstream decides not to care. But it is and remains wrong
>> to claim that the other version does not exist
> Unless Rockchip says they fused the wrong OTP during production.
> Regardless of the SoC silkscreen, the chip type on OTP is the same,
> so how does Rockchip distinguish these chips?
Please read the rest of my previous reply where I sent code locations 
where and how they do.
>
> --
> 2.25.1
>
>

  reply	other threads:[~2025-07-26 11:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-12 17:37 [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and NanoPi Zero2 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 1/6] dt-bindings: arm: rockchip: Add Radxa ROCK 2A/2F Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 2/6] arm64: dts: " Jonas Karlman
2025-07-13 13:39   ` Yao Zi
2025-07-14  9:44   ` Nicolas Frattaroli
2025-07-14 10:49     ` Jonas Karlman
2025-07-14 11:15       ` Nicolas Frattaroli
2025-07-12 17:37 ` [PATCH v3 3/6] dt-bindings: arm: rockchip: Add ArmSoM Sige1 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 4/6] arm64: dts: " Jonas Karlman
2025-07-15 14:01   ` Chukun Pan
2025-07-15 14:21     ` Jonas Karlman
2025-07-16  7:00       ` Chukun Pan
2025-07-12 17:37 ` [PATCH v3 5/6] dt-bindings: arm: rockchip: Add FriendlyElec NanoPi Zero2 Jonas Karlman
2025-07-12 17:37 ` [PATCH v3 6/6] arm64: dts: " Jonas Karlman
2025-07-13 19:13 ` [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and " Alex Bee
2025-07-13 20:13   ` Jonas Karlman
2025-07-13 20:56     ` Alex Bee
2025-07-14  0:04       ` Jonas Karlman
2025-07-14  5:53         ` Alex Bee
2025-07-15 18:56           ` Heiko Stübner
2025-07-19  9:58             ` Alex Bee
2025-07-19 14:30               ` Chukun Pan
2025-07-19 16:07                 ` Alex Bee
2025-07-20  9:45                   ` Alex Bee
2025-07-20 13:40                     ` Chukun Pan
2025-07-20 15:51                       ` Alex Bee
2025-07-21 14:00                         ` Chukun Pan
2025-07-21 18:07                           ` Alex Bee
2025-07-23 13:40                             ` Chukun Pan
2025-07-26 11:07                               ` Alex Bee [this message]
2025-07-14  1:00       ` Yao Zi
2025-07-14  8:52         ` Nicolas Frattaroli
2025-07-14 15:24 ` Rob Herring (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f62d1a8-0e5b-4e66-bbe2-53a355df3c1e@gmail.com \
    --to=knaerzche@gmail.com \
    --cc=amadeus@jmu.edu.cn \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=ziyao@disroot.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).