From: "Paweł Jarosz" <paweljarosz3691@gmail.com>
To: Kever Yang <kever.yang@rock-chips.com>, Johan Jonker <jbx6244@gmail.com>
Cc: sjg@chromium.org, philipp.tomsich@vrull.eu, u-boot@lists.denx.de
Subject: Re: [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig
Date: Sun, 13 Mar 2022 13:41:30 +0100 [thread overview]
Message-ID: <784c7dc5-15d5-5eb9-a463-3fc2231a3243@gmail.com> (raw)
In-Reply-To: <f3890647-ccf5-0333-045d-e9a5c698524c@rock-chips.com>
Hi Kever,
> Thanks for you hard working on this, would you mind to share what's the
> motivation for support rk3066 and MK808 board?
> RK3066 is an SoC release at 2012, which has been EOL for a long time,
> and MK808 is a product at 2013, almost 10 years ago.
That is true but at least here at Poland there are still rk3066 devices which
you can buy. And i don't think it's an exception. There are known cases
in opensource community of support for hardware much older than 10 years.
I.e. thanks to Linus Torwalds linux still supports EISA FDDI [1].
There are at least a few rk3066a SOC users and in the spirit of
Linus Torvalds' open source principles, adding support for this
platform is the correct step.
RK3066 is a great soc to play with.
I use my MK808 for three years now to keep my 3d printer in contact
with my local network.
I have been using the URZ0350 as a wifi camera for a long time.
And guess what! They don't want to break down.
[1] https://blog.desdelinux.net/en/linus-supports-a-device-by-a-user/
> I'm not object for enable more SoC support on the mainline, and I know
> you have spend a lot
> of time on this, I have do something like this before, but to be honest
> I don't think it's a good idea to add support for
> rk3066 on mainline now.
I do not agree.
As long as the world is using armv7 architecture adding support for SOC
rk3066a is a great and noble idea.
I personally am working on following up on my and Johan's patches by
adding support for writing firmware to these devices, using only opensource
tools like u-boot and rkflashtool. This support can be extended to other
devices such as rk3399, rk3568 and others. So other SOCs can also benefit
from adding support for rk3066a.
I also want to add that Linux actively supports rk3066a [2].
So if linux supports it, U-BOOT SHOULD ALSO!
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=rk3066
I appeal to you Kever Yang in the spirit of opensource, don't give up on
rk3066a yet. These devices are there and they work!
Thanks
-Paweł
> I merge the patches from Paweł Jarosz many years ago into rockchip local
> u-boot and make it work,
> I want to make the branch support as much SoCs as possible at that time.
> But later I found there is no people to use
> it, and the U-Boot is getting more and more heavy, old SoC support is
> the one part people want to clean,
> for it always bring in more '#if, #else' or something like this clean up
> series patches, and more terrible thing is how to
> always maintain the source code works on the old hardware. I do make
> everything work for a long time at first,
> but one day my only rk3066 board is broken, and I'm not able to do it
> anymore.
>
> Thanks,
> - Kever
next prev parent reply other threads:[~2022-03-13 12:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 16:48 [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig Johan Jonker
2021-12-30 16:48 ` [PATCH v3 2/6] rockchip: move CONFIG_SYS_ARCH_TIMER " Johan Jonker
2022-01-12 20:03 ` Simon Glass
2021-12-30 16:48 ` [PATCH v3 3/6] rockchip: spl: change call condition rockchip_stimer_init() Johan Jonker
2022-01-12 20:03 ` Simon Glass
2021-12-30 16:48 ` [PATCH v3 4/6] rockchip: tpl: " Johan Jonker
2022-01-12 20:03 ` Simon Glass
2021-12-30 16:48 ` [PATCH v3 5/6] rockchip: spl: replace ifdef by IS_ENABLED for timer_init() call condition Johan Jonker
2022-01-12 20:03 ` Simon Glass
2021-12-30 16:48 ` [PATCH v3 6/6] rockchip: tpl: use " Johan Jonker
2022-01-12 20:03 ` Simon Glass
2022-01-12 20:03 ` [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig Simon Glass
2022-03-12 8:51 ` Jagan Teki
2022-03-12 10:01 ` Johan Jonker
2022-03-12 14:39 ` Kever Yang
2022-03-13 12:41 ` Paweł Jarosz [this message]
2022-03-13 22:23 ` Simon Glass
2022-03-14 15:36 ` Johan Jonker
2022-03-16 7:06 ` Kever Yang
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=784c7dc5-15d5-5eb9-a463-3fc2231a3243@gmail.com \
--to=paweljarosz3691@gmail.com \
--cc=20211230164825.6489-1-jbx6244@gmail.com \
--cc=jbx6244@gmail.com \
--cc=kever.yang@rock-chips.com \
--cc=philipp.tomsich@vrull.eu \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/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