realtek: add rtd129x, rtd1319 and rtd1619b sub-targets #12538

phinexhung · 2023-05-05T10:45:49Z

Add Realtek DHC SoC sub-targets which are rtd129x, rtd1319 and rtd1619b.

These three sub-targets have been used in some NAS products.

Add basic IRQ mux driver so that we can rely on upstream DesignWare serial driver for console output.

musashino205 · 2023-05-05T13:02:19Z

RTL83xx/RTL93xx SoCs in realtek target are MIPS, but RTD129x/RTD13xx/RTD161x SoCs are ARM (aarch64). So IMO, they shoud be added with new target.

phinexhung · 2023-05-05T14:13:02Z

Hi @musashino205 ,

Per discussed with @oliv3r in my previous pull request, #12520, he suggested using makefile to control different architecture.

That is why I abandon the previous request and submit this new one.

Hurricos · 2023-05-06T16:27:12Z

I think @oliv3r was just searching for answers.

@phinexhung: are there any device driver patches in common between the existing MIPS-based realtek target and your new hardware? I'm guessing not -- that would be the most sensible reason to reuse the existing realtek target.

I'd feel better about a single target if Realtek were reusing the stuff under target/linux/realtek/patches-5.15.

You'll note that Mediatek owns all of the products under the ramips/ and mediatek/ targets -- it's accepted to have multiple major targets per vendor, esp. if they are different arches, even in the cases where the SoCs perform the same role.

My understanding is that the community wants to see you begin to upstream the patches you have to mainline Linux, as OpenWrters have been doing with the realtek target as-is.

oliv3r · 2023-05-07T08:34:31Z

RTL83xx/RTL93xx SoCs in realtek target are MIPS, but RTD129x/RTD13xx/RTD161x SoCs are ARM (aarch64). So IMO, they shoud be added with new target.

How so? If tthe build system can handle it (which it looks like it can) there's no reason to have realtek-mips and realtek-arm. those are just cpu choices. What if realtek releases an RTL94xx which is an ARM based switch?

oliv3r · 2023-05-07T08:39:30Z

I think @oliv3r was just searching for answers.

I was, but oth, I think it does make sense to have it all under one umbrella. Even if the makefile magic gets a bit odd.

@phinexhung: are there any device driver patches in common between the existing MIPS-based realtek target and your new hardware? I'm guessing not -- that would be the most sensible reason to reuse the existing realtek target.

Hopefully, we'll have no drivers in openwrt and everything upstreamed. If we take that as our starting point, then having it all under realtek still makes sense imo.

I'd feel better about a single target if Realtek were reusing the stuff under target/linux/realtek/patches-5.15.

Well the chip-info stuff hopefully can be shared. The switches themselves have very few IP peripherials generally speaking. a reall y big one for the switching stuff of course.

I wonder what ethernet driver the RTD stuff is using. Is it a realtek ethernet, or some designware/off-the-shelf ethernet component?

You'll note that Mediatek owns all of the products under the ramips/ and mediatek/ targets -- it's accepted to have multiple major targets per vendor, esp. if they are different arches, even in the cases where the SoCs perform the same role.

I saw that too, and was a bit confused :p buyout/legacy being part of it? Who's the actual maintainer of that stuff?

My understanding is that the community wants to see you begin to upstream the patches you have to mainline Linux, as OpenWrters have been doing with the realtek target as-is.

Some openwrt-ers have; and that's of course the ideal situation, especially when a vendor is involved, as they have the capacity to most defiantly do so. For the switching stuff, I'd be a bit more hesitant, as it is reverse engineered, undocumented stuff that's being upstreamed, often with unintended consequences. Personally, I'm even as to see if we can drop the rtl9xxx stuff from mainline, until it matures a bit more and re-submitting it once confidence is a bit higher.... but that's just me thinking out-loud :)

phinexhung · 2023-05-07T13:17:04Z

I think @oliv3r was just searching for answers.

I was, but oth, I think it does make sense to have it all under one umbrella. Even if the makefile magic gets a bit odd.

@phinexhung: are there any device driver patches in common between the existing MIPS-based realtek target and your new hardware? I'm guessing not -- that would be the most sensible reason to reuse the existing realtek target.

Hopefully, we'll have no drivers in openwrt and everything upstreamed. If we take that as our starting point, then having it all under realtek still makes sense imo.

Agree with this point of view, if everything is upstreamed, that make sense to put these in the same umbrella.

This is also our target as well although it really takes time.

I'd feel better about a single target if Realtek were reusing the stuff under target/linux/realtek/patches-5.15.

Well the chip-info stuff hopefully can be shared. The switches themselves have very few IP peripherials generally speaking. a reall y big one for the switching stuff of course.

I wonder what ethernet driver the RTD stuff is using. Is it a realtek ethernet, or some designware/off-the-shelf ethernet component?

Ethernet share the same IP with rtl8168. The only difference is that the former is based on PCIe, while in RTD1xxx, it is based on SoC Bus.

You'll note that Mediatek owns all of the products under the ramips/ and mediatek/ targets -- it's accepted to have multiple major targets per vendor, esp. if they are different arches, even in the cases where the SoCs perform the same role.

I saw that too, and was a bit confused :p buyout/legacy being part of it? Who's the actual maintainer of that stuff?

My understanding is that the community wants to see you begin to upstream the patches you have to mainline Linux, as OpenWrters have been doing with the realtek target as-is.

Some openwrt-ers have; and that's of course the ideal situation, especially when a vendor is involved, as they have the capacity to most defiantly do so. For the switching stuff, I'd be a bit more hesitant, as it is reverse engineered, undocumented stuff that's being upstreamed, often with unintended consequences. Personally, I'm even as to see if we can drop the rtl9xxx stuff from mainline, until it matures a bit more and re-submitting it once confidence is a bit higher.... but that's just me thinking out-loud :)

For RTD1xxx target, we can said that it would be officially supported. During these days, we normally use openwrt as our standard SDK for NAS customers. We are glad to see if we can get these upstreamed in the near future.

oliv3r · 2023-05-07T15:48:51Z

I think @oliv3r was just searching for answers.

I was, but oth, I think it does make sense to have it all under one umbrella. Even if the makefile magic gets a bit odd.

@phinexhung: are there any device driver patches in common between the existing MIPS-based realtek target and your new hardware? I'm guessing not -- that would be the most sensible reason to reuse the existing realtek target.

Hopefully, we'll have no drivers in openwrt and everything upstreamed. If we take that as our starting point, then having it all under realtek still makes sense imo.

Agree with this point of view, if everything is upstreamed, that make sense to put these in the same umbrella.

Sadly, RTL is not doing this themselves, so we are doing it with a lot of reverse engineering. If you have access to people or documents, that could be super valueable :)

anyway, I've created #12541 to reduce scope even more of this MR.

This is also our target as well although it really takes time.

I'd feel better about a single target if Realtek were reusing the stuff under target/linux/realtek/patches-5.15.

Well the chip-info stuff hopefully can be shared. The switches themselves have very few IP peripherials generally speaking. a reall y big one for the switching stuff of course.
I wonder what ethernet driver the RTD stuff is using. Is it a realtek ethernet, or some designware/off-the-shelf ethernet component?

Ethernet share the same IP with rtl8168. The only difference is that the former is based on PCIe, while in RTD1xxx, it is based on SoC Bus.

Ok, that's good to know. If you could find out what IP the rtl83xx uses, it's only curious for naming and sharing a driver. Right now, we have no idea :(

You'll note that Mediatek owns all of the products under the ramips/ and mediatek/ targets -- it's accepted to have multiple major targets per vendor, esp. if they are different arches, even in the cases where the SoCs perform the same role.

I saw that too, and was a bit confused :p buyout/legacy being part of it? Who's the actual maintainer of that stuff?

My understanding is that the community wants to see you begin to upstream the patches you have to mainline Linux, as OpenWrters have been doing with the realtek target as-is.

Some openwrt-ers have; and that's of course the ideal situation, especially when a vendor is involved, as they have the capacity to most defiantly do so. For the switching stuff, I'd be a bit more hesitant, as it is reverse engineered, undocumented stuff that's being upstreamed, often with unintended consequences. Personally, I'm even as to see if we can drop the rtl9xxx stuff from mainline, until it matures a bit more and re-submitting it once confidence is a bit higher.... but that's just me thinking out-loud :)

For RTD1xxx target, we can said that it would be officially supported. During these days, we normally use openwrt as our standard SDK for NAS customers. We are glad to see if we can get these upstreamed in the near future.

That's very exciting. Maybe you can even convince the RTL guys at some point to do the same, so that it'll be a RTK default practise :) but baby steps :p

phinexhung · 2023-05-08T03:25:19Z

I think @oliv3r was just searching for answers.

I was, but oth, I think it does make sense to have it all under one umbrella. Even if the makefile magic gets a bit odd.

@phinexhung: are there any device driver patches in common between the existing MIPS-based realtek target and your new hardware? I'm guessing not -- that would be the most sensible reason to reuse the existing realtek target.

Hopefully, we'll have no drivers in openwrt and everything upstreamed. If we take that as our starting point, then having it all under realtek still makes sense imo.

Agree with this point of view, if everything is upstreamed, that make sense to put these in the same umbrella.

Sadly, RTL is not doing this themselves, so we are doing it with a lot of reverse engineering. If you have access to people or documents, that could be super valueable :)

At least we do, we have been working with kernel maintainer to get part of our source upstreamed.
And actually part of the dts and source have been upstreamed since kernel 5.8.
I can access people internally but it depends on their policy for open source.
My idea is to let our case be a successful story internally and hopefully other teams can leverage on this.

anyway, I've created #12541 to reduce scope even more of this MR.

This is also our target as well although it really takes time.

I'd feel better about a single target if Realtek were reusing the stuff under target/linux/realtek/patches-5.15.

Well the chip-info stuff hopefully can be shared. The switches themselves have very few IP peripherials generally speaking. a reall y big one for the switching stuff of course.
I wonder what ethernet driver the RTD stuff is using. Is it a realtek ethernet, or some designware/off-the-shelf ethernet component?

Ethernet share the same IP with rtl8168. The only difference is that the former is based on PCIe, while in RTD1xxx, it is based on SoC Bus.

Ok, that's good to know. If you could find out what IP the rtl83xx uses, it's only curious for naming and sharing a driver. Right now, we have no idea :(

BTW, there are two different IPs internally. One is 816x, which has been upstreamed and that is what we have been using in RTD1xxx SoC. You can find it under drivers/net/ethernet/realtek/ folder. The other is multi-port switch which might be the current rtl83xx, rtl93xx sub targets in openwrt. I don't think we can use the same driver for these two different ethernet ports since they belonged to different department within realtek.

You'll note that Mediatek owns all of the products under the ramips/ and mediatek/ targets -- it's accepted to have multiple major targets per vendor, esp. if they are different arches, even in the cases where the SoCs perform the same role.

I saw that too, and was a bit confused :p buyout/legacy being part of it? Who's the actual maintainer of that stuff?

My understanding is that the community wants to see you begin to upstream the patches you have to mainline Linux, as OpenWrters have been doing with the realtek target as-is.

Some openwrt-ers have; and that's of course the ideal situation, especially when a vendor is involved, as they have the capacity to most defiantly do so. For the switching stuff, I'd be a bit more hesitant, as it is reverse engineered, undocumented stuff that's being upstreamed, often with unintended consequences. Personally, I'm even as to see if we can drop the rtl9xxx stuff from mainline, until it matures a bit more and re-submitting it once confidence is a bit higher.... but that's just me thinking out-loud :)

For RTD1xxx target, we can said that it would be officially supported. During these days, we normally use openwrt as our standard SDK for NAS customers. We are glad to see if we can get these upstreamed in the near future.

That's very exciting. Maybe you can even convince the RTL guys at some point to do the same, so that it'll be a RTK default practise :) but baby steps :p

Convincing others to go upstream is really a big challenge. Normally business will driver this and make this easier.
In any case, I can try to link with others if they have the same idea to get their source upstreamed.

phinexhung · 2023-05-08T03:35:22Z

Hi @oliv3r

I will force push for the changes based on the result of your new MR #12541.

Checking the build log, I found there are some kernel configs from rtl93xx and should be set to n in our rtd1xxx subtarget.

But I cannot duplicate this kind of error locally by issuing "make target/compile" or "make V=s" with subtarget set to rtd129x.

How could I reproduce the error reported by CI ?

BTW, if these kernel configs are only for switch SoCs, should we bind these kernel configs to specific SoC types using dependency rule in Kconfig ?

Run make target/compile -j$(nproc) BUILD_LOG=1 || ret=$? .github/workflows/scripts/show_build_failures.sh
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a build dependency on 'libpam', which does not exist
make[2]: Entering directory '/__w/openwrt/openwrt/openwrt/scripts/config'
make[2]: 'conf' is up to date.
make[2]: Leaving directory '/__w/openwrt/openwrt/openwrt/scripts/config'
 make[1] target/compile
 make[2] -C target/linux compile
    ERROR: target/linux failed to build.
make -r target/compile: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/__w/openwrt/openwrt/openwrt/include/toplevel.mk:231: target/compile] Error 1
====== Make errors from logs/target/linux/compile.txt ======
*
* Multiplexer I2C Chip support
*
GPIO-based I2C arbitration (I2C_ARB_GPIO_CHALLENGE) [N/m/?] n
GPIO-based I2C multiplexer (I2C_MUX_GPIO) [M/n/?] m
General Purpose I2C multiplexer (I2C_MUX_GPMUX) [N/m/?] n
LTC LTC4306/5 I2C multiplexer (I2C_MUX_LTC4306) [N/m/?] n
NXP PCA[9](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:10)541 I2C Master Selector (I2C_MUX_PCA9541) [M/n/?] m
NXP PCA954x and PCA984x I2C Mux/switches (I2C_MUX_PCA954x) [M/n/?] m
Register-based I2C multiplexer (I2C_MUX_REG) [N/m/?] n
RTL9300 based I2C multiplexer (I2C_MUX_RTL9300) [N/m/?] (NEW) make[6]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[5]: *** [Makefile:628: syncconfig] Error 2
make[4]: *** [Makefile:748: include/config/auto.conf.cmd] Error 2
make[3]: *** [Makefile:32: /__w/openwrt/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-realtek_rtd129x/linux-5.15.1[10](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:11)/.modules] Error 2
make[2]: *** [Makefile:[11](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:12): compile] Error 2
time: target/linux/compile#26.34#9.94#31.[17](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:18)
Error: Process completed with exit code 2.

oliv3r · 2023-05-08T07:41:56Z

Hi @oliv3r

I will force push for the changes based on the result of your new MR #12541.

Checking the build log, I found there are some kernel configs from rtl93xx and should be set to n in our rtd1xxx subtarget.

But I cannot duplicate this kind of error locally by issuing "make target/compile" or "make V=s" with subtarget set to rtd129x.

How could I reproduce the error reported by CI ?

BTW, if these kernel configs are only for switch SoCs, should we bind these kernel configs to specific SoC types using dependency rule in Kconfig ?

Run make target/compile -j$(nproc) BUILD_LOG=1 || ret=$? .github/workflows/scripts/show_build_failures.sh
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a build dependency on 'libpam', which does not exist
make[2]: Entering directory '/__w/openwrt/openwrt/openwrt/scripts/config'
make[2]: 'conf' is up to date.
make[2]: Leaving directory '/__w/openwrt/openwrt/openwrt/scripts/config'
 make[1] target/compile
 make[2] -C target/linux compile
    ERROR: target/linux failed to build.
make -r target/compile: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/__w/openwrt/openwrt/openwrt/include/toplevel.mk:231: target/compile] Error 1
====== Make errors from logs/target/linux/compile.txt ======
*
* Multiplexer I2C Chip support
*
GPIO-based I2C arbitration (I2C_ARB_GPIO_CHALLENGE) [N/m/?] n
GPIO-based I2C multiplexer (I2C_MUX_GPIO) [M/n/?] m
General Purpose I2C multiplexer (I2C_MUX_GPMUX) [N/m/?] n
LTC LTC4306/5 I2C multiplexer (I2C_MUX_LTC4306) [N/m/?] n
NXP PCA[9](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:10)541 I2C Master Selector (I2C_MUX_PCA9541) [M/n/?] m
NXP PCA954x and PCA984x I2C Mux/switches (I2C_MUX_PCA954x) [M/n/?] m
Register-based I2C multiplexer (I2C_MUX_REG) [N/m/?] n
RTL9300 based I2C multiplexer (I2C_MUX_RTL9300) [N/m/?] (NEW) make[6]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[5]: *** [Makefile:628: syncconfig] Error 2
make[4]: *** [Makefile:748: include/config/auto.conf.cmd] Error 2
make[3]: *** [Makefile:32: /__w/openwrt/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-realtek_rtd129x/linux-5.15.1[10](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:11)/.modules] Error 2
make[2]: *** [Makefile:[11](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:12): compile] Error 2
time: target/linux/compile#26.34#9.94#31.[17](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:18)
Error: Process completed with exit code 2.

We have individual kconfig's for each target atm, so you should be able to disable them. That RTL9300 driver will go away hopefully soon (I have a replacement) and we'll need some kconfig magic to make all of this work out nicely. (e.g. default y if ARCH_REALTEK_SOC && ARCH_MIPS for example.

I think the CI is failing because it's (for some reason) enabling the rt9300 driver.

phinexhung · 2023-05-08T08:46:20Z

Hi @oliv3r
I will force push for the changes based on the result of your new MR #12541.
Checking the build log, I found there are some kernel configs from rtl93xx and should be set to n in our rtd1xxx subtarget.
But I cannot duplicate this kind of error locally by issuing "make target/compile" or "make V=s" with subtarget set to rtd129x.
How could I reproduce the error reported by CI ?
BTW, if these kernel configs are only for switch SoCs, should we bind these kernel configs to specific SoC types using dependency rule in Kconfig ?

Run make target/compile -j$(nproc) BUILD_LOG=1 || ret=$? .github/workflows/scripts/show_build_failures.sh
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a build dependency on 'libpam', which does not exist
make[2]: Entering directory '/__w/openwrt/openwrt/openwrt/scripts/config'
make[2]: 'conf' is up to date.
make[2]: Leaving directory '/__w/openwrt/openwrt/openwrt/scripts/config'
 make[1] target/compile
 make[2] -C target/linux compile
    ERROR: target/linux failed to build.
make -r target/compile: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/__w/openwrt/openwrt/openwrt/include/toplevel.mk:231: target/compile] Error 1
====== Make errors from logs/target/linux/compile.txt ======
*
* Multiplexer I2C Chip support
*
GPIO-based I2C arbitration (I2C_ARB_GPIO_CHALLENGE) [N/m/?] n
GPIO-based I2C multiplexer (I2C_MUX_GPIO) [M/n/?] m
General Purpose I2C multiplexer (I2C_MUX_GPMUX) [N/m/?] n
LTC LTC4306/5 I2C multiplexer (I2C_MUX_LTC4306) [N/m/?] n
NXP PCA[9](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:10)541 I2C Master Selector (I2C_MUX_PCA9541) [M/n/?] m
NXP PCA954x and PCA984x I2C Mux/switches (I2C_MUX_PCA954x) [M/n/?] m
Register-based I2C multiplexer (I2C_MUX_REG) [N/m/?] n
RTL9300 based I2C multiplexer (I2C_MUX_RTL9300) [N/m/?] (NEW) make[6]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[5]: *** [Makefile:628: syncconfig] Error 2
make[4]: *** [Makefile:748: include/config/auto.conf.cmd] Error 2
make[3]: *** [Makefile:32: /__w/openwrt/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-realtek_rtd129x/linux-5.15.1[10](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:11)/.modules] Error 2
make[2]: *** [Makefile:[11](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:12): compile] Error 2
time: target/linux/compile#26.34#9.94#31.[17](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:18)
Error: Process completed with exit code 2.

We have individual kconfig's for each target atm, so you should be able to disable them. That RTL9300 driver will go away hopefully soon (I have a replacement) and we'll need some kconfig magic to make all of this work out nicely. (e.g. default y if ARCH_REALTEK_SOC && ARCH_MIPS for example.

That's sound great and can solve this issue.

I think the CI is failing because it's (for some reason) enabling the rt9300 driver.

Does this mean that I can just ignore the error currently?

cortex-a55 is a successor to cortex-a53 but with different optimization. Enable compiler specific flag to enable a55 optimization.

Move architecture related options into target.mk within subtarget folder. These subtargets have been used in several NAS products, either using SPI or eMMC as booting media. Signed-off-by: Phinex Hung <phinex@realtek.com>

Support rtd129x, rtd1319 and rtd1619b irq mux driver Signed-off-by: James Tai <james.tai@realtek.com> Signed-off-by: Phinex Hung <phinex@realtek.com>

Update rtd129x.dtsi, rtd1295.dtsi and rtd1296.dtsi as well. The upstream ones are out of date, update these to enable SMP. Add dts files for the following two boards: 1.rtd1295 giraffe eMMC 2GB board 2.rtd1296 saola eMMC 2GB board Signed-off-by: Phinex Hung <phinex@realtek.com>

Also add rtd1319 SoC common dtsi file, which is rtd13xx.dtsi. Signed-off-by: Phinex Hung <phinex@realtek.com>

Add rtd1619b SoC common dtsi file, which contains basic settings. Signed-off-by: Phinex Hung <phinex@realtek.com>

support rtd129x, rtd1319 and rtd1619b with console boot Signed-off-by: Phinex Hung <phinex@realtek.com>

oliv3r · 2023-05-08T15:57:44Z

target/linux/realtek/Makefile

 FEATURES:=ramdisk squashfs
-SUBTARGETS:=rtl838x rtl839x rtl930x rtl931x
+SUBTARGETS:=rtl838x rtl839x rtl930x rtl931x rtd129x rtd1319 rtd1619b


lets keep them sorted; lets put the rtd entries first

Sure. That is good and I will modify this later once your MR is merged.

oliv3r · 2023-05-08T15:57:58Z

target/linux/realtek/Makefile


 KERNEL_PATCHVER:=5.15

 define Target/Description
-	Build firmware images for Realtek RTL83xx based boards.
+	Build firmware images for Realtek Router/NAS boards.


Maybe your name is more generic, since we might cover router, switch and NAS ?

oliv3r · 2023-05-08T15:58:47Z

target/linux/realtek/files-5.15/arch/arm64/boot/dts/realtek/rtd1295-giraffe-emmc-2gb.dts

@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2017-2019 Andreas Färber


Isn't this dts already upstream? I don't think you need to explicitly re-add it here, but I'm not that deep into the openwrt buildsystem.

No, this is for our standard evaluation board. Andrea only commit some COST boards manufactured by our customers, such as: rtd1295-mele-v9.dts, rtd1295-probox2-ava.dts and rtd1295-zidoo-x9s.dts. These files has been upstreamed since kernel 5.8. I just copy the template from these files, so that I keep the author name in this file. The similar condition exists for rtd1296 as well.

Yeah, not sure if copyright works that way, if you wrote it from scratch, its your copyright. If you copied it from andreas, I think you still need your copyright, and then add something like 'based on XXX'. But this is all legalese :p

oliv3r · 2023-05-12T09:19:16Z

Hi @oliv3r
I will force push for the changes based on the result of your new MR #12541.
Checking the build log, I found there are some kernel configs from rtl93xx and should be set to n in our rtd1xxx subtarget.
But I cannot duplicate this kind of error locally by issuing "make target/compile" or "make V=s" with subtarget set to rtd129x.
How could I reproduce the error reported by CI ?
BTW, if these kernel configs are only for switch SoCs, should we bind these kernel configs to specific SoC types using dependency rule in Kconfig ?

Run make target/compile -j$(nproc) BUILD_LOG=1 || ret=$? .github/workflows/scripts/show_build_failures.sh
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a build dependency on 'libpam', which does not exist
make[2]: Entering directory '/__w/openwrt/openwrt/openwrt/scripts/config'
make[2]: 'conf' is up to date.
make[2]: Leaving directory '/__w/openwrt/openwrt/openwrt/scripts/config'
 make[1] target/compile
 make[2] -C target/linux compile
    ERROR: target/linux failed to build.
make -r target/compile: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/__w/openwrt/openwrt/openwrt/include/toplevel.mk:231: target/compile] Error 1
====== Make errors from logs/target/linux/compile.txt ======
*
* Multiplexer I2C Chip support
*
GPIO-based I2C arbitration (I2C_ARB_GPIO_CHALLENGE) [N/m/?] n
GPIO-based I2C multiplexer (I2C_MUX_GPIO) [M/n/?] m
General Purpose I2C multiplexer (I2C_MUX_GPMUX) [N/m/?] n
LTC LTC4306/5 I2C multiplexer (I2C_MUX_LTC4306) [N/m/?] n
NXP PCA[9](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:10)541 I2C Master Selector (I2C_MUX_PCA9541) [M/n/?] m
NXP PCA954x and PCA984x I2C Mux/switches (I2C_MUX_PCA954x) [M/n/?] m
Register-based I2C multiplexer (I2C_MUX_REG) [N/m/?] n
RTL9300 based I2C multiplexer (I2C_MUX_RTL9300) [N/m/?] (NEW) make[6]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[5]: *** [Makefile:628: syncconfig] Error 2
make[4]: *** [Makefile:748: include/config/auto.conf.cmd] Error 2
make[3]: *** [Makefile:32: /__w/openwrt/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-realtek_rtd129x/linux-5.15.1[10](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:11)/.modules] Error 2
make[2]: *** [Makefile:[11](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:12): compile] Error 2
time: target/linux/compile#26.34#9.94#31.[17](https://github.com/openwrt/openwrt/actions/runs/4892559093/jobs/8753803216?pr=12538#step:26:18)
Error: Process completed with exit code 2.

We have individual kconfig's for each target atm, so you should be able to disable them. That RTL9300 driver will go away hopefully soon (I have a replacement) and we'll need some kconfig magic to make all of this work out nicely. (e.g. default y if ARCH_REALTEK_SOC && ARCH_MIPS for example.

That's sound great and can solve this issue.

I think the CI is failing because it's (for some reason) enabling the rt9300 driver.

Does this mean that I can just ignore the error currently?

You should be able to disable the driver via Kconfig magic, which will remove the error yeah. If you enable it to test/try out things, yeah you can ignore those errors.

phinexhung · 2023-05-30T06:15:05Z

Hi @oliv3r

Any progress for your MR, #12541 ?

So that I can try to rebase my MR on yours?

phinexhung mentioned this pull request May 5, 2023

Add Realtek DHC target rtd1xxx and its subtargets #12520

Closed

github-actions bot added build/scripts/tools pull request/issues for build, scripts and tools related changes kernel pull request/issue with Linux kernel related changes target/realtek pull request/issue for realtek target labels May 5, 2023

phinexhung and others added 7 commits May 8, 2023 19:54

include: add support for cortex-a55

f9ada55

cortex-a55 is a successor to cortex-a53 but with different optimization. Enable compiler specific flag to enable a55 optimization.

realtek: kernel: add irq mux driver for Realtek DHC SoCs

9f6b1ff

Support rtd129x, rtd1319 and rtd1619b irq mux driver Signed-off-by: James Tai <james.tai@realtek.com> Signed-off-by: Phinex Hung <phinex@realtek.com>

realtek: image: add 1319 Pymparticles eMMC 2GB board support

a2cf33a

Also add rtd1319 SoC common dtsi file, which is rtd13xx.dtsi. Signed-off-by: Phinex Hung <phinex@realtek.com>

realtek: image: add rtd1619b bleedingedge eMMC 2GB board

6f34459

Add rtd1619b SoC common dtsi file, which contains basic settings. Signed-off-by: Phinex Hung <phinex@realtek.com>

realtek: kernel: config: add default kernel configs for DHC SoCs

8adecca

support rtd129x, rtd1319 and rtd1619b with console boot Signed-off-by: Phinex Hung <phinex@realtek.com>

phinexhung force-pushed the master-realtek branch from 858a06d to 8adecca Compare May 8, 2023 11:55

oliv3r suggested changes May 11, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

realtek: add rtd129x, rtd1319 and rtd1619b sub-targets #12538

realtek: add rtd129x, rtd1319 and rtd1619b sub-targets #12538

phinexhung commented May 5, 2023

musashino205 commented May 5, 2023

phinexhung commented May 5, 2023 •

edited

Hurricos commented May 6, 2023 •

edited

oliv3r commented May 7, 2023

oliv3r commented May 7, 2023

phinexhung commented May 7, 2023

oliv3r commented May 7, 2023

phinexhung commented May 8, 2023

phinexhung commented May 8, 2023 •

edited

oliv3r commented May 8, 2023 •

edited

phinexhung commented May 8, 2023

oliv3r May 8, 2023

phinexhung May 12, 2023

oliv3r May 8, 2023

phinexhung May 12, 2023

oliv3r May 8, 2023

phinexhung May 12, 2023

oliv3r May 12, 2023

oliv3r commented May 12, 2023

phinexhung commented May 30, 2023

realtek: add rtd129x, rtd1319 and rtd1619b sub-targets #12538

Are you sure you want to change the base?

realtek: add rtd129x, rtd1319 and rtd1619b sub-targets #12538

Conversation

phinexhung commented May 5, 2023

musashino205 commented May 5, 2023

phinexhung commented May 5, 2023 • edited

Hurricos commented May 6, 2023 • edited

oliv3r commented May 7, 2023

oliv3r commented May 7, 2023

phinexhung commented May 7, 2023

oliv3r commented May 7, 2023

phinexhung commented May 8, 2023

phinexhung commented May 8, 2023 • edited

oliv3r commented May 8, 2023 • edited

phinexhung commented May 8, 2023

oliv3r May 8, 2023

Choose a reason for hiding this comment

phinexhung May 12, 2023

Choose a reason for hiding this comment

oliv3r May 8, 2023

Choose a reason for hiding this comment

phinexhung May 12, 2023

Choose a reason for hiding this comment

oliv3r May 8, 2023

Choose a reason for hiding this comment

phinexhung May 12, 2023

Choose a reason for hiding this comment

oliv3r May 12, 2023

Choose a reason for hiding this comment

oliv3r commented May 12, 2023

phinexhung commented May 30, 2023

phinexhung commented May 5, 2023 •

edited

Hurricos commented May 6, 2023 •

edited

phinexhung commented May 8, 2023 •

edited

oliv3r commented May 8, 2023 •

edited